Re: [HS][up!] fail2ban
as-tu aussi un fichier iptables-blocktype.conf dans action.d ? https://github.com/sergejmueller/fail2ban/blob/master/action.d/ iptables-blocktype.conf Le 2 févr. 15 à 17:43, BERTRAND Joël a écrit : Philippe Gras a écrit : Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit : Philippe Gras a écrit : Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit : Philippe Gras a écrit : Je rencontre un problème sur les tentatives d'exploits (casser un mot de passe en testant des milliers de combinaisons possibles). Chez moi, fail2ban bannit bien les IP, mais l'attaque continue… Chez moi aussi, ça fait ça, mais comme les attaquants sont décorrélés, pas de problème. J'ai eu des queues de bannis de plus de 50 machines et la cible récidive fonctionne parfaitement. En revanche, je ferme autoritairement la connexion avec un ICMP bien senti, je n'attends pas que la connexion se ferme d'elle même en DROPant le paquet. Ça aide un peu... Ah, OK ! Peux-tu expliquer comment tu fermes autoritairement la connexion avec un ICMP bien senti ? Au lieu de garder la configuration par défaut (d'il y a très longtemps, je n'ai pas vérifié si cette configuration avait changé récemment) qui installe un DROP, mes règles installent un REJET avec --reject-with icmp-port-unreachable Tu veux parler de la configuration de fail2ban, c'est ça ? Oui. Ça t'ennuierait de communiquer ta conf. perso, que je la recopie chez moi ? (… et d'autres sur la liste éventuellement aussi, parce que ça a l'air trop cool) Si tu le dis... Elle n'a rien d'extraordinaire. Dans jail.conf, j'ai un : banaction = iptables46-multiport - ipv4 _et_ ipv6 et dans action.d/iptables-common.conf un : blocktype = REJECT --reject-with icmp-port-unreachable Le reste ressemble assez à une configuration par défaut. Encore une fois, je n'ai pas suivi les évolutions de la configuration par défaut et je ne sais pas comment est configuré un fail2ban récent out of the box. JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54cfa91c.70...@systella.fr -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/e1ffb3ed-8021-44ac-aea2-3bc10ea35...@worldonline.fr
Re: upgrade : garder ou télécharger le fichier.conf
Le 2 févr. 15 à 21:05, andre_deb...@numericable.fr a écrit : Bonsoir, Dans un upgrade de système et que l'installation demande si on souhaite : - garder le paquet.conf - télécharger le nouveau paquet .conf Que faut-il répondre ? Si on choisit télécharger le nouveau paquet .conf contiendra t-il les anciennes configurations et options mises par l'utilisateur de l'ancien fichier ? Non, le nouveau paquet.conf ne contient que les nouvelles configurations. Par contre, il est peut-être nécessaire pour faire fonctionner le programme mis à jour. Il vaut mieux l'accepter quand même, mais en ayant pris soin de mettre une copie de sauvegarde de son ancien paquet.conf quelque part où on pourra y piocher ses propres paramètres. J'ai eu le problème avec mon dernier upgrade, et j'ai dû refaire l'opération en acceptant le nouveau paquet pour que ça marche. Merci. André -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/ 201502022105.57314.andre_deb...@numericable.fr -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/70d59798-05b0-42f8-aec3-fa2e48e19...@worldonline.fr
upgrade : garder ou télécharger le fichier.conf
Bonsoir, Dans un upgrade de système et que l'installation demande si on souhaite : - garder le paquet.conf - télécharger le nouveau paquet .conf Que faut-il répondre ? Si on choisit télécharger le nouveau paquet .conf contiendra t-il les anciennes configurations et options mises par l'utilisateur de l'ancien fichier ? Merci. André -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201502022105.57314.andre_deb...@numericable.fr
Re: upgrade : garder ou télécharger le fichier.conf
Le lundi 2 février 2015, 21:50:14 Philippe Gras a écrit : Le 2 févr. 15 à 21:05, andre_deb...@numericable.fr a écrit : Bonsoir, ’soir, Dans un upgrade de système et que l'installation demande si on souhaite : - garder le paquet.conf - télécharger le nouveau paquet .conf Gni ? « Télécharger » ? « Installer », je vois souvent. « Télécharger », j’ai jamais vu… […] Il vaut mieux l'accepter quand même, mais en ayant pris soin de mettre une copie de sauvegarde de son ancien paquet.conf quelque part où on pourra y piocher ses propres paramètres. Si on accepte le nouveau, l’ancien est renommé en .dpkg-old. Si on garde le sien, le nouveau est installé en .dpkg-dist. Donc on peut regarder ça à tête reposée (en plus de l’option à chaud, non citée, « voir le diff »). (Il y a aussi des .dpkg-bak et des .dpkg-remove…) Si on a une configuration très différente de la configuration de base, utiliser un gestionnaire de versions (git, hg…) me semble une bonne idée. Si on fait rarement des modifs, bien commenter le but de la modif (voire le noter ailleurs, pour pouvoir l’appliquer… ailleurs). Une bonne doc. évite le « mais non j’ai jamais touché à ça, écrase tout… ah tiens ça marche plus comme avant »… -- Sylvain Sauvage -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/1689941.7xt8eY1EqE@earendil
Re: Faille critique découverte dans GLIBC
Bonjour, Voilà, je m'absente quelques jours et vous continuez sans moi ! Très intéressante cette discussion, merci à tous. Le samedi 31 janvier 2015 à 9:57, mrr a écrit : Essaye lsof. Avec ou sans argument si tu veux une _longue_ liste. Y'a aussi une autre commande de ce gout dont je me rappelle plus là. Ça ne serait pas la commande « fuser » par hasard ? « fuser - identify processes using files or sockets » Seb -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150202102038.gd13...@sebian.nob900.homeip.net
Re: Faire une migration d'un système dans sa partition chrootée
Le vendredi 30 janvier 2015 à 15:20, Samy Mezani a écrit : Le 30/01/2015 15:08, andre_deb...@numericable.fr a écrit : Je monte et chroot cette 2ème partition et lance les commandes de migration... qui devraient upgrader Wheezy n°2. C'est ça, tu montes ta racine 2 dans un point de montage de ta partition 1 Tu montes également /dev, /dev/pts, et je ne sais plus si c'est nécessaire /proc et /sys (d'après https://wiki.debian.org/chroot ce n'est pas utile) : mount --bind /dev/pts /partition1/pointdemontage/dev/pts etc. Depuis que j'utilise « schroot » (paquet éponyme), je n'ai plus à me soucier de tous les montages « bind », il le fait pour moi. Je peux même « entrer dans » mon chroot sans passer root avant. Je vous le recommande. Seb -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150202102627.ge13...@sebian.nob900.homeip.net
Re: [HS][up!] fail2ban
Philippe Gras a écrit : Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit : Philippe Gras a écrit : Je rencontre un problème sur les tentatives d'exploits (casser un mot de passe en testant des milliers de combinaisons possibles). Chez moi, fail2ban bannit bien les IP, mais l'attaque continue… Chez moi aussi, ça fait ça, mais comme les attaquants sont décorrélés, pas de problème. J'ai eu des queues de bannis de plus de 50 machines et la cible récidive fonctionne parfaitement. En revanche, je ferme autoritairement la connexion avec un ICMP bien senti, je n'attends pas que la connexion se ferme d'elle même en DROPant le paquet. Ça aide un peu... Ah, OK ! Peux-tu expliquer comment tu fermes autoritairement la connexion avec un ICMP bien senti ? Au lieu de garder la configuration par défaut (d'il y a très longtemps, je n'ai pas vérifié si cette configuration avait changé récemment) qui installe un DROP, mes règles installent un REJET avec --reject-with icmp-port-unreachable Tu veux parler de la configuration de fail2ban, c'est ça ? Oui. Si je comprends bien, tu aurais le même problème que moi si tu attendais que la connexion se fermât Oui j'ai eu ce genre de problème par le passé. En plus, lorsqu'on parle au zombie, il passe à autre chose plus vite, c'est tout bénef :-P Que veux-tu dire par-là ? Casser la connexion avec un DROP ou un REJECT, ce n'est pas la même chose finalement ? Non, ce n'est pas la même chose. DROP, le paquet de l'émetteur tombe dans un trou noir et la connexion tombe par un timeout côté émetteur. Avec un REJECT, j'informe explicitement l'émetteur que le port est fermé en coupant la communication de mon côté. Si l'émetteur n'est pas trop idiot, il passe à autre chose. JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54cf9c1d.7040...@systella.fr
Re: [HS][up!] fail2ban
Pardon de remonter ce sujet. As-tu réussi à stopper ces attaques avec fail2ban, finalement ? Je rencontre un problème sur les tentatives d'exploits (casser un mot de passe en testant des milliers de combinaisons possibles). Chez moi, fail2ban bannit bien les IP, mais l'attaque continue… Le 14 janv. 15 à 22:50, BERTRAND Joël a écrit : Bonsoir à tous, J'observe un comportement étrange sans savoir si ce comportement est provoqué par le patch IPv6 (mais il n'a rien de complexe) ou si c'est dû à l'augmentation ces derniers jours des attaques. En effet, j'ai un /29 et je subis actuellement en IPv4 des attaques sur toutes les IP à un rythme soutenu. […] JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54b6e498.4050...@systella.fr -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/cc8dc30a-a4a0-419c-a44a-ff2c1749a...@worldonline.fr
Re: [HS][up!] fail2ban
Philippe Gras a écrit : Je rencontre un problème sur les tentatives d'exploits (casser un mot de passe en testant des milliers de combinaisons possibles). Chez moi, fail2ban bannit bien les IP, mais l'attaque continue… Chez moi aussi, ça fait ça, mais comme les attaquants sont décorrélés, pas de problème. J'ai eu des queues de bannis de plus de 50 machines et la cible récidive fonctionne parfaitement. En revanche, je ferme autoritairement la connexion avec un ICMP bien senti, je n'attends pas que la connexion se ferme d'elle même en DROPant le paquet. Ça aide un peu... Ah, OK ! Peux-tu expliquer comment tu fermes autoritairement la connexion avec un ICMP bien senti ? Au lieu de garder la configuration par défaut (d'il y a très longtemps, je n'ai pas vérifié si cette configuration avait changé récemment) qui installe un DROP, mes règles installent un REJET avec --reject-with icmp-port-unreachable Si je comprends bien, tu aurais le même problème que moi si tu attendais que la connexion se fermât Oui j'ai eu ce genre de problème par le passé. En plus, lorsqu'on parle au zombie, il passe à autre chose plus vite, c'est tout bénef :-P JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54cf9615.3030...@systella.fr
Re: [HS][up!] fail2ban
Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit : Philippe Gras a écrit : Je rencontre un problème sur les tentatives d'exploits (casser un mot de passe en testant des milliers de combinaisons possibles). Chez moi, fail2ban bannit bien les IP, mais l'attaque continue… Chez moi aussi, ça fait ça, mais comme les attaquants sont décorrélés, pas de problème. J'ai eu des queues de bannis de plus de 50 machines et la cible récidive fonctionne parfaitement. En revanche, je ferme autoritairement la connexion avec un ICMP bien senti, je n'attends pas que la connexion se ferme d'elle même en DROPant le paquet. Ça aide un peu... Ah, OK ! Peux-tu expliquer comment tu fermes autoritairement la connexion avec un ICMP bien senti ? Au lieu de garder la configuration par défaut (d'il y a très longtemps, je n'ai pas vérifié si cette configuration avait changé récemment) qui installe un DROP, mes règles installent un REJET avec --reject-with icmp-port-unreachable Tu veux parler de la configuration de fail2ban, c'est ça ? Si je comprends bien, tu aurais le même problème que moi si tu attendais que la connexion se fermât Oui j'ai eu ce genre de problème par le passé. En plus, lorsqu'on parle au zombie, il passe à autre chose plus vite, c'est tout bénef :-P Que veux-tu dire par-là ? Casser la connexion avec un DROP ou un REJECT, ce n'est pas la même chose finalement ? JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54cf9615.3030...@systella.fr -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/15dad622-f74d-44b4-9acd-d42772c69...@worldonline.fr
Re: [HS][up!] fail2ban
Philippe Gras a écrit : Pardon de remonter ce sujet. As-tu réussi à stopper ces attaques avec fail2ban, finalement ? Oui, ça s'est calmé, mais il y a eu une quinzaine de jours assez folkloriques. Je rencontre un problème sur les tentatives d'exploits (casser un mot de passe en testant des milliers de combinaisons possibles). Chez moi, fail2ban bannit bien les IP, mais l'attaque continue… Chez moi aussi, ça fait ça, mais comme les attaquants sont décorrélés, pas de problème. J'ai eu des queues de bannis de plus de 50 machines et la cible récidive fonctionne parfaitement. En revanche, je ferme autoritairement la connexion avec un ICMP bien senti, je n'attends pas que la connexion se ferme d'elle même en DROPant le paquet. Ça aide un peu... Cordialement, JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54cf8e2a.5050...@systella.fr
Re: [HS][up!] fail2ban
Je rencontre un problème sur les tentatives d'exploits (casser un mot de passe en testant des milliers de combinaisons possibles). Chez moi, fail2ban bannit bien les IP, mais l'attaque continue… Chez moi aussi, ça fait ça, mais comme les attaquants sont décorrélés, pas de problème. J'ai eu des queues de bannis de plus de 50 machines et la cible récidive fonctionne parfaitement. En revanche, je ferme autoritairement la connexion avec un ICMP bien senti, je n'attends pas que la connexion se ferme d'elle même en DROPant le paquet. Ça aide un peu... Ah, OK ! Peux-tu expliquer comment tu fermes autoritairement la connexion avec un ICMP bien senti ? Si je comprends bien, tu aurais le même problème que moi si tu attendais que la connexion se fermât naturellement, à moins qu'il ne s'agisse pas du même type d'attaques… Cordialement, JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/79c86362-0bb9-41e9-884d-d9253edd7...@worldonline.fr
Re: [HS][up!] fail2ban
Philippe Gras a écrit : as-tu aussi un fichier iptables-blocktype.conf dans action.d ? https://github.com/sergejmueller/fail2ban/blob/master/action.d/iptables-blocktype.conf Non. Mon fail2ban est un fail2ban d'origine contrôlée patché pour qu'il surveille aussi IPv6. Je n'ai pas cherché à le modifier. JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54d07ad5.6080...@systella.fr
Re: [HS][up!] fail2ban
Philippe Gras a écrit : Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit : Philippe Gras a écrit : Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit : Philippe Gras a écrit : Je rencontre un problème sur les tentatives d'exploits (casser un mot de passe en testant des milliers de combinaisons possibles). Chez moi, fail2ban bannit bien les IP, mais l'attaque continue… Chez moi aussi, ça fait ça, mais comme les attaquants sont décorrélés, pas de problème. J'ai eu des queues de bannis de plus de 50 machines et la cible récidive fonctionne parfaitement. En revanche, je ferme autoritairement la connexion avec un ICMP bien senti, je n'attends pas que la connexion se ferme d'elle même en DROPant le paquet. Ça aide un peu... Ah, OK ! Peux-tu expliquer comment tu fermes autoritairement la connexion avec un ICMP bien senti ? Au lieu de garder la configuration par défaut (d'il y a très longtemps, je n'ai pas vérifié si cette configuration avait changé récemment) qui installe un DROP, mes règles installent un REJET avec --reject-with icmp-port-unreachable Tu veux parler de la configuration de fail2ban, c'est ça ? Oui. Ça t'ennuierait de communiquer ta conf. perso, que je la recopie chez moi ? (… et d'autres sur la liste éventuellement aussi, parce que ça a l'air trop cool) Si tu le dis... Elle n'a rien d'extraordinaire. Dans jail.conf, j'ai un : banaction = iptables46-multiport - ipv4 _et_ ipv6 et dans action.d/iptables-common.conf un : blocktype = REJECT --reject-with icmp-port-unreachable Le reste ressemble assez à une configuration par défaut. Encore une fois, je n'ai pas suivi les évolutions de la configuration par défaut et je ne sais pas comment est configuré un fail2ban récent out of the box. JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54cfa91c.70...@systella.fr
Re: [HS][up!] fail2ban
Le 2 févr. 15 à 17:43, BERTRAND Joël a écrit : Philippe Gras a écrit : Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit : Philippe Gras a écrit : Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit : Philippe Gras a écrit : Je rencontre un problème sur les tentatives d'exploits (casser un mot de passe en testant des milliers de combinaisons possibles). Chez moi, fail2ban bannit bien les IP, mais l'attaque continue… Chez moi aussi, ça fait ça, mais comme les attaquants sont décorrélés, pas de problème. J'ai eu des queues de bannis de plus de 50 machines et la cible récidive fonctionne parfaitement. En revanche, je ferme autoritairement la connexion avec un ICMP bien senti, je n'attends pas que la connexion se ferme d'elle même en DROPant le paquet. Ça aide un peu... Ah, OK ! Peux-tu expliquer comment tu fermes autoritairement la connexion avec un ICMP bien senti ? Au lieu de garder la configuration par défaut (d'il y a très longtemps, je n'ai pas vérifié si cette configuration avait changé récemment) qui installe un DROP, mes règles installent un REJET avec --reject-with icmp-port-unreachable Tu veux parler de la configuration de fail2ban, c'est ça ? Oui. Ça t'ennuierait de communiquer ta conf. perso, que je la recopie chez moi ? (… et d'autres sur la liste éventuellement aussi, parce que ça a l'air trop cool) Si tu le dis... Elle n'a rien d'extraordinaire. Dans jail.conf, j'ai un : banaction = iptables46-multiport - ipv4 _et_ ipv6 et dans action.d/iptables-common.conf un : blocktype = REJECT --reject-with icmp-port-unreachable Merci :-) C'est en effet cette ligne qui m'intéresse tout particulièrement. Le reste ressemble assez à une configuration par défaut. Encore une fois, je n'ai pas suivi les évolutions de la configuration par défaut et je ne sais pas comment est configuré un fail2ban récent out of the box. De toute façon, ma configuration non plus n'a plus grand-chose à voir avec celle d'origine. Même si mes paquets datent du 25 décembre de l'année dernière… Vu que je tourne avec NginX, j'ai dû créer plein de filtres et une partie de mes sites transitent par Cloudflare, ce qui a des conséquences aussi sur le traitement des actions. JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54cfa91c.70...@systella.fr
Re: [HS][up!] fail2ban
Le 2 févr. 15 à 16:47, BERTRAND Joël a écrit : Philippe Gras a écrit : Le 2 févr. 15 à 16:21, BERTRAND Joël a écrit : Philippe Gras a écrit : Je rencontre un problème sur les tentatives d'exploits (casser un mot de passe en testant des milliers de combinaisons possibles). Chez moi, fail2ban bannit bien les IP, mais l'attaque continue… Chez moi aussi, ça fait ça, mais comme les attaquants sont décorrélés, pas de problème. J'ai eu des queues de bannis de plus de 50 machines et la cible récidive fonctionne parfaitement. En revanche, je ferme autoritairement la connexion avec un ICMP bien senti, je n'attends pas que la connexion se ferme d'elle même en DROPant le paquet. Ça aide un peu... Ah, OK ! Peux-tu expliquer comment tu fermes autoritairement la connexion avec un ICMP bien senti ? Au lieu de garder la configuration par défaut (d'il y a très longtemps, je n'ai pas vérifié si cette configuration avait changé récemment) qui installe un DROP, mes règles installent un REJET avec --reject-with icmp-port-unreachable Tu veux parler de la configuration de fail2ban, c'est ça ? Oui. Ça t'ennuierait de communiquer ta conf. perso, que je la recopie chez moi ? (… et d'autres sur la liste éventuellement aussi, parce que ça a l'air trop cool) Si je comprends bien, tu aurais le même problème que moi si tu attendais que la connexion se fermât Oui j'ai eu ce genre de problème par le passé. En plus, lorsqu'on parle au zombie, il passe à autre chose plus vite, c'est tout bénef :-P Que veux-tu dire par-là ? Casser la connexion avec un DROP ou un REJECT, ce n'est pas la même chose finalement ? Non, ce n'est pas la même chose. DROP, le paquet de l'émetteur tombe dans un trou noir et la connexion tombe par un timeout côté émetteur. Avec un REJECT, j'informe explicitement l'émetteur que le port est fermé en coupant la communication de mon côté. Si l'émetteur n'est pas trop idiot, il passe à autre chose. Dans ma petite tête, je pensais que les mecs lançaient leur logiciel avant d'aller faire la bringue en fumant des joints, avec leurs copains de la mafia russe… J'ai des requêtes en forbidden qui commencent le soir et se terminent vers 7h00 le lendemain matin, j'ai pas l'impression que ça les formalise plus que ça ! JKB -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/54cf9c1d.7040...@systella.fr -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/a25736b2-0eaf-4c6f-b018-4bb511e56...@worldonline.fr
