Sur mon petit serveur Linux (Debian 4.0, kernel 2.6.22 de
backports.org), mon firewall utilise le module recent pour zapper les
tentatives répétées de connexion ssh, à raison de 3 connexions par
minutes max:
# internet:ssh (rate-limited 3 connections/min)
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
J'aimerais avoir la même "protection" de mon SSH en IPv6, mais le
module recent ne semble pas exister pour ip6tables. fail2ban ne
fonctionne pas en IPv6 non plus.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Salut,
J'aimerais avoir la même "protection" de mon SSH en IPv6,
La machine subit beaucoup d'attaques SSH en IPv6 ?
mais le module recent ne semble pas exister pour ip6tables.
Les patches pour ajouter le support d'IPv6 dans le noyau et ip6tables (il faut les deux) ont été soumis sur la liste de développement de Netfilter très récemment. Il faudra être patient pour qu'ils arrivent dans les versions stables, sans parler des versions Debian.
fail2ban ne fonctionne pas en IPv6 non plus.
Je connais mal fail2ban, mais si je ne m'abuse il se base sur l'analyse des logs d'échec d'authentification de sshd et l'exécution de commandes paramétrables pour créer les règles iptables. Il n'y a vraiment pas moyen d'adapter ça pour qu'il fonctionne en IPv6 ?
Salut,
J'aimerais avoir la même "protection" de mon SSH en IPv6,
La machine subit beaucoup d'attaques SSH en IPv6 ?
mais le module recent ne semble pas exister pour ip6tables.
Les patches pour ajouter le support d'IPv6 dans le noyau et ip6tables
(il faut les deux) ont été soumis sur la liste de développement de
Netfilter très récemment. Il faudra être patient pour qu'ils arrivent
dans les versions stables, sans parler des versions Debian.
fail2ban ne fonctionne pas en IPv6 non plus.
Je connais mal fail2ban, mais si je ne m'abuse il se base sur l'analyse
des logs d'échec d'authentification de sshd et l'exécution de commandes
paramétrables pour créer les règles iptables. Il n'y a vraiment pas
moyen d'adapter ça pour qu'il fonctionne en IPv6 ?
J'aimerais avoir la même "protection" de mon SSH en IPv6,
La machine subit beaucoup d'attaques SSH en IPv6 ?
mais le module recent ne semble pas exister pour ip6tables.
Les patches pour ajouter le support d'IPv6 dans le noyau et ip6tables (il faut les deux) ont été soumis sur la liste de développement de Netfilter très récemment. Il faudra être patient pour qu'ils arrivent dans les versions stables, sans parler des versions Debian.
fail2ban ne fonctionne pas en IPv6 non plus.
Je connais mal fail2ban, mais si je ne m'abuse il se base sur l'analyse des logs d'échec d'authentification de sshd et l'exécution de commandes paramétrables pour créer les règles iptables. Il n'y a vraiment pas moyen d'adapter ça pour qu'il fonctionne en IPv6 ?
Nicolas KOWALSKI
Pascal Hambourg writes:
Salut,
Hello,
J'aimerais avoir la même "protection" de mon SSH en IPv6,
La machine subit beaucoup d'attaques SSH en IPv6 ?
Non, aucune jusqu'à présent. C'est plus une histoire de curiosité et d'envie de faire propre.
mais le module recent ne semble pas exister pour ip6tables.
Les patches pour ajouter le support d'IPv6 dans le noyau et ip6tables (il faut les deux) ont été soumis sur la liste de développement de Netfilter très récemment. Il faudra être patient pour qu'ils arrivent dans les versions stables, sans parler des versions Debian.
Ok, merci pour l'info.
fail2ban ne fonctionne pas en IPv6 non plus.
Je connais mal fail2ban, mais si je ne m'abuse il se base sur l'analyse des logs d'échec d'authentification de sshd et l'exécution de commandes paramétrables pour créer les règles iptables. Il n'y a vraiment pas moyen d'adapter ça pour qu'il fonctionne en IPv6 ?
Des expressions régulières à adapter ou à créer, oui. Je vais approfondir tout ça.
J'aimerais avoir la même "protection" de mon SSH en IPv6,
La machine subit beaucoup d'attaques SSH en IPv6 ?
Non, aucune jusqu'à présent. C'est plus une histoire de curiosité et
d'envie de faire propre.
mais le module recent ne semble pas exister pour ip6tables.
Les patches pour ajouter le support d'IPv6 dans le noyau et ip6tables
(il faut les deux) ont été soumis sur la liste de développement de
Netfilter très récemment. Il faudra être patient pour qu'ils arrivent
dans les versions stables, sans parler des versions Debian.
Ok, merci pour l'info.
fail2ban ne fonctionne pas en IPv6 non plus.
Je connais mal fail2ban, mais si je ne m'abuse il se base sur
l'analyse des logs d'échec d'authentification de sshd et l'exécution
de commandes paramétrables pour créer les règles iptables. Il n'y a
vraiment pas moyen d'adapter ça pour qu'il fonctionne en IPv6 ?
Des expressions régulières à adapter ou à créer, oui. Je vais
approfondir tout ça.
J'aimerais avoir la même "protection" de mon SSH en IPv6,
La machine subit beaucoup d'attaques SSH en IPv6 ?
Non, aucune jusqu'à présent. C'est plus une histoire de curiosité et d'envie de faire propre.
mais le module recent ne semble pas exister pour ip6tables.
Les patches pour ajouter le support d'IPv6 dans le noyau et ip6tables (il faut les deux) ont été soumis sur la liste de développement de Netfilter très récemment. Il faudra être patient pour qu'ils arrivent dans les versions stables, sans parler des versions Debian.
Ok, merci pour l'info.
fail2ban ne fonctionne pas en IPv6 non plus.
Je connais mal fail2ban, mais si je ne m'abuse il se base sur l'analyse des logs d'échec d'authentification de sshd et l'exécution de commandes paramétrables pour créer les règles iptables. Il n'y a vraiment pas moyen d'adapter ça pour qu'il fonctionne en IPv6 ?
Des expressions régulières à adapter ou à créer, oui. Je vais approfondir tout ça.
Merci Pascal, -- Nicolas
Nicolas KOWALSKI
Pascal Hambourg writes:
(il faut les deux) ont été soumis sur la liste de développement de Netfilter très récemment. Il faudra être patient pour qu'ils arrivent dans les versions stables, sans parler des versions Debian.
En tout cas ce ne sera pas avant Linux 2.6.26 en ce qui concerne le noyau.
C'est bon à savoir.
Je me permets d'ajouter que je n'aime pas trop l'utilisation de la correspondance 'recent' dans un contexte de sécurité, car elle est facile à abuser par usurpation d'adresse source.
Que conseillerais-tu alors pour limiter les attaques en force brute actuelles ?
(il faut les deux) ont été soumis sur la liste de développement de
Netfilter très récemment. Il faudra être patient pour qu'ils arrivent
dans les versions stables, sans parler des versions Debian.
En tout cas ce ne sera pas avant Linux 2.6.26 en ce qui concerne le noyau.
C'est bon à savoir.
Je me permets d'ajouter que je n'aime pas trop l'utilisation de la
correspondance 'recent' dans un contexte de sécurité, car elle est
facile à abuser par usurpation d'adresse source.
Que conseillerais-tu alors pour limiter les attaques en force brute
actuelles ?
(il faut les deux) ont été soumis sur la liste de développement de Netfilter très récemment. Il faudra être patient pour qu'ils arrivent dans les versions stables, sans parler des versions Debian.
En tout cas ce ne sera pas avant Linux 2.6.26 en ce qui concerne le noyau.
C'est bon à savoir.
Je me permets d'ajouter que je n'aime pas trop l'utilisation de la correspondance 'recent' dans un contexte de sécurité, car elle est facile à abuser par usurpation d'adresse source.
Que conseillerais-tu alors pour limiter les attaques en force brute actuelles ?
-- Nicolas
Nicolas KOWALSKI
Pascal Hambourg writes:
Que conseillerais-tu alors pour limiter les attaques en force brute actuelles ?
Les solutions de types fail2ban ou équivalent, qui ont l'avantage de se baser sur de vraies tentatives de login et pas seulement sur des paquets SYN. Ou bien à l'inverse les solutions à base de port-knocking si les clients le permettent, pour autoriser a priori plutôt que bloquer a posteriori.
Bon, il faudra m'armer de patience. C'est sur les "goals" de Lenny selon le BT:
En attendant, mon sshd n'accepte que les connexions par clé publique, et pour certains utilisateurs non-système seulement. Ca limite les risques, et au pire remplira mes logs.
Que conseillerais-tu alors pour limiter les attaques en force brute
actuelles ?
Les solutions de types fail2ban ou équivalent, qui ont l'avantage de
se baser sur de vraies tentatives de login et pas seulement sur des
paquets SYN. Ou bien à l'inverse les solutions à base de port-knocking
si les clients le permettent, pour autoriser a priori plutôt que
bloquer a posteriori.
Bon, il faudra m'armer de patience. C'est sur les "goals" de Lenny
selon le BT:
En attendant, mon sshd n'accepte que les connexions par clé publique,
et pour certains utilisateurs non-système seulement. Ca limite les
risques, et au pire remplira mes logs.
Que conseillerais-tu alors pour limiter les attaques en force brute actuelles ?
Les solutions de types fail2ban ou équivalent, qui ont l'avantage de se baser sur de vraies tentatives de login et pas seulement sur des paquets SYN. Ou bien à l'inverse les solutions à base de port-knocking si les clients le permettent, pour autoriser a priori plutôt que bloquer a posteriori.
Bon, il faudra m'armer de patience. C'est sur les "goals" de Lenny selon le BT:
En attendant, mon sshd n'accepte que les connexions par clé publique, et pour certains utilisateurs non-système seulement. Ca limite les risques, et au pire remplira mes logs.
