[Linux + iptables] Blocage des IP faisant de nombreuses tentatives sur SSH

Le
Gerard Menvussa
Bonjour.

Pour éviter d'avoir des rapports logwatch qui n'en finissent pas. J'ai
mis en place deux règles dans mon firewall pour utiliser le module
"recent" contre les attaques en force brute sur SSH. Cela donne ceci :

iptables -A INPUT -p tcp --syn --dport 22 -m recent --update --seconds
300 --hitcount 2 --name SSH -j DROP

iptables -A INPUT -p tcp --syn --dport 22 -m recent --set --name SSH -j
ACCEPT

La première ligne contrôle la présence d'une adresse dans la liste, met
à jour la date et le compteur associé et drop si l'adresse est déjà
apparue il y a moins de 5 minutes et à deux reprise.
La seconde note l'adresse d'une demande de connexion sur le port SSH

Je teste cette configuration depuis quelques mois. Cela donne de bon
résultats et je ne me suis jamais retrouvé à la porte de mon serveur
jusqu'à présent ;-) (je touche du bois)

J'aimerais avoir votre avis sur cette technique et savoir si vous
connaissez une façon plus intelligente et efficace de bloquer les
adresses qui tentent des attaques de ce type.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Yannick Palanque
Le #890697
Bonjour,

2007-12-03T22:24:55GMT, Gerard Menvussa
Pour éviter d'avoir des rapports logwatch qui n'en finissent pas.
J'ai mis en place deux règles dans mon firewall pour utiliser le
module "recent" contre les attaques en force brute sur SSH. Cela
donne ceci :


N'étant pas trop copain avec iptables, j'ai installé fail2ban.
Ça a l'air de donner le même résultat, je ne retrouve plus qu'au
maximum 2 à 3 tentatives de connexion par IP.
Après les classiques
admin/password: 1 time
guest/password: 1 time
test/password: 1 time
ou autres du même genre, pouf.

--
« Quand je serai grand, je ferai des bug reports sur la LKML »
-- Octane in fcolm

JOORIS Emmanuel
Le #890696
Bonjour,

2007-12-03T22:24:55GMT, Gerard Menvussa
Pour éviter d'avoir des rapports logwatch qui n'en finissent pas.
J'ai mis en place deux règles dans mon firewall pour utiliser le
module "recent" contre les attaques en force brute sur SSH. Cela
donne ceci :


N'étant pas trop copain avec iptables, j'ai installé fail2ban.
Ça a l'air de donner le même résultat, je ne retrouve plus qu'au
maximum 2 à 3 tentatives de connexion par IP.
Après les classiques
admin/password: 1 time
guest/password: 1 time
test/password: 1 time
ou autres du même genre, pouf.



juste une petite question, avec fail2ban, y a t'il moyen de ban
directement une adresse ip si elle tente de ce connecter sur un user
dont le nom peut etre choisis ?


gerbier
Le #890695
JOORIS Emmanuel wrote:
Bonjour,



juste une petite question, avec fail2ban, y a t'il moyen de ban
directement une adresse ip si elle tente de ce connecter sur un user
dont le nom peut etre choisis ?


oui, parce que fail2ban cherche un motif dans les log. il te faut juste
modifier la configuration par défaut.


Malcom
Le #890694
Bonjour,

je suis ne connais pas non plus le module recent, mais j'ai une petite
question : le drop d'iptables est il définitif ou recent permet il de
n'effectuer ce drop que pour une durée donnée (30mn par exemple) ?

Si c'est définitif, je serais personnellement assez mitigé sur cette
technique qui t'expose à des attaques de type IP spoofing. L'attaquant
voyant qu'il est automatiquement bloqué, peut s'amuser à spoofer
l'adresse IP de ton serveur DNS et de ton serveur mail, juste histoire
de plonger dans le noir... Et si tu utilises une adresse IP fixe,
pourquoi pas la tienne ?...

Personnellement j'utilise un HIDS absolument formidable (oui je sais
je m'emballe, mais bon il est vraiment sympa !) c'est OSSEC.
Il te permet de blacklister automatiquement les attaquants (pas
seulement les SSH brute force) selon de nombreux critères et cela pour
une durée de 30 mn par défaut.

Bien sur, encore une fois, je ne connais pas recent et peut être le
fait il également ?

Cordialement,
Cédric.
Bonjour.

Pour �viter d'avoir des rapports logwatch qui n'en finissent pas. J'ai
mis en place deux r�gles dans mon firewall pour utiliser le module
"recent" contre les attaques en force brute sur SSH. Cela donne ceci :

iptables -A INPUT -p tcp --syn --dport 22 -m recent --update --seconds
300 --hitcount 2 --name SSH -j DROP

iptables -A INPUT -p tcp --syn --dport 22 -m recent --set --name SSH -j
ACCEPT

La premi�re ligne contr�le la pr�sence d'une adresse dans la liste, met
� jour la date et le compteur associ� et drop si l'adresse est d�j�
apparue il y a moins de 5 minutes et � deux reprise.
La seconde note l'adresse d'une demande de connexion sur le port SSH

Je teste cette configuration depuis quelques mois. Cela donne de bon
r�sultats et je ne me suis jamais retrouv� � la porte de mon serveur
jusqu'� pr�sent ;-) (je touche du bois)

J'aimerais avoir votre avis sur cette technique et savoir si vous
connaissez une fa�on plus intelligente et efficace de bloquer les
adresses qui tentent des attaques de ce type.


Fabien LE LEZ
Le #890693
On 05 Dec 2007 23:59:32 GMT, Malcom
Si c'est définitif, je serais personnellement assez mitigé sur cette
technique qui t'expose à des attaques de type IP spoofing. L'attaquant
voyant qu'il est automatiquement bloqué, peut s'amuser à spoofer
l'adresse IP de ton serveur DNS et de ton serveur mail, juste histoire
de plonger dans le noir... Et si tu utilises une adresse IP fixe,
pourquoi pas la tienne ?...


L'argument vaut tout aussi bien s'il n'est pas définitif.
Par exemple, si le blacklistage dure 10 minutes, il suffit de
renouveler l'attaque toutes les dix minutes pour bloquer
définitivemnet l'IP en question.
Le même raisonnement vaut pour n'importe quel délai.

Gerard Menvussa
Le #890692
Bonjour,

2007-12-03T22:24:55GMT, Gerard Menvussa
Pour éviter d'avoir des rapports logwatch qui n'en finissent pas.
J'ai mis en place deux règles dans mon firewall pour utiliser le
module "recent" contre les attaques en force brute sur SSH. Cela
donne ceci :


N'étant pas trop copain avec iptables, j'ai installé fail2ban.
Ça a l'air de donner le même résultat, je ne retrouve plus qu'au
maximum 2 à 3 tentatives de connexion par IP.
Après les classiques
admin/password: 1 time
guest/password: 1 time
test/password: 1 time
ou autres du même genre, pouf.


Merci. M'en vais jeter un oeil à ça.


Malcom
Le #888728
On 6 déc, 01:59, Fabien LE LEZ
On 05 Dec 2007 23:59:32 GMT, Malcom
Si c'est définitif, je serais personnellement assez mitigé sur cette
technique qui t'expose à des attaques de type IP spoofing. L'attaquant
voyant qu'il est automatiquement bloqué, peut s'amuser à spoofer
l'adresse IP de ton serveur DNS et de ton serveur mail, juste histoire
de plonger dans le noir... Et si tu utilises une adresse IP fixe,
pourquoi pas la tienne ?...


L'argument vaut tout aussi bien s'il n'est pas définitif.
Par exemple, si le blacklistage dure 10 minutes, il suffit de
renouveler l'attaque toutes les dix minutes pour bloquer
définitivemnet l'IP en question.
Le même raisonnement vaut pour n'importe quel délai.


Pas tout à fait à mon avis. En effet, les outils automatisés de crack
n'inclut pas ce type de tempo, or ils représentent la très grande
majorité des attaques sur le Net. La tempo ne peut être génante que
dans le cas d'attaques très ciblées, réalisées par des pirates
connaissant la valeur de cette tempo. Sans faire disparaître la menace
(ce qui est impossible sauf à se déconnecter et à s'enfermer dans un
bunker avec une cage de faraday) on contribue donc à la réduire ! :-)


Pascal Hambourg
Le #888727
Salut,


je suis ne connais pas non plus le module recent, mais j'ai une petite
question : le drop d'iptables est il définitif ou recent permet il de
n'effectuer ce drop que pour une durée donnée (30mn par exemple) ?


Ce n'est pas une mise en liste noire, c'est une condition basée en temps
réel sur des événements passés : par exemple si on a reçu plus de 2
paquets de la même adresse durant les 5 dernières minutes.

Si c'est définitif, je serais personnellement assez mitigé sur cette
technique qui t'expose à des attaques de type IP spoofing.


Et même si c'est temporaire, voir la réponse de Fabien.

L'attaquant
voyant qu'il est automatiquement bloqué, peut s'amuser à spoofer
l'adresse IP de ton serveur DNS et de ton serveur mail, juste histoire
de plonger dans le noir...


Il y a peu de chances que ces serveurs aient besoin de se connecter en
SSH sur sa machine. :-)

Et si tu utilises une adresse IP fixe, pourquoi pas la tienne ?...


En effet. Toutefois la correspondance 'recent' a une option pour
différencier les sources non seulement par leur adresse mais aussi par
le TTL des paquets, afin de contrer le spoofing. Cependant cela peut
être exploité par un attaquant pour échapper au bloquage : il lui suffit
de faire varier son TTL initial à chaque tentative de connexion.

Une parade contre le spoofing consisterait peut-être à ne pas se baser
sur le SYN mais sur le premier ACK du client renvoyé en réponse au
SYN/ACK du serveur. Pour distinguer le premier ACK des suivants, on
pourrait utiliser le marquage de connexion avec la cible CONNMARK et la
correspondance 'connmark'.

Au chapitre des faiblesses de 'recent' on peut ajouter que sa mémoire
n'est pas illimitée et ne peut retenir qu'un certain nombre de
d'adresses par table, les plus anciennes étant oubliées, écrasées au
profit des nouvelles. La valeur par défaut est 100. Là encore, un
attaquant pourra se faire oublier en bourrant la table avec des adresses
spoofées avant de recommencer son attaque.

Bref, le blocage par la correspondance 'recent' peut suffire contre les
attaques automatiques des robots, mais pas contre un attaquant déterminé
qui peut le contourner même en abuser pour provoquer un déni de service.

Pascal Hambourg
Le #888726
On 6 déc, 01:59, Fabien LE LEZ
Si c'est définitif, je serais personnellement assez mitigé sur cette
technique qui t'expose à des attaques de type IP spoofing. [...]


L'argument vaut tout aussi bien s'il n'est pas définitif.
Par exemple, si le blacklistage dure 10 minutes, il suffit de
renouveler l'attaque toutes les dix minutes pour bloquer
définitivemnet l'IP en question.
Le même raisonnement vaut pour n'importe quel délai.


Pas tout à fait à mon avis. En effet, les outils automatisés de crack
n'inclut pas ce type de tempo, or ils représentent la très grande
majorité des attaques sur le Net.


Les outils automatisés de crack ne font pas de spoofing, leur but est
d'entrer dans le système, pas de provoquer un DoS. Le délai importe peu
dans la mesure où l'adresse source est très rapidement bloquée après
quelques tentatives de connexion.

La tempo ne peut être génante que
dans le cas d'attaques très ciblées, réalisées par des pirates
connaissant la valeur de cette tempo.


Gênante pour qui, l'attaquant ou la victime ?
Dans le cas d'une attaque ciblée par spoofing pour réaliser un DoS de
l'adresse usurpée, il suffit d'envoyer des paquets en continu à un
intervalle réduit de l'ordre de la minute, ce qui représente une charge
minime, pour maintenir le DoS en permanence. Donc ici encore le délai de
blocage importe peu.



Eric Razny
Le #888725
Le Thu, 06 Dec 2007 11:35:40 +0000, Pascal Hambourg a écrit :

Les outils automatisés de crack ne font pas de spoofing, leur but est
d'entrer dans le système, pas de provoquer un DoS. Le délai importe peu
dans la mesure où l'adresse source est très rapidement bloquée après
quelques tentatives de connexion.


De toute façon avec les piles IP actuelles il faut quand même se lever
de très bonne heure pour faire un spoofing pour entrer dans le système
(pas de DOS) en dehors du LAN (où d'un lieu où on peut sniffer les
réponses)

Gênante pour qui, l'attaquant ou la victime ?
Dans le cas d'une attaque ciblée par spoofing pour réaliser un DoS de
l'adresse usurpée, il suffit d'envoyer des paquets en continu à un
intervalle réduit de l'ordre de la minute, ce qui représente une charge
minime, pour maintenir le DoS en permanence. Donc ici encore le délai de
blocage importe peu.


D'où pour des service type ssh, il peut être interressant de laisser
passer systématiquement les paquets "valides" en provenance d'une adresse
IP (celle d'où on administre habituellement). Des outils comme fail2ban
qui se basent sur les logs (échec de connexion ssh par exemple) plutôt
que sur le nombre de SYN arrivant (pour du TCP bien sur) sont
interressant dans ce contexte

Eric

Publicité
Poster une réponse
Anonyme