Accueil › Publications taguées Linux › Page 2

Linux

Moderniser iptables après 10 ans… sans casser Docker !

Posté le de — Aucun commentaire ↓
Licorne sysadmin réorganisant un ancien classeur de règles firewall en chemins SSH, Docker et blacklist IP

Bonjour à tous, aujourd’hui on va parler du firewall iptables, et de vieux articles qui ont plutôt bien vieilli (et d’un quatrième encore tout frais), et d’une petite modification d’interface réseau qui aurait pu mettre le serveur dans le noir. Bref, un sujet parfaitement raisonnable à traiter un soir en SSH.

Pour rappel, ou pour les nouveaux qui nous rejoignent (coucou 👋) le serveur qui héberge ce site est directement exposé dans un datacenter OVH. Il porte plusieurs services web derrière un Nginx Proxy Manager, lui-même dans Docker (cf. ma série sur Docker), sans WAF ou CDN externe pour cacher la m… poussière sous le tapis. Les ports 22, 80 et 443 doivent rester accessibles depuis Internet. Et toute la politique du firewall doit donc fonctionner pour de vrai, dans l’environnement « à peine agressif d’Internet », pas seulement avoir l’air impressionnante dans un article du blog.

La leçon de cette migration tient en une phrase : un firewall n’est pas une liste de règles, c’est le chemin réel suivi par les paquets. Et ce chemin avait beaucoup changé depuis 2017.

Quatre articles, quatre couches de défense du firewall iptables

Ce chantier est le fils spirituel … Lire la suite

Codex en Remote SSH : moderniser un backup directement sur le serveur

Posté le de — Aucun commentaire ↓
Codex en Remote SSH pour auditer et valider un backup Docker sur un serveur distant

Bonjour à tous, aujourd’hui je vais vous parler de Codex en Remote SSH et d’un vieux script de backup qui traînait sur mon serveur. Vous savez, le genre de script qu’on a écrit quelques années plus tôt, qui a toujours plus ou moins fait le boulot et qu’on évite de regarder de trop près tant que les sauvegardes semblent tomber quelque part…

Sauf qu’entre-temps, j’ai migré le serveur de Debian 12 vers Debian 13 (Cf. Crowdsec), quelques containers ont disparu, d’autres ont changé, et j’avais finalement très peu retouché au script de sauvegarde d’origine. Un retour aux sources après ma série sur Docker et Portainer, en quelque sorte. Il était donc temps de vérifier si ce machin sauvegardait encore réellement quelque chose.

Pour le coup, je n’ai pas commencé par ouvrir une console SSH et modifier le Bash au petit bonheur. J’ai ouvert le serveur directement dans VS Code avec l’extension Remote SSH, puis j’ai travaillé avec Codex de manière interactive sur la machine.

L’objectif n’était pas de demander à une IA : « fais-moi un script de backup ». L’objectif était de lui faire auditer l’existant, confronter ses hypothèses au vrai serveur, proposer une nouvelle version, puis … Lire la suite

Crowdsec

Posté le de — Aucun commentaire ↓

Bonjour à tous. Oui, je sais, cela fait presque deux ans que je n’ai rien écrit sur le blog, mais je ne suis pas encore mort, et ce n’est pas faute d’avoir des brouillons plein les placards… Bref, la vie de Head of CERT est bien remplie ! Tout ça pour vous dire que j’ai migré le serveur geekeries.org vers un nouveau. Debian 12 se rapprochait doucement de sa fin de vie, et comme dirait Marc Fred, je n’avais pas envie de mériter de m’en prendre une. Donc on ne réfléchit pas, on patch 😉 Bref, quelques heures plus tard, et le temps de tout bien reconfigurer (iptables, fail2ban, docker, etc.), je vais pouvoir vous parler de CrowdSec et de la version free que vous pouvez déployer sur vos machines.

CrowdSec, c’est quoi déjà ?

CrowdSec se présente lui-même comme un IPS open source et participatif. Vous vous souvenez de mes posts sur AbuseIPDB? Eh bien CrowdSec, c’est globalement le même principe qu’un AbuseIPDB en mode “boosté aux hormones”. Je m’explique : comme pour AbuseIPDB, CrowdSec s’installe en tant qu’agent sur votre ou vos serveurs. Il surveille les journaux d’événements locaux à la recherche d’événements en … Lire la suite

Rsyslog too many open files

Posté le de — Aucun commentaire ↓

Bonjour à tous, aujourd’hui je voulais vous partager une erreur que j’ai rencontrée récemment avec une infra Splunk, plus exactement avec la couche de collecte Rsyslog (vous savez celle que je recommande dans mon podcast sur les 10 commandements du SIEM). Cette erreur qu’on a fini par identifier dans les journaux avec le message suivant « rsyslog too many open files » et plus précisément la ligne suivante :

May 06 05:47:13 myserver rsyslogd[6896]: file '/splunk-inputs/PROXY/myproxyhost/2022-05-06T03+02-PROD-PROXY.log': open error: Too many open files [v8.24.0-41.el7_7.2 try http://www.rsyslog.com/e/2433 ]

Le log d’erreur arrive dans /var/log/message à priori. Néanmoins, de mon côté on ne l’a vu que depuis la commande journalctl, quelques exemples qui m’ont permis de la mettre en avant :

journalctl --no-pager | tail -f
journalctl -u rsyslog
journalctl --no-pager > /tmp/rsyslogtmp.log

Par défaut, la limite pour rsyslog était à 1024 fichiers ouverts simultanément sur notre système. Pas bien clair sur le pourquoi car les limites systèmes (cf. fichier /etc/security/limits.conf) été bien à 64000 :

ulimit -Sn
64000

Pour autant notre processus rsyslog plafonné à 1024 fichiers. Ce qui causait une erreur bien zarb où on perdait 15min de log au début de chaque heure. Du coup, avec l’aide … Lire la suite