[netfilter] limiter les attaques SSH par dictionnaire
35 réponses
Sébastien Kirche
Bonsoir,
sur la pauvre passerelle de mon pauvre petit domaine, je retrouve dans
les logs plusieurs centaines de fois par jour les traces de scripts
kiddies qui tentent d'accéder à mon système en utilisant un dictionnaire
de logins SSH.
Niveau sécurité c'est sans importance puisque que j'ai supprimé la
possibilité d'accès SSH par mot de passe en ne conservant que
l'utilisation de clé privée.
Seulement sshd trace quand même chaque tentative dans /var/log/auth.log.
Pour le seul problème de log j'aurais pu diminuer le LogLevel mais vu
que ma passerelle est motorisée par une SparcStation20 bi-75MHz (ouaouh
la puissance !) je souhaite également limiter le gaspillage de cpu
qu'occasionne chaque tentative de login surtout quand c'est en rafale.
J'ai trouvé DenyHosts qui trace la fréquence des logins SSH et en cas
d'abus ajoute l'émetteur dans /etc/hosts.deny, seulement je n'aime pas
trop l'idée d'une modification automatique d'un fichier système.
J'ai pensé que Netfilter devait pouvoir suffire et j'ai rajouté les
règles suivantes à ma config existante (extrait d'iptables-save) :
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 --name DEFAULT --rsource -j REJECT --reject-with icmp-port-unreachable
Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait
j'utilise la target DROP mais dans le cas présent j'ai utilisé REJECT
qui permet de ne pas devoir attendre un timeout pour la négociation SSH...
Dans le message <news:, *Emmanuel Florac* tapota sur f.c.o.l.configuration :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont l'état est INVALID, dont l'adresse est usurpée ou dont le type est suspicieux.
Dans le cas en question, ça s'applique parfaitement aux tentatives de connexions SSH automatisées,
Faut-il les détecter comme il faut. Laisser le firewall «DROPer» systématiquement et automatiquement les connexions intempestives est, à mon humble avis, risqué. C'est un moyen qui peut vite être détourné à l'encontre de l'usager normal via un déni de service par usurpation de son adresse IP.
J'estime que le comportement par défaut d'un firewall est de respecté au mieux les règles. Ensuite, rien n'empêche de faire des exceptions mais en évitant l'automatisation de ces exceptions.
qui arrivent le plus souvent avec des adresses invalides ou forgées (j'ai même eu des tentatives avec des adresses en 10.x.x.x !!!!)
Je ferais la même remarque que Pascal.
Le DROP s'impose donc,
Je ne vois pas pourquoi, un REJECT n'est guère plus couteux.
un REJECT c'est faire bien trop d'honneur aux script kiddies.
Le but n'est pas de respecter les automates et autres pirates, mais de respecter au mieux les utilisations normales ou erronées.
-- Sébastien Monbrun aka TiChou
Dans le message <news:pan.2006.03.08.20.52.36.405983@imaginet.fr>,
*Emmanuel Florac* tapota sur f.c.o.l.configuration :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont
l'état est INVALID, dont l'adresse est usurpée ou dont le type est
suspicieux.
Dans le cas en question, ça s'applique parfaitement aux tentatives de
connexions SSH automatisées,
Faut-il les détecter comme il faut. Laisser le firewall «DROPer»
systématiquement et automatiquement les connexions intempestives est, à mon
humble avis, risqué. C'est un moyen qui peut vite être détourné à l'encontre
de l'usager normal via un déni de service par usurpation de son adresse IP.
J'estime que le comportement par défaut d'un firewall est de respecté au
mieux les règles. Ensuite, rien n'empêche de faire des exceptions mais en
évitant l'automatisation de ces exceptions.
qui arrivent le plus souvent avec des adresses invalides ou forgées (j'ai
même eu des tentatives avec des adresses en 10.x.x.x !!!!)
Je ferais la même remarque que Pascal.
Le DROP s'impose donc,
Je ne vois pas pourquoi, un REJECT n'est guère plus couteux.
un REJECT c'est faire bien trop d'honneur aux script kiddies.
Le but n'est pas de respecter les automates et autres pirates, mais de
respecter au mieux les utilisations normales ou erronées.
Dans le message <news:, *Emmanuel Florac* tapota sur f.c.o.l.configuration :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont l'état est INVALID, dont l'adresse est usurpée ou dont le type est suspicieux.
Dans le cas en question, ça s'applique parfaitement aux tentatives de connexions SSH automatisées,
Faut-il les détecter comme il faut. Laisser le firewall «DROPer» systématiquement et automatiquement les connexions intempestives est, à mon humble avis, risqué. C'est un moyen qui peut vite être détourné à l'encontre de l'usager normal via un déni de service par usurpation de son adresse IP.
J'estime que le comportement par défaut d'un firewall est de respecté au mieux les règles. Ensuite, rien n'empêche de faire des exceptions mais en évitant l'automatisation de ces exceptions.
qui arrivent le plus souvent avec des adresses invalides ou forgées (j'ai même eu des tentatives avec des adresses en 10.x.x.x !!!!)
Je ferais la même remarque que Pascal.
Le DROP s'impose donc,
Je ne vois pas pourquoi, un REJECT n'est guère plus couteux.
un REJECT c'est faire bien trop d'honneur aux script kiddies.
Le but n'est pas de respecter les automates et autres pirates, mais de respecter au mieux les utilisations normales ou erronées.
-- Sébastien Monbrun aka TiChou
Sébastien Monbrun aka TiChou
Dans le message <news:, *aze* tapota sur f.c.o.l.configuration :
Pour en revenir à netfilter. Il y a donc une manière avec iptables pour se débarasser des récidivistes...
Mouais, si on veut. Voir ma réponse à Emmanuel Florac.
Mais peut-on faire la même avec du ponctuel sur plusieurs port ? Un peu comme le stealth de nmap (je crois, de mémoire). Comme cela Sébastien se débarasse aussi des attaques générique de tests. Si tu dis "oui" tu m'interesses ! :)
Il existe des outils pour se prémunir de ce genre d'attaque. Par exemple Snort ou encore psad.
-- Sébastien Monbrun aka TiChou
Dans le message <news:pan.2006.03.08.21.21.49.995902@aze>,
*aze* tapota sur f.c.o.l.configuration :
Pour en revenir à netfilter.
Il y a donc une manière avec iptables pour se débarasser des
récidivistes...
Mouais, si on veut. Voir ma réponse à Emmanuel Florac.
Mais peut-on faire la même avec du ponctuel sur plusieurs port ? Un peu
comme le stealth de nmap (je crois, de mémoire).
Comme cela Sébastien se débarasse aussi des attaques générique de tests.
Si tu dis "oui" tu m'interesses ! :)
Il existe des outils pour se prémunir de ce genre d'attaque. Par exemple
Snort ou encore psad.
Dans le message <news:, *aze* tapota sur f.c.o.l.configuration :
Pour en revenir à netfilter. Il y a donc une manière avec iptables pour se débarasser des récidivistes...
Mouais, si on veut. Voir ma réponse à Emmanuel Florac.
Mais peut-on faire la même avec du ponctuel sur plusieurs port ? Un peu comme le stealth de nmap (je crois, de mémoire). Comme cela Sébastien se débarasse aussi des attaques générique de tests. Si tu dis "oui" tu m'interesses ! :)
Il existe des outils pour se prémunir de ce genre d'attaque. Par exemple Snort ou encore psad.
-- Sébastien Monbrun aka TiChou
aze
Le Wed, 08 Mar 2006 22:41:31 +0100, Sébastien Monbrun aka TiChou a écrit :
Dans le message <news:, *aze* tapota sur f.c.o.l.configuration :
Pour en revenir à netfilter. Il y a donc une manière avec iptables pour se débarasser des récidivistes...
Mouais, si on veut. Voir ma réponse à Emmanuel Florac.
J'y ai répondu.
Mais peut-on faire la même avec du ponctuel sur plusieurs port ? Un peu comme le stealth de nmap (je crois, de mémoire). Comme cela Sébastien se débarasse aussi des attaques générique de tests. Si tu dis "oui" tu m'interesses ! :)
Il existe des outils pour se prémunir de ce genre d'attaque. Par exemple Snort ou encore psad.
Snort ne permet pas d'agir ou alors il se sont enfin décidé à implémenter une possibilité de réponse ? En tout cas pas dans la 2.4.0.
Pour psad il faut que je l'essaye.
Le Wed, 08 Mar 2006 22:41:31 +0100, Sébastien Monbrun aka TiChou a
écrit :
Dans le message <news:pan.2006.03.08.21.21.49.995902@aze>,
*aze* tapota sur f.c.o.l.configuration :
Pour en revenir à netfilter.
Il y a donc une manière avec iptables pour se débarasser des
récidivistes...
Mouais, si on veut. Voir ma réponse à Emmanuel Florac.
J'y ai répondu.
Mais peut-on faire la même avec du ponctuel sur plusieurs port ? Un peu
comme le stealth de nmap (je crois, de mémoire).
Comme cela Sébastien se débarasse aussi des attaques générique de tests.
Si tu dis "oui" tu m'interesses ! :)
Il existe des outils pour se prémunir de ce genre d'attaque. Par exemple
Snort ou encore psad.
Snort ne permet pas d'agir ou alors il se sont enfin décidé à
implémenter une possibilité de réponse ? En tout cas pas dans la 2.4.0.
Le Wed, 08 Mar 2006 22:41:31 +0100, Sébastien Monbrun aka TiChou a écrit :
Dans le message <news:, *aze* tapota sur f.c.o.l.configuration :
Pour en revenir à netfilter. Il y a donc une manière avec iptables pour se débarasser des récidivistes...
Mouais, si on veut. Voir ma réponse à Emmanuel Florac.
J'y ai répondu.
Mais peut-on faire la même avec du ponctuel sur plusieurs port ? Un peu comme le stealth de nmap (je crois, de mémoire). Comme cela Sébastien se débarasse aussi des attaques générique de tests. Si tu dis "oui" tu m'interesses ! :)
Il existe des outils pour se prémunir de ce genre d'attaque. Par exemple Snort ou encore psad.
Snort ne permet pas d'agir ou alors il se sont enfin décidé à implémenter une possibilité de réponse ? En tout cas pas dans la 2.4.0.
Pour psad il faut que je l'essaye.
aze
Le Wed, 08 Mar 2006 22:32:52 +0100, Sébastien Monbrun aka TiChou a écrit :
Dans le message <news:, *Emmanuel Florac* tapota sur f.c.o.l.configuration :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont l'état est INVALID, dont l'adresse est usurpée ou dont le type est suspicieux.
Dans le cas en question, ça s'applique parfaitement aux tentatives de connexions SSH automatisées,
Faut-il les détecter comme il faut. Laisser le firewall «DROPer» systématiquement et automatiquement les connexions intempestives est, à mon humble avis, risqué. C'est un moyen qui peut vite être détourné à l'encontre de l'usager normal via un déni de service par usurpation de son adresse IP.
Attend, je ne comprend pas ta logique: Tu as un usagé "normal" qui a un ordinateur piraté... Mais dans ce cas là, peut-on encore dire que son ordinateur est "normal" et donc doit-on faire de la politesse avec lui ? Sachant qu'en fait ce n'est pas une application "normale" qui est en train de tester tes ports ? Autre version son ordinateur n'est pas piraté et c'est juste une usurpation d'adresse par un serveur de nom traffiqué, donc dans ce cas là tu dis à la personne qui ne t'a pas contactée: "désolé mais vous n'avez pas accés ici"... Moui, disons que si le crackeur est retord et qu'il emploi certaines adresses en .gov tu vas vite avoir une surprise.
J'estime que le comportement par défaut d'un firewall est de respecté au mieux les règles. Ensuite, rien n'empêche de faire des exceptions mais en évitant l'automatisation de ces exceptions.
Sachant la vitesse à laquelle tout cela se passe ?
qui arrivent le plus souvent avec des adresses invalides ou forgées (j'ai même eu des tentatives avec des adresses en 10.x.x.x !!!!)
Je ferais la même remarque que Pascal.
Le DROP s'impose donc,
Je ne vois pas pourquoi, un REJECT n'est guère plus couteux.
Un REJECT entraine une réponse de ta part qui peu et certainement va être analysée (à par script bien sûr), pas dans le cas d'un forgé bien sûr, mais tu en connais beaucoups des idiots qui tente un crack sur un ordinateur avec une adresse forgée réelle qui ne lui permet pas de savoir le résultat de son probe ? Je ne dis pas n'en avoir jamais vu mais franchement cela ne m'inquiête guêre !!! ;)
Quant à l'adresse en 10.x... de mémoire, comme la plupart des serveurs ne la reconduisent pas (rfc si je me souviens bien) cela s'ignifie que l'attaque est sur la même portion de réseau que la cible, donc bien que forgée, elle répondra.
un REJECT c'est faire bien trop d'honneur aux script kiddies.
Le but n'est pas de respecter les automates et autres pirates, mais de respecter au mieux les utilisations normales ou erronées.
Une utilisation normale fait rarement appel à SSH. Une autorisation erronées, j'entend qui fait une erreur d'adresse ip par exemple, ne la refait pas plus d'une voir deux fois. Après... Comment appelles-tu cela d'ailleurs ? Une erreur de programmation sur un retour d'erreur d'ip qui bouclerait en incrémentant sans le vouloir dans le fichier le plus proche sur le disque dur qui justement est un dictionnaire ? <8°P
Je ne comprends pas ton raisonnement, pour moi j'ai l'impression que tu fait plutôt du social (pour ainsi dire) alors qu'il essaye de se proteger.
Le Wed, 08 Mar 2006 22:32:52 +0100, Sébastien Monbrun aka TiChou a
écrit :
Dans le message <news:pan.2006.03.08.20.52.36.405983@imaginet.fr>,
*Emmanuel Florac* tapota sur f.c.o.l.configuration :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont
l'état est INVALID, dont l'adresse est usurpée ou dont le type est
suspicieux.
Dans le cas en question, ça s'applique parfaitement aux tentatives de
connexions SSH automatisées,
Faut-il les détecter comme il faut. Laisser le firewall «DROPer»
systématiquement et automatiquement les connexions intempestives est, à mon
humble avis, risqué. C'est un moyen qui peut vite être détourné à l'encontre
de l'usager normal via un déni de service par usurpation de son adresse IP.
Attend, je ne comprend pas ta logique:
Tu as un usagé "normal" qui a un ordinateur piraté... Mais dans ce cas
là, peut-on encore dire que son ordinateur est "normal" et donc doit-on
faire de la politesse avec lui ? Sachant qu'en fait ce n'est pas une
application "normale" qui est en train de tester tes ports ?
Autre version son ordinateur n'est pas piraté et c'est juste une
usurpation d'adresse par un serveur de nom traffiqué, donc dans ce cas
là tu dis à la personne qui ne t'a pas contactée: "désolé mais vous
n'avez pas accés ici"... Moui, disons que si le crackeur est retord et
qu'il emploi certaines adresses en .gov tu vas vite avoir une surprise.
J'estime que le comportement par défaut d'un firewall est de respecté
au mieux les règles. Ensuite, rien n'empêche de faire des exceptions
mais en évitant l'automatisation de ces exceptions.
Sachant la vitesse à laquelle tout cela se passe ?
qui arrivent le plus souvent avec des adresses invalides ou forgées (j'ai
même eu des tentatives avec des adresses en 10.x.x.x !!!!)
Je ferais la même remarque que Pascal.
Le DROP s'impose donc,
Je ne vois pas pourquoi, un REJECT n'est guère plus couteux.
Un REJECT entraine une réponse de ta part qui peu et certainement va
être analysée (à par script bien sûr), pas dans le cas d'un forgé
bien sûr, mais tu en connais beaucoups des idiots qui tente un crack sur
un ordinateur avec une adresse forgée réelle qui ne lui permet pas de
savoir le résultat de son probe ? Je ne dis pas n'en avoir jamais vu mais
franchement cela ne m'inquiête guêre !!! ;)
Quant à l'adresse en 10.x... de mémoire, comme la plupart des serveurs
ne la reconduisent pas (rfc si je me souviens bien) cela s'ignifie que
l'attaque est sur la même portion de réseau que la cible, donc bien que
forgée, elle répondra.
un REJECT c'est faire bien trop d'honneur aux script kiddies.
Le but n'est pas de respecter les automates et autres pirates, mais de
respecter au mieux les utilisations normales ou erronées.
Une utilisation normale fait rarement appel à SSH.
Une autorisation erronées, j'entend qui fait une erreur d'adresse ip par
exemple, ne la refait pas plus d'une voir deux fois.
Après... Comment appelles-tu cela d'ailleurs ? Une erreur de
programmation sur un retour d'erreur d'ip qui bouclerait en incrémentant
sans le vouloir dans le fichier le plus proche sur le disque dur qui
justement est un dictionnaire ? <8°P
Je ne comprends pas ton raisonnement, pour moi j'ai l'impression que tu
fait plutôt du social (pour ainsi dire) alors qu'il essaye de se proteger.
Le Wed, 08 Mar 2006 22:32:52 +0100, Sébastien Monbrun aka TiChou a écrit :
Dans le message <news:, *Emmanuel Florac* tapota sur f.c.o.l.configuration :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont l'état est INVALID, dont l'adresse est usurpée ou dont le type est suspicieux.
Dans le cas en question, ça s'applique parfaitement aux tentatives de connexions SSH automatisées,
Faut-il les détecter comme il faut. Laisser le firewall «DROPer» systématiquement et automatiquement les connexions intempestives est, à mon humble avis, risqué. C'est un moyen qui peut vite être détourné à l'encontre de l'usager normal via un déni de service par usurpation de son adresse IP.
Attend, je ne comprend pas ta logique: Tu as un usagé "normal" qui a un ordinateur piraté... Mais dans ce cas là, peut-on encore dire que son ordinateur est "normal" et donc doit-on faire de la politesse avec lui ? Sachant qu'en fait ce n'est pas une application "normale" qui est en train de tester tes ports ? Autre version son ordinateur n'est pas piraté et c'est juste une usurpation d'adresse par un serveur de nom traffiqué, donc dans ce cas là tu dis à la personne qui ne t'a pas contactée: "désolé mais vous n'avez pas accés ici"... Moui, disons que si le crackeur est retord et qu'il emploi certaines adresses en .gov tu vas vite avoir une surprise.
J'estime que le comportement par défaut d'un firewall est de respecté au mieux les règles. Ensuite, rien n'empêche de faire des exceptions mais en évitant l'automatisation de ces exceptions.
Sachant la vitesse à laquelle tout cela se passe ?
qui arrivent le plus souvent avec des adresses invalides ou forgées (j'ai même eu des tentatives avec des adresses en 10.x.x.x !!!!)
Je ferais la même remarque que Pascal.
Le DROP s'impose donc,
Je ne vois pas pourquoi, un REJECT n'est guère plus couteux.
Un REJECT entraine une réponse de ta part qui peu et certainement va être analysée (à par script bien sûr), pas dans le cas d'un forgé bien sûr, mais tu en connais beaucoups des idiots qui tente un crack sur un ordinateur avec une adresse forgée réelle qui ne lui permet pas de savoir le résultat de son probe ? Je ne dis pas n'en avoir jamais vu mais franchement cela ne m'inquiête guêre !!! ;)
Quant à l'adresse en 10.x... de mémoire, comme la plupart des serveurs ne la reconduisent pas (rfc si je me souviens bien) cela s'ignifie que l'attaque est sur la même portion de réseau que la cible, donc bien que forgée, elle répondra.
un REJECT c'est faire bien trop d'honneur aux script kiddies.
Le but n'est pas de respecter les automates et autres pirates, mais de respecter au mieux les utilisations normales ou erronées.
Une utilisation normale fait rarement appel à SSH. Une autorisation erronées, j'entend qui fait une erreur d'adresse ip par exemple, ne la refait pas plus d'une voir deux fois. Après... Comment appelles-tu cela d'ailleurs ? Une erreur de programmation sur un retour d'erreur d'ip qui bouclerait en incrémentant sans le vouloir dans le fichier le plus proche sur le disque dur qui justement est un dictionnaire ? <8°P
Je ne comprends pas ton raisonnement, pour moi j'ai l'impression que tu fait plutôt du social (pour ainsi dire) alors qu'il essaye de se proteger.
Emmanuel Florac
Le Wed, 08 Mar 2006 22:11:20 +0100, Pascal Hambourg a écrit :
Euh, je vois mal comment on peut espérer établir une connexion TCP et à plus forte raison SSH avec une adresse source invalide, forgée ou privée, c'est-à-dire en aveugle... :-
Moi aussi, mais j'ai les logs pour moi... Certaines adresses sont valides, d'autres totalement fantaisistes.
-- Toutes les organisations ont leur règles, et les Femmes Algériennes doivent avoir aussi leurs règles. Aït Ahmed.
Le Wed, 08 Mar 2006 22:11:20 +0100, Pascal Hambourg a écrit :
Euh, je vois mal comment on peut espérer établir une connexion TCP et à
plus forte raison SSH avec une adresse source invalide, forgée ou
privée, c'est-à-dire en aveugle... :-
Moi aussi, mais j'ai les logs pour moi... Certaines adresses sont valides,
d'autres totalement fantaisistes.
--
Toutes les organisations ont leur règles, et les Femmes Algériennes
doivent avoir aussi leurs règles.
Aït Ahmed.
Le Wed, 08 Mar 2006 22:11:20 +0100, Pascal Hambourg a écrit :
Euh, je vois mal comment on peut espérer établir une connexion TCP et à plus forte raison SSH avec une adresse source invalide, forgée ou privée, c'est-à-dire en aveugle... :-
Moi aussi, mais j'ai les logs pour moi... Certaines adresses sont valides, d'autres totalement fantaisistes.
-- Toutes les organisations ont leur règles, et les Femmes Algériennes doivent avoir aussi leurs règles. Aït Ahmed.
Emmanuel Florac
Le Wed, 08 Mar 2006 23:53:15 +0100, aze a écrit :
Je ne comprends pas ton raisonnement, pour moi j'ai l'impression que tu fait plutôt du social (pour ainsi dire) alors qu'il essaye de se proteger.
Avec succès jusqu'à présent... Il y a bien un gars "légitime" qui s'est fait "enfermé dehors" une fois ou deux mais c'est tout.
-- L'esprit qu'on veut avoir gâte celui qu'on a. Jean-Baptiste Louis Grisset.
Le Wed, 08 Mar 2006 23:53:15 +0100, aze a écrit :
Je ne comprends pas ton raisonnement, pour moi j'ai l'impression que tu
fait plutôt du social (pour ainsi dire) alors qu'il essaye de se
proteger.
Avec succès jusqu'à présent... Il y a bien un gars "légitime" qui
s'est fait "enfermé dehors" une fois ou deux mais c'est tout.
--
L'esprit qu'on veut avoir gâte celui qu'on a.
Jean-Baptiste Louis Grisset.
Je ne comprends pas ton raisonnement, pour moi j'ai l'impression que tu fait plutôt du social (pour ainsi dire) alors qu'il essaye de se proteger.
Avec succès jusqu'à présent... Il y a bien un gars "légitime" qui s'est fait "enfermé dehors" une fois ou deux mais c'est tout.
-- L'esprit qu'on veut avoir gâte celui qu'on a. Jean-Baptiste Louis Grisset.
Pascal Hambourg
Euh, je vois mal comment on peut espérer établir une connexion TCP et à plus forte raison SSH avec une adresse source invalide, forgée ou privée, c'est-à-dire en aveugle... :-
Moi aussi, mais j'ai les logs pour moi... Certaines adresses sont valides, d'autres totalement fantaisistes.
Les logs du serveur SSH ?
Euh, je vois mal comment on peut espérer établir une connexion TCP et à
plus forte raison SSH avec une adresse source invalide, forgée ou
privée, c'est-à-dire en aveugle... :-
Moi aussi, mais j'ai les logs pour moi... Certaines adresses sont valides,
d'autres totalement fantaisistes.
Euh, je vois mal comment on peut espérer établir une connexion TCP et à plus forte raison SSH avec une adresse source invalide, forgée ou privée, c'est-à-dire en aveugle... :-
Moi aussi, mais j'ai les logs pour moi... Certaines adresses sont valides, d'autres totalement fantaisistes.
Les logs du serveur SSH ?
Sebastien Monbrun aka TiChou
Dans le message <news:, *aze* tapota sur f.c.o.l.configuration :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont l'état est INVALID, dont l'adresse est usurpée ou dont le type est suspicieux.
Dans le cas en question, ça s'applique parfaitement aux tentatives de connexions SSH automatisées,
Faut-il les détecter comme il faut. Laisser le firewall «DROPer» systématiquement et automatiquement les connexions intempestives est, à mon humble avis, risqué. C'est un moyen qui peut vite être détourné à l'encontre de l'usager normal via un déni de service par usurpation de son adresse IP.
Attend, je ne comprend pas ta logique: Tu as un usagé "normal" qui a un ordinateur piraté... Mais dans ce cas là, peut-on encore dire que son ordinateur est "normal" et donc doit-on faire de la politesse avec lui ?
Je le répète, il ne s'agit pas d'être poli avec les « vilains » mais de l'être avec les usagers normaux. Une bonne politique de sécurité se doit d'être la moins contraignante possible pour une utilisation standard. La lutte contre les « vilains » doit éviter d'aller à l'encontre des « gentils ». Or l'efficacité d'un tel filtrage (celui de « DROPer » automatiquement) est douteuse et apporte généralement plus de contrainte, sans parler du risque du déni de service.
Vouloir se barricader à tout prix, en oubliant volontairement certains principes et fondements des communications réseaux, démontre un problème de compétence ou d'une « parano » injustifiée.
Autre version son ordinateur n'est pas piraté et c'est juste une usurpation d'adresse par un serveur de nom traffiqué,
Je ne vois pas comment une adresse IP pourrait être usurpée en « trafiquant » un serveur de nom.
donc dans ce cas là tu dis à la personne qui ne t'a pas contactée: "désolé mais vous n'avez pas accés ici"... Moui, disons que si le crackeur est retord et qu'il emploi certaines adresses en .gov tu vas vite avoir une surprise.
Je n'ai pas compris ici votre remarque. Et de quelle surprise parlez-vous ?
J'estime que le comportement par défaut d'un firewall est de respecté au mieux les règles. Ensuite, rien n'empêche de faire des exceptions mais en évitant l'automatisation de ces exceptions.
Sachant la vitesse à laquelle tout cela se passe ?
Désolé, pas compris où vous vouliez en venir.
Le DROP s'impose donc,
Je ne vois pas pourquoi, un REJECT n'est guère plus couteux.
Un REJECT entraine une réponse de ta part
Oui. Minime, soulignons le.
qui peu et certainement va être analysée (à par script bien sûr),
Admettons. Et ensuite ? Que craignez-vous de cette éventuelle analyse ? Pensez-vous qu'en vous cachant vous serez réellement ou mieux protégé ? Ou bien ne pensez-vous pas que vous allez plutôt attiser la curiosité ?
un REJECT c'est faire bien trop d'honneur aux script kiddies.
Le but n'est pas de respecter les automates et autres pirates, mais de respecter au mieux les utilisations normales ou erronées.
Une utilisation normale fait rarement appel à SSH.
Ici il s'agit de SSH. Mais le problème serait le même s'il s'agissait d'un service mail, web ou autre.
Une autorisation erronées, j'entend qui fait une erreur d'adresse ip par exemple, ne la refait pas plus d'une voir deux fois. Après... Comment appelles-tu cela d'ailleurs ? Une erreur de programmation sur un retour d'erreur d'ip qui bouclerait en incrémentant sans le vouloir dans le fichier le plus proche sur le disque dur qui justement est un dictionnaire ? <8°P
Ce n'est pas le jeu de règles iptables qui a été suggéré par l'OP, qui peut détecter efficacement et empêcher ce genre d'attaque. Ce n'est pas non plus une quelconque règle iptables qui pourrait accomplir cette tâche. Il faut un IDS derrière ou bien un filtre applicatif avancé. Le plus simple est de ne pas tenir compte de ces attaques mais de s'assurer d'avoir ses services correctement configurés et à jour. Si on craint le déni de service, par exemple avec des tentatives de connexion en masse, on peut utiliser le match limit.
Je ne comprends pas ton raisonnement,
Permettez moi de vous retourner cette remarque. :-) J'avoue n'avoir pas compris où vous vouliez en venir. J'avoue aussi ne pas comprendre en quoi mon point de vue vous paraît contraignant et illogique.
pour moi j'ai l'impression que tu fait plutôt du social (pour ainsi dire)
Appelez ça comme vous voulez. :-) L'expérience m'a plus d'une fois démontré qu'il valait mieux, en sécurité, faire du « social » que de la « répression » à tout va.
alors qu'il essaye de se proteger.
Se protéger de quoi ? D'une attaque sans réelle conséquence et nuisance ?
La discussion se portant essentiellement sur une politique de sécurité, je vous invite à poursuivre la discussion sur le groupe fr.comp.securite vers lequel je place un fu2.
xpost+fu fc.securite
-- Sébastien Monbrun aka TiChou
Dans le message <news:pan.2006.03.08.22.53.11.14212@aze>,
*aze* tapota sur f.c.o.l.configuration :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont
l'état est INVALID, dont l'adresse est usurpée ou dont le type est
suspicieux.
Dans le cas en question, ça s'applique parfaitement aux tentatives de
connexions SSH automatisées,
Faut-il les détecter comme il faut. Laisser le firewall «DROPer»
systématiquement et automatiquement les connexions intempestives est, à
mon humble avis, risqué. C'est un moyen qui peut vite être détourné à
l'encontre de l'usager normal via un déni de service par usurpation de
son adresse IP.
Attend, je ne comprend pas ta logique:
Tu as un usagé "normal" qui a un ordinateur piraté... Mais dans ce cas
là, peut-on encore dire que son ordinateur est "normal" et donc doit-on
faire de la politesse avec lui ?
Je le répète, il ne s'agit pas d'être poli avec les « vilains » mais de
l'être avec les usagers normaux. Une bonne politique de sécurité se doit
d'être la moins contraignante possible pour une utilisation standard. La
lutte contre les « vilains » doit éviter d'aller à l'encontre des «
gentils ».
Or l'efficacité d'un tel filtrage (celui de « DROPer » automatiquement) est
douteuse et apporte généralement plus de contrainte, sans parler du risque
du déni de service.
Vouloir se barricader à tout prix, en oubliant volontairement certains
principes et fondements des communications réseaux, démontre un problème de
compétence ou d'une « parano » injustifiée.
Autre version son ordinateur n'est pas piraté et c'est juste une
usurpation d'adresse par un serveur de nom traffiqué,
Je ne vois pas comment une adresse IP pourrait être usurpée en «
trafiquant » un serveur de nom.
donc dans ce cas là tu dis à la personne qui ne t'a pas contactée: "désolé
mais vous n'avez pas accés ici"... Moui, disons que si le crackeur est
retord et qu'il emploi certaines adresses en .gov tu vas vite avoir une
surprise.
Je n'ai pas compris ici votre remarque. Et de quelle surprise parlez-vous ?
J'estime que le comportement par défaut d'un firewall est de respecté
au mieux les règles. Ensuite, rien n'empêche de faire des exceptions
mais en évitant l'automatisation de ces exceptions.
Sachant la vitesse à laquelle tout cela se passe ?
Désolé, pas compris où vous vouliez en venir.
Le DROP s'impose donc,
Je ne vois pas pourquoi, un REJECT n'est guère plus couteux.
Un REJECT entraine une réponse de ta part
Oui. Minime, soulignons le.
qui peu et certainement va être analysée (à par script bien sûr),
Admettons. Et ensuite ? Que craignez-vous de cette éventuelle analyse ?
Pensez-vous qu'en vous cachant vous serez réellement ou mieux protégé ? Ou
bien ne pensez-vous pas que vous allez plutôt attiser la curiosité ?
un REJECT c'est faire bien trop d'honneur aux script kiddies.
Le but n'est pas de respecter les automates et autres pirates, mais de
respecter au mieux les utilisations normales ou erronées.
Une utilisation normale fait rarement appel à SSH.
Ici il s'agit de SSH. Mais le problème serait le même s'il s'agissait d'un
service mail, web ou autre.
Une autorisation erronées, j'entend qui fait une erreur d'adresse ip par
exemple, ne la refait pas plus d'une voir deux fois.
Après... Comment appelles-tu cela d'ailleurs ? Une erreur de
programmation sur un retour d'erreur d'ip qui bouclerait en incrémentant
sans le vouloir dans le fichier le plus proche sur le disque dur qui
justement est un dictionnaire ? <8°P
Ce n'est pas le jeu de règles iptables qui a été suggéré par l'OP, qui peut
détecter efficacement et empêcher ce genre d'attaque. Ce n'est pas non plus
une quelconque règle iptables qui pourrait accomplir cette tâche. Il faut un
IDS derrière ou bien un filtre applicatif avancé.
Le plus simple est de ne pas tenir compte de ces attaques mais de s'assurer
d'avoir ses services correctement configurés et à jour. Si on craint le déni
de service, par exemple avec des tentatives de connexion en masse, on peut
utiliser le match limit.
Je ne comprends pas ton raisonnement,
Permettez moi de vous retourner cette remarque. :-)
J'avoue n'avoir pas compris où vous vouliez en venir. J'avoue aussi ne pas
comprendre en quoi mon point de vue vous paraît contraignant et illogique.
pour moi j'ai l'impression que tu fait plutôt du social (pour ainsi dire)
Appelez ça comme vous voulez. :-) L'expérience m'a plus d'une fois démontré
qu'il valait mieux, en sécurité, faire du « social » que de la «
répression » à tout va.
alors qu'il essaye de se proteger.
Se protéger de quoi ? D'une attaque sans réelle conséquence et nuisance ?
La discussion se portant essentiellement sur une politique de sécurité, je
vous invite à poursuivre la discussion sur le groupe fr.comp.securite vers
lequel je place un fu2.
Dans le message <news:, *aze* tapota sur f.c.o.l.configuration :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont l'état est INVALID, dont l'adresse est usurpée ou dont le type est suspicieux.
Dans le cas en question, ça s'applique parfaitement aux tentatives de connexions SSH automatisées,
Faut-il les détecter comme il faut. Laisser le firewall «DROPer» systématiquement et automatiquement les connexions intempestives est, à mon humble avis, risqué. C'est un moyen qui peut vite être détourné à l'encontre de l'usager normal via un déni de service par usurpation de son adresse IP.
Attend, je ne comprend pas ta logique: Tu as un usagé "normal" qui a un ordinateur piraté... Mais dans ce cas là, peut-on encore dire que son ordinateur est "normal" et donc doit-on faire de la politesse avec lui ?
Je le répète, il ne s'agit pas d'être poli avec les « vilains » mais de l'être avec les usagers normaux. Une bonne politique de sécurité se doit d'être la moins contraignante possible pour une utilisation standard. La lutte contre les « vilains » doit éviter d'aller à l'encontre des « gentils ». Or l'efficacité d'un tel filtrage (celui de « DROPer » automatiquement) est douteuse et apporte généralement plus de contrainte, sans parler du risque du déni de service.
Vouloir se barricader à tout prix, en oubliant volontairement certains principes et fondements des communications réseaux, démontre un problème de compétence ou d'une « parano » injustifiée.
Autre version son ordinateur n'est pas piraté et c'est juste une usurpation d'adresse par un serveur de nom traffiqué,
Je ne vois pas comment une adresse IP pourrait être usurpée en « trafiquant » un serveur de nom.
donc dans ce cas là tu dis à la personne qui ne t'a pas contactée: "désolé mais vous n'avez pas accés ici"... Moui, disons que si le crackeur est retord et qu'il emploi certaines adresses en .gov tu vas vite avoir une surprise.
Je n'ai pas compris ici votre remarque. Et de quelle surprise parlez-vous ?
J'estime que le comportement par défaut d'un firewall est de respecté au mieux les règles. Ensuite, rien n'empêche de faire des exceptions mais en évitant l'automatisation de ces exceptions.
Sachant la vitesse à laquelle tout cela se passe ?
Désolé, pas compris où vous vouliez en venir.
Le DROP s'impose donc,
Je ne vois pas pourquoi, un REJECT n'est guère plus couteux.
Un REJECT entraine une réponse de ta part
Oui. Minime, soulignons le.
qui peu et certainement va être analysée (à par script bien sûr),
Admettons. Et ensuite ? Que craignez-vous de cette éventuelle analyse ? Pensez-vous qu'en vous cachant vous serez réellement ou mieux protégé ? Ou bien ne pensez-vous pas que vous allez plutôt attiser la curiosité ?
un REJECT c'est faire bien trop d'honneur aux script kiddies.
Le but n'est pas de respecter les automates et autres pirates, mais de respecter au mieux les utilisations normales ou erronées.
Une utilisation normale fait rarement appel à SSH.
Ici il s'agit de SSH. Mais le problème serait le même s'il s'agissait d'un service mail, web ou autre.
Une autorisation erronées, j'entend qui fait une erreur d'adresse ip par exemple, ne la refait pas plus d'une voir deux fois. Après... Comment appelles-tu cela d'ailleurs ? Une erreur de programmation sur un retour d'erreur d'ip qui bouclerait en incrémentant sans le vouloir dans le fichier le plus proche sur le disque dur qui justement est un dictionnaire ? <8°P
Ce n'est pas le jeu de règles iptables qui a été suggéré par l'OP, qui peut détecter efficacement et empêcher ce genre d'attaque. Ce n'est pas non plus une quelconque règle iptables qui pourrait accomplir cette tâche. Il faut un IDS derrière ou bien un filtre applicatif avancé. Le plus simple est de ne pas tenir compte de ces attaques mais de s'assurer d'avoir ses services correctement configurés et à jour. Si on craint le déni de service, par exemple avec des tentatives de connexion en masse, on peut utiliser le match limit.
Je ne comprends pas ton raisonnement,
Permettez moi de vous retourner cette remarque. :-) J'avoue n'avoir pas compris où vous vouliez en venir. J'avoue aussi ne pas comprendre en quoi mon point de vue vous paraît contraignant et illogique.
pour moi j'ai l'impression que tu fait plutôt du social (pour ainsi dire)
Appelez ça comme vous voulez. :-) L'expérience m'a plus d'une fois démontré qu'il valait mieux, en sécurité, faire du « social » que de la « répression » à tout va.
alors qu'il essaye de se proteger.
Se protéger de quoi ? D'une attaque sans réelle conséquence et nuisance ?
La discussion se portant essentiellement sur une politique de sécurité, je vous invite à poursuivre la discussion sur le groupe fr.comp.securite vers lequel je place un fu2.
xpost+fu fc.securite
-- Sébastien Monbrun aka TiChou
octane
Euh, je vois mal comment on peut espérer établir une connexion TCP et à plus forte raison SSH avec une adresse source invalide, forgée ou privée, c'est-à-dire en aveugle... :-
http://www.gulker.com/ra/hack/tsattack.html
pour du ssh en spoof, ca me parait quand meme plus dur..
Euh, je vois mal comment on peut espérer établir une connexion TCP et à
plus forte raison SSH avec une adresse source invalide, forgée ou
privée, c'est-à-dire en aveugle... :-
http://www.gulker.com/ra/hack/tsattack.html
pour du ssh en spoof, ca me parait quand meme plus dur..
Euh, je vois mal comment on peut espérer établir une connexion TCP et à plus forte raison SSH avec une adresse source invalide, forgée ou privée, c'est-à-dire en aveugle... :-
http://www.gulker.com/ra/hack/tsattack.html
pour du ssh en spoof, ca me parait quand meme plus dur..
Emmanuel Florac
Le Thu, 09 Mar 2006 12:13:04 +0100, Pascal Hambourg a écrit :
Les logs du serveur SSH ?
Voui, bien sûr.
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
Le Thu, 09 Mar 2006 12:13:04 +0100, Pascal Hambourg a écrit :
Les logs du serveur SSH ?
Voui, bien sûr.
--
Le travail est la malédiction des classes qui boivent.
O. Wilde.
