[gull] [Resolu] fail2ban + ipset (ksoftirqd congestionne a ~500Ko/s (Ubuntu 22.04))

[Frederic Dumas]

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