Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 14 juin 14 à 13:02, Pascal Hambourg a écrit : Philippe Gras a écrit : Le 07/06/2014 23:05, nb a écrit : INPUT ne sert pas pour une connexion déjà établie, seulement pour l'établissement d'une connexion (paquet tcp syn) Non. INPUT voit passer *tous* les paquets IP reçus destinés à la machine qui n'ont pas été bloqués avant. Je n'ai pas vu de forum ou de liste dédiée à Iptables En anglais : Liste Debian : debian-firew...@lists.debian.org Liste du noyau : netfil...@vger.kernel.org Merci :-) Il existe apparemment une différence dans le traitement des paquets par iptable selon leur état. Non. Toute différence de traitement selon l'état du paquet ne peut provenir que des règles mises en place. La seule exception, c'est le fonctionnement de la table 'nat'. Si iptables ne fait pas ce que tu veux, alors c'est que ton jeu de règles est à revoir. J'ai compris. -- 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/539c2bd2.6070...@plouf.fr.eu.org -- 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/df4e6241-44bd-4434-98a1-664a4c71f...@worldonline.fr
Re: [IPTABLES] Comment lister les paquets rejetés ?
Philippe Gras a écrit : Le 07/06/2014 23:05, nb a écrit : INPUT ne sert pas pour une connexion déjà établie, seulement pour l'établissement d'une connexion (paquet tcp syn) Non. INPUT voit passer *tous* les paquets IP reçus destinés à la machine qui n'ont pas été bloqués avant. Je n'ai pas vu de forum ou de liste dédiée à Iptables En anglais : Liste Debian : debian-firew...@lists.debian.org Liste du noyau : netfil...@vger.kernel.org Il existe apparemment une différence dans le traitement des paquets par iptable selon leur état. Non. Toute différence de traitement selon l'état du paquet ne peut provenir que des règles mises en place. La seule exception, c'est le fonctionnement de la table 'nat'. Si iptables ne fait pas ce que tu veux, alors c'est que ton jeu de règles est à revoir. -- 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/539c2bd2.6070...@plouf.fr.eu.org
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 07/06/14 à 18:16, Philippe Gras ph.g...@worldonline.fr a écrit : PG Pour ce qui est des 400, de certaines 404 et 403, je pense que tu PG peux t'inspirer de ça: PG http://spamcleaner.org/fr/misc/w00tw00t.html PG PG Je vais d'ailleurs le faire moi-même, parce que j'ai plein de PG requêtes avec cette chaîne : En quoi c'est gênant ? Répondre à ce genre de requete avec une 404 coûtera bcp moins de ressources qu'une règle iptables qui va analyser tous les paquets http. Si vraiment ça dérange, ajouter une règle nginx (location ~ w00tw00t) pour écrire l'ip dans un fichier tmp (sans passer par du php, avec echo dans nginx) et une tâche cron qui récupère les listes pour les blacklister avec iptables et les recopier ailleurs pour les enlever au prochain passage me parait plus efficace, mais j'ai jamais pris la peine de le faire malgré des milliers de requetes comme ça par jour. Même chose pour la dernière règle de la page, lancer une regex plus un algo pour les paquets qui match me parait un gaspillage important, mieux vaudrait créer un vhost par défaut qui va prendre les requetes directes sur l'ip (http://xxx.xxx.xxx.xxx/) pour bannir tout le monde qui arrive là (faudrait être sûr que les googlebot co lancent jamais ces requetes, pas étudié la question car me sens pas concerné avec un varnish en frontal). J'ai l'impression que ce genre de protection ne protège que des scripts kiddies assez inoffensifs, les vrais méchants sont pas assez stupides pour se faire repérer avec des attaques aussi connues. -- Daniel On croit mourir pour la patrie; on meurt pour des industriels. Anatole France -- 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/20140609133206.49bf7...@quad.lairdutemps.org
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 9 juin 14 à 13:32, Daniel Caillibaud a écrit : Le 07/06/14 à 18:16, Philippe Gras ph.g...@worldonline.fr a écrit : PG Pour ce qui est des 400, de certaines 404 et 403, je pense que tu PG peux t'inspirer de ça: PG http://spamcleaner.org/fr/misc/w00tw00t.html PG PG Je vais d'ailleurs le faire moi-même, parce que j'ai plein de PG requêtes avec cette chaîne : En quoi c'est gênant ? Répondre à ce genre de requete avec une 404 coûtera bcp moins de ressources qu'une règle iptables qui va analyser tous les paquets http. Ah, bon ? Je veux bien le croire, mais ça demande à être confirmé. Parce que si ce n'est pas iptables qui analyse les paquets, c'est le serveur virtuel qui va le faire ensuite, non ? Donc le résultat serait identique au niveau du temps d'attente, non ? Si vraiment ça dérange, ajouter une règle nginx (location ~ w00tw00t) pour écrire l'ip dans un fichier tmp (sans passer par du php, avec echo dans nginx) et une tâche cron qui récupère les listes pour les blacklister avec iptables et les recopier ailleurs pour les enlever au prochain passage me parait plus efficace, mais j'ai jamais pris la peine de le faire malgré des milliers de requetes comme ça par jour. Oui, ça me parait une bonne idée. Comment comparer la vitesse d'exécution des 2 règles ? Même chose pour la dernière règle de la page, lancer une regex plus un algo pour les paquets qui match me parait un gaspillage important, mieux vaudrait créer un vhost par défaut qui va prendre les requetes directes sur l'ip (http:// xxx.xxx.xxx.xxx/) pour bannir tout le monde qui arrive là (faudrait être sûr que les googlebot co lancent jamais ces requetes, pas étudié la question car me sens pas concerné avec un varnish en frontal). C'est déjà le cas chez moi. Je ne crois pas que les crawlers s'intéressent aux IP, je ne l'ai jamais remarqué. Mais ça pourrait venir, on ne sait jamais… J'ai l'impression que ce genre de protection ne protège que des scripts kiddies assez inoffensifs, les vrais méchants sont pas assez stupides pour se faire repérer avec des attaques aussi connues. Je suis complètement d'accord avec cette assertion. Le problème, c'est que les script kiddies sont très gourmands, et vraiment très envahissants. J'aimerais bien réserver l'accès de mon serveur à des utilisateurs légitimes, car il est tout petit, pas très costaud, donc le compromis est difficile à trouver entre une certaine tolérance avec les bots, et une discrimination rigoureuse… Ph. Gras -- Daniel On croit mourir pour la patrie; on meurt pour des industriels. Anatole France -- 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/ 20140609133206.49bf7...@quad.lairdutemps.org
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le Sun, 8 Jun 2014 18:29:41 +0200, Philippe Gras ph.g...@worldonline.fr a écrit : Le 8 juin 14 à 17:57, Francois Lafont a écrit : Juste pour conclure, je voulais ajouter ceci. Juste après un : iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP *pendant* l'attaque, il est tout à fait possible que ton serveur apache soit encore dans les choux. En effet, avant la mise en place des règles ci-dessus, des requêtes http étaient sûrement en cours et celles-là ton apache souhaite les honorer. Du coup, ton apache envoie tant bien que mal ses réponses aux méchants hôtes 72.44.248.136 et 66.23.229.10. Normalement, les 2 méchants sont censés envoyer un paquet d'acquittement comme quoi ils ont bien reçu la réponse du serveur. Mais ces paquets d'acquittement ne peuvent plus arriver car les 2 règles ci-dessus l'empêchent. Du coup, apache2 cherche à renvoyer à nouveau ses réponses etc. Et du coup, il continue à être dans les choux pendant un certain temps. Oui, c'est très possible. J'ai pensé à autre chose aussi, par rapport à ce que François réfute, c'est que j'ai aussi une règle dans mon firewall qui empêche les connexions établies d'être cassées. Il serait possible que je sois obligé de demander expressément de casser celles-là, et l'une après l'autre. Car l'attaquant n'en utilisait qu'une seule à la fois. En revanche, avec un truc du genre : 1. invoke-rc.d apache2 stop # on arrête toutes les connexions en cours. Oui, mais je marche avec NginX d'une part, et comme j'étais dessus aussi, je n'avais pas envie de me bannir moi-même. Ceci dit, j'avais installé précédemment un module limiteur qui existe sur le serveur NginX, mais ça n'a pas vraiment gêné le mec pour attaquer. 2. iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP 3. invoke-rc.d apache2 start il me semble que ton apache2 est serein aussitôt après et les 2 méchants hôtes ne peuvent plus l'embêter. J'ai l'impression qu'on était tous les 2 chacun de notre côté à contrer l'autre, et après que je l'ai eu droppé une première fois, il est revenu avec l'autre IP. -- François Lafont bonjour, serait-il possible d'indiquer la liste des paquets installés pour se protéger des attaques en installant : -a) denyhost -b) portsentry slt bernard -- 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/20140609192901.7ecc2d95@hamtaro
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 09/06/14 à 14:38, Philippe Gras ph.g...@worldonline.fr a écrit : PG PG Le 9 juin 14 à 13:32, Daniel Caillibaud a écrit : PG PG Le 07/06/14 à 18:16, Philippe Gras ph.g...@worldonline.fr a écrit : PG PG Pour ce qui est des 400, de certaines 404 et 403, je pense que tu PG PG peux t'inspirer de ça: PG PG http://spamcleaner.org/fr/misc/w00tw00t.html PG PG PG PG Je vais d'ailleurs le faire moi-même, parce que j'ai plein de PG PG requêtes avec cette chaîne : PG PG En quoi c'est gênant ? PG PG Répondre à ce genre de requete avec une 404 coûtera bcp moins de PG ressources qu'une règle PG iptables qui va analyser tous les paquets http. PG PG Ah, bon ? Je veux bien le croire, mais ça demande à être confirmé. PG Parce que si ce n'est pas PG iptables qui analyse les paquets, c'est le serveur virtuel qui va le PG faire ensuite, non ? Donc le PG résultat serait identique au niveau du temps d'attente, non ? Je pense pas, le serveur web n'aura que les urls à pbs à traiter, alors que iptable va traiter tous les paquets tcp du port 80. (chez moi les scripts kiddies c'est qq centaines de requetes, milliers quand ils s'excitent, sur pas mal de millions, j'ai jamais vu d'impact sur les temps de réponse des utilisateurs légitimes) PG Si vraiment ça dérange, ajouter une règle nginx (location ~ PG w00tw00t) pour écrire l'ip dans un PG fichier tmp (sans passer par du php, avec echo dans nginx) et une PG tâche cron qui récupère les PG listes pour les blacklister avec iptables et les recopier ailleurs PG pour les enlever au prochain PG passage me parait plus efficace, mais j'ai jamais pris la peine de PG le faire malgré des milliers PG de requetes comme ça par jour. PG PG Oui, ça me parait une bonne idée. Comment comparer la vitesse PG d'exécution des 2 règles ? La mesurer... Mais amha c'est de l'énergie gaspillée, sauf si tu veux étudier ce cas en détails... PG Même chose pour la dernière règle de la page, lancer une regex plus PG un algo pour les PG paquets qui match me parait un gaspillage important, mieux vaudrait PG créer un vhost par défaut PG qui va prendre les requetes directes sur l'ip (http:// PG xxx.xxx.xxx.xxx/) pour bannir tout le PG monde qui arrive là (faudrait être sûr que les googlebot co PG lancent jamais ces requetes, pas PG étudié la question car me sens pas concerné avec un varnish en PG frontal). PG PG C'est déjà le cas chez moi. Je ne crois pas que les crawlers PG s'intéressent aux IP, je ne l'ai jamais PG remarqué. Mais ça pourrait venir, on ne sait jamais… PG PG J'ai l'impression que ce genre de protection ne protège que des PG scripts kiddies assez PG inoffensifs, les vrais méchants sont pas assez stupides pour se PG faire repérer avec des attaques PG aussi connues. PG PG Je suis complètement d'accord avec cette assertion. Le problème, PG c'est que les script kiddies sont PG très gourmands, et vraiment très envahissants. C'est là que j'ai du mal à suivre, si qq milliers de requetes sur une 404 ralentissent ton appli c'est l'appli qui a un pb. (c'est vrai que certains cms envoient toutes les 404 au controleur principal, qui doit charger toute l'appli pour répondre à la fin 404, si c'est du php utiliser apc doit pas mal réduire la charge en général, et notamment dans ces cas là). PG J'aimerais bien réserver l'accès de mon serveur à des utilisateurs PG légitimes, car il est tout petit, pas PG très costaud, donc le compromis est difficile à trouver entre une PG certaine tolérance avec les bots, et PG une discrimination rigoureuse… Si c'est trop compliqué de modifier l'appli faut ajouter qq location pour ces urls à pb, même avec qq milliers d'appels sur une petite machine, c'est pas ça qui va fatiguer ton nginx. -- Daniel Pour atteindre le bonheur il y a deux règles : 1. Contentez vous de ce que vous avez. 2. Essayez d'en avoir un maximum. -- 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/20140610004417.3fd66...@quad.lairdutemps.org
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 9 juin 14 à 19:29, Bernard Schoenacker a écrit : bonjour, serait-il possible d'indiquer la liste des paquets installés pour se protéger des attaques en installant : -a) denyhost Ça pourrait être une solution, mais pas en l'espèce. J'administre des sites en PHP qui sont publics sur le port 80, et les visiteurs sont invités à s'inscrire pour produire du contenu. La gestion des utilisateurs légitimes (ou pas) est faite avec PHP donc très en aval. -b) portsentry Mon problème n'est pas une question de ports ouverts à fermer, là on parle du port 80, qui doit rester accessible à tout le monde sauf les casse-pieds. slt bernard -- 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/20140609192901.7ecc2d95@hamtaro -- 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/cc4b382a-8828-48b8-ad2b-14934fe77...@worldonline.fr
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 10 juin 14 à 00:44, Daniel Caillibaud a écrit : Le 09/06/14 à 14:38, Philippe Gras ph.g...@worldonline.fr a écrit : PG PG Le 9 juin 14 à 13:32, Daniel Caillibaud a écrit : PG PG Le 07/06/14 à 18:16, Philippe Gras ph.g...@worldonline.fr a écrit : PG PG Pour ce qui est des 400, de certaines 404 et 403, je pense que tu PG PG peux t'inspirer de ça: PG PG http://spamcleaner.org/fr/misc/w00tw00t.html PG PG PG PG Je vais d'ailleurs le faire moi-même, parce que j'ai plein de PG PG requêtes avec cette chaîne : PG PG En quoi c'est gênant ? PG PG Répondre à ce genre de requete avec une 404 coûtera bcp moins de PG ressources qu'une règle PG iptables qui va analyser tous les paquets http. PG PG Ah, bon ? Je veux bien le croire, mais ça demande à être confirmé. PG Parce que si ce n'est pas PG iptables qui analyse les paquets, c'est le serveur virtuel qui va le PG faire ensuite, non ? Donc le PG résultat serait identique au niveau du temps d'attente, non ? Je pense pas, le serveur web n'aura que les urls à pbs à traiter, alors que iptable va traiter tous les paquets tcp du port 80. Pas faux :-D (chez moi les scripts kiddies c'est qq centaines de requetes, milliers quand ils s'excitent, sur pas mal de millions, j'ai jamais vu d'impact sur les temps de réponse des utilisateurs légitimes) J'ai quand même remarqué un impact sur le chargement des pages sur le frontend, mais pas limitant pour l'utilisateur lambda. Comme ce sont mes sites, mon œil est exercé et exigeant :-) PG Si vraiment ça dérange, ajouter une règle nginx (location ~ PG w00tw00t) pour écrire l'ip dans un PG fichier tmp (sans passer par du php, avec echo dans nginx) et une PG tâche cron qui récupère les PG listes pour les blacklister avec iptables et les recopier ailleurs PG pour les enlever au prochain PG passage me parait plus efficace, mais j'ai jamais pris la peine de PG le faire malgré des milliers PG de requetes comme ça par jour. PG PG Oui, ça me parait une bonne idée. Comment comparer la vitesse PG d'exécution des 2 règles ? La mesurer... Mais amha c'est de l'énergie gaspillée, sauf si tu veux étudier ce cas en détails... Pendant que j'y suis… Sur PHP.net, j'ai vu un type mesurer elseif et else if, alors je n'aurai pas peur du ridicule en vous présentant les résultats ! PG Même chose pour la dernière règle de la page, lancer une regex plus PG un algo pour les PG paquets qui match me parait un gaspillage important, mieux vaudrait PG créer un vhost par défaut PG qui va prendre les requetes directes sur l'ip (http:// PG xxx.xxx.xxx.xxx/) pour bannir tout le PG monde qui arrive là (faudrait être sûr que les googlebot co PG lancent jamais ces requetes, pas PG étudié la question car me sens pas concerné avec un varnish en PG frontal). PG PG C'est déjà le cas chez moi. Je ne crois pas que les crawlers PG s'intéressent aux IP, je ne l'ai jamais PG remarqué. Mais ça pourrait venir, on ne sait jamais… PG PG J'ai l'impression que ce genre de protection ne protège que des PG scripts kiddies assez PG inoffensifs, les vrais méchants sont pas assez stupides pour se PG faire repérer avec des attaques PG aussi connues. PG PG Je suis complètement d'accord avec cette assertion. Le problème, PG c'est que les script kiddies sont PG très gourmands, et vraiment très envahissants. C'est là que j'ai du mal à suivre, si qq milliers de requetes sur une 404 ralentissent ton appli c'est l'appli qui a un pb. C'est du Wordpress, donc ce n'est déjà pas très performant à la base… Mais ce ne sont pas des erreurs 404 dont il s'agit, mais 403 (Forbidden). (c'est vrai que certains cms envoient toutes les 404 au controleur principal, qui doit charger toute l'appli pour répondre à la fin 404, si c'est du php utiliser apc doit pas mal réduire la charge en général, et notamment dans ces cas là). J'utilise Memcached + Xcache (équivalent à APC, 1 poil moins performant, mais très fiable). PG J'aimerais bien réserver l'accès de mon serveur à des utilisateurs PG légitimes, car il est tout petit, pas PG très costaud, donc le compromis est difficile à trouver entre une PG certaine tolérance avec les bots, et PG une discrimination rigoureuse… Si c'est trop compliqué de modifier l'appli faut ajouter qq location pour ces urls à pb, même avec qq milliers d'appels sur une petite machine, c'est pas ça qui va fatiguer ton nginx. Je crois que NginX s'en fout, il bloque l'accès sans se poser de question. C'est moi qui fatigue. L'idée que tu as exposée, j'y ai réfléchi cet après-midi, et je la trouve super. De plus, elle irait bien avec un anti-spam que j'ai développé en PHP, mais que je souhaiterais améliorer pour le faire bosser plus vite. Coupler les 2 serait tout simplement mortel :-) -- Daniel Pour atteindre le bonheur il y a deux règles : 1. Contentez vous de ce que vous avez. 2. Essayez d'en avoir un maximum. -- Lisez la FAQ de la liste avant de poser
Re: [IPTABLES] Comment lister les paquets rejetés ?
Bonjour à tous, Le 07/06/2014 23:05, nb a écrit : Le 07/06/2014 20:31, Philippe Gras a écrit : Non, justement pas quel que soit l'état de la connexion, et c'est logique. On n'aurait pas de règle pour les connexions établies, sinon ;-) Philippe a raison. INPUT ne sert pas pour une connexion déjà établie, seulement pour l'établissement d'une connexion (paquet tcp syn) Loin de moi l'idée de vouloir vous embêter avec tout ça (j'essaye vraiment d'être constructif dans ma démarche) mais il me semble sincèrement que Philippe et toi nb vous trompez sur ce point. J'essaye de donner une explication ci-dessous qui tend à le prouver. Certes, ça n'a pas de rapport direct avec Debian mais je trouve que le sujet n'est pas inintéressant en soi. Et dans le pire des cas, si on me montre que j'ai tort (ce qui est tout à fait envisageable ;)), j'en serais le premier content car j'aurais appris quelque chose (et je pense que je ne serai pas le seul). J'ai une petite Debian Wheezy toute simple sur laquelle j'ai un petit apache2 qui tourne (avec la fameuse page « It works »). Je n'ai fait à la base aucune modification iptables (et donc par défaut tout passe etc). Cette machine a pour IP 172.31.0.1/16. Je crée alors ces deux règles : iptables -A INPUT -p tcp --dport 80 -s 172.31.100.144 -j LOG --log-prefix BASIC INPUT iptables -A INPUT -p tcp --dport 80 -s 172.31.100.144 -m state --state RELATED,ESTABLISHED -j LOG --log-prefix STATE INPUT J'ai juste repris le même type de règle que Philippe (dans son message du 7 juin à 18h16) sauf que : * j'ai pris une autre IP source (qui correspond à l'IP d'une VM sur mon réseau local 172.31.0.0/16) * j'ai changé l'action. Au lieu de faire un DROP comme Philippe, je me contente simplement de journaliser les paquets qui matchent les règles avec un préfixe différent pour les différencier dans le log. Une fois que tout ça est en place, je me rends sur la machine dont l'IP est 172.31.100.144 et je me contente de visiter une fois la page http://172.31.0.1 qui m'affiche « It works ». Au même moment je regarde le fichier de log /var/log/kern.log du serveur apache2 et voici toutes les lignes que j'obtiens au moment de la visite de la page web : [ 3082.346423] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=60953 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0· [ 3082.346697] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60954 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK URGP=0· [ 3082.346704] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60954 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK URGP=0· [ 3082.357986] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=372 TOS=0x00 PREC=0x00 TTL=64 ID=60955 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK PSH URGP=0· [ 3082.357994] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=372 TOS=0x00 PREC=0x00 TTL=64 ID=60955 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK PSH URGP=0· [ 3082.358973] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60956 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK URGP=0· [ 3082.358980] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60956 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK URGP=0· [ 3087.360441] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60957 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK FIN URGP=0· [ 3087.360448] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60957 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK FIN URGP=0· [ 3087.360968] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60958 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK URGP=0· [ 3087.360975] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60958 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK URGP=0· J'ai juste enlevé quelques champs (comme le champ MAC par exemple) pour écourter un peu les lignes. En regardant le champ ID des paquets et en regardant le préfixe (BASIC INPUT ou STATE INPUT), on peut constater que tout paquet qui a été matché par la règle « STATE INPUT » (la règle 2) l'a été également avec la règle « BASIC INPUT » (la règle 1). Pour moi, cela confirme bien le fait que la règle : iptables -A INPUT -p tcp --dport 80 -s 172.31.100.144 -j DROP va faire un DROP sur tous les paquets destinés à un processus local (correspondant à du tcp, dont le port de destination vaut 80 et l'IP source est 172.31.100.144) et cela quel que soit l'état de la connexion indiqué dans l'entête tcp (donc même pour des paquets correspondant à une connexion déjà établie). Voilà. Si je me suis planté, alors toutes mes excuses,
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 8 juin 14 à 12:24, Francois Lafont a écrit : Bonjour à tous, Le 07/06/2014 23:05, nb a écrit : Le 07/06/2014 20:31, Philippe Gras a écrit : Non, justement pas quel que soit l'état de la connexion, et c'est logique. On n'aurait pas de règle pour les connexions établies, sinon ;-) Philippe a raison. INPUT ne sert pas pour une connexion déjà établie, seulement pour l'établissement d'une connexion (paquet tcp syn) Loin de moi l'idée de vouloir vous embêter avec tout ça (j'essaye vraiment d'être constructif dans ma démarche) mais il me semble sincèrement que Philippe et toi nb vous trompez sur ce point. J'essaye de donner une explication ci-dessous qui tend à le prouver. Certes, ça n'a pas de rapport direct avec Debian mais je trouve que le sujet n'est pas inintéressant en soi. Et dans le pire des cas, si on me montre que j'ai tort (ce qui est tout à fait envisageable ;)), j'en serais le premier content car j'aurais appris quelque chose (et je pense que je ne serai pas le seul). OK, ce n'est pas Debian, mais Iptables. Mais on peut l'installer sur une Debian. Je n'ai pas vu de forum ou de liste dédiée à Iptables, alors je pose ma question ici même. J'ai une petite Debian Wheezy toute simple sur laquelle j'ai un petit apache2 qui tourne (avec la fameuse page « It works »). Je n'ai fait à la base aucune modification iptables (et donc par défaut tout passe etc). Cette machine a pour IP 172.31.0.1/16. OK pour cette démonstration, mais le cas que j'ai évoqué est différent, dans la mesure où j'ai dû établir ma règle pendant l'attaque, je ne l'ai pas écrite avant. Je crois qu'il y a une explication à cet état de choses ici : http://www.bortzmeyer.org/rate-limiting-dos.html = Ici, on met les adresses IP dans une table nommée Web. On peut afficher son contenu avec cat /proc/net/xt_recent/Web pour surveiller le bon fonctionnement. On ne teste que les paquets TCP de type SYN, ceux envoyés pour créer une nouvelle connexion (on aurait pu remplacer --tcp-flags SYN SYN par -m state --state NEW mais cette commande est à état, ce qui est toujours déconseillé face à une DoS). = Il existe apparemment une différence dans le traitement des paquets par iptables selon leur état. Je crée alors ces deux règles : iptables -A INPUT -p tcp --dport 80 -s 172.31.100.144 -j LOG --log- prefix BASIC INPUT iptables -A INPUT -p tcp --dport 80 -s 172.31.100.144 -m state -- state RELATED,ESTABLISHED -j LOG --log-prefix STATE INPUT J'ai juste repris le même type de règle que Philippe (dans son message du 7 juin à 18h16) sauf que : * j'ai pris une autre IP source (qui correspond à l'IP d'une VM sur mon réseau local 172.31.0.0/16) * j'ai changé l'action. Au lieu de faire un DROP comme Philippe, je me contente simplement de journaliser les paquets qui matchent les règles avec un préfixe différent pour les différencier dans le log. Une fois que tout ça est en place, je me rends sur la machine dont l'IP est 172.31.100.144 et je me contente de visiter une fois la page http://172.31.0.1 qui m'affiche « It works ». Au même moment je regarde le fichier de log /var/log/kern.log du serveur apache2 et voici toutes les lignes que j'obtiens au moment de la visite de la page web : [ 3082.346423] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=60953 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0· [ 3082.346697] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60954 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK URGP=0· [ 3082.346704] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60954 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK URGP=0· [ 3082.357986] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=372 TOS=0x00 PREC=0x00 TTL=64 ID=60955 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK PSH URGP=0· [ 3082.357994] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=372 TOS=0x00 PREC=0x00 TTL=64 ID=60955 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK PSH URGP=0· [ 3082.358973] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60956 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK URGP=0· [ 3082.358980] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60956 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK URGP=0· [ 3087.360441] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60957 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK FIN URGP=0· [ 3087.360448] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60957 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK FIN URGP=0· [
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 08/06/2014 13:58, Philippe Gras a écrit : OK, ce n'est pas Debian, mais Iptables. Mais on peut l'installer sur une Debian. Je n'ai pas vu de forum ou de liste dédiée à Iptables, alors je pose ma question ici même. Personnellement, ça ne me dérange absolument que le sujet soit abordé ici. OK pour cette démonstration, mais le cas que j'ai évoqué est différent, dans la mesure où j'ai dû établir ma règle pendant l'attaque, je ne l'ai pas écrite avant. Certes, mais très honnêtement je pense que ça ne change rien au fait qu'avec les règles que tu indiquais : 1. iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP 2. iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP 3. iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 72.44.248.136 -j DROP 4. iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 66.23.229.10 -j DROP les règles 3 et 4 sont inutiles car si un paquet matche la 3, de toute façon il matchera la 1 avant et sera « dropé » et si un paquet matche la 4 il sera « dropé » de toute façon par la 2 avant. Mais au final, ce n'est pas très grave, il y a juste une sorte de redondance. Rien de bien méchant donc. Je crois qu'il y a une explication à cet état de choses ici : http://www.bortzmeyer.org/rate-limiting-dos.html = Ici, on met les adresses IP dans une table nommée Web. On peut afficher son contenu avec cat /proc/net/xt_recent/Web pour surveiller le bon fonctionnement. On ne teste que les paquets TCP de type SYN, ceux envoyés pour créer une nouvelle connexion (on aurait pu remplacer --tcp-flags SYN SYN par -m state --state NEW mais cette commande est à état, ce qui est toujours déconseillé face à une DoS). = Merci bien Philippe pour ce lien qui est très intéressant. Perso, j'y est appris pas mal de trucs. En revanche, je n'y ai pas trop vu le rapport avec la question soulevée ici. Il existe apparemment une différence dans le traitement des paquets par iptables selon leur état. Vraiment je ne crois pas. Si, dans la définition d'une règle via iptables, tu ne précises rien quant à l'état de la connexion tcp, alors la règle ne dépendra pas de cet état, tout simplement. Dans le lien précédent en l'occurrence, les règles indiquées dépendent explicitement de l'état de la connexion car l'auteur cherche à attraper les paquets IP qui contiennent des segments tcp qui correspondent à des demandes de connexion d'où l'option « --tcp-flags SYN SYN » clairement spécifiée quasiment à chaque fois. -- François Lafont -- 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/539477fb.8070...@free.fr
Re: [IPTABLES] Comment lister les paquets rejetés ?
Juste pour conclure, je voulais ajouter ceci. Juste après un : iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP *pendant* l'attaque, il est tout à fait possible que ton serveur apache soit encore dans les choux. En effet, avant la mise en place des règles ci-dessus, des requêtes http étaient sûrement en cours et celles-là ton apache souhaite les honorer. Du coup, ton apache envoie tant bien que mal ses réponses aux méchants hôtes 72.44.248.136 et 66.23.229.10. Normalement, les 2 méchants sont censés envoyer un paquet d'acquittement comme quoi ils ont bien reçu la réponse du serveur. Mais ces paquets d'acquittement ne peuvent plus arriver car les 2 règles ci-dessus l'empêchent. Du coup, apache2 cherche à renvoyer à nouveau ses réponses etc. Et du coup, il continue à être dans les choux pendant un certain temps. En revanche, avec un truc du genre : 1. invoke-rc.d apache2 stop # on arrête toutes les connexions en cours. 2. iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP 3. invoke-rc.d apache2 start il me semble que ton apache2 est serein aussitôt après et les 2 méchants hôtes ne peuvent plus l'embêter. -- François Lafont -- 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/539487e8.80...@free.fr
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 8 juin 14 à 17:57, Francois Lafont a écrit : Juste pour conclure, je voulais ajouter ceci. Juste après un : iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP *pendant* l'attaque, il est tout à fait possible que ton serveur apache soit encore dans les choux. En effet, avant la mise en place des règles ci-dessus, des requêtes http étaient sûrement en cours et celles-là ton apache souhaite les honorer. Du coup, ton apache envoie tant bien que mal ses réponses aux méchants hôtes 72.44.248.136 et 66.23.229.10. Normalement, les 2 méchants sont censés envoyer un paquet d'acquittement comme quoi ils ont bien reçu la réponse du serveur. Mais ces paquets d'acquittement ne peuvent plus arriver car les 2 règles ci-dessus l'empêchent. Du coup, apache2 cherche à renvoyer à nouveau ses réponses etc. Et du coup, il continue à être dans les choux pendant un certain temps. Oui, c'est très possible. J'ai pensé à autre chose aussi, par rapport à ce que François réfute, c'est que j'ai aussi une règle dans mon firewall qui empêche les connexions établies d'être cassées. Il serait possible que je sois obligé de demander expressément de casser celles-là, et l'une après l'autre. Car l'attaquant n'en utilisait qu'une seule à la fois. En revanche, avec un truc du genre : 1. invoke-rc.d apache2 stop # on arrête toutes les connexions en cours. Oui, mais je marche avec NginX d'une part, et comme j'étais dessus aussi, je n'avais pas envie de me bannir moi-même. Ceci dit, j'avais installé précédemment un module limiteur qui existe sur le serveur NginX, mais ça n'a pas vraiment gêné le mec pour attaquer. 2. iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP 3. invoke-rc.d apache2 start il me semble que ton apache2 est serein aussitôt après et les 2 méchants hôtes ne peuvent plus l'embêter. J'ai l'impression qu'on était tous les 2 chacun de notre côté à contrer l'autre, et après que je l'ai eu droppé une première fois, il est revenu avec l'autre IP. -- François Lafont -- 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/539487e8.80...@free.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/cba8d913-c375-4617-9eeb-e524dfbc2...@worldonline.fr
[IPTABLES] Comment lister les paquets rejetés ?
Bonjour à toutes et à tous, suite à une attaque, j'ai restreint les accès sur le port 80 de mon serveur avec Iptables : === ~# iptables -L INPUT -nvx Chain INPUT (policy DROP 7178 packets, 2268524 bytes) pkts bytes target prot opt in out source destination 9 774 DROP tcp -- * * 0.0.0.0/0XXX.XXX.XXX tcp dpt:80 STRING match GET /w00tw00t.at. ALGO name bm TO 70 40 9636 DROP tcp -- * * 0.0.0.0/0 XXX.XXX.XXX tcp dpt:80 STRING match Host: XXX.XXX.XXX ALGO name bm TO 600 93193 37333670 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0state RELATED,ESTABLISHED 7530 566937 ACCEPT all -- lo * 0.0.0.0/00.0.0.0/0 33026804 ACCEPT icmp -- * * 0.0.0.0/00.0.0.0/0 00 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0state RELATED,ESTABLISHED 4480 234832tcp -- * * 0.0.0.0/00.0.0.0/0tcp dpt:80flags: 0x02/0x02 recent: SET name: web side: source 13 780 DROP tcp -- * * 0.0.0.0/00.0.0.0/0tcp dpt:80flags: 0x02/0x02 recent: UPDATE seconds: 5 hit_count: 10 name: web side: source 38 1992 DROP tcp -- * * 0.0.0.0/00.0.0.0/0tcp dpt:80flags: 0x02/0x02 limit: above 3/sec burst 7 mode srcip srcmask 28 4392 230136 ACCEPT tcp -- * * 0.0.0.0/00.0.0.0/0tcp dpt:80flags: 0x02/0x02 limit: avg 7/sec burst 12 37 1924 DROP tcp -- * * 0.0.0.0/00.0.0.0/0tcp dpt:80flags: 0x02/0x02 === Y a-t-il un moyen de lister les paquets rejetés pour vérifier que mes règles sont conformes à ce que je souhaitais faire ? D'autant plus que le serveur virtuel que j'utilise n'est pas Apache, mais NginX. J'ai peur que les match string soient un peu différentes… Je me suis servi de ressources sur le Web. Je peux vous les communiquer en cas de besoin. D'avance, merci pour vos lumières… Ph. Gras
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le Samedi 7 Juin 2014 11:22 CEST, Philippe Gras ph.g...@worldonline.fr a écrit: Bonjour à toutes et à tous, suite à une attaque, j'ai restreint les accès sur le port 80 de mon serveur avec Iptables : === ~# iptables -L INPUT -nvx Chain INPUT (policy DROP 7178 packets, 2268524 bytes) pkts bytes target prot opt in out === Y a-t-il un moyen de lister les paquets rejetés pour vérifier que mes règles sont conformes à ce que je souhaitais faire ? Je pense que tu peux utiliser LOG avant DROP. Ca ira dans la log système -- 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/7fd0-5392f600-3-46a5ca00@89467399
Re: [IPTABLES] Comment lister les paquets rejetés ?
Bonjour, Le samedi 07 juin 2014, Philippe Gras a écrit... Y a-t-il un moyen de lister les paquets rejetés pour vérifier que mes règles sont conformes à ce que je souhaitais faire ? Tu peux loger les paquets qui correspondent à une règle. Il suffit de mettre la règle « -j LOG » juste avant la règle qui jette, avec une option --log-prefix parlante pour toi. Quand tu es bon sur la règle, tu vires le logging. -- jm -- 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/20140607111203.GA7830@espinasse
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 7 juin 14 à 13:12, Jean-Michel OLTRA a écrit : Bonjour, Le samedi 07 juin 2014, Philippe Gras a écrit... Y a-t-il un moyen de lister les paquets rejetés pour vérifier que mes règles sont conformes à ce que je souhaitais faire ? Tu peux loger les paquets qui correspondent à une règle. Il suffit de mettre la règle « -j LOG » juste avant la règle qui jette, avec une option --log-prefix parlante pour toi. Quand tu es bon sur la règle, tu vires le logging. -- jm OK et merci ! c'est une bonne idée, je vais plancher dessus :-) Pendant que j'y suis, j'ai réussi à dropper le pirate pendant son action ! J'ai eu l'impression que ça a eu un effet très déstabilisant. C'était du brute force et non du ddos, donc son script n'avait de conséquences que dans l'administration : 15.000 requêtes par jour et par action, sur la même page, et tout le backend ramait comme pas possible ! Ça vous intéresse de savoir comment j'ai fait ? Ph. Gras -- 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/20140607111203.GA7830@espinasse
Re: [IPTABLES] Comment lister les paquets rejetés ?
On Saturday 07 June 2014 14:18:23 Philippe Gras wrote: C'était du brute force et non du ddos, donc son script n'avait de conséquences que dans l'administration : 15.000 requêtes par jour et par action, sur la même page, et tout le backend ramait comme pas possible ! Ça vous intéresse de savoir comment j'ai fait ? Ph. Gras Oui, car mon site reçoit des requêtes permanentes sur des pages obsolètes et/ou sur des chemins qui n'existent pas... etc : 400 Bad Request 403 Forbidden 404 Not Found 302 tentative d'attaques 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/201406071431.29239.andre_deb...@numericable.fr
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 7 juin 14 à 14:31, andre_deb...@numericable.fr a écrit : On Saturday 07 June 2014 14:18:23 Philippe Gras wrote: C'était du brute force et non du ddos, donc son script n'avait de conséquences que dans l'administration : 15.000 requêtes par jour et par action, sur la même page, et tout le backend ramait comme pas possible ! Ça vous intéresse de savoir comment j'ai fait ? Ph. Gras Oui, car mon site reçoit des requêtes permanentes sur des pages obsolètes et/ou sur des chemins qui n'existent pas... etc : 400 Bad Request 403 Forbidden 404 Not Found Pour ce qui est des 400, de certaines 404 et 403, je pense que tu peux t'inspirer de ça: http://spamcleaner.org/fr/misc/w00tw00t.html Je vais d'ailleurs le faire moi-même, parce que j'ai plein de requêtes avec cette chaîne : FCKeditor qui doit correspondre à un espace d'administration d'un CMS quelconque et ça correspondrait à de l'exploit. 302 tentative d'attaques Par contre, pour celles qui correspondent à ton, ou tes domaines et les redirections 302 tu ferais mieux de les laisser accessibles, pour ne pas cramer ton référencement naturel. Mais ce que j'ai réussi à faire n'a rien à voir puisqu'il s'agissait de bannir le pirate en train d'attaquer. Ça l'a stoppé net une première fois, il a changé de serveur et d'IP, mais j'ai pu le remarquer, et recommencer. Il a abandonné cette nuit-là. Ça dure depuis lundi. = # iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP # iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp -- dport 80 -s 72.44.248.136 -j DROP # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp -- dport 80 -s 66.23.229.10 -j DROP = Dans mes logs, ça donne ça : = 72.44.248.136 - - [06/Jun/2014:00:55:58 +0200] POST /wp-login.php HTTP/1.0 403 168 - - 72.44.248.136 - - [06/Jun/2014:00:55:59 +0200] POST /wp-login.php HTTP/1.0 403 168 - - 72.44.248.136 - - [06/Jun/2014:00:55:59 +0200] POST /wp-login.php HTTP/1.0 403 168 - - 72.44.248.136 - - [06/Jun/2014:00:55:59 +0200] POST /wp-login.php HTTP/1.0 403 168 - - 66.23.229.10 - - [06/Jun/2014:00:56:05 +0200] POST /wp-login.php HTTP/1.0 403 168 - - 66.23.229.10 - - [06/Jun/2014:00:56:05 +0200] POST /wp-login.php HTTP/1.0 403 168 - - 66.23.229.10 - - [06/Jun/2014:00:56:05 +0200] POST /wp-login.php HTTP/1.0 403 168 - - 66.23.229.10 - - [06/Jun/2014:00:56:06 +0200] POST /wp-login.php HTTP/1.0 403 168 - - = L'astuce, c'est après avoir rejeté l'IP en INPUT, on la rejette en RELATED,ESTABLISHED également (parce que le bot est connecté). Ça le déconnecte, et il ne peut plus revenir se connecter une nouvelle fois. Enjoy ! 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/ 201406071431.29239.andre_deb...@numericable.fr
Re: [IPTABLES] Comment lister les paquets rejetés ?
Bonjour, Le 07/06/2014 18:16, Philippe Gras a écrit : = # iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP # iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 72.44.248.136 -j DROP # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 66.23.229.10 -j DROP = Sauf erreur de ma part, les deux dernière règles ci-dessus sont inutiles. Si ça matche pour l'une d'entre elles, ça matchera de toute façon pour une des deux premières. -- François Lafont -- 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/53934dc3.5010...@free.fr
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 7 juin 14 à 19:37, Francois Lafont a écrit : Bonjour, Le 07/06/2014 18:16, Philippe Gras a écrit : = # iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP # iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp -- dport 80 -s 72.44.248.136 -j DROP # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp -- dport 80 -s 66.23.229.10 -j DROP = Sauf erreur de ma part, les deux dernière règles ci-dessus sont inutiles. Si ça matche pour l'une d'entre elles, ça matchera de toute façon pour une des deux premières. Non, en fait. Si le client est déjà connecté sur le serveur, INPUT ne matche pas. C'était le cas pour moi. J'ai vu que ça ramait dans le backend, et je suis allé voir les logs, et c'est là que j'ai remarqué le manège… J'ai d'abord établi la première règle, mais il était toujours là à taper dans le mur. Il faut d'abord le dropper en RELATED ou ESTABLISHED, et ensuite, il n'a plus la possibilité de revenir, à cause du drop en INPUT. Après avoir rejeté la première IP, le gars est revenu avec une deuxième. J'ai établi une deuxième série de 2 règles, et il a laissé tomber. Il était déjà tard. Ph. Gras -- François Lafont -- 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/53934dc3.5010...@free.fr
Re: [IPTABLES] Comment lister les paquets rejetés ?
Bonsoir, Le 07/06/2014 19:37, Francois Lafont a écrit : = # iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP # iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 72.44.248.136 -j DROP # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 66.23.229.10 -j DROP = Sauf erreur de ma part, les deux dernière règles ci-dessus sont inutiles. Si ça matche pour l'une d'entre elles, ça matchera de toute façon pour une des deux premières. J'aurais tendance à être d'accord avec ca : les deux premières règles doivent matcher , quelque soit l'état de la connexion. @+ Christophe. -- 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/5393543f.7000...@stuxnet.org
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 7 juin 14 à 20:04, Christophe a écrit : Bonsoir, Le 07/06/2014 19:37, Francois Lafont a écrit : = # iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP # iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp -- dport 80 -s 72.44.248.136 -j DROP # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp -- dport 80 -s 66.23.229.10 -j DROP = Sauf erreur de ma part, les deux dernière règles ci-dessus sont inutiles. Si ça matche pour l'une d'entre elles, ça matchera de toute façon pour une des deux premières. J'aurais tendance à être d'accord avec ca : les deux premières règles doivent matcher , quelque soit l'état de la connexion. Non, justement pas quel que soit l'état de la connexion, et c'est logique. On n'aurait pas de règle pour les connexions établies, sinon ;-) @+ Christophe. -- 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/5393543f.7000...@stuxnet.org -- 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/6b7fc62a-8cf6-469b-83ce-208434e06...@worldonline.fr
Re: [IPTABLES] Comment lister les paquets rejetés ?
Bonsoir, Le 07/06/2014 20:31, Philippe Gras a écrit : Non, justement pas quel que soit l'état de la connexion, et c'est logique. On n'aurait pas de règle pour les connexions établies, sinon ;-) Euh ... -m précise un module complémentaire à ta règle . en l'occurrence -m state S'il n'est pas précisé , ta règle matche quelque soit le 'state' . Qu'il soit NEW, ESTABLISHED, RELATED, INVALID, ... @+ Christophe. -- 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/53935b96.6080...@stuxnet.org
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 7 juin 14 à 20:36, Christophe a écrit : Bonsoir, Le 07/06/2014 20:31, Philippe Gras a écrit : Non, justement pas quel que soit l'état de la connexion, et c'est logique. On n'aurait pas de règle pour les connexions établies, sinon ;-) Euh ... -m précise un module complémentaire à ta règle . en l'occurrence -m state S'il n'est pas précisé , ta règle matche quelque soit le 'state' . Qu'il soit NEW, ESTABLISHED, RELATED, INVALID, ... J'en ai fait l'expérience jeudi, et je me souviens que ça n'a pas marché. @+ Christophe. -- 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/53935b96.6080...@stuxnet.org -- 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/27f7bd1e-2b9a-4f47-ad0f-0473589ad...@worldonline.fr
Re: [IPTABLES] Comment lister les paquets rejetés ?
Le Samedi 7 Juin 2014 20:36 CEST, Christophe t...@stuxnet.org a écrit: Bonsoir, Le 07/06/2014 20:31, Philippe Gras a écrit : Non, justement pas quel que soit l'état de la connexion, et c'est logique. On n'aurait pas de règle pour les connexions établies, sinon ;-) Philippe a raison. INPUT ne sert pas pour une connexion déjà établie, seulement pour l'établissement d'une connexion (paquet tcp syn) Mais tout ceci n'est pas très Debian... -- 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/7fd0-53937e80-7-46a5ca00@89467401
Re: [IPTABLES] Comment lister les paquets rejetés ?
INPUT ne sert pas pour une connexion déjà établie, seulement pour l'établissement d'une connexion (paquet tcp syn) Merci de venir à mon secours :-) Autre chose que je n'ai pas bien capté : la différence entre -A (add) et -I (insert). Mais tout ceci n'est pas très Debian... C'est vrai, mais ça rentre bien à l'intérieur. Je n'ai pas vu de forum spécifique à iptables, alors je tente ma chance. -- 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/7fd0-53937e80-7-46a5ca00@89467401 -- 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/588f56ad-4fe5-40a3-8701-cc209a2cb...@worldonline.fr
