apache2 + mod remoteip, cloudflare, fail2ban

RidingAround · Le 26/03/2022, à 10:07

Bonjour à tous,

pour protéger des serveurs web abritant des Word Press, j'utilise ufw et fail2ban [ENTRE AUTRES NOMBREUX DISPOSITIFS DE SÉCURITÉ].
J'ai créé un filter apache-wp.conf et sa jail [apache-wp]. Il s'agit de bannir les accès répétés au backoffice.
De base, ça fonctionne bien.

Filter :

[Definition]
file_preserved = wp-login\.php|xmlrpc\.php
failregex = ^<HOST> -.*(POST|GET) /%(file_preserved)s HTTP.*200.*
ignoreregex =

Jail :

[apache-wp]
enabled = true
port    = 80,443
filter  = apache-wp
logpath = /var/log/apache2/access.monsite.log

Puis, j'ai vu que dans les logs je n'avais que les IP cloudflare, en tant que CDN/proxy.
Donc les attaques répétées, même si elles étaient prise en compte par f2b, n'aparaissaient que sous la forme des IP rotatives cloudflare
172.64.0.0/16 par exemple.

Comme je voulais voir les vrais IP dans les logs, alors j'ai activé un mod apache2 dédié à ça :

sudo a2enmod remoteip

sudo nano /etc/apache2/conf-available/remoteip.conf

avec dedans :

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 172.64.0.0/13

suivi d'un

sudo a2enconf remoteip

à ce moment, elles étaient en clair dans les logs.

Mais j'ai aussi vu que fail2ban ne fonctionnait plus. Il faisait bien son travail en ajoutant des lignes dans iptables, mais elles étaient sans effet.

Info : voici un log de bannissement iptables -L , d'une ip cloudflare qui est bien bannie :

REJECT     all  --  141.101.xxx.xxx       anywhere             reject-with icmp-port-unreachable

et voici deux lignes générées par un bannissement qui ne fonctionne pas, quand remoteip est activé :

REJECT     all  --  176-184-xxx-xxx.abo.bbox.fr  anywhere             reject-with icmp-port-unreachable

REJECT     all  --  pc-241-204-xxx-xxx.cm.vtr.net  anywhere             reject-with icmp-port-unreachable

Donc on sait maintenant que le premier fonctionne, mais pas le deuxième. Il y a des différences de rédaction entre ces deux adresses. Je pense que c'est lié en cause ou conséquence.

Dans les logs, c'est pourtant la même présentation entre une IP cloudflare et une IP récupérée avec remoteip :

141.101.xxx.xxx - - [26/Mar/2022:15:25:31 +0100] "POST /xmlrpc.php HTTP/1.1" 200 2898 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"

176.184.xxx.xxx - - [26/Mar/2022:15:25:39 +0100] "POST /wp-login.php HTTP/1.1" 200 4027 "[url]https://jhkfghj.host/wp-login.php[/url]" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0"

Je n'ai pas du tout envie de passer par l'API Cloudflare qui agit sur leur pare-feu, considérant que je devrais déjà réussir à bannir une IP en local, dans la mesure ou remoteip me permet de les voir.

Libre discussion ...

Dernière modification par RidingAround (Le 29/03/2022, à 08:58)

bruno · Le 26/03/2022, à 15:32

Bonjour,

Les questions de serveurs sont a poser dans la section « serveurs »
J'ai déplacé ton sujet.

Cela te montre à quel point des outils comme fail2ban sont inutiles pour se protéger des attaques par force brute. Je t'ai déjà dit que ce n'était pas une protection. Au niveau sécurité cela permet uniquement de diminuer la probabilité de réussite d'une attaque par force brute issue d'une même IP. Autrement dit en terme de sécurité cela ne sert pratiquement à rien. Un service bien configuré, avec des mots de passes solides, n'est pas sensible à ce type d'attaque. Et d'autre part un attaquant déterminé va utiliser des dizaines (voire beaucoup plus) d'IP différentes pour cela.

Malheureusement les outils comme fail2ban ou crowdsec sont souvent présentés comme des solutions de sécurité indispensables alors que ce n'en sont pas.

Pour la sécurité de ton Wordpress force l'utilisation de mot de passe très solides (Wordprees ou ses extensions savent faire cela), et bloque l'accès à xmlrpc.php si tu n'en a pas l'usage.

RidingAround · Le 26/03/2022, à 15:51

Merci,

sur 3 vps, fail2ban bloque une ip toutes les 3 minutes. Si ce n'est pas le point central en théorie, et ça ne l'est pas du tout, comme je t'ai déjà dit, il se trouve qu'en pratique ici, c'est un outil que je veux voir fonctionner pour cette raison.
Son rôle est donc de bloquer les tentatives qui utilisent une même IP pendant un temps, même court. C'est ce que j'en attends, aux côtés de toute la batterie de choses que j 'ai déployées. Il n'est pas principal, mais il n'est pas non plus long à déployer alors je ne vais pas l'ignorer.
Il sert notamment à décharger le serveur de certains attaquants humains et de nombreux robots, quand les uns et les autres utilisent des IP répétitives, et sont, malgré tout, la majorité des tentatives. Pourquoi ne devrais-je rien faire sur ce point, si ce n'est pas compliqué ?

De toutes façons, je veux des réponses à ce sujet, je ne vais pas l'abandonner; il concerne beaucoup de monde, ça devrait trouver réponse bientôt.

RidingAround · Le 28/03/2022, à 08:44

Ok, donc pour résumer, on peut en fait se demander pourquoi fail2ban, quand il est derrière cloudflare et une conf remoteip apache, ne bannit pas correctement dans iptables. Pourquoi diable afin de bannir ceci :

176.184.123.123 - - [28/Mar/2022:09:32:17 +0200] "POST /wp-login.php HTTP/1.1" 200 4065 "https://ythjfi.host/wp-login.php" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0"

rédige-t-il ceic :

REJECT     all  --  176-184-123-123.abo.bbox.fr  anywhere             reject-with icmp-port-unreachable

Ca n'arrive pas quand remoteip est désactivée. Mais j'en ai besoin pour ne pas bannir les ip cloudflare.

Je pense que c'est ce type de rédaction qui empêche le filtre de fonctionner.

Dernière modification par RidingAround (Le 28/03/2022, à 08:57)

bruno · Le 28/03/2022, à 10:29

Tu as essayé de modifier la mise en forme des logs quand mod_remoteip est activé ?

Par défaut tu dois avoir ;

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

Avec mod_remoteip si tu veux l'IP distante plutôt que le nom d'hôte :

LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

cf. la doc Apache : https://httpd.apache.org/docs/2.4/mod/m … onfig.html

Dernière modification par bruno (Le 28/03/2022, à 10:29)

RidingAround · Le 28/03/2022, à 11:45

Bien vu, merci, avec un h en effet ça serait une piste.
Mais les logs sont comme ça :

216.244.66.226 - - [28/Mar/2022:12:28:31 +0200] "GET

et je me retrouve avec des lignes iptables comme ça :

216-244-66-226.domaine.truc  - - [28/Mar/2022:12:28:31 +0200] "GET

ce qui m'a fait penser qu'à un moment, on avait plutôt un problème d'interprétation réseau. Je sais pas, je vais voir la conf apache déjà en effet.

Dernière modification par RidingAround (Le 28/03/2022, à 11:45)

RidingAround · Le 28/03/2022, à 11:52

Le bannissement ne fonctionne toujours pas côté serveur. Même quand les logs sont corrects.
Je pense toujours à une fonction réseau. Faut que je me penche sur les fichiers conf (action.d) fail2ban, mais c'est secondaire.

Dernière modification par RidingAround (Le 29/03/2022, à 08:59)

RidingAround · Le 28/03/2022, à 15:26

Bon j'ai regardé dans
/etc/fail2ban/action.d/iptables.conf
La fonction qui permet de bannir sur la base d'une ligne de log ce serait donc ça :

actionstart = <iptables> -N f2b-<name>
              <iptables> -A f2b-<name> -j <returntype>
              <iptables> -I <chain> -p <protocol> --dport <port> -j f2b-<name>

et

actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>

Et là, je comprends toujours pas comment on passe d'une IP inscrite dans les logs comme suit :

123.123.123.123

à un cirque de ce genre dans iptables :

123-123-123-123-abo-fournisseur

ou bien encore des inepties du genre

ps427400.uselessfreakingdoma1n.com

Et si je désactive remoteip d'apache, alors j'ai les IP cloudflare, sous la même forme, avec un bannissement qui fonctionne à merveille (mais jusqu'à ce que plus personne ne puisse voir le site protégé sur ces ip rotatives).

Dernière modification par RidingAround (Le 29/03/2022, à 09:18)

bruno · Le 28/03/2022, à 16:54

Tu n'aurais pas modifié la directive usedns dans la configuration de fail2ban par hasard ?

RidingAround · Le 28/03/2022, à 17:18

Oui, je suis sur cette piste à l'instant même. Il y a une hypothétique fonction reverse dns évoquée dans certains débats. C'est ce que je me dis depuis le début on devrait être d'accord.
J'ai pas activé ça, ma je vais tenter de l'ajouter avec X au bout
Je fouine chez moi quand je reviens.

Dernière modification par RidingAround (Le 28/03/2022, à 17:19)

RidingAround · Le 28/03/2022, à 17:42

ok le fichier /etc/fail2ban/jail.conf contient
usedns = warn
par défaut
Je l'ai mis à no, et c'est pareil.
Je le mets à raw, je retente.

Etonnant, il semble que j'aie toujours les mêmes types de ban. Mais je comprends quelquechose, les IP cloudflare (3 dernières) sont en clair, quand les IP de dehors sont ajoutées du domaine. On est bien sur un ajout, et franchement je suis sidéré que ça ne vienne pas de cette fonction usedns... je confirmerai plus tard en flushant tout ce tintouin.

Chain f2b-apache-wp (1 references)
target prot opt source destination
REJECT all -- whms.ikarusweb.com anywhere reject-with icmp-port-unreachable
REJECT all -- 123-123-123-123.abo.xxx.fr anywhere reject-with icmp-port-unreachable
REJECT all -- 172.69.69.90 anywhere reject-with icmp-port-unreachable
REJECT all -- 162.158.50.30 anywhere reject-with icmp-port-unreachable
REJECT all -- 141.101.68.65 anywhere reject-with icmp-port-unreachable

Lamentable de devoir compter sur des plugins de CMS; je veux ce truc côté serveur pour toutes les bonnes raisons du monde.
J'ai aussi posté sur le community de cloudflare.

Mais bien joué, et merci encore. Je continue.

Dernière modification par RidingAround (Le 28/03/2022, à 17:51)

RidingAround · Le 29/03/2022, à 08:40

Tiens, si tu fais pas iptables -L mais plutôt iptables --list -n, la table ne contient pas les domaines. Je précise en passant, même si je n'y crois pas vraiment.
Je pense plutôt que fail2ban ne sait pas comment mettre une IP suivie d'un domaine (dans le routage) dans un tunnel de bannissement.
Auquel cas, il faudrait regarder dans iptables-multiport.conf ce que fait :

actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>

et comment le forcer à tronquer l'IP, sachant qu'il travaille déjà avec l'option -n qui limite sa lecture au numérique ...

actioncheck = <iptables> -n -L <chain> | grep -q 'f2b-<name>[ \t]'

Dernière modification par RidingAround (Le 29/03/2022, à 09:01)

RidingAround · Le 03/12/2022, à 10:55

Bonjour à tous,
après plusieurs mois d'hébergement sous la forme énoncée dans ce topice, je tenais à vous dire ce que l'absence de fail2ban peut engendrer.
Je l'ai désactivé quelques jours sur un serveur hébergeant 5 solutions à forte fréquentation et à sensibilité particulière.
Dans les attaques brute force réalisées par des IP qui ne sont pas en rotation, déclenchant 1 log de bannissement toutes les 2 minutes tout de même, de nombreuses attaques ont mené à un écroulement des ressources du serveur, des alertes de ma solution de monitoring Zabbix, avec envois de mails sur les triggers de cpu (envolée, charge) puis finalement de remplissage de disque dur (access.log), des ralentissements pour les utilisateurs, des phases de sauvegardes nocturnes (rsync ou dupli) qui prenaient tellement de temps qu'elles débordaient sur le matin, des erreurs 5xx ou de connexion à la base de données dans les pires des cas.
Avec remoteip et fail2ban, j'évitais tout ceci.
J'ai ajouté une config iptables permettant de limiter les quantités d'actions (type ddos mais pas seulement) par "personne" et pare période indépendamment.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 26/03/2022, à 10:07

apache2 + mod remoteip, cloudflare, fail2ban

#2 Le 26/03/2022, à 15:32

Re : apache2 + mod remoteip, cloudflare, fail2ban

#3 Le 26/03/2022, à 15:51

Re : apache2 + mod remoteip, cloudflare, fail2ban

#4 Le 28/03/2022, à 08:44

Re : apache2 + mod remoteip, cloudflare, fail2ban

#5 Le 28/03/2022, à 10:29

Re : apache2 + mod remoteip, cloudflare, fail2ban

#6 Le 28/03/2022, à 11:45

Re : apache2 + mod remoteip, cloudflare, fail2ban

#7 Le 28/03/2022, à 11:52

Re : apache2 + mod remoteip, cloudflare, fail2ban

#8 Le 28/03/2022, à 15:26

Re : apache2 + mod remoteip, cloudflare, fail2ban

#9 Le 28/03/2022, à 16:54

Re : apache2 + mod remoteip, cloudflare, fail2ban

#10 Le 28/03/2022, à 17:18

Re : apache2 + mod remoteip, cloudflare, fail2ban

#11 Le 28/03/2022, à 17:42

Re : apache2 + mod remoteip, cloudflare, fail2ban

#12 Le 29/03/2022, à 08:40

Re : apache2 + mod remoteip, cloudflare, fail2ban

#13 Le 03/12/2022, à 10:55

Re : apache2 + mod remoteip, cloudflare, fail2ban

Pied de page des forums