Les petites infos – 2
Petites infos pour gros article 
SSHGuard
Je suis assez mécontent de Fail2ban : Usine à gaz, regex, attaques non détectées, consommation… Il fait « relativement » le job mais quand il faut mettre les mains dedans, ça devient l’enfer. Avis personnel bien sûr.
Dès que je cherche à remplacer un outil je passe par AlternativeTo, j’ai été surpris de trouver un soft mieux noté que Fail2ban dont je n’avais jamais entendu parler : SSHGuard. La rencontre a mal débuté : Documentation pointant vers la Wayback Machine (??), code source chez SourceForge, nom mal choisi.
J’ai cependant bien fait de creuser :
- Licence BSD, activement maintenu
- Gère de nombreux services (OpenSSH, Sendmail, Exim, Dovecot, vsftpd, proftpd…), full IPv6 support et prend en charge les backends : pf, ipfw, firewalld, ipset, iptables, nftables
- Consommation insignifiante sur le système
- Fait le job sitôt installé
- Deux fichiers de configuration dont 1 pour whitelist les adresses/hosts (voir les fichiers
/usr/lib/x86_64-linux-gnu/sshg*pour aller plus loin) - Version 2.3.1 dispo sur Debian Buster
- Le délai de blocage de 120s par défaut (modifiable) est multiplié par 1.5 aux blocages suivants, plus une IP est bloquée plus elle sera bloquée longtemps automatiquement
- Un patch a été proposé pour bloquer par service, si une attaque arrive sur le service OpenSSH, on bannit l’IP seulement sur ce service/port, on ne bloque pas l’IP pour l’ensemble des ports (utile en entreprise)
Quelques inconvénients :
- Documentation éparse, datée, peu précise
- Pour ajouter des signatures
- Avant la version 2.4 les services ont des codes (100, 240…) plutôt que des noms (sshd, exim…), idée complètement perchée je trouve
- On comprend rapidement que son périmètre est bien moins étendu que Fail2ban, on peut faire/configurer moins de choses mais sa simplicité fait sa force
On reste sur Fail2ban au boulot mais on va suivre SSHGuard d’un œil attentif. Je songe à l’adopter pour mes postes/serveurs persos même si je dois le tester davantage et attendre que d’autres blogueurs fassent un retour dessus, au boulot !
Fichiers .swp de nano
Lorsqu’on édite un fichier avec nano, un fichier « temporaire » .swp est créé. J’ai consulté la doc, fait des recherches sur le net et le dépôt Git, effectué des tests, rien ne semble prévu pour pouvoir désactiver cette fonctionnalité. Sur Vim : set noswapfile.
omrelp: could not connect to remote server, librelp error 10014
Au démarrage d’un serveur un message récurrent, moche et pénible s’affiche venant de rsyslog. Centraliser les logs de tous les serveurs devient une bonne pratique dans le monde professionnel, on utilise pour cela rsyslog et le module omrelp en général. Le problème est que rsyslog démarre (trop) tôt, avant que le network soit up, il n’arrive pas à joindre le serveur qui centralise les logs. Dès qu’il arrive à le joindre, ça logue correctement, un systemctl restart rsyslog est inutile, demeure ce message moche dans les logs au démarrage. J’utilise beaucoup les drop-ins systemd maintenant, on va « surcharger » la configuration du service rsyslog en lui disant de démarrer plus tard dans /etc/systemd/system/rsyslog.service.d/rsyslog.conf qu’on fera suivre d’un systemctl daemon-reload afin que ce soit pris en compte.
[Unit] After=network-online.target
https://bugzilla.redhat.com/show_bug.cgi?id=1263853
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
L’option AuthorizedKeysFile de sshd_config
La plupart des outils de gestion de configuration (Ansible, Puppet, Chef…) permettent d’ajouter/supprimer un fichier aisément sur une flotte de machines. Pour ajouter un accès à un utilisateur sur des serveurs, on utilisera l’option AuthorizedKeysFile dans le fichier /etc/ssh/sshd_config ainsi.
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 /etc/ssh/client_keys
Dans authorized_keys on mettra les clés de l’équipe (accès permanent), dans authorized_keys2 la clé de l’intervenant (accès temporaire) par exemple.
Le format de date en_US.UTF-8 sur Buster
La norme sur les serveurs en environnement professionnel est LANG=en_US.UTF-8. Avant Debian Buster si on faisait date ça donnait.
date Sat Dec 7 14:21:25 CET 2019
Sur Debian Buster ça donne.
date Sat 07 Dec 2019 02:21:25 PM CET
Normal (1, 2). Aucune solution simple pour avoir le format en 24h, on peut changer les locales (locale pour les afficher) en éditant /etc/default/locale ou en faisant localectl set-locale LANG=en_GB.UTF-8 par exemple (qui ne fait que modifier le fichier /etc/default/locale) mais un redémarrage sera nécessaire pour que le changement soit effectif…
Si on veut un truc plus lisible, on pourra ajouter export LC_TIME="fr_FR.UTF-8" dans son ~/.bashrc (ce que j’ai déconseillé pour avoir la même config/sortie que les clients) ou faire directement sur la ligne de commande.
LC_TIME="fr_FR.UTF-8" date samedi 7 décembre 2019, 16:35:04 (UTC+0100)
