# IP BANNIE génère des erreurs dans les logs apache **URL:** \ **Category:** Support Debian\ **Created:** [Juin 6, 2020, 10:58 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272 "2020-06-06T10:58:13Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Juin 6, 2020, 10:58 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/1 "2020-06-06T10:58:14Z")
Bonjour, J’ai une IP bannie qui génère des erreurs dans les logs Apache. ```nohighlight $ sudo iptables -L |grep -i 193.106.31.130 DROP all -- 193.106.31.130 anywhere 2020-06-01T16:16:51+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-01T16:16:51+00:00 WARNING 193.106.31.130 jerror Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-01T16:16:52+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-01T16:16:52+00:00 WARNING 193.106.31.130 jerror Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-01T16:16:52+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-01T16:16:52+00:00 WARNING 193.106.31.130 jerror Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-01T16:16:52+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-01T16:16:52+00:00 WARNING 193.106.31.130 jerror Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. ``` Cette IP ne devrait elle pas être bannie sur tous les ports, qu’est ce que j’ai manqué ? ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Juin 6, 2020, 11:08 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/2 "2020-06-06T11:08:59Z")
Comment as-tu procéder pour bloquer l’IP ? Pour du radical : ```auto iptables -A INPUT -s xxx.xxx.xxx.xxx -j DROP ``` un peu moins radical : ```auto iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port 80 -j DROP ``` Le mieux étant de te faire une règle qui va bien avec Fail2ban pour protégé éventuellement ton accès 😉 ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 6, 2020, 2:25 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/3 "2020-06-06T14:25:52Z")
+1 Et surtout à quel moment exact a été ajoutée cette règle iptables ? Si cette IP était déjà à l’origine d’une attaque par force brute sur Joomla au moment où la règle a été insérée c’est sans doute normal de continuer à voir des tentatives du fait de la persistance des connexions (HTTP et TCP). ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Juin 6, 2020, 4:28 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/4 "2020-06-06T16:28:42Z")
C’est en ajoutant des règles fail2ban que je me suis aperçu que les attaques de cette IP persistaient. Où est paramétrée le temps de persistance des connexions ? ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 6, 2020, 5:50 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/5 "2020-06-06T17:50:46Z")
Il ne faut pas toucher à ce type de paramètre sans savoir ce que l’on fait exactement. La question est de savoir quel a été le délai entre l’établissement de la règle iptables et les tentatives provenant de cette IP dans les logs ; qui ne semblent pas être des logs d’Apache par ailleurs. ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Juin 6, 2020, 7:19 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/6 "2020-06-06T19:19:44Z")
Ce n’est pas pour y toucher mais savoir la valeur par défaut pour savoir au bout de combien de temps ces attaques n’ont plus aucune raison d’apparaitre… à moins que l’attaque soie déclenchée dans l’intervalle de temps du cache. Autrement dit: comment annuler cette connexion si elle existe encore ? ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 7, 2020, 7:41 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/7 "2020-06-07T07:41:34Z")
Ce que j’ai indiqué est juste une hypothèse qui peut s’avérer complètement fausse. Il faut que tu répondes à ma question et que tu sois plus précis : - quelle règle fail2ban avec quel temps de bannissement et quel nombre de tentatives ; - quelles autres règles iptables, notamment sur les connexions établies ; - d’où provient ton extrait de logs. Au niveau applicatif Apache maintient le délai d’inactivité par défaut est de 5 secondes, cf. [https://httpd.apache.org/docs/current/mod/core.html#keepalive](https://httpd.apache.org/docs/current/mod/core.html#keepalive) Tes logs montrent plusieurs tentatives effectuées dans un délai très court ce qui m’a conduit à l’hypothèse d’une connexion persistante (du moins tant que le service n’est pas redémarré). ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Juin 8, 2020, 9:41 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/8 "2020-06-08T09:41:28Z")
> [@anon70622873](#): > > quelle règle fail2ban avec quel temps de bannissement et quel nombre de tentatives ; Disons que je n’ai pas encore fixé de jail pour fail2ban > [@anon70622873](#): > > quelles autres règles iptables, notamment sur les connexions établies ; ```auto cat /usr/local/sbin/firewall/firewall ... function ban { LIST="193.106.31.130" for IP in $LIST do iptables -A INPUT -s $IP -j DROP done echo "IP bannies activé" } # Réinitialise les règles iptables -t filter -F iptables -t filter -X # Bloque tout le trafic iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP iptables -t filter -P OUTPUT DROP # Autorise les connexions déjà établies et localhost iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -t filter -A INPUT -i lo -j ACCEPT iptables -t filter -A OUTPUT -o lo -j ACCEPT # ICMP (Ping) iptables -t filter -A INPUT -p icmp -j ACCEPT iptables -t filter -A OUTPUT -p icmp -j ACCEPT # SSH ... # DNS iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT # HTTP iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT # FTP iptables -t filter -A OUTPUT -p tcp --dport 20:21 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 20:21 -j ACCEPT # Mail SMTP iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 587 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 587 -j ACCEPT # Mail POP3 iptables -t filter -A INPUT -p tcp --dport 110 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT # Mail IMAP iptables -t filter -A INPUT -p tcp --dport 143 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT # NTP (horloge du serveur) iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT # SSL iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT # OPENVPN iptables -t filter -A INPUT -p tcp --dport 444 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 444 -j ACCEPT # Opendkim iptables -t filter -A INPUT -p tcp --dport 8891 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 8891 -j ACCEPT # Amavis iptables -t filter -A INPUT -p tcp --dport 10024 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 10024 -j ACCEPT # postfix auth iptables -t filter -A INPUT -p tcp --dport 10025 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 10025 -j ACCEPT #Banned ban #logging iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "IPTables-INPUT-Dropped: " --log-level 4 iptables -A OUTPUT -m limit --limit 5/min -j LOG --log-prefix "IPTables-OUTPUT-Dropped: " --log-level 4 #TEAMVIEWER #iptables -A OUTPUT -o eth0 -p tcp --dport 5938 -m state --state NEW -j ACCEPT #reject all others iptables -A INPUT -j REJECT ``` > [@anon70622873](#): > > d’où provient ton extrait de logs. Il s’agit du fichier error.php d’un site Joomla 3 ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 8, 2020, 11:23 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/9 "2020-06-08T11:23:32Z")
Bon je suppose que depuis le temps tu ne vois plus cette IP dans tes logs. Au vu de l’ordre de tes règles iptables, si la connexion est déjà établie les requêtes passent. Donc si le script a été lancé alors que 193.106.31.130 avait déjà établi la connexion avec ton serveur, c’est normal. ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Juin 11, 2020, 8:33 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/10 "2020-06-11T08:33:28Z")
Le dernier log de cette IP remonte à ce matin: ```auto ... 2020-06-11T04:31:25+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T04:31:25+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T04:31:25+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T04:31:25+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T04:31:26+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T07:15:51+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T07:15:52+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T07:15:52+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T07:15:52+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T07:15:52+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T07:15:53+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. ... 2020-06-11T07:17:08+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T07:17:08+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T07:17:08+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T07:17:09+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T07:17:09+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. 2020-06-11T07:17:09+00:00 INFO 193.106.31.130 joomlafailure Le nom d'utilisateur ne correspond pas au mot de passe, ou vous n'avez pas encore de compte. ``` Donc si je sais lire, cet utilisateur arrive toujours à passer, avec plusieurs tentatives par secondes ! On remarque qu’il s’est écoulé 3 heures entre le dernier accès à 4:31 et le suivant 7:15. Donc ça devrait dépasser le time out des conexions établies, non ? ---
**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\ **Post date:** [Juin 11, 2020, 8:39 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/11 "2020-06-11T08:39:55Z")
Bonjour, As-tu vu cette page web ? [https://www.abuseipdb.com/check/193.106.31.130](https://www.abuseipdb.com/check/193.106.31.130) ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 11, 2020, 8:58 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/12 "2020-06-11T08:58:43Z")
Effectivement il y a un truc pas normal. Soit tes règles iptables sont foireuses, le retour de : ```auto iptables -L -n ``` permettrait de s’en assurer. Soit l’IP des logs ne correspond pas à l’IP réelle de la machine qui tente cette attaque par force brute. Il faudrait voir les logs d’Apache pas ceux de joomla. @anon29980398 : abuseipdb est toujours intéressant, on voit que cette même IP est active depuis plus d’un an sur ce type d’attaque. ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Juin 11, 2020, 10:07 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/13 "2020-06-11T10:07:36Z")
> [@anon70622873](#): > > iptables -L -n Il me semble avoir donné ça au tout début mais je le renvois: ```auto Chain INPUT (policy DROP) target prot opt source destination f2b-ssh all -- 0.0.0.0/0 0.0.0.0/0 f2b-ssh-ddos all -- 0.0.0.0/0 0.0.0.0/0 f2b-rpcbind all -- 0.0.0.0/0 0.0.0.0/0 f2b-pam-generic all -- 0.0.0.0/0 0.0.0.0/0 f2b-php-url-fopen all -- 0.0.0.0/0 0.0.0.0/0 f2b-apache-nohome all -- 0.0.0.0/0 0.0.0.0/0 f2b-apache-badbots all -- 0.0.0.0/0 0.0.0.0/0 f2b-apache-overflows all -- 0.0.0.0/0 0.0.0.0/0 f2b-apache all -- 0.0.0.0/0 0.0.0.0/0 f2b-joomla-login-errors all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 85.31.203.69 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 94.23.227.123 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 94.23.227.123 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 176.151.215.68 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 149.202.55.226 0.0.0.0/0 tcp dpt:22 ACCEPT all -- 84.123.94.200 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:20:21 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:587 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:110 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:143 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:444 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8891 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:9010 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10024 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10025 ACCEPT all -- 10.0.192.0/26 0.0.0.0/0 ACCEPT all -- 10.0.193.0/26 0.0.0.0/0 ACCEPT all -- 10.0.193.64/26 0.0.0.0/0 ACCEPT all -- 85.31.192.0/26 0.0.0.0/0 ACCEPT all -- 85.31.193.0/26 0.0.0.0/0 ACCEPT all -- 85.31.193.64/26 0.0.0.0/0 ACCEPT all -- 85.31.194.186 0.0.0.0/0 ACCEPT all -- 78.153.253.0/24 0.0.0.0/0 ACCEPT all -- 85.31.202.0/28 0.0.0.0/0 ACCEPT all -- 85.31.202.224/27 0.0.0.0/0 ACCEPT all -- 10.0.209.0/24 0.0.0.0/0 ACCEPT all -- 78.153.252.0/23 0.0.0.0/0 ACCEPT all -- 94.23.227.123 0.0.0.0/0 ACCEPT all -- 85.31.201.150 0.0.0.0/0 ACCEPT tcp -- 94.23.227.123 0.0.0.0/0 tcp dpt:22 DROP all -- 119.29.157.216 0.0.0.0/0 DROP all -- 185.234.219.62 0.0.0.0/0 DROP all -- 172.69.194.15 0.0.0.0/0 DROP all -- 172.69.194.21 0.0.0.0/0 DROP all -- 172.69.194.51 0.0.0.0/0 DROP all -- 172.69.194.69 0.0.0.0/0 DROP all -- 213.194.184.212 0.0.0.0/0 DROP all -- 193.106.31.130 0.0.0.0/0 LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 5/min burst 5 LOG flags 0 level 4 prefix "IPTables-INPUT-Dropped: " REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ACCEPT all -- 84.123.94.200 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:20:21 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:587 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:110 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:143 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:123 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:444 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8891 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:9010 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10024 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10025 ACCEPT all -- 0.0.0.0/0 10.0.192.0/26 ACCEPT all -- 0.0.0.0/0 10.0.193.0/26 ACCEPT all -- 0.0.0.0/0 10.0.193.64/26 ACCEPT all -- 0.0.0.0/0 85.31.192.0/26 ACCEPT all -- 0.0.0.0/0 85.31.193.0/26 ACCEPT all -- 0.0.0.0/0 85.31.193.64/26 ACCEPT all -- 0.0.0.0/0 85.31.194.186 ACCEPT all -- 0.0.0.0/0 78.153.253.0/24 ACCEPT all -- 0.0.0.0/0 85.31.202.0/28 ACCEPT all -- 0.0.0.0/0 85.31.202.224/27 ACCEPT all -- 0.0.0.0/0 10.0.209.0/24 ACCEPT all -- 0.0.0.0/0 78.153.252.0/23 ACCEPT all -- 0.0.0.0/0 94.23.227.123 ACCEPT all -- 0.0.0.0/0 85.31.201.150 ACCEPT all -- 0.0.0.0/0 192.168.1.0/24 LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 5/min burst 5 LOG flags 0 level 4 prefix "IPTables-OUTPUT-Dropped: " Chain f2b-apache (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain f2b-apache-badbots (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain f2b-apache-nohome (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain f2b-apache-overflows (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain f2b-joomla-login-errors (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain f2b-pam-generic (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain f2b-php-url-fopen (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain f2b-rpcbind (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain f2b-ssh (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain f2b-ssh-ddos (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 ``` ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 11, 2020, 10:15 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/14 "2020-06-11T10:15:44Z")
> [@kmchen](#): > > ```plaintext > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 > > ``` Chaîne INPUT, seconde règle, C.Q.F.D. ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Juin 15, 2020, 8:56 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/15 "2020-06-15T08:56:39Z")
> [@anon70622873](#): > > ACCEPT all – 0.0.0.0/0 0.0.0.0/0 Oui mais il semble que cette règle vienne soit appliquée à l’interface loop back: ```auto iptables -t filter -A INPUT -i lo -j ACCEPT iptables -t filter -A OUTPUT -o lo -j ACCEPT ``` Commen faire resortir les interfaces concernés avec ipatables -L ? ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 15, 2020, 9:44 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/16 "2020-06-15T09:44:39Z")
Tu ferais mieux de ne pas établir de règles iptables et te contenter de régler précisément tes filtres fail2ban. ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Juin 15, 2020, 10:34 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/17 "2020-06-15T10:34:20Z")
Oui je vais paramétrer fail2ban mais j’aimerais comprendre pourquoi le parefeu installé ne fonctionne pas. J’ai bien compris qu’une règle laissait tout passer mais je n’arrive pas à trouver laquelle. Voici le début du script iptables utilisé, pour moi tout est ouvert seulement sur l’interface lo loopback: ```auto # Réinitialise les règles iptables -t filter -F iptables -t filter -X # Bloque tout le trafic iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP iptables -t filter -P OUTPUT DROP #Banned ban # Autorise les connexions déjà établies et localhost iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -t filter -A INPUT -i lo -j ACCEPT iptables -t filter -A OUTPUT -o lo -j ACCEPT # ICMP (Ping) iptables -t filter -A INPUT -p icmp -j ACCEPT iptables -t filter -A OUTPUT -p icmp -j ACCEPT ... ``` Les tags « -i lo » et « -o lo » ne devrait ils pas s’appliquer seulement à l’interface loopback ? ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 15, 2020, 10:59 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/18 "2020-06-15T10:59:58Z")
Au temps pour moi, je ne t’ai pas demandé la sortie détaillée et j’ai mal interprété. Oui, la règle que j’évoquais est sûrement limitée à l’interface _lo_. Redonne : ```nohighlight iptables -L -n -v ``` Ceci dit cela ne change rien concernant l’ordre des règles, ici par exemple tu acceptes tout ce qui entre sur le port 80. ```nohighlight ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ``` Si un paquet correspond à cette règle, les suivantes seront ignorées et donc celle qui est censée bannir l’IP en question. ---
**Author:** ![kmchen](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kmchen](https://www.debian-fr.org/u/kmchen)\ **Post date:** [Juin 15, 2020, 2:05 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/19 "2020-06-15T14:05:00Z")
Merci Bruno, je pense avoir compris maintenant. C’est que la règle sur le port 80 arrive avant le banissement des IP: ```auto $ sudo iptables -L -n -v Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 14 896 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ... 0 0 DROP all -- * * 193.106.31.130 0.0.0.0/0 ... ``` Il faut que je mette les règles de banissement en début de script ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 15, 2020, 2:17 UTC](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272/20 "2020-06-15T14:17:46Z")
C’est cela 😉 Lorsqu’un paquet correspond à une règle celle-ci est appliquée (il est accepté ou rejeté) et les suivantes ont ignorées. D’où l’importance de l’ordre dans lequel elles son établies. De manière générale on bloque d’abord on autorise ensuite. [Page suivante](https://www.debian-fr.org/t/ip-bannie-genere-des-erreurs-dans-les-logs-apache/82272.md?page=2)