[gull] [Vraiment resolu] fail2ban + ipset (ksoftirqd congestionne a ~500Ko/s (Ubuntu 22.04))
Frederic Dumas
f.dumas at ellis.siteparc.fr
Mon Sep 30 17:04:24 CEST 2024
Hello,
des erreurs dans le log de fail2ban m'ont fait comprendre que la configuration par défaut d'ipset ne convient pas aux grosses listes (>64K) d'adresses bannies par fail2ban:
> fail2ban.utils [927653]: ERROR 7f9ceb6bb750 -- exec: ipset add f2b-sshd 112.6.[xxx.xxx anonymized] timeout 0 -exist
> fail2ban.utils [927653]: ERROR 7f9ceb6bb750 -- stderr: 'ipset v7.15: Hash is full, cannot add more elements'
> fail2ban.utils [927653]: ERROR 7f9ceb6bb750 -- returned 1
> fail2ban.actions [927653]: ERROR Failed to execute ban jail 'sshd' action 'iptables-ipset-proto6' [SNIP]: Error banning 112.6.[xxx.xxx anonymized]
Pour chaque 'jail', fail2ban crée dans ipset un jeu de données indépendant. Dans mon cas, une première liste de ~500 adresses bannies de http ont pu sans problème être toutes enregistrées par ipset; puis une seconde liste de ~70K adresses bannies pour avoir répété des attaques en ssh ont congestionné ipset: seules les 65535 premières ont pu être enregistrées. Ni les ~5K restantes, ni toutes les nouvelles IP attaquant ne peuvent être enregistrées; elles ne sont donc pas filtrées, rendant fail2ban inopérant pour la 'jail' protégeant sshd.
Le problème est très clairement décrit dans ce rapport de bug datant de l'année dernière:
https://github.com/fail2ban/fail2ban/issues/3549
Une solution est disponible, permettant à fail2ban de faire créer par ipset de plus grand jeux de données:
https://github.com/fail2ban/fail2ban/pull/3564
Dans mon cas, cette version de fail2ban n'étant pas celle des dépôts d'Ubuntu 22.04, le plus simple fut d'abandonner le bantime -1 que j'avais configuré dans fail2ban, pour un bantime de quelques mois; la liste d'adresses bannies a dégrossie de quelques dizaine de milliers, compatible avec la configuration par défaut d'ipset.
C'est un "bug" un peu vicieux, parce que (1) silencieux, visible seulement si on va manuellement jeter un oeil dans les logs, (2) qui retire tout utilité à fail2ban pour le protocole concerné dès qu'il se déclenche, alors qu'apparemment, la 'jail' correspondante est correctement configurée. Sauf que plus aucune nouvelle adresse bannie n'est effectivement bloquée.
On me glisse dans l'oreillette qu'il serait peut-être temps de passer à nftables, plutôt que de bricoler ipset en surcouche d'iptables. :-) Merci à la régie !
--
Frédéric Dumas
f.dumas at ellis.siteparc.fr
> Le 28 sept. 2024 à 18:31, Frederic Dumas via gull <gull at forum.linux-gull.ch> a écrit :
>
>
> Complément, pour ceux que l'utilisation d'ipset par fail2ban intéressera. Marc, tu as posé le bon diagnostic, pour la suite, le web fut mon ami. L'installation du paquet ipset provoque l'écriture de trois fichiers supplémentaires dans /etc/fail2ban/action.d:
>
>> iptables-ipset-proto4.conf
>> iptables-ipset-proto6-allports.conf
>> iptables-ipset-proto6.conf
>
> Source: https://serverfault.com/questions/1082564/fail2ban-ipset-which-conf-to-use/1082704#1082704
>
>
> L'ajout de ces lignes
>
>> banaction = iptables-ipset-proto6
>> banaction_allports = iptables-ipset-proto6-allports
>
> dans la section [DEFAULT] du fichier de configuration jail.local (dans /etc/fail2ban/) devrait suffire. Les instructions de jail.local ont préséance sur les instructions par défaut encore présentes dans jail.conf:
>
>> banaction = iptables-multiport
>> banaction_allports = iptables-allports
>
> Ces deux directives ne s'appliquent donc plus dès qu'on redémarre fail2ban.
>
>
> Redémarrer fail2ban
>
>> # systemctl restart fail2ban
>
>
> Au passage, aucune action manuelle supplémentaire n'est requise pour conserver l'historique des IP bannies par fail2ban. À l'arrêt de fail2ban, les 70K+ règles reject ont été effacées d'iptables:
>
>> # iptables -n --list --line-numbers | sed '/^num\|^$\|^Chain/d' | wc -l
>> 0
>
>
> Au redémarrage, c'est fail2ban qui recharge les ip bannies dans ipset, cette fois-ci. La migration d'iptables à ipset est donc vraiment simple. Les règles iptables créées par fail2ban se limitent à deux lignes:
>
>> # iptables -n --list --line-numbers
>> Chain INPUT (policy ACCEPT)
>> num target prot opt source destination
>> 1 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443 match-set f2b-apache-auth src reject-with rcmp-port-unreachable
>> 2 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 22 match-set f2b-sshd src reject-with icmp-port-unreachable
>
>
> La vitesse de transfert sur le (gros) téléchargement en cours vient de passer de ~500Ko/s à ~6Mo/s. ksoftirqd n'est plus déclenché. Marc, quand je suis dans le coin, il faut qu'on prenne une bière ensemble. Encore merci !
>
>
>>> ksoftirqd qui saturait (très visible avec top, peu
>>> avec htop sans config)
>
> Merci aussi de faire remarquer cette différence entre top et htop; elle n'est pas seulement cosmétique. Dans mon cas, c'est le script pyhton glances qui avait attiré mon attention sur la charge énorme liée à ksoftirqd. J'aurai pu regarder top plus tôt, je m'étais habitué à htop.
>
>
> --
> Frédéric Dumas
> f.dumas at ellis.siteparc.fr
>
>
>> Le 28 sept. 2024 à 15:52, Frederic Dumas via gull <gull at forum.linux-gull.ch> a écrit :
>>
>>
>> Tu as vu juste du premier coup Marc, avec iptables.
>> Mille mercis.
>>
>>
>>> # iptables -n --list --line-numbers | sed '/^num\|^$\|^Chain/d' | wc -l
>>> 71045
>>
>>
>> Avec un bantime à -1 sur fail2ban, le magasin se rempli vite.
>>
>>
>>> # fail2ban-client status apache-auth | head -n8
>>> Status for the jail: apache-auth
>>> |- Filter
>>> | |- Currently failed: 4
>>> | |- Total failed: 436
>>> | `- File list: /var/log/apache2/transmission_error.log /var/log/apache2/error.log
>>> `- Actions
>>> |- Currently banned: 576
>>> |- Total banned: 576
>>
>>
>>> # fail2ban-client status sshd | head -n8
>>> Status for the jail: sshd
>>> |- Filter
>>> | |- Currently failed: 5
>>> | |- Total failed: 37918
>>> | `- File list: /var/log/auth.log
>>> `- Actions
>>> |- Currently banned: 70468
>>> |- Total banned: 70468
>>
>>
>> 576 + 70468 = 71044
>>
>> CQFD.
>>
>>
>> Il faut maintenant purger les 70K+ drops d'iptable, peut-être exporter les IP de fail2ban. Une fois le package ipset ajouté au système, où se fait la configuration manuelle pour dire à fail2ban de l'utiliser, plutôt que de continuer à écrire des règles iptable ?
>>
>>
>> --
>> Frédéric Dumas
>> f.dumas at ellis.siteparc.fr
>>
>>
>>> Le 28 sept. 2024 à 14:18, Marc SCHAEFER via gull <gull at forum.linux-gull.ch> a écrit :
>>>
>>> Hello,
>>>
>>> On Sat, Sep 28, 2024 at 01:06:43PM +0200, Frederic Dumas via gull wrote:
>>>> un petit casse tête sur Ubuntu, puisque c'est le week-end. Ce tout petit serveur s'étrangle dès qu'on tire dessus en sftp à peine quelques Mb/s. ksoftirqd vient faire la police, et le débit moyen plafonne à ~500Ko/s (~5Mb/s), alors que de l'autre coté, le client sftp est sur un accès GPON.
>>>
>>> J'ai plusieurs idées (*), mais que dit nestat -i ?
>>>
>>>> Ça parait personnalisé par l'hébergeur dans l'image Ubuntu installée
>>>> sur ses serveurs.
>>>
>>> Peut-être lui demander pourquoi?
>>>
>>>
>>> (*) - trop de règles iptables: en remplaçant par ipset j'ai
>>> obtenu de sacré gains de performance sur des systèmes
>>> peu performants (ok, ça commence à se voir dès 20'000
>>> entrées, j'en ai > 200'000) -- c'était exactement
>>> ksoftirqd qui saturait (très visible avec top, peu
>>> avec htop sans config)
>>> - TCP/TSO non activé: une interruption par paquet y.c
>>> confirmations
>>> - sshd monothread
>>> - pertes de paquets
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> gull mailing list
>> gull at forum.linux-gull.ch
>> https://forum.linux-gull.ch/mailman/listinfo/gull
>
>
>
> _______________________________________________
> gull mailing list
> gull at forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull
More information about the gull
mailing list