[netfilter] limiter les attaques SSH par dictionnaire

Le
Sébastien Kirche
Bonsoir,

sur la pauvre passerelle de mon pauvre petit domaine, je retrouve dans
les logs plusieurs centaines de fois par jour les traces de scripts
kiddies qui tentent d'accéder à mon système en utilisant un dictionnaire
de logins SSH.

Niveau sécurité c'est sans importance puisque que j'ai supprimé la
possibilité d'accès SSH par mot de passe en ne conservant que
l'utilisation de clé privée.

Seulement sshd trace quand même chaque tentative dans /var/log/auth.log.

Pour le seul problème de log j'aurais pu diminuer le LogLevel mais vu
que ma passerelle est motorisée par une SparcStation20 bi-75MHz (ouaouh
la puissance !) je souhaite également limiter le gaspillage de cpu
qu'occasionne chaque tentative de login surtout quand c'est en rafale.

J'ai trouvé DenyHosts qui trace la fréquence des logins SSH et en cas
d'abus ajoute l'émetteur dans /etc/hosts.deny, seulement je n'aime pas
trop l'idée d'une modification automatique d'un fichier système.

J'ai pensé que Netfilter devait pouvoir suffire et j'ai rajouté les
règles suivantes à ma config existante (extrait d'iptables-save) :

-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource

-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 --name DEFAULT --rsource -j REJECT --reject-with icmp-port-unreachable

Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait
j'utilise la target DROP mais dans le cas présent j'ai utilisé REJECT
qui permet de ne pas devoir attendre un timeout pour la négociation SSH

Que pensez-vous de tout ça ?
--
Sébastien Kirche
Vos réponses Page 1 / 4
Trier par : date / pertinence
Emmanuel Florac
Le #1723777
Le Tue, 07 Mar 2006 22:46:22 +0100, Sébastien Kirche a écrit :


Que pensez-vous de tout ça ?


j'ai un script perl qui fait la même chose...

--
L'église est une secte qui a réussi.
Ernest Renan.

Sébastien Monbrun aka TiChou
Le #1723776
Dans le message *Sébastien Kirche* tapota sur f.c.o.l.configuration :

Salut Sébastien,

j'ai rajouté les règles suivantes à ma config existante (extrait
d'iptables-save) :

-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --set --name DEFAULT --rsource

-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --update --seconds 60 --hitcount 2 --name DEFAULT --rsource -j
REJECT --reject-with icmp-port-unreachable

Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait
j'utilise la target DROP


Ce n'est pas l'idéal, mais tout dépend des règles en question. Un REJECT est
souvent bien plus propre qu'un DROP. Et pour éviter les dénis de service de
type flood, on peut alors envisager d'utiliser le match limit.

mais dans le cas présent j'ai utilisé REJECT qui permet de ne pas devoir
attendre un timeout pour la négociation SSH...


Bien. Sauf qu'il serait préférable de renvoyer un TCP RST étant donné qu'il
s'agit ici d'une connexion TCP :

... -j REJECT --reject-with tcp-reset

--
Sébastien Monbrun aka TiChou

Sébastien Kirche
Le #1723775
Le 7 March 2006 à 22:59, Sébastien Monbrun aka TiChou vraute :

Pour beaucoup de mes règles netfilter, quand je refuse un paquet en
fait j'utilise la target DROP


Ce n'est pas l'idéal, mais tout dépend des règles en question. Un
REJECT est souvent bien plus propre qu'un DROP. Et pour éviter les
dénis de service de type flood, on peut alors envisager d'utiliser le
match limit.


Pas tellement de cas détaillés en fait, en dehors du filtrage de
quelques windowseries, les paquets n'ayant pas fait l'objet d'une
acception explicite (paquet en réponse à un paquet sortant du lan,
protocoles entrants acceptés comme SSH, SMTP,...) sont droppés.

falbala:~# iptables-save |grep DROP
:INPUT DROP [1:48]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A allowed -p tcp -j DROP
-A bad_tcp_packets -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A udp_packets -i eth0 -p udp -m udp --dport 135:139 -j DROP
-A udp_packets -d 255.255.255.255 -i eth0 -p udp -m udp --dport 67:68 -j DROP

Je peux mettre en ligne iptables-save en entier et le script de départ
si ça t'intéresse. Tu parles plus le netfilter couramment que moi ;o)

mais dans le cas présent j'ai utilisé REJECT qui permet de ne pas
devoir attendre un timeout pour la négociation SSH...


Bien. Sauf qu'il serait préférable de renvoyer un TCP RST étant donné
qu'il s'agit ici d'une connexion TCP :

... -j REJECT --reject-with tcp-reset


C'est corrigé. En fait c'est une idée que j'ai reprise où initialement
les paquets étaient droppés. J'avais remplacé DROP par REJECT par contre
le --reject-with icmp-port-unreachable doit être rajouté par défaut par
netfilter pour les -j REJECT qui ne précisent rien ? Ce n'était pas
précisé dans mon script.

Merci des conseils.
--
Sébastien Kirche


Sébastien Kirche
Le #1723774
Le 7 March 2006 à 22:56, Emmanuel Florac vraute :

Que pensez-vous de tout ça ?


j'ai un script perl qui fait la même chose...


...que DenyHosts, ou que la solution netfilter avec ipt_recent + rejet
des paquets ?
--
Sébastien Kirche


gerbier
Le #1723770
Sébastien Kirche wrote:
Bonsoir,

sur la pauvre passerelle de mon pauvre petit domaine, je retrouve dans
les logs plusieurs centaines de fois par jour les traces de scripts
kiddies qui tentent d'accéder à mon système en utilisant un dictionnaire
de logins SSH.

Niveau sécurité c'est sans importance puisque que j'ai supprimé la
possibilité d'accès SSH par mot de passe en ne conservant que
l'utilisation de clé privée.

Seulement sshd trace quand même chaque tentative dans /var/log/auth.log.

Pour le seul problème de log j'aurais pu diminuer le LogLevel mais vu
que ma passerelle est motorisée par une SparcStation20 bi-75MHz (ouaouh
la puissance !) je souhaite également limiter le gaspillage de cpu
qu'occasionne chaque tentative de login surtout quand c'est en rafale.

J'ai trouvé DenyHosts qui trace la fréquence des logins SSH et en cas
d'abus ajoute l'émetteur dans /etc/hosts.deny, seulement je n'aime pas
trop l'idée d'une modification automatique d'un fichier système.

J'ai pensé que Netfilter devait pouvoir suffire et j'ai rajouté les
règles suivantes à ma config existante (extrait d'iptables-save) :

-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource

-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 --name DEFAULT --rsource -j REJECT --reject-with icmp-port-unreachable

Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait
j'utilise la target DROP mais dans le cas présent j'ai utilisé REJECT
qui permet de ne pas devoir attendre un timeout pour la négociation SSH...

Que pensez-vous de tout ça ?


j'utiliserais le logiciel failban (en python):

Fail2Ban scans log files like /var/log/pwdfail and bans IP
that makes too many password failures. It updates firewall
rules to reject the IP address. These rules can be defined by
the user. Fail2Ban can read multiple log files such as sshd
or Apache web server ones.

l'avantage, c'est que l'effet n'est que temporaire, ce qui bloque les
rafales d'attaques.

Emmanuel Florac
Le #1723568
Le Tue, 07 Mar 2006 23:25:52 +0100, Sébastien Kirche a écrit :


...que DenyHosts, ou que la solution netfilter avec ipt_recent + rejet des
paquets ?


il interdit avec iptables les IP qui ont 3 tentatives de connexion
échouée. J'en ai 2 ou 3 par jour, en moyenne, et je supprime les
enregistrements de plus d'un mois :)

--
Writing about music is like dancing about architecture.
Frank Zappa

Sébastien Kirche
Le #1733958
Le 8 March 2006 à 14:54, Sébastien Monbrun aka TiChou vraute :

Dans un soucis de transparence (la sécurité par l'obscurantisme
n'existe pas), de respect des normes (RFC), de courtoisie (répondre
poliment à une connexion erronée) et de confort (répondre au lieu de
faire attendre inutilement ; timeout), un firewall avec une bonne
politique devrait répondre à ces deux principes :

- Ne devraient être bloqués/ignorés (DROP) que les paquets dont l'état
est INVALID, dont l'adresse est usurpée ou dont le type est
suspicieux.
- Devraient être rejetés (REJECT), avec le bon message (TCP RST pour
TCP, ICMP port unreachable pour UDP, ICMP protocol unreachable pour un
protocole autre, ...), les paquets dont l'état est valide (! INVALID) mais
qu'on ne veut pas accepter.


Je pense que je vais passer en revue ma config netfilter. Ça me
permettra certainement de mettre un coup de balai dans mon script de
configuration. Et je vais en profiter pour corriger le cas des paquets
ignorés.

Enfin, comme je le sous-entendais précédemment, pour limiter les
attaques qui pourraient conduire à un trafic montant important, on
peut utiliser le match limit d'iptables afin de limiter le nombre de
REJECT émis.


J'ai du temps en ce moment. Je vais en profiter pour me replonger dans
iptables, son utilisation n'est pas toujours évidente pour moi.

--
Sébastien Kirche

Nicolas George
Le #1733955
Sébastien Monbrun aka TiChou wrote in message
avec le bon message (TCP RST pour
TCP


Ce n'est pas clair. Si mes souvenirs sont bons, TCP RST est à comprendre
comme « port fermé ». ICMP port unreachable est une réponse tout à fait
valide pour indiquer explicitement que le port est interdit par un firewall.
D'ailleurs, nmap affiche des résultats différents : filtered ou closed.

PS : Je viens de remarquer qu'il y avait un soucis sur le reverse de ton
adresse IP at home :


Je crois que les DNS de Proxad ont des vapeurs depuis ce matin.

Sébastien Monbrun aka TiChou
Le #1733952
Dans le message *Nicolas George* tapota sur f.c.o.l.configuration :

Ce n'est pas clair. Si mes souvenirs sont bons, TCP RST est à comprendre
comme « port fermé ». ICMP port unreachable est une réponse tout à fait
valide pour indiquer explicitement que le port est interdit par un
firewall. D'ailleurs, nmap affiche des résultats différents : filtered ou
closed.


Oui, tu as raison. La question est alors de savoir si le firewall doit
présenter un port comme fermé ou comme interdit.

--
Sébastien Monbrun aka TiChou

Sébastien Monbrun aka TiChou
Le #1733950
Attention, fu2 sur la hiérarchie proxad.*

Dans le message *Nicolas George* tapota sur f.c.o.l.configuration :

PS : Je viens de remarquer qu'il y avait un soucis sur le reverse de ton
adresse IP at home :


Je crois que les DNS de Proxad ont des vapeurs depuis ce matin.


Effectivement, les serveurs DNS de Free en charge des reverses des adresses
IP de leurs clients (ns2-rev.proxad.net et ns3-rev.proxad.net) répondent 2
enregistrements PTR pour chacune des adresses IP se trouvant dans la classe
81.56.128.0/17.

Exemple :

$ dig +short -x 81.56.128.1
lns-vlq-39f-81-56-128-1.adsl.proxad.net.
lns-bzn-51f-81-56-128-1.adsl.proxad.net.

$ dig +short -x 81.56.192.1
lns-th2-5f-81-56-192-1.adsl.proxad.net.
lns-bzn-50f-81-56-192-1.adsl.proxad.net.

$ dig +short -x 81.56.224.1
lns-bzn-50f-81-56-224-1.adsl.proxad.net.
lns-th2-5f-81-56-224-1.adsl.proxad.net.

$ dig +short -x 81.56.255.1
lns-bzn-47f-81-56-255-1.adsl.proxad.net.
lns-th2-4f-81-56-255-1.adsl.proxad.net.

Espérons que cela soit passager, car j'en connais qui rencontrent déjà des
problèmes avec leur serveur mail.

fu2 proxad.free.services

--
Sébastien Monbrun aka TiChou


Publicité
Poster une réponse
Anonyme