Iptables interdire les pays sauf la france

Support Debian
#1

Bonjour,

je cherche a interdire les pays au quel je suis souvent sujet a des attaques, souvent les attaques viennes de pays de l’est mais aussi parfois du coté de l’ouest.
dernier pays qui attaque: Serbie, chine, Pologne, korée, Angleterre, Chicago, Bankok

Pourquoi j’ai ouvert ssh sur tout le web ?
j’ai du ouvrir ssh avec un simple mot de passe utilisateur.
j’ai des utilisateurs retissant à l’utilisation de linux et leur imposer de mettre une cle RSA ou DSA dans leur windows sera plus que périlleux.
ajouter un service FTP est une solution mais je dois faire la demande a l’admin reseaux et justifier mes besoins. (se justifier parfois c’est fatigant)
que vaut il mieux ? restreindre plus SSH et ouvrir un FTP ou interdire les pays par iptables.
root est interdit en ssh
un seul utilisateur est autorisé a se connecter a ssh
au bout de 5 erreurs, l’IP est bannie par fail2ban.

j’ai mit les même règles pour apache sur un htaccess.

savez vous ou trouver les IP a interdire tous les pays sauf la france ?
est il possible de faire un filtre dans /etc/fail2ban/filter.d/ pour ssh:
qui ban une IP dés qu’un utilisateur utilise un compte root ou un compte inexistant sur la machine ?

Jun 16 02:57:18 localhost sshd[25998]: Failed password for invalid user dsi from 46.22.144.135 port 42908 ssh2 Jun 16 02:57:18 localhost sshd[25997]: Failed password for root from 46.22.144.135 port 42903 ssh2 Jun 16 02:57:18 localhost sshd[25992]: Failed password for root from 46.22.144.135 port 42743 ssh2 Jun 16 02:57:19 localhost sshd[26001]: Failed password for root from 46.22.144.135 port 43234 ssh2 Jun 16 02:57:19 localhost sshd[26002]: Failed password for invalid user univ-paris8 from 46.22.144.135 port 43250 ssh2 Jun 16 02:57:20 localhost sshd[26005]: Failed password for root from 46.22.144.135 port 43426 ssh2 Jun 16 02:57:20 localhost sshd[26006]: Failed password for invalid user fr from 46.22.144.135 port 43428 ssh2 Jun 16 02:57:20 localhost sshd[26009]: Failed password for invalid user dsi from 46.22.144.135 port 43562 ssh2 Jun 16 02:57:20 localhost sshd[26010]: Failed password for root from 46.22.144.135 port 43570 ssh2 Jun 16 02:57:21 localhost sshd[26014]: Failed password for root from 46.22.144.135 port 43755 ssh2 Jun 16 02:57:21 localhost sshd[26017]: Failed password for root from 46.22.144.135 port 43891 ssh2 Jun 16 02:57:21 localhost sshd[26018]: Failed password for invalid user univ-paris8 from 46.22.144.135 port 43914 ssh2 Jun 16 03:39:05 localhost sshd[1592]: Failed password for root from 120.203.214.98 port 48271 ssh2 Jun 16 06:08:37 localhost sshd[31628]: Failed password for root from 203.192.198.12 port 54135 ssh2 Jun 16 06:08:40 localhost sshd[31631]: Failed password for root from 203.192.198.12 port 56103 ssh2 Jun 16 10:30:06 localhost sshd[19714]: Failed password for root from 74.208.231.137 port 43551 ssh2 Jun 16 10:30:09 localhost sshd[20112]: Failed password for root from 74.208.231.137 port 43886 ssh2 Jun 16 10:30:12 localhost sshd[20116]: Failed password for root from 74.208.231.137 port 44214 ssh2 Jun 16 10:30:15 localhost sshd[20122]: Failed password for root from 74.208.231.137 port 44482 ssh2 Jun 16 10:30:18 localhost sshd[20124]: Failed password for root from 74.208.231.137 port 44768 ssh2 Jun 16 10:30:21 localhost sshd[20131]: Failed password for root from 74.208.231.137 port 45051 ssh2 Jun 16 13:01:58 localhost sshd[18088]: Failed password for root from 124.224.20.98 port 46713 ssh2 Jun 16 13:02:08 localhost sshd[18091]: Failed password for root from 124.224.20.98 port 49837 ssh2

#2

Hi,

[quote]est il possible de faire un filtre dans /etc/fail2ban/filter.d/ pour ssh:[/quote]Bien sûr, la configuration par défaut est /etc/fail2ban/filter.d/sshd.conf
Il semble que les messages d’erreurs obtenues ne correspondent pas au standard de fail2ban.
Les failregex pourraient être :

Failed password for invalid user (.*) from \[<HOST>\] Failed password for root from \[<HOST>\] (.*)

[quote]au bout de 5 erreurs, l’IP est bannie par fail2ban[/quote]Dés le premier essai, il est possible de bannir une adresse IP avec maxretry = 1 dans /etc/fail2ban/jail.conf (ou jail.custom)

#3

Merci pour la piste Sikkin

j’ai rajouté un filtre pour l’utilisateur root et utilisateurs inexistant

filter.d/ssh-custom.conf

[INCLUDES]

before = common.conf


[Definition]

_daemon = sshd

failregex = Failed none for invalid user root from <HOST> .*
            Invalid user .* from <HOST> 
ignoreregex =

jail.conf

[ssh]

enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 5


[ssh-custom]

enabled = true
port    = ssh
filter  = sshd-custom
logpath  = /var/log/auth.log
maxretry = 1

avec root ou un utilisateur inexistant

[code]
Hi,

The IP xxxxxxxxxxxxx has just been banned by Fail2Ban after
1 attempts against ssh-custom.[/code]

avec un utilisateur réelle

[code]
Hi,

The IP xxxxxxxxxxxxxx has just been banned by Fail2Ban after
5 attempts against ssh.[/code]

on va dire que c’est mieux, je pense que ça peut suffire avec ce filtre au niveau sécurité.

#4

Salut,

Tu peut très bien faire cela via le fichier .htaccess :083

Par ici : countryipblocks.net/country_selection.php

Sélectionnes le(s) pays te posant soucis et tu coches “.htaccess Deny” puis tu lances la création de cette liste, un copier/coller et voilà … 8)

Une idée de mon htaccess … ?

[code] ll .htaccess
-rw-r–r-- 1 root root 3280787 31 mai 15:26 .htaccess

nano -c /…/…/.htaccess

[ ligne 2/126827 (0%), col. 1/1 (100%), car. 26/3280537 (0%) ]
[/code]

Sécurisation d'un serveur web sous apache 2.4 et debian buster
#5

Les fichiers .htaccess ne concernent que le serveur web Apache. Aucun effet pour SSH et autres services.

Par contre il existe des générateurs pour faire exactement ce que demande Tonyx

ipinfodb.com/ip_country_block.php

#6

Salut,

J’ai peut être pô tout bien lu … :033

Bref.

Pareillement. Avec le même lien que j’ai cité ci-haut.

Suffit de sélectionner au format CDIR. :033

[code]# Copyright 2012 Country IP Blocks LLC
#all rights reserved.
#This list may not be redistributed in any form.
#this list includes network data on the following countries:

PAYS

41.77.176.0/21
41.96.0.0/12
41.191.252.0/22
41.200.0.0/15
…[/code]

Ceci dit, iptables se prend (charge) une sacrée louche …

#7

Y’a même des scripts tout prêts à l’emploi

linuxstall.com/block-country-iptables/

(perso je préfère la solution fail2ban)

#8

Tu m’étonnes… Une règle iptables par bloc d’IP c’est violent ! :confused:
Pour charger tout un ensemble d’IPs et vérifier tout d’un coup avec une seule règle iptables, il faut aller voir du côté de ipset. Fonctionnellement ça fait la même chose que des milliers de règles dans iptables, mais c’est incomparablement plus optimisé.

#9

est il possible d’indiquer un fichier texte dans lequel iptables ou/et apache irais chercher la liste des CIDR a autoriser ou interdire sans pourrir la conf et ne pas se retrouver avec 3000 lignes de plus ?

iptables -L --line-numbers sur 3000 lignes mouais

en tout cas merci a tous pour m’avoir aidé sur la sécurité

ipset j’y regarderais a tête reposé plus tard

#10

Salut,

A ta place je chercherais comment accepter la France et deby of all :slightly_smiling:

#11

Avec ipset je crois que ça se fait directement (je t’avouerai que je ne l’ai jamais testé hein, c’est quelqu’un qui en avait parlé sur le forum et j’ai retenu car ça m’avait semblé très intéressant).
Avec juste iptables, c’est pas bien dur d’écrire un script shell qui lit un fichier texte et crée les règles à la volée… D’ailleurs je suis certain qu’un script comme ça traîne déjà sur le forum, y’a plus qu’à le retrouver. :mrgreen:

#12

Salut,

J’avais inclus dans .htaccess quelques pays de l’est particulièrement virulents mais j’ai été oblige de faire marche arrière suite au temps d’attente pour arriver à se connecter.
Quitte à faire une list mieux vaudrait prendre le problème à l’envers et autoriser les CIDR français que ce soit pour iptables ou htaccess.

#13

+1 pour la discrimination positive. Il est plus facile d’interdire toute ip sauf les ip françaises. La liste à consulter est plus courte.

Comme le souligne syam, ipset est effectivement l’outil le plus approprié. A ma connaissance le noyau stable n’est pas compilé avec le support pour ipset. Il faudra passer par module-assistant et les sources d’ipset pour en faire un module. Pas très compliqué, c’est l’affaire de 3 minutes. Il faudra sans doute installer les entêtes de ton noyau pour la compilation du module.

aptitude install module-assistant linux-headers-$(uname -r) ipset ipset-source module-assistant auto-install ipset-source
Pour la règle ipset, choisir le set type nethash et insérer les adresses ip françaises sous la forme CIDR. Un bête script dash/bash/awk de quelques lignes fera l’affaire.

#14

PascalHambourg évidemment!

indesirables-firewall-t37580-25.html#p378693

Je ne suis pas allé plus loin que l’installation faute d’un réel besoin…
Mais ça mériterait un vrai retour et une page dans le Wiki!

#15

Salut,

Mais la solution de Pascal ne m’est pas permise sur ce foutu Synology : Je ne peux pas installer IPSET :mrgreen:

#16

Console-toi, je viens de faire quelques tests grossiers et, à condition que mon protocole de test soit correct, ipset ne semble pas plus rapide qu’iptables.

Protocole: iptables vs ipset sur une grosse liste noire d’adresses CIDR (2800 adresses) avec un REJECT comme target pour pouvoir mesurer le temps de réaction du firewall à renvoyer un icmp-port-unreachable. Sur le poste de test (exclu par la liste noire), un simple$ time ssh <ip_firewall>

Aucune différence notable. Sur le firewall par contre le temps de chargement des “règles” est 3 fois plus rapide avec ipset. En mémoire, ipset semble plus léger (2 Mo de différence) - pour autant que la commande free donne une idée correcte de l’utilisation de la mémoire (rien n’est plus difficile sous Linux de se faire un idée exacte de l’utilisation réelle de la mémoire).

J’ai mis la règle d’exclusion du poste test à la fin ou au début, aucune différence. J’ai un peu l’impression qu’iptables optimise la recherche d’ip, après chargement des règles dans le noyau.

Je sais que mes conclusions vont à l’encontre de ce qu’on dit sur le net mais les résultats sont là. Peut-être que les dernières versions de netfilter/iptables optimisent la recherche d’ip. Si vous avez des idées pour améliorer le test…

#17

Je ne crois pas que ton test soit fiable :

  • 2800 adresses c’est rien du tout
  • tu mesures avec une granularité de l’ordre de la milliseconde alors que le temps de traitement est très certainement inférieur
  • le temps de traitement est complètement noyé dans le temps que mettent les paquets réseau à faire l’aller-retour
  • augmenter sérieusement la taille de la liste noire, mettre le poste de test à la fin
  • envoyer autant de connexions simultanées que tu peux
  • mesurer l’occupation CPU sur le firewall
    Je pense que ça serait déjà un peu plus fiable. Je vais voir si je peux faire un test dans ce genre, je reviens… :wink:
#18

Résultats du test…

J’ai pris l’ensemble des adresses proposées par countryipblocks.net/country_selection.php soit plus de 128000. J’ai déplacé 192.168.0.0/16 (mon réseau) tout à la fin.

iptables : 2.9 secondes de chargement (iptables-restore), règles au format -A INPUT -s -j REJECT
ipset : 7.6 secondes de chargement (ipset restore), une seule règle iptables -A INPUT -m set --match-set TEST src -j REJECT

Depuis un autre poste j’ai floodé avec des pings pour une bande passante totale de 7.9 Mo/s :

Sur le “firewall” (Atom N450 1.66GHz) :

  • iptables se maintient à environ 5 % d’utilisation CPU
  • ipset se maintient à environ 1 % d’utilisation CPU
    Les deux mesures ont été prises avec top, et incluent KDE et SSH qui continuaient de tourner en arrière plan (environ 0.5 % CPU à retrancher des valeurs mesurées).

Bref, mon test semble confirmer qu’ipset est largement plus optimisé (même si le chargement initial est plus long). :wink:
Je n’ai pas cherché à voir l’utilisation mémoire.

#19

D’abord, une petite mise au point : ce n’est pas ma solution, mais juste une piste possible que j’avais mentionnée. Je n’ai moi-même jamais utilisé ipset.

Concernant les résultats de tests de performances, cela s’explique par l’algorithme de recherche utilisé par ipset, plus coûteux à la mise en place mais plus efficace à l’utilisation que le simple parcours séquentiel d’iptables.

Enfin, et peut-être le plus important, il faut garder à l’esprit que ces liste de blocs d’adresses ne sont pas la vérité absolue : elles produiront forcément des faux positifs et des faux négatifs : filiales de boîtes étrangères implantées en France qui ont des adresses “étrangères” et vice versa, blocs alloués à un FAI français mais pas (encore) répertoriées… Même une boîte que je connais n’est pas capable de répertorier complètement toutes les plages d’adresses qu’elle possède, c’est dire…

#20

[quote=“syam”]Résultats du test…
Bref, mon test semble confirmer qu’ipset est largement plus optimisé (même si le chargement initial est plus long). :wink:
Je n’ai pas cherché à voir l’utilisation mémoire.[/quote]
Ce test est intéressant mais incomplet. Il ne mesure pas l’essentiel: en combien de temps netfilter trouve-t-il l’ip bannie et y répond-t-il. C’est ça qu’il faut mesurer. Ta boucle met chaque ping en arrière-plan sans attendre la réponse icmp. Il est donc impossible, avec ton test, de déterminer, côté attaquant, en combien de temps le firewall réagit à ton flood. Tu vas me dire qu’en cas de reject ou de drop ce n’est pas important mais ça l’est dans le cas d’un target accept. Essaye:

time (LOOPS=50; while ((LOOPS--)); do nc <ipCIble> 22; done) Tu peux remplacer netcat par ping, ssh ou ce que tu veux.

Quand je fais ce test, les premiers retours du icmp-port-unreachable sont immédiats, les suivants sont temporisés pour une raison que je ne m’explique pas. Le firewall ne contient que les règles du test. Rien d’autre. En conséquence, les deux méthodes (iptables et ipset) donnent les mêmes résultats sur un fichier d’ip CIDR de 31000 lignes. Il faudrait que je fasse un tcpdump sur les sorties icmp du serveur et en mesure la durée.

Ou alors il faudrait trouver une autre méthodologie pour calculer le temps mis par le firewall pour trouver l’ip filtrée dans ses tables et y répondre. Il faut surveiller l’activité du cpu, d’accord, mais pas en charge uniquement mais plutôt en charge pondérée par la durée.

Je n’aurai plus beaucoup de temps les semaines qui viennent pour poursuivre ces tests mais je passerai pour lire la suite de tes cogitations.