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.
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.
Cela serait-il casse-pieds pour l'intrus ?
Ça ressemble à un honeypot mais avec un miel au gout infâme. Donc je ne vois pas quel ours serait tenté de rester. Pourquoi vouloir faire ça ? Ça prendra forcément plus de ressources que de ne rien faire. Si tu ne veux pas voir de connexions sur ssh, change de port et fais du port knocking. Tu ne seras à l'abri de rien, mais tu auras certainement beaucoup moins de logs pour ssh.
Vincent Ramos a écrit :
Bonjour,
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.
Cela serait-il casse-pieds pour l'intrus ?
Ça ressemble à un honeypot mais avec un miel au gout infâme. Donc je ne
vois pas quel ours serait tenté de rester.
Pourquoi vouloir faire ça ? Ça prendra forcément plus de ressources que
de ne rien faire.
Si tu ne veux pas voir de connexions sur ssh, change de port et fais du
port knocking. Tu ne seras à l'abri de rien, mais tu auras certainement
beaucoup moins de logs pour ssh.
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.
Cela serait-il casse-pieds pour l'intrus ?
Ça ressemble à un honeypot mais avec un miel au gout infâme. Donc je ne vois pas quel ours serait tenté de rester. Pourquoi vouloir faire ça ? Ça prendra forcément plus de ressources que de ne rien faire. Si tu ne veux pas voir de connexions sur ssh, change de port et fais du port knocking. Tu ne seras à l'abri de rien, mais tu auras certainement beaucoup moins de logs pour ssh.
Vincent Ramos
Olivier Masson wrote:
Ça ressemble à un honeypot mais avec un miel au gout infâme. Donc je ne vois pas quel ours serait tenté de rester.
Jolie métaphore.
Pourquoi vouloir faire ça ? Ça prendra forcément plus de ressources que de ne rien faire.
C'est aussi ce que je me disais. Bon, les ressources prises par yes sont cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Si tu ne veux pas voir de connexions sur ssh, change de port et fais du port knocking. Tu ne seras à l'abri de rien, mais tu auras certainement beaucoup moins de logs pour ssh.
Pour le changement de ports, je l'ai eu fait. Le problème est qu'une des machines que j'administre est derrière une passerelle (rectorale) qui n'ouvre que certains ports et sur laquelle je n'ai aucun droit. Bref, les ports 22, 80, 25 et 21 sont ouverts et utilisés. Point barre.
Quand au port knocking, je n'ai encore jamais essayé. Vu que j'ai un système de sauvegardes incrémentales à distance avec rsync par ssh, je n'ai pas encore cherché à savoir si je peux m'en servir avec cette application. De même pour monter des systèmes de fichiers distants par sshfs. Je vais chercher de la doc ; merci pour l'idée.
Olivier Masson wrote:
Ça ressemble à un honeypot mais avec un miel au gout infâme. Donc je ne
vois pas quel ours serait tenté de rester.
Jolie métaphore.
Pourquoi vouloir faire ça ? Ça prendra forcément plus de ressources que
de ne rien faire.
C'est aussi ce que je me disais. Bon, les ressources prises par yes sont
cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les
Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Si tu ne veux pas voir de connexions sur ssh, change de port et fais du
port knocking. Tu ne seras à l'abri de rien, mais tu auras certainement
beaucoup moins de logs pour ssh.
Pour le changement de ports, je l'ai eu fait. Le problème est qu'une des
machines que j'administre est derrière une passerelle (rectorale) qui
n'ouvre que certains ports et sur laquelle je n'ai aucun droit. Bref,
les ports 22, 80, 25 et 21 sont ouverts et utilisés. Point barre.
Quand au port knocking, je n'ai encore jamais essayé. Vu que j'ai un
système de sauvegardes incrémentales à distance avec rsync par ssh, je
n'ai pas encore cherché à savoir si je peux m'en servir avec cette
application. De même pour monter des systèmes de fichiers distants par
sshfs. Je vais chercher de la doc ; merci pour l'idée.
Ça ressemble à un honeypot mais avec un miel au gout infâme. Donc je ne vois pas quel ours serait tenté de rester.
Jolie métaphore.
Pourquoi vouloir faire ça ? Ça prendra forcément plus de ressources que de ne rien faire.
C'est aussi ce que je me disais. Bon, les ressources prises par yes sont cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Si tu ne veux pas voir de connexions sur ssh, change de port et fais du port knocking. Tu ne seras à l'abri de rien, mais tu auras certainement beaucoup moins de logs pour ssh.
Pour le changement de ports, je l'ai eu fait. Le problème est qu'une des machines que j'administre est derrière une passerelle (rectorale) qui n'ouvre que certains ports et sur laquelle je n'ai aucun droit. Bref, les ports 22, 80, 25 et 21 sont ouverts et utilisés. Point barre.
Quand au port knocking, je n'ai encore jamais essayé. Vu que j'ai un système de sauvegardes incrémentales à distance avec rsync par ssh, je n'ai pas encore cherché à savoir si je peux m'en servir avec cette application. De même pour monter des systèmes de fichiers distants par sshfs. Je vais chercher de la doc ; merci pour l'idée.
Fabien LE LEZ
On 23 Jun 2008 16:48:50 GMT, Vincent Ramos :
C'est aussi ce que je me disais. Bon, les ressources prises par yes sont cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les
...robots. La première phase, repérer les mots de passe valides, se fait bien sûr par robot. Mais je pense que la seconde phase, ouvrir une session puis regarder ce qu'on peut en faire, est aussi traitée par un robot.
Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Bloque ces deux pays (si tu le peux).
Quand au port knocking, je n'ai encore jamais essayé.
Si je ne m'abuse, une passerelle qui bloque la quasi-totalité des ports rend le port-knocking inopérant.
On 23 Jun 2008 16:48:50 GMT, Vincent Ramos :
C'est aussi ce que je me disais. Bon, les ressources prises par yes sont
cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les
...robots.
La première phase, repérer les mots de passe valides, se fait bien sûr
par robot.
Mais je pense que la seconde phase, ouvrir une session puis regarder
ce qu'on peut en faire, est aussi traitée par un robot.
Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Bloque ces deux pays (si tu le peux).
Quand au port knocking, je n'ai encore jamais essayé.
Si je ne m'abuse, une passerelle qui bloque la quasi-totalité des
ports rend le port-knocking inopérant.
C'est aussi ce que je me disais. Bon, les ressources prises par yes sont cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les
...robots. La première phase, repérer les mots de passe valides, se fait bien sûr par robot. Mais je pense que la seconde phase, ouvrir une session puis regarder ce qu'on peut en faire, est aussi traitée par un robot.
Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Bloque ces deux pays (si tu le peux).
Quand au port knocking, je n'ai encore jamais essayé.
Si je ne m'abuse, une passerelle qui bloque la quasi-totalité des ports rend le port-knocking inopérant.
mpg
Le (on) lundi 23 juin 2008 19:16, Fabien LE LEZ a écrit (wrote) :
Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Bloque ces deux pays (si tu le peux).
Ouais, vive l'internet fermé ! Non, franchement, je trouve ça très moche de bloquer les gens à l'IP d'origine : c'est comme de la discrimination au faciès.
Quand au port knocking, je n'ai encore jamais essayé.
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 ? Avec des bonnes valeurs de X et N, ça rend les logs beaucoup plus propres en stoppant net les attaques par dictionnaire. D'après moins expérience, peut-être pas significative, les robots n'essayent pas une deuxième fois après avoir été bloqués 15 minutes.
Et contrairement au port knocking ou au changement de port, d'une part ça ne fait pas d'hypothèse sur les ports filtrés ou non par la passerelle locale, et aussi ça ne demande aucune configuration particulière côté utilisateur.
Manuel.
Le (on) lundi 23 juin 2008 19:16, Fabien LE LEZ a écrit (wrote) :
Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Bloque ces deux pays (si tu le peux).
Ouais, vive l'internet fermé ! Non, franchement, je trouve ça très moche de
bloquer les gens à l'IP d'origine : c'est comme de la discrimination au
faciès.
Quand au port knocking, je n'ai encore jamais essayé.
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 ? Avec des bonnes valeurs de X et N, ça rend les logs beaucoup plus
propres en stoppant net les attaques par dictionnaire. D'après moins
expérience, peut-être pas significative, les robots n'essayent pas une
deuxième fois après avoir été bloqués 15 minutes.
Et contrairement au port knocking ou au changement de port, d'une part ça ne
fait pas d'hypothèse sur les ports filtrés ou non par la passerelle locale,
et aussi ça ne demande aucune configuration particulière côté utilisateur.
Le (on) lundi 23 juin 2008 19:16, Fabien LE LEZ a écrit (wrote) :
Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Bloque ces deux pays (si tu le peux).
Ouais, vive l'internet fermé ! Non, franchement, je trouve ça très moche de bloquer les gens à l'IP d'origine : c'est comme de la discrimination au faciès.
Quand au port knocking, je n'ai encore jamais essayé.
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 ? Avec des bonnes valeurs de X et N, ça rend les logs beaucoup plus propres en stoppant net les attaques par dictionnaire. D'après moins expérience, peut-être pas significative, les robots n'essayent pas une deuxième fois après avoir été bloqués 15 minutes.
Et contrairement au port knocking ou au changement de port, d'une part ça ne fait pas d'hypothèse sur les ports filtrés ou non par la passerelle locale, et aussi ça ne demande aucune configuration particulière côté utilisateur.
Manuel.
Fabien LE LEZ
On 23 Jun 2008 23:09:46 GMT, mpg :
Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Bloque ces deux pays (si tu le peux).
Ouais, vive l'internet fermé ! Non, franchement, je trouve ça très moche de bloquer les gens à l'IP d'origine : c'est comme de la discrimination au faciès.
Il s'agit ici d'un serveur SSH. Il y a donc de bonnes chances pour que tous les utilisateurs légitimes se connectent depuis l'Europe (en visant très large). Si c'est bien le cas, bloquer carrément certaines régions du monde (Russie, Chine, etc.) ne me paraît en rien choquant.
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.
On 23 Jun 2008 23:09:46 GMT, mpg <mpg@elzevir.fr>:
Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Bloque ces deux pays (si tu le peux).
Ouais, vive l'internet fermé ! Non, franchement, je trouve ça très moche de
bloquer les gens à l'IP d'origine : c'est comme de la discrimination au
faciès.
Il s'agit ici d'un serveur SSH. Il y a donc de bonnes chances pour que
tous les utilisateurs légitimes se connectent depuis l'Europe (en
visant très large). Si c'est bien le cas, bloquer carrément certaines
régions du monde (Russie, Chine, etc.) ne me paraît en rien choquant.
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.
Coréens et les Chinois qui, désespérément, pourrissent mes logs.
Bloque ces deux pays (si tu le peux).
Ouais, vive l'internet fermé ! Non, franchement, je trouve ça très moche de bloquer les gens à l'IP d'origine : c'est comme de la discrimination au faciès.
Il s'agit ici d'un serveur SSH. Il y a donc de bonnes chances pour que tous les utilisateurs légitimes se connectent depuis l'Europe (en visant très large). Si c'est bien le cas, bloquer carrément certaines régions du monde (Russie, Chine, etc.) ne me paraît en rien choquant.
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.
Thomas
In article , Fabien LE LEZ wrote:
On 23 Jun 2008 16:48:50 GMT, Vincent Ramos :
>C'est aussi ce que je me disais. Bon, les ressources prises par yes sont >cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les
...robots. La première phase, repérer les mots de passe valides, se fait bien sûr par robot. Mais je pense que la seconde phase, ouvrir une session puis regarder ce qu'on peut en faire, est aussi traitée par un robot.
donc la question est : est ce que ça peut être utile de flooder ces robots ? (pour les ralentir, donc réduire temporairement leur nuisance sur les autres, ...)
si oui, est il intéressant de leur envoyer que des 0 (cad le caractère NUL), plutôt que "y<retour>", pour avoir plus de compression, cad plus de débit virtuel à débit réel constant, et en plus du travail pour la décompression ?
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <9hmv54laq02ophffmq2v69p14p78kh7ghl@4ax.com>,
Fabien LE LEZ <gramster@gramster.com> wrote:
On 23 Jun 2008 16:48:50 GMT, Vincent Ramos :
>C'est aussi ce que je me disais. Bon, les ressources prises par yes sont
>cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les
...robots.
La première phase, repérer les mots de passe valides, se fait bien sûr
par robot.
Mais je pense que la seconde phase, ouvrir une session puis regarder
ce qu'on peut en faire, est aussi traitée par un robot.
donc la question est :
est ce que ça peut être utile de flooder ces robots ? (pour les
ralentir, donc réduire temporairement leur nuisance sur les autres, ...)
si oui,
est il intéressant de leur envoyer que des 0 (cad le caractère NUL),
plutôt que "y<retour>",
pour avoir plus de compression, cad plus de débit virtuel à débit réel
constant, et en plus du travail pour la décompression ?
--
j'agis contre l'assistanat, je travaille dans une SCOP !
>C'est aussi ce que je me disais. Bon, les ressources prises par yes sont >cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les
...robots. La première phase, repérer les mots de passe valides, se fait bien sûr par robot. Mais je pense que la seconde phase, ouvrir une session puis regarder ce qu'on peut en faire, est aussi traitée par un robot.
donc la question est : est ce que ça peut être utile de flooder ces robots ? (pour les ralentir, donc réduire temporairement leur nuisance sur les autres, ...)
si oui, est il intéressant de leur envoyer que des 0 (cad le caractère NUL), plutôt que "y<retour>", pour avoir plus de compression, cad plus de débit virtuel à débit réel constant, et en plus du travail pour la décompression ?
-- j'agis contre l'assistanat, je travaille dans une SCOP !
jenaipasdemail
Fabien LE LEZ wrote:
>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).
-- Benoit Leraillez
Seuls les idéaux ne changent pas d'avis.
Fabien LE LEZ <gramster@gramster.com> wrote:
>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).
-- Benoit Leraillez
Seuls les idéaux ne changent pas d'avis.
Kevin Denis
Le 24-06-2008, Thomas a écrit :
>C'est aussi ce que je me disais. Bon, les ressources prises par yes sont >cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les
...robots. La première phase, repérer les mots de passe valides, se fait bien sûr par robot. Mais je pense que la seconde phase, ouvrir une session puis regarder ce qu'on peut en faire, est aussi traitée par un robot.
donc la question est : est ce que ça peut être utile de flooder ces robots ? (pour les ralentir, donc réduire temporairement leur nuisance sur les autres, ...)
si oui, est il intéressant de leur envoyer que des 0 (cad le caractère NUL), plutôt que "y<retour>", pour avoir plus de compression, cad plus de débit virtuel à débit réel constant, et en plus du travail pour la décompression ?
Dans ce cas là, si le but est de ralentir l'assaillant, je conseille de regarder l'utilisation de la cible TARPIT d'iptables: TARPIT Captures and holds incoming TCP connections using no local per-connection resources. Connections are accepted, but immediately switched to the persist state (0 byte window), in which the remote side stops sending data and asks to continue every 60-240 seconds. Attempts to close the connection are ignored, forcing the remote side to time out the connection in 12-24 minutes.
man iptables , ou http://linux.die.net/man/8/iptables -- Kevin
Le 24-06-2008, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit :
>C'est aussi ce que je me disais. Bon, les ressources prises par yes sont
>cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les
...robots.
La première phase, repérer les mots de passe valides, se fait bien sûr
par robot.
Mais je pense que la seconde phase, ouvrir une session puis regarder
ce qu'on peut en faire, est aussi traitée par un robot.
donc la question est :
est ce que ça peut être utile de flooder ces robots ? (pour les
ralentir, donc réduire temporairement leur nuisance sur les autres, ...)
si oui,
est il intéressant de leur envoyer que des 0 (cad le caractère NUL),
plutôt que "y<retour>",
pour avoir plus de compression, cad plus de débit virtuel à débit réel
constant, et en plus du travail pour la décompression ?
Dans ce cas là, si le but est de ralentir l'assaillant, je conseille
de regarder l'utilisation de la cible TARPIT d'iptables:
TARPIT
Captures and holds incoming TCP connections using no local per-connection
resources. Connections are accepted, but immediately switched to the
persist state (0 byte window), in which the remote side stops sending
data and asks to continue every 60-240 seconds. Attempts to close the
connection are ignored, forcing the remote side to time out the connection
in 12-24 minutes.
man iptables , ou http://linux.die.net/man/8/iptables
--
Kevin
>C'est aussi ce que je me disais. Bon, les ressources prises par yes sont >cependant assez faibles. Pourquoi faire cela ? Pour juste embêter les
...robots. La première phase, repérer les mots de passe valides, se fait bien sûr par robot. Mais je pense que la seconde phase, ouvrir une session puis regarder ce qu'on peut en faire, est aussi traitée par un robot.
donc la question est : est ce que ça peut être utile de flooder ces robots ? (pour les ralentir, donc réduire temporairement leur nuisance sur les autres, ...)
si oui, est il intéressant de leur envoyer que des 0 (cad le caractère NUL), plutôt que "y<retour>", pour avoir plus de compression, cad plus de débit virtuel à débit réel constant, et en plus du travail pour la décompression ?
Dans ce cas là, si le but est de ralentir l'assaillant, je conseille de regarder l'utilisation de la cible TARPIT d'iptables: TARPIT Captures and holds incoming TCP connections using no local per-connection resources. Connections are accepted, but immediately switched to the persist state (0 byte window), in which the remote side stops sending data and asks to continue every 60-240 seconds. Attempts to close the connection are ignored, forcing the remote side to time out the connection in 12-24 minutes.
man iptables , ou http://linux.die.net/man/8/iptables -- Kevin
Fabien LE LEZ
On 24 Jun 2008 01:34:32 GMT, Thomas :
est ce que ça peut être utile de flooder ces robots ? (pour les ralentir, donc réduire temporairement leur nuisance sur les autres, ...)
Peut-être, mais il faut faire attention à ne pas flooder ta machine par la même occasion.
On 24 Jun 2008 01:34:32 GMT, Thomas :
est ce que ça peut être utile de flooder ces robots ? (pour les
ralentir, donc réduire temporairement leur nuisance sur les autres, ...)
Peut-être, mais il faut faire attention à ne pas flooder ta machine
par la même occasion.
est ce que ça peut être utile de flooder ces robots ? (pour les ralentir, donc réduire temporairement leur nuisance sur les autres, ...)
Peut-être, mais il faut faire attention à ne pas flooder ta machine par la même occasion.
Stephane Catteau
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 ?
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.
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 ?
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 ?
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.
