[Linux + iptables] Blocage des IP faisant de nombreuses tentatives sur SSH
12 réponses
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
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.
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
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
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
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 ?
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 ?
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
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.
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.
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
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
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.
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
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.
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
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
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.
On 05 Dec 2007 23:59:32 GMT, Malcom <cedric.thibault@gmail.com>:
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.
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
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.
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.
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
On 6 déc, 01:59, Fabien LE LEZ wrote:
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 ! :-)
On 6 déc, 01:59, Fabien LE LEZ <grams...@gramster.com> wrote:
On 05 Dec 2007 23:59:32 GMT, Malcom <cedric.thiba...@gmail.com>:
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 ! :-)
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
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.
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.
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
On 6 déc, 01:59, Fabien LE LEZ wrote:
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.
On 6 déc, 01:59, Fabien LE LEZ <grams...@gramster.com> wrote:
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.
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 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
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
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
