Mes logs affichent souvent des tentatives de connexion par ssh avec des
identifiants communs comme root, test, guest, etc., et comme mot de
passe « password » ou le même mot que l'identifiant (test:test, etc.).
Bien sûr, ces tentatives sont vaines. Je me demandais cependant ce que
pourrait entraîner, pour la machine intrusive et la machine « attaquée »
la mauvaise blague suivante :
-- créer un compte « test » et lui donner comme mot de passe «
password » ;
-- lui donner comme shell de connexion /usr/bin/yes.
Cela créerait-il une faille ? J'imagine que si /usr/bin/yes en a une,
elle peut-être exploitable, mais je ne vois pas trop comment on pourrait
interagir avec cette application voire passer à un autre shell à partir
de /usr/bin/yes.
> >Je vais dire un truc con, mais pourquoi pas utiliser un truc comme > >fail2ban qui bannit les gens après X tentatives de connexions > >ratées en moins de N minutes ? > > C'est une solution, à étudier soigneusement avant mise en place pour > éviter le risque de DoS.
Tu peux me dire comment s'effectue le DoS stp ? Parce que si c'est une attaque sur un port avec un mauvais login/pwd ET en utilisant une asdresse IP qui va être utilisée par quelqu'un de « normal »... Il en faut des attaques (ce qui est réalisable, je sais).
Suffit d'attendre le 29 fevrier pour fail2ban
Le 24 Jun 2008 07:09:28 GMT,
jenaipasdemail@mamado3o.com.invalid (Benoit) a écrit :
> >Je vais dire un truc con, mais pourquoi pas utiliser un truc comme
> >fail2ban qui bannit les gens après X tentatives de connexions
> >ratées en moins de N minutes ?
>
> C'est une solution, à étudier soigneusement avant mise en place pour
> éviter le risque de DoS.
Tu peux me dire comment s'effectue le DoS stp ? Parce que si c'est
une attaque sur un port avec un mauvais login/pwd ET en utilisant une
asdresse IP qui va être utilisée par quelqu'un de « normal »... Il en
faut des attaques (ce qui est réalisable, je sais).
> >Je vais dire un truc con, mais pourquoi pas utiliser un truc comme > >fail2ban qui bannit les gens après X tentatives de connexions > >ratées en moins de N minutes ? > > C'est une solution, à étudier soigneusement avant mise en place pour > éviter le risque de DoS.
Tu peux me dire comment s'effectue le DoS stp ? Parce que si c'est une attaque sur un port avec un mauvais login/pwd ET en utilisant une asdresse IP qui va être utilisée par quelqu'un de « normal »... Il en faut des attaques (ce qui est réalisable, je sais).
Suffit d'attendre le 29 fevrier pour fail2ban
Vincent Ramos
mpg wrote:
Si je ne m'abuse, une passerelle qui bloque la quasi-totalité des ports rend le port-knocking inopérant.
Je vais dire un truc con, mais pourquoi pas utiliser un truc comme fail2ban qui bannit les gens après X tentatives de connexions ratées en moins de N minutes ?
J'utilise déjà. Ma question était surtout théorique.
mpg wrote:
Si je ne m'abuse, une passerelle qui bloque la quasi-totalité des
ports rend le port-knocking inopérant.
Je vais dire un truc con, mais pourquoi pas utiliser un truc comme
fail2ban qui bannit les gens après X tentatives de connexions ratées en
moins de N minutes ?
J'utilise déjà. Ma question était surtout théorique.
Si je ne m'abuse, une passerelle qui bloque la quasi-totalité des ports rend le port-knocking inopérant.
Je vais dire un truc con, mais pourquoi pas utiliser un truc comme fail2ban qui bannit les gens après X tentatives de connexions ratées en moins de N minutes ?
J'utilise déjà. Ma question était surtout théorique.
mpg
Le (on) mardi 24 juin 2008 23:14, Patrick Lamaiziere a écrit (wrote) :
Tu peux me dire comment s'effectue le DoS stp ? Parce que si c'est une attaque sur un port avec un mauvais login/pwd ET en utilisant une asdresse IP qui va être utilisée par quelqu'un de « normal »... Il en faut des attaques (ce qui est réalisable, je sais).
Suffit d'attendre le 29 fevrier pour fail2ban
Tout comme il suffisait d'étudier les mises à jour du paquet openssl de Debian à une époque : on est à l'abri de rien avec aucun outil. Notons quand même qu'un 29 février avec fail2ban n'est pas particulièrement pire qu'un autre jour sans fail2ban :-)
Manuel.
Le (on) mardi 24 juin 2008 23:14, Patrick Lamaiziere a écrit (wrote) :
Tu peux me dire comment s'effectue le DoS stp ? Parce que si c'est
une attaque sur un port avec un mauvais login/pwd ET en utilisant une
asdresse IP qui va être utilisée par quelqu'un de « normal »... Il en
faut des attaques (ce qui est réalisable, je sais).
Suffit d'attendre le 29 fevrier pour fail2ban
Tout comme il suffisait d'étudier les mises à jour du paquet openssl de
Debian à une époque : on est à l'abri de rien avec aucun outil. Notons
quand même qu'un 29 février avec fail2ban n'est pas particulièrement pire
qu'un autre jour sans fail2ban :-)
Le (on) mardi 24 juin 2008 23:14, Patrick Lamaiziere a écrit (wrote) :
Tu peux me dire comment s'effectue le DoS stp ? Parce que si c'est une attaque sur un port avec un mauvais login/pwd ET en utilisant une asdresse IP qui va être utilisée par quelqu'un de « normal »... Il en faut des attaques (ce qui est réalisable, je sais).
Suffit d'attendre le 29 fevrier pour fail2ban
Tout comme il suffisait d'étudier les mises à jour du paquet openssl de Debian à une époque : on est à l'abri de rien avec aucun outil. Notons quand même qu'un 29 février avec fail2ban n'est pas particulièrement pire qu'un autre jour sans fail2ban :-)
Manuel.
mpg
Le (on) mardi 24 juin 2008 17:42, Stephane Catteau a écrit (wrote) :
2) Une règle globale traitera le reste des cas de figure, pour être sûr de ne pas en oublier.
Dans la conf de fail2ban, c'est plutôt le contraire : il n'y a pas de cas par défaut, juste des cas spécifiques par service.
A partir de là, il suffit d'envoyer une vague massive de paquets UDP en forgeant l'adresse émetrice, et en cinq minutes on bloque une classe C.
Une question que je me pose est la suivante. fail2ban fonctionne en fait en regardant les entrées produites par sshd dans les log (je prend le cas de ssh, je ne connais pas pour le reste). Pour qu'une telle entrée soit produite, il ne faut pas quand même que le début du protocole de connexion ait eu lieu, ce qui du coup demande considérablement plus de ressources pour lancer une attaque qu'un simple flood UDP ?
Manuel.
Le (on) mardi 24 juin 2008 17:42, Stephane Catteau a écrit (wrote) :
2) Une règle globale traitera le reste des cas de figure, pour être sûr
de ne pas en oublier.
Dans la conf de fail2ban, c'est plutôt le contraire : il n'y a pas de cas
par défaut, juste des cas spécifiques par service.
A partir de là, il suffit d'envoyer une vague massive de paquets UDP
en forgeant l'adresse émetrice, et en cinq minutes on bloque une classe
C.
Une question que je me pose est la suivante. fail2ban fonctionne en fait en
regardant les entrées produites par sshd dans les log (je prend le cas de
ssh, je ne connais pas pour le reste). Pour qu'une telle entrée soit
produite, il ne faut pas quand même que le début du protocole de connexion
ait eu lieu, ce qui du coup demande considérablement plus de ressources
pour lancer une attaque qu'un simple flood UDP ?
Le (on) mardi 24 juin 2008 17:42, Stephane Catteau a écrit (wrote) :
2) Une règle globale traitera le reste des cas de figure, pour être sûr de ne pas en oublier.
Dans la conf de fail2ban, c'est plutôt le contraire : il n'y a pas de cas par défaut, juste des cas spécifiques par service.
A partir de là, il suffit d'envoyer une vague massive de paquets UDP en forgeant l'adresse émetrice, et en cinq minutes on bloque une classe C.
Une question que je me pose est la suivante. fail2ban fonctionne en fait en regardant les entrées produites par sshd dans les log (je prend le cas de ssh, je ne connais pas pour le reste). Pour qu'une telle entrée soit produite, il ne faut pas quand même que le début du protocole de connexion ait eu lieu, ce qui du coup demande considérablement plus de ressources pour lancer une attaque qu'un simple flood UDP ?
Manuel.
Pascal Hambourg
Salut,
Stephane Catteau a écrit :
Benoit devait dire quelque chose comme ceci :
Je vais dire un truc con, mais pourquoi pas utiliser un truc comme fail2ban qui bannit les gens après X tentatives de connexions ratées en moins de N minutes ?
C'est une solution, à étudier soigneusement avant mise en place pour éviter le risque de DoS.
Tu peux me dire comment s'effectue le DoS stp ?
En exploitant une éventuelle faille dans l'examen des logs d'accès par fail2ban qui permettrait de bannir des utilisateurs à tort. Une faille de ce type avait été découverte en début d'année.
Le plus simple, et qui marche assez bien, est de partir du principe que l'admin est une feignasse et que le filtrage se fait au niveau du filtre IP en bordure du réseau. Celui-ci banira toute adresses IP qui fera, disons plus de 10 (tentatives de) connexions sur un même port en 5 minutes. Comme l'admin est une feignasse, et que mine de rien en matière de filtrage IP le mieux est parfois l'enemi du bien, il y aura règles : 1) Les services pouvant nécessiter légitimement plusieurs connexions courtes (HTTP par exemple) seront exemptées de contrôle. Même chose pour les services pouvant recevoir de nombreux paquets UDP en un temps limité (DNS par exemple). 2) Une règle globale traitera le reste des cas de figure, pour être sûr de ne pas en oublier.
A partir de là, il suffit d'envoyer une vague massive de paquets UDP en forgeant l'adresse émetrice, et en cinq minutes on bloque une classe C.
Euh, quel rapport avec fail2ban ?
Salut,
Stephane Catteau a écrit :
Benoit devait dire quelque chose comme ceci :
Je vais dire un truc con, mais pourquoi pas utiliser un truc comme fail2ban
qui bannit les gens après X tentatives de connexions ratées en moins de N
minutes ?
C'est une solution, à étudier soigneusement avant mise en place pour
éviter le risque de DoS.
Tu peux me dire comment s'effectue le DoS stp ?
En exploitant une éventuelle faille dans l'examen des logs d'accès par
fail2ban qui permettrait de bannir des utilisateurs à tort. Une faille
de ce type avait été découverte en début d'année.
Le plus simple, et qui marche assez bien, est de partir du principe
que l'admin est une feignasse et que le filtrage se fait au niveau du
filtre IP en bordure du réseau. Celui-ci banira toute adresses IP qui
fera, disons plus de 10 (tentatives de) connexions sur un même port en
5 minutes. Comme l'admin est une feignasse, et que mine de rien en
matière de filtrage IP le mieux est parfois l'enemi du bien, il y aura
règles :
1) Les services pouvant nécessiter légitimement plusieurs connexions
courtes (HTTP par exemple) seront exemptées de contrôle. Même chose
pour les services pouvant recevoir de nombreux paquets UDP en un temps
limité (DNS par exemple).
2) Une règle globale traitera le reste des cas de figure, pour être sûr
de ne pas en oublier.
A partir de là, il suffit d'envoyer une vague massive de paquets UDP
en forgeant l'adresse émetrice, et en cinq minutes on bloque une classe
C.
Je vais dire un truc con, mais pourquoi pas utiliser un truc comme fail2ban qui bannit les gens après X tentatives de connexions ratées en moins de N minutes ?
C'est une solution, à étudier soigneusement avant mise en place pour éviter le risque de DoS.
Tu peux me dire comment s'effectue le DoS stp ?
En exploitant une éventuelle faille dans l'examen des logs d'accès par fail2ban qui permettrait de bannir des utilisateurs à tort. Une faille de ce type avait été découverte en début d'année.
Le plus simple, et qui marche assez bien, est de partir du principe que l'admin est une feignasse et que le filtrage se fait au niveau du filtre IP en bordure du réseau. Celui-ci banira toute adresses IP qui fera, disons plus de 10 (tentatives de) connexions sur un même port en 5 minutes. Comme l'admin est une feignasse, et que mine de rien en matière de filtrage IP le mieux est parfois l'enemi du bien, il y aura règles : 1) Les services pouvant nécessiter légitimement plusieurs connexions courtes (HTTP par exemple) seront exemptées de contrôle. Même chose pour les services pouvant recevoir de nombreux paquets UDP en un temps limité (DNS par exemple). 2) Une règle globale traitera le reste des cas de figure, pour être sûr de ne pas en oublier.
A partir de là, il suffit d'envoyer une vague massive de paquets UDP en forgeant l'adresse émetrice, et en cinq minutes on bloque une classe C.
Euh, quel rapport avec fail2ban ?
Stephane Catteau
mpg n'était pas loin de dire :
Une question que je me pose est la suivante. fail2ban fonctionne en fait en regardant les entrées produites par sshd dans les log (je prend le cas de ssh, je ne connais pas pour le reste). Pour qu'une telle entrée soit produite, il ne faut pas quand même que le début du protocole de connexion ait eu lieu, ce qui du coup demande considérablement plus de ressources pour lancer une attaque qu'un simple flood UDP ?
Vi vi, comme l'a fait remarquer Pascal Hambourg un peu plus loin, je me suis plantu en beauté. Je ne sais pas pourquoi, mon cerveau à complètement zapé fail2ban et j'ai répondu sur les mécanismes de banissement intégrés au filtre IP (comme celui de PF par exemple). J'irais me faire donner cent coups de fouets dès que je trouverais le temps.
mpg n'était pas loin de dire :
Une question que je me pose est la suivante. fail2ban fonctionne en fait en
regardant les entrées produites par sshd dans les log (je prend le cas de
ssh, je ne connais pas pour le reste). Pour qu'une telle entrée soit
produite, il ne faut pas quand même que le début du protocole de connexion
ait eu lieu, ce qui du coup demande considérablement plus de ressources
pour lancer une attaque qu'un simple flood UDP ?
Vi vi, comme l'a fait remarquer Pascal Hambourg un peu plus loin, je
me suis plantu en beauté. Je ne sais pas pourquoi, mon cerveau à
complètement zapé fail2ban et j'ai répondu sur les mécanismes de
banissement intégrés au filtre IP (comme celui de PF par exemple).
J'irais me faire donner cent coups de fouets dès que je trouverais le
temps.
Une question que je me pose est la suivante. fail2ban fonctionne en fait en regardant les entrées produites par sshd dans les log (je prend le cas de ssh, je ne connais pas pour le reste). Pour qu'une telle entrée soit produite, il ne faut pas quand même que le début du protocole de connexion ait eu lieu, ce qui du coup demande considérablement plus de ressources pour lancer une attaque qu'un simple flood UDP ?
Vi vi, comme l'a fait remarquer Pascal Hambourg un peu plus loin, je me suis plantu en beauté. Je ne sais pas pourquoi, mon cerveau à complètement zapé fail2ban et j'ai répondu sur les mécanismes de banissement intégrés au filtre IP (comme celui de PF par exemple). J'irais me faire donner cent coups de fouets dès que je trouverais le temps.
