J'ai une petite machine sous linux Suse 10.3 avec SuFirewall2
Je subis depuis plus de 24 heures des tentatives de connexion en ssh.
Visiblement l'attaquant se cache derrière des IP forgées.
Il y a un essai toutes les 2 à 3 minutes avec un login différent à chaque
fois mais dont le nom croît en ordre alphabétique.
Normalement je bannis pour une heure les IP qui ont plus de trois connexions
infructeuses mais dans ce cas, cela ne marche pas.
Y aurait-il un moyen de détecter l'IP réelle de l'attaquant ???
Avec un blacklistage d'1 heure pour chaque IP ayant 3 echecs, bon courage deja rien que pour trouver le username.
Sauf que si le botnet dispose de suffisament d'ip, le blacklistage ne sert à rien.
D'après les logs que l'on peut trouver sur le net en recherchant certaines des IP indiquées, non seulement il dispose d'un bon parc d'adresses IP, mais en plus il ne va pas jusqu'au trois tentatives.
Un blacklistage de quelques minutes valable pour toutes les ip serait peut-être une solution (avec si besoin des plages spécifiques en white-list).
Dans l'un de mes messages précédent j'ai pointé un fichier denyssh.host qui contient entre autres un bon nombre[1] des adresses IP de ce botnet. Bloquer toutes ces adresses au moins pour deux ou trois jours serait encore plus efficace.
[1] Je ne suis pas non plus allé les comparer une à une hein.
Jean-Marc Desperrier n'était pas loin de dire :
Avec un blacklistage d'1 heure pour chaque IP ayant 3 echecs, bon
courage deja rien que pour trouver le username.
Sauf que si le botnet dispose de suffisament d'ip, le blacklistage ne
sert à rien.
D'après les logs que l'on peut trouver sur le net en recherchant
certaines des IP indiquées, non seulement il dispose d'un bon parc
d'adresses IP, mais en plus il ne va pas jusqu'au trois tentatives.
Un blacklistage de quelques minutes valable pour toutes les ip serait
peut-être une solution (avec si besoin des plages spécifiques en
white-list).
Dans l'un de mes messages précédent j'ai pointé un fichier
denyssh.host qui contient entre autres un bon nombre[1] des adresses IP
de ce botnet. Bloquer toutes ces adresses au moins pour deux ou trois
jours serait encore plus efficace.
[1]
Je ne suis pas non plus allé les comparer une à une hein.
Avec un blacklistage d'1 heure pour chaque IP ayant 3 echecs, bon courage deja rien que pour trouver le username.
Sauf que si le botnet dispose de suffisament d'ip, le blacklistage ne sert à rien.
D'après les logs que l'on peut trouver sur le net en recherchant certaines des IP indiquées, non seulement il dispose d'un bon parc d'adresses IP, mais en plus il ne va pas jusqu'au trois tentatives.
Un blacklistage de quelques minutes valable pour toutes les ip serait peut-être une solution (avec si besoin des plages spécifiques en white-list).
Dans l'un de mes messages précédent j'ai pointé un fichier denyssh.host qui contient entre autres un bon nombre[1] des adresses IP de ce botnet. Bloquer toutes ces adresses au moins pour deux ou trois jours serait encore plus efficace.
[1] Je ne suis pas non plus allé les comparer une à une hein.
EPiKoiEncore
Bonjour à tous
Je me permets de m'immiscer dans votre discussion car je me demandais s'il était possible de s'abonner (au niveau du serveur ssh) à des listes d'ip blacklistées un peu comme dans postfix avec les rbl spamcop ou mail-abuse Les hosts.deny me semblent un peu figés face à la volatilité des IP.
P.S. Pour le blacklistage, j'ai mis 86400 secondes, cela devrait calmer ;-) Mais je suis loin d'être un expert en sécurité comme vous tous, quand je vois ce que vous écrivez ...
Merci Alain
"Stephane Catteau" a écrit dans le message de news:
Jean-Marc Desperrier n'était pas loin de dire :
Avec un blacklistage d'1 heure pour chaque IP ayant 3 echecs, bon courage deja rien que pour trouver le username.
Sauf que si le botnet dispose de suffisament d'ip, le blacklistage ne sert à rien.
D'après les logs que l'on peut trouver sur le net en recherchant certaines des IP indiquées, non seulement il dispose d'un bon parc d'adresses IP, mais en plus il ne va pas jusqu'au trois tentatives.
Un blacklistage de quelques minutes valable pour toutes les ip serait peut-être une solution (avec si besoin des plages spécifiques en white-list).
Dans l'un de mes messages précédent j'ai pointé un fichier denyssh.host qui contient entre autres un bon nombre[1] des adresses IP de ce botnet. Bloquer toutes ces adresses au moins pour deux ou trois jours serait encore plus efficace.
[1] Je ne suis pas non plus allé les comparer une à une hein.
Bonjour à tous
Je me permets de m'immiscer dans votre discussion car je me demandais s'il
était possible de s'abonner (au niveau du serveur ssh) à des listes d'ip
blacklistées un peu comme dans postfix avec les rbl spamcop ou mail-abuse
Les hosts.deny me semblent un peu figés face à la volatilité des IP.
P.S.
Pour le blacklistage, j'ai mis 86400 secondes, cela devrait calmer ;-)
Mais je suis loin d'être un expert en sécurité comme vous tous, quand je
vois ce que vous écrivez ...
Merci
Alain
"Stephane Catteau" <steph.nospam@sc4x.net> a écrit dans le message de news:
mn.53227d9c7b217cd1.30736@sc4x.org...
Jean-Marc Desperrier n'était pas loin de dire :
Avec un blacklistage d'1 heure pour chaque IP ayant 3 echecs, bon
courage deja rien que pour trouver le username.
Sauf que si le botnet dispose de suffisament d'ip, le blacklistage ne
sert à rien.
D'après les logs que l'on peut trouver sur le net en recherchant
certaines des IP indiquées, non seulement il dispose d'un bon parc
d'adresses IP, mais en plus il ne va pas jusqu'au trois tentatives.
Un blacklistage de quelques minutes valable pour toutes les ip serait
peut-être une solution (avec si besoin des plages spécifiques en
white-list).
Dans l'un de mes messages précédent j'ai pointé un fichier
denyssh.host qui contient entre autres un bon nombre[1] des adresses IP
de ce botnet. Bloquer toutes ces adresses au moins pour deux ou trois
jours serait encore plus efficace.
[1]
Je ne suis pas non plus allé les comparer une à une hein.
Je me permets de m'immiscer dans votre discussion car je me demandais s'il était possible de s'abonner (au niveau du serveur ssh) à des listes d'ip blacklistées un peu comme dans postfix avec les rbl spamcop ou mail-abuse Les hosts.deny me semblent un peu figés face à la volatilité des IP.
P.S. Pour le blacklistage, j'ai mis 86400 secondes, cela devrait calmer ;-) Mais je suis loin d'être un expert en sécurité comme vous tous, quand je vois ce que vous écrivez ...
Merci Alain
"Stephane Catteau" a écrit dans le message de news:
Jean-Marc Desperrier n'était pas loin de dire :
Avec un blacklistage d'1 heure pour chaque IP ayant 3 echecs, bon courage deja rien que pour trouver le username.
Sauf que si le botnet dispose de suffisament d'ip, le blacklistage ne sert à rien.
D'après les logs que l'on peut trouver sur le net en recherchant certaines des IP indiquées, non seulement il dispose d'un bon parc d'adresses IP, mais en plus il ne va pas jusqu'au trois tentatives.
Un blacklistage de quelques minutes valable pour toutes les ip serait peut-être une solution (avec si besoin des plages spécifiques en white-list).
Dans l'un de mes messages précédent j'ai pointé un fichier denyssh.host qui contient entre autres un bon nombre[1] des adresses IP de ce botnet. Bloquer toutes ces adresses au moins pour deux ou trois jours serait encore plus efficace.
[1] Je ne suis pas non plus allé les comparer une à une hein.
fx [François-Xavier Peretmere]
on the 10/12/2009 15:09 EPiKoiEncore wrote the following:
Bonjour à tous
Je me permets de m'immiscer dans votre discussion car je me demandais s'il était possible de s'abonner (au niveau du serveur ssh) à des listes d'ip blacklistées un peu comme dans postfix avec les rbl spamcop ou mail-abuse Les hosts.deny me semblent un peu figés face à la volatilité des IP.
http://denyhosts.sourceforge.net/ ?
Ps : merci de répondre en dessous du message original.
-- Fx
on the 10/12/2009 15:09 EPiKoiEncore wrote the following:
Bonjour à tous
Je me permets de m'immiscer dans votre discussion car je me demandais s'il
était possible de s'abonner (au niveau du serveur ssh) à des listes d'ip
blacklistées un peu comme dans postfix avec les rbl spamcop ou mail-abuse
Les hosts.deny me semblent un peu figés face à la volatilité des IP.
http://denyhosts.sourceforge.net/ ?
Ps : merci de répondre en dessous du message original.
on the 10/12/2009 15:09 EPiKoiEncore wrote the following:
Bonjour à tous
Je me permets de m'immiscer dans votre discussion car je me demandais s'il était possible de s'abonner (au niveau du serveur ssh) à des listes d'ip blacklistées un peu comme dans postfix avec les rbl spamcop ou mail-abuse Les hosts.deny me semblent un peu figés face à la volatilité des IP.
http://denyhosts.sourceforge.net/ ?
Ps : merci de répondre en dessous du message original.
-- Fx
Jean-Marc Desperrier
Jean-Marc Desperrier wrote:
Un blacklistage de quelques minutes valable pour toutes les ip serait peut-être une solution (avec si besoin des plages spécifiques en white-list).
En fait, ça ne marche pas du tout ce genre de solution.
Le bot, s'il est obstiné et attaque en force, dérobe systématiquement le "slot" de connexion à l'utilisateur légitime car il rebloque instantanément le système pour plusieurs minutes dès qu'il se débloque et le système apparaît donc comme constamment bloqué.
Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On drop tout par défaut. - L'utilisateur légitime se connecte à un port secret, qui est lui aussi droppé - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut se connecter sans drop au port légitime et envoyer ses identifiants - si l'ip se connecte à un autre port que le bon pendant les 30 secondes, cela ferme la fenêtre - il faut voir les numéros des deux ports juste comme un pré-filtrage qui évite d'encombrer les log et le CPU en gérant trop de tentatives de connexions rejetées.
Jean-Marc Desperrier wrote:
Un blacklistage de quelques minutes valable pour toutes les ip serait
peut-être une solution (avec si besoin des plages spécifiques en
white-list).
En fait, ça ne marche pas du tout ce genre de solution.
Le bot, s'il est obstiné et attaque en force, dérobe systématiquement le
"slot" de connexion à l'utilisateur légitime car il rebloque
instantanément le système pour plusieurs minutes dès qu'il se débloque
et le système apparaît donc comme constamment bloqué.
Une autre méthode efficace serait peut-être d'utiliser 2 ports :
- On drop tout par défaut.
- L'utilisateur légitime se connecte à un port secret, qui est lui aussi
droppé
- Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut
se connecter sans drop au port légitime et envoyer ses identifiants
- si l'ip se connecte à un autre port que le bon pendant les 30
secondes, cela ferme la fenêtre
- il faut voir les numéros des deux ports juste comme un pré-filtrage
qui évite d'encombrer les log et le CPU en gérant trop de tentatives de
connexions rejetées.
Un blacklistage de quelques minutes valable pour toutes les ip serait peut-être une solution (avec si besoin des plages spécifiques en white-list).
En fait, ça ne marche pas du tout ce genre de solution.
Le bot, s'il est obstiné et attaque en force, dérobe systématiquement le "slot" de connexion à l'utilisateur légitime car il rebloque instantanément le système pour plusieurs minutes dès qu'il se débloque et le système apparaît donc comme constamment bloqué.
Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On drop tout par défaut. - L'utilisateur légitime se connecte à un port secret, qui est lui aussi droppé - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut se connecter sans drop au port légitime et envoyer ses identifiants - si l'ip se connecte à un autre port que le bon pendant les 30 secondes, cela ferme la fenêtre - il faut voir les numéros des deux ports juste comme un pré-filtrage qui évite d'encombrer les log et le CPU en gérant trop de tentatives de connexions rejetées.
Stephane Catteau
Jean-Marc Desperrier n'était pas loin de dire :
Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On drop tout par défaut. - L'utilisateur légitime se connecte à un port secret, qui est lui aussi droppé - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut se connecter sans drop au port légitime et envoyer ses identifiants
Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate voulant absolument rentrer sur la machine fera un scan de port systématique avec analyse du service qui répond, or une telle personne finirait de toute façon par comprendre ton mécanisme d'ouverture de fenêtre. Du coup, autant demander directement à SSH d'écouter sur cet autre port (2222 par exemple) et le problème est réglé. Si c'est un bot il croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai pirate bah ça ne changera de toute façon pas grand chose aux données du problème. Par contre ça limitera les risques d'effets de bord négatif.
Jean-Marc Desperrier n'était pas loin de dire :
Une autre méthode efficace serait peut-être d'utiliser 2 ports :
- On drop tout par défaut.
- L'utilisateur légitime se connecte à un port secret, qui est lui aussi
droppé
- Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut
se connecter sans drop au port légitime et envoyer ses identifiants
Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate
voulant absolument rentrer sur la machine fera un scan de port
systématique avec analyse du service qui répond, or une telle personne
finirait de toute façon par comprendre ton mécanisme d'ouverture de
fenêtre.
Du coup, autant demander directement à SSH d'écouter sur cet autre
port (2222 par exemple) et le problème est réglé. Si c'est un bot il
croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai
pirate bah ça ne changera de toute façon pas grand chose aux données du
problème. Par contre ça limitera les risques d'effets de bord négatif.
Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On drop tout par défaut. - L'utilisateur légitime se connecte à un port secret, qui est lui aussi droppé - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut se connecter sans drop au port légitime et envoyer ses identifiants
Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate voulant absolument rentrer sur la machine fera un scan de port systématique avec analyse du service qui répond, or une telle personne finirait de toute façon par comprendre ton mécanisme d'ouverture de fenêtre. Du coup, autant demander directement à SSH d'écouter sur cet autre port (2222 par exemple) et le problème est réglé. Si c'est un bot il croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai pirate bah ça ne changera de toute façon pas grand chose aux données du problème. Par contre ça limitera les risques d'effets de bord négatif.
EPiKoiEncore
""fx [François-Xavier Peretmere]"" a écrit dans le message de news: 4b21492a$
Les hosts.deny me semblent un peu figés face à la volatilité des IP.
http://denyhosts.sourceforge.net/ ?
Ha que merci que j'y vais de ce pas !!
Ps : merci de répondre en dessous du message original.
Oups ! Serais-je devenu un gougnafier ? Je vous l'dis mon bon Monsieur : tout fout l'camp ;-)
Désolé et merci de cette petite claque sur mes fesses plus très roses
""fx [François-Xavier Peretmere]"" <fx@terra.fr> a écrit dans le message de
news: 4b21492a$1@ac-versailles.fr...
Les hosts.deny me semblent un peu figés face à la volatilité des IP.
http://denyhosts.sourceforge.net/ ?
Ha que merci que j'y vais de ce pas !!
Ps : merci de répondre en dessous du message original.
Oups !
Serais-je devenu un gougnafier ?
Je vous l'dis mon bon Monsieur : tout fout l'camp ;-)
Désolé et merci de cette petite claque sur mes fesses plus très roses
""fx [François-Xavier Peretmere]"" a écrit dans le message de news: 4b21492a$
Les hosts.deny me semblent un peu figés face à la volatilité des IP.
http://denyhosts.sourceforge.net/ ?
Ha que merci que j'y vais de ce pas !!
Ps : merci de répondre en dessous du message original.
Oups ! Serais-je devenu un gougnafier ? Je vous l'dis mon bon Monsieur : tout fout l'camp ;-)
Désolé et merci de cette petite claque sur mes fesses plus très roses
Netsurfeur
Jean-Marc Desperrier a écrit :
Jean-Marc Desperrier wrote: Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On drop tout par défaut. - L'utilisateur légitime se connecte à un port secret, qui est lui aussi droppé - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut se connecter sans drop au port légitime et envoyer ses identifiants - si l'ip se connecte à un autre port que le bon pendant les 30 secondes, cela ferme la fenêtre - il faut voir les numéros des deux ports juste comme un pré-filtrage qui évite d'encombrer les log et le CPU en gérant trop de tentatives de connexions rejetées.
La technique existe, c'est le "port knocking" (http://fr.wikipedia.org/wiki/Port_knocking). En utilisant une séquence de plusieurs ports, ça résiste bien au simple scan. Une description pour Ubuntu (mais pouvant être adaptée pour d'autres Linux) : http://doc.ubuntu-fr.org/port-knocking
-- Netsurfeur
Jean-Marc Desperrier a écrit :
Jean-Marc Desperrier wrote:
Une autre méthode efficace serait peut-être d'utiliser 2 ports :
- On drop tout par défaut.
- L'utilisateur légitime se connecte à un port secret, qui est lui aussi
droppé
- Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut
se connecter sans drop au port légitime et envoyer ses identifiants
- si l'ip se connecte à un autre port que le bon pendant les 30
secondes, cela ferme la fenêtre
- il faut voir les numéros des deux ports juste comme un pré-filtrage
qui évite d'encombrer les log et le CPU en gérant trop de tentatives de
connexions rejetées.
La technique existe, c'est le "port knocking"
(http://fr.wikipedia.org/wiki/Port_knocking).
En utilisant une séquence de plusieurs ports, ça résiste bien au simple
scan. Une description pour Ubuntu (mais pouvant être adaptée pour
d'autres Linux) : http://doc.ubuntu-fr.org/port-knocking
Jean-Marc Desperrier wrote: Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On drop tout par défaut. - L'utilisateur légitime se connecte à un port secret, qui est lui aussi droppé - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut se connecter sans drop au port légitime et envoyer ses identifiants - si l'ip se connecte à un autre port que le bon pendant les 30 secondes, cela ferme la fenêtre - il faut voir les numéros des deux ports juste comme un pré-filtrage qui évite d'encombrer les log et le CPU en gérant trop de tentatives de connexions rejetées.
La technique existe, c'est le "port knocking" (http://fr.wikipedia.org/wiki/Port_knocking). En utilisant une séquence de plusieurs ports, ça résiste bien au simple scan. Une description pour Ubuntu (mais pouvant être adaptée pour d'autres Linux) : http://doc.ubuntu-fr.org/port-knocking
-- Netsurfeur
Eric Razny
Bonjour.
Le Fri, 11 Dec 2009 11:38:57 +0100, Stephane Catteau a écrit :
Jean-Marc Desperrier n'était pas loin de dire :
Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On drop tout par défaut. - L'utilisateur légitime se connecte à un port secret, qui est lui aussi droppé - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut se connecter sans drop au port légitime et envoyer ses identifiants
le port knocking fonctionne bien mais il vaut mieux une succession de plusieurs port dans un ordre précis (le même port pouvant être utilisé plusieurs fois ;)
Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate voulant absolument rentrer sur la machine fera un scan de port systématique avec analyse du service qui répond, or une telle personne finirait de toute façon par comprendre ton mécanisme d'ouverture de fenêtre.
Si tu paramètre correctement ton port-knocking j'en doute!
Du coup, autant demander directement à SSH d'écouter sur cet autre port (2222 par exemple) et le problème est réglé. Si c'est un bot il croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai pirate bah ça ne changera de toute façon pas grand chose aux données du problème. Par contre ça limitera les risques d'effets de bord négatif.
pour les logs mettre ssh ailleurs que sur le 22/TCP c'est clairement mieux. Par contre les deux solutions présentées ici ont le même défaut qui peut être rédhibitoire : en "extérieur" certains opérateurs ne laissent passer que certains ports, assez souvent 22 à ma grande joie d'ailleurs, mais en en bloquent d'autre. Quand tu as besoin de ton ssh le changement de port n'est pas la panacée en ce cas.
Eric
Bonjour.
Le Fri, 11 Dec 2009 11:38:57 +0100, Stephane Catteau a écrit :
Jean-Marc Desperrier n'était pas loin de dire :
Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On
drop tout par défaut.
- L'utilisateur légitime se connecte à un port secret, qui est lui
aussi droppé
- Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut
se connecter sans drop au port légitime et envoyer ses identifiants
le port knocking fonctionne bien mais il vaut mieux une succession de
plusieurs port dans un ordre précis (le même port pouvant être utilisé
plusieurs fois ;)
Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate
voulant absolument rentrer sur la machine fera un scan de port
systématique avec analyse du service qui répond, or une telle personne
finirait de toute façon par comprendre ton mécanisme d'ouverture de
fenêtre.
Si tu paramètre correctement ton port-knocking j'en doute!
Du coup, autant demander directement à SSH d'écouter sur cet autre
port (2222 par exemple) et le problème est réglé. Si c'est un bot il
croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai
pirate bah ça ne changera de toute façon pas grand chose aux données du
problème. Par contre ça limitera les risques d'effets de bord négatif.
pour les logs mettre ssh ailleurs que sur le 22/TCP c'est clairement
mieux. Par contre les deux solutions présentées ici ont le même défaut
qui peut être rédhibitoire : en "extérieur" certains opérateurs ne
laissent passer que certains ports, assez souvent 22 à ma grande joie
d'ailleurs, mais en en bloquent d'autre. Quand tu as besoin de ton ssh le
changement de port n'est pas la panacée en ce cas.
Le Fri, 11 Dec 2009 11:38:57 +0100, Stephane Catteau a écrit :
Jean-Marc Desperrier n'était pas loin de dire :
Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On drop tout par défaut. - L'utilisateur légitime se connecte à un port secret, qui est lui aussi droppé - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut se connecter sans drop au port légitime et envoyer ses identifiants
le port knocking fonctionne bien mais il vaut mieux une succession de plusieurs port dans un ordre précis (le même port pouvant être utilisé plusieurs fois ;)
Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate voulant absolument rentrer sur la machine fera un scan de port systématique avec analyse du service qui répond, or une telle personne finirait de toute façon par comprendre ton mécanisme d'ouverture de fenêtre.
Si tu paramètre correctement ton port-knocking j'en doute!
Du coup, autant demander directement à SSH d'écouter sur cet autre port (2222 par exemple) et le problème est réglé. Si c'est un bot il croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai pirate bah ça ne changera de toute façon pas grand chose aux données du problème. Par contre ça limitera les risques d'effets de bord négatif.
pour les logs mettre ssh ailleurs que sur le 22/TCP c'est clairement mieux. Par contre les deux solutions présentées ici ont le même défaut qui peut être rédhibitoire : en "extérieur" certains opérateurs ne laissent passer que certains ports, assez souvent 22 à ma grande joie d'ailleurs, mais en en bloquent d'autre. Quand tu as besoin de ton ssh le changement de port n'est pas la panacée en ce cas.
Eric
Eric Razny
Bonjour.
Le Fri, 11 Dec 2009 11:38:57 +0100, Stephane Catteau a écrit :
Jean-Marc Desperrier n'était pas loin de dire :
Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On drop tout par défaut. - L'utilisateur légitime se connecte à un port secret, qui est lui aussi droppé - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut se connecter sans drop au port légitime et envoyer ses identifiants
le port knocking fonctionne bien mais il vaut mieux une succession de plusieurs port dans un ordre précis (le même port pouvant être utilisé plusieurs fois ;)
Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate voulant absolument rentrer sur la machine fera un scan de port systématique avec analyse du service qui répond, or une telle personne finirait de toute façon par comprendre ton mécanisme d'ouverture de fenêtre.
Si tu paramètre correctement ton port-knocking j'en doute!
Du coup, autant demander directement à SSH d'écouter sur cet autre port (2222 par exemple) et le problème est réglé. Si c'est un bot il croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai pirate bah ça ne changera de toute façon pas grand chose aux données du problème. Par contre ça limitera les risques d'effets de bord négatif.
pour les logs mettre ssh ailleurs que sur le 22/TCP c'est clairement mieux. Par contre les deux solutions présentées ici ont le même défaut qui peut être rédhibitoire : en "extérieur" certains opérateurs ne laissent passer que certains ports, assez souvent 22 à ma grande joie d'ailleurs, mais en en bloquent d'autre. Quand tu as besoin de ton ssh le changement de port n'est pas la panacée en ce cas.
Eric
Bonjour.
Le Fri, 11 Dec 2009 11:38:57 +0100, Stephane Catteau a écrit :
Jean-Marc Desperrier n'était pas loin de dire :
Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On
drop tout par défaut.
- L'utilisateur légitime se connecte à un port secret, qui est lui
aussi droppé
- Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut
se connecter sans drop au port légitime et envoyer ses identifiants
le port knocking fonctionne bien mais il vaut mieux une succession de
plusieurs port dans un ordre précis (le même port pouvant être utilisé
plusieurs fois ;)
Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate
voulant absolument rentrer sur la machine fera un scan de port
systématique avec analyse du service qui répond, or une telle personne
finirait de toute façon par comprendre ton mécanisme d'ouverture de
fenêtre.
Si tu paramètre correctement ton port-knocking j'en doute!
Du coup, autant demander directement à SSH d'écouter sur cet autre
port (2222 par exemple) et le problème est réglé. Si c'est un bot il
croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai
pirate bah ça ne changera de toute façon pas grand chose aux données du
problème. Par contre ça limitera les risques d'effets de bord négatif.
pour les logs mettre ssh ailleurs que sur le 22/TCP c'est clairement
mieux. Par contre les deux solutions présentées ici ont le même défaut
qui peut être rédhibitoire : en "extérieur" certains opérateurs ne
laissent passer que certains ports, assez souvent 22 à ma grande joie
d'ailleurs, mais en en bloquent d'autre. Quand tu as besoin de ton ssh le
changement de port n'est pas la panacée en ce cas.
Le Fri, 11 Dec 2009 11:38:57 +0100, Stephane Catteau a écrit :
Jean-Marc Desperrier n'était pas loin de dire :
Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On drop tout par défaut. - L'utilisateur légitime se connecte à un port secret, qui est lui aussi droppé - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut se connecter sans drop au port légitime et envoyer ses identifiants
le port knocking fonctionne bien mais il vaut mieux une succession de plusieurs port dans un ordre précis (le même port pouvant être utilisé plusieurs fois ;)
Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate voulant absolument rentrer sur la machine fera un scan de port systématique avec analyse du service qui répond, or une telle personne finirait de toute façon par comprendre ton mécanisme d'ouverture de fenêtre.
Si tu paramètre correctement ton port-knocking j'en doute!
Du coup, autant demander directement à SSH d'écouter sur cet autre port (2222 par exemple) et le problème est réglé. Si c'est un bot il croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai pirate bah ça ne changera de toute façon pas grand chose aux données du problème. Par contre ça limitera les risques d'effets de bord négatif.
pour les logs mettre ssh ailleurs que sur le 22/TCP c'est clairement mieux. Par contre les deux solutions présentées ici ont le même défaut qui peut être rédhibitoire : en "extérieur" certains opérateurs ne laissent passer que certains ports, assez souvent 22 à ma grande joie d'ailleurs, mais en en bloquent d'autre. Quand tu as besoin de ton ssh le changement de port n'est pas la panacée en ce cas.
Eric
bruno.treguier_at_shom.fr
Le 09/12/2009 à 12:51, Xavier Roche a écrit :
EPiKoiEncore a écrit :
Visiblement l'attaquant se cache derrière des IP forgées.
Forgées ou IP de proxy ouverts ? Je n'ai jamais vu de ma vie une seule attaque avec une "IP forgée" (l'IP spoofing est plus du domaine de la légende urbaine que de la réalité, mis à part quelques curiosités d'attaques par UDP ou ICMP)
Bonjour,
L'IP spoofing est tout sauf une légende urbaine, c'est d'ailleurs cette technique (entre autres) qui a été utilisée par Kevin Mitnick lors de sa célèbre attaque contre les ordinateurs de Tsutomu Shimomura (usurpation IP + SYN flooding + prédiction des numéros de séquence TCP). Elle a même été plus ou moins automatisée par la suite (par d'autres, Mitnick ayant été arrêté entre-temps).
Cela dit, outre le fait que déjà, à l'époque (fin 1994), très peu de gens étaient capables de mettre en oeuvre une telle attaque (et encore moins de la comprendre ;-) ), de nombreuses améliorations ont depuis été apportées aux piles TCP/IP, (meilleure randomisation des numéros de séquence TCP et implémentation des SYN cookies, notamment), ce qui la rend encore plus difficile à mener désormais.
Aujourd'hui, l'usurpation IP est donc effectivement, à mon avis, plutôt une attaque "épouvantail" qu'autre chose (dans la mesure où la dangerosité perçue en est très exagérée, étant donné le nombre de pré-requis qu'elle impose) mais elle a bel et bien été réalisée.
Par ailleurs, il n'est pas totalement exclu que la découverte d'une ou plusieurs autre(s) faille(s) protocolaire(s) la remette "en selle" un de ces jours, même si cela reste actuellement du domaine du très improbable.
Bruno
Le 09/12/2009 à 12:51, Xavier Roche a écrit :
EPiKoiEncore a écrit :
Visiblement l'attaquant se cache derrière des IP forgées.
Forgées ou IP de proxy ouverts ? Je n'ai jamais vu de ma vie une seule
attaque avec une "IP forgée" (l'IP spoofing est plus du domaine de la
légende urbaine que de la réalité, mis à part quelques curiosités
d'attaques par UDP ou ICMP)
Bonjour,
L'IP spoofing est tout sauf une légende urbaine, c'est d'ailleurs cette
technique (entre autres) qui a été utilisée par Kevin Mitnick lors de sa
célèbre attaque contre les ordinateurs de Tsutomu Shimomura (usurpation
IP + SYN flooding + prédiction des numéros de séquence TCP). Elle a même
été plus ou moins automatisée par la suite (par d'autres, Mitnick ayant
été arrêté entre-temps).
Cela dit, outre le fait que déjà, à l'époque (fin 1994), très peu de
gens étaient capables de mettre en oeuvre une telle attaque (et encore
moins de la comprendre ;-) ), de nombreuses améliorations ont depuis été
apportées aux piles TCP/IP, (meilleure randomisation des numéros de
séquence TCP et implémentation des SYN cookies, notamment), ce qui la
rend encore plus difficile à mener désormais.
Aujourd'hui, l'usurpation IP est donc effectivement, à mon avis, plutôt
une attaque "épouvantail" qu'autre chose (dans la mesure où la
dangerosité perçue en est très exagérée, étant donné le nombre de
pré-requis qu'elle impose) mais elle a bel et bien été réalisée.
Par ailleurs, il n'est pas totalement exclu que la découverte d'une ou
plusieurs autre(s) faille(s) protocolaire(s) la remette "en selle" un de
ces jours, même si cela reste actuellement du domaine du très improbable.
Visiblement l'attaquant se cache derrière des IP forgées.
Forgées ou IP de proxy ouverts ? Je n'ai jamais vu de ma vie une seule attaque avec une "IP forgée" (l'IP spoofing est plus du domaine de la légende urbaine que de la réalité, mis à part quelques curiosités d'attaques par UDP ou ICMP)
Bonjour,
L'IP spoofing est tout sauf une légende urbaine, c'est d'ailleurs cette technique (entre autres) qui a été utilisée par Kevin Mitnick lors de sa célèbre attaque contre les ordinateurs de Tsutomu Shimomura (usurpation IP + SYN flooding + prédiction des numéros de séquence TCP). Elle a même été plus ou moins automatisée par la suite (par d'autres, Mitnick ayant été arrêté entre-temps).
Cela dit, outre le fait que déjà, à l'époque (fin 1994), très peu de gens étaient capables de mettre en oeuvre une telle attaque (et encore moins de la comprendre ;-) ), de nombreuses améliorations ont depuis été apportées aux piles TCP/IP, (meilleure randomisation des numéros de séquence TCP et implémentation des SYN cookies, notamment), ce qui la rend encore plus difficile à mener désormais.
Aujourd'hui, l'usurpation IP est donc effectivement, à mon avis, plutôt une attaque "épouvantail" qu'autre chose (dans la mesure où la dangerosité perçue en est très exagérée, étant donné le nombre de pré-requis qu'elle impose) mais elle a bel et bien été réalisée.
Par ailleurs, il n'est pas totalement exclu que la découverte d'une ou plusieurs autre(s) faille(s) protocolaire(s) la remette "en selle" un de ces jours, même si cela reste actuellement du domaine du très improbable.
