Le blogouille de Caro et Nico

Entre famille, sport et aventures !

Renouvellement certbot pour apache debian avec http-01

Bon Let’s Encrypt met fin au support du challenge type TLS-SNI. Donc on passe à autre chose, si possible automatisé. On se tente un challenge type http-01, qui passe finalement avec

certbot certonly –webroot -w /var/www -d www.caronico.fr

Tout simplement. Possibilité de le faire un mode –dry-run pour le faire un coup à blanc, ensuite pour de vrai, possibilité de vérifier la date et les détails du certificat dans le navigateur web.

Enfin refaire un coup de certbot renew –dry-run

pour simuler un nouveau rafraichissement du certificat. Attention à bien se positionner dans le dossier /var/www pour faire ces commandes.

Enfin, il faut relancer le service dovecot, pour recharger les nouveaux certificats mis à jour, sinon celui ci garde en mémoire les anciens certs.

Mise en place du DKIM

DKIM (DomainKeys Identified Mail) permet de protéger le nom de domaine au niveau des mails pour éviter qu’une autre personne en usurpe l’identité. Il faut plusieurs composants pour que cela fonctionne :

Installer opendkim et le configurer avec postfix. Attention sur le package debian il y a une certaine confusion sur le port de socket d’écoute entre 8891 et8892 dans les fichiers de config. Tout doit pointer vers le 8891.

Vérifier le tout dans un email de trafic de test de base que postfix arrive bien à communiquer avec opendkim et que tout circule. Bonus : les emails entrants bénéficient maintenant de vérification DKIM à leur tour.

Générer la clef de sécurité DKIM et l’intégrer aux records DNS domaine. Attention la clef étant assez grande (2048 bits) certaines interfaces de contrôle des DNS ont du mal à accepter une telle chaine. On peut passer en TXT / mode brut et éditer, sinon maintenant l’interface de OVH gère correctement l’insertion de de la chaine DKIM.

Ensuite on peut tester immédiatement avec un outils comme https://dkimvalidator.com/ si cela fonctionne. L’outils ne met pas en cache le DNS, donc dès que la modification est faîte on peut envoyer un mail signé. L’outils fournit pas mal de renseignements, en particulier si le mail est bien signé, si la signature publique est bien lisible dans le DNS (et quelle signature/record il tente de chercher) et enfin si la signature match. Bonus : on peut voir une analyse SpamAssassin de cet email et voir si des ajustements sont nécessaires.

Ensuite il faut ajuster le record DNS progressivement, en vérifiant bien l’impact sur le trafic de mails, ainsi que les reports DMARC des principales plateforme. Il y a plusieurs outils de tests sympa pour vérifier le handshake end-to-end, en envoyant un test de mail qui passe toute la chaîne de sécurité, avec vérification antispam complète, SPF, DKIM et spamassassin. Faire monter progressivement le niveau de policy du DKIM, de test vers prod, puis renforcer la policy vers QUARANTAINE, puis quelques jours plus tard vers REJECT.

En surveillant les rapports DMARC j’ai pu noter que le nombre de tentatives de spoofing a baissé, voir passé à zéro sous quelques semaines. Rudement efficace la policy reject !

Debian Live USB 9.4.0 with persistence

Ok, I spent some time to get the Live USB media of Debian Live 9.4.0 working. The documentation and experience is scattered around on Internet, so let’s get this here together so I can reproduce it later.

Scenario : deploy Debian Stretch 9.4.0 Live on USB stick with persistence, from Windows environment.

Source the right ISO : I got the amd 64bits edition with MATE environment, and non-free firmware. The non-free firmware was needed to get things working like in particular the Intel Wifi card.

User the right tool : Rufus was making the best installation, despite it does not provide persistence support, which need to be added after initial install.

Create the image, by using Rufus on your USB stick and selecting the ISO file you downloaded. That initial, primary, active, first permission has to be FAT32. It will take the whole space on the drive, that is OK.

Once the ISO file has been transferred/installed on the stick, time to get a tool like EPM (EaseUS Partition Manager) to resize down the primary FAT32 partition to something much smaller, like 3GB to cover your ISO image (mine was 2.2GB).

Create a new partition after this one (you can user the whole space remaining), and the under Linux Debian reformat it to « ext4 » and label it « persistence ». The persistence is NOT supported on FAT32 file, I figured that out by getting errors in kernel.log.

Then mount this newly created ext4 volume, and on the root of it, create a file named « persistence.conf » and add 2 lines (the second being an empty, blank line), the first just contains :

/ union

Close it all, reboot and select kernel option by pressing « tab » on the boot menu and adding « persistence » (without the quotes) to the boot.
The kernel should get it, and with that union on / level, you simply get full persistence of the environment.
You can happily create folders on Desktop, in your home, change your password as well install and upgrade packages, and find this back when you reboot.

 

Lutte anti slowhack / botnet hack.

Bon alors… quand on gère des serveurs qui sont connectés sur internet, malgré le firewall, dès qu’on a une bonne série de services (SSH, FTPs, HTTPs, IMAPs, SMTPs, POP3s, etc…) on se retrouve avec un PAQUET de tentative d’intrusions, du genre plusieurs à la minute… à force cela devient fatiguant et fait tourner les machines pour rien.

En utilisant une bonne combinaison d’outils, on arrive à bien contenir les attaques basiques de type brute force venant de la même IP. En particulier avec les outils Fail2Ban et DenyHosts. Par contre depuis plusieurs mois je fait face à un nouveau type de problème, des milliers d’addresses IP différentes qui tentent toute une combinaison de login et mot de passe différents, genre « classique », mais à chaque fois, une seule unique IP tente une combinaison, puis quelques secondes après, c’est une autre IP qui tente une combinaison légèrement différente. Ca a l’air bien foutu, mais difficile à bloquer, en fait il y a quelques parades. 

Par exemple Dovecot logge se genre de choses

2017-11-12 14:44:08 auth-worker(7082): Info: sql(eleanor,101.187.110.152): unknown user (given password: password)

 

Et voilà l ‘adresse IP 101.187.110.152 qui tente la combinaison eleanor/password … je serais curieux de savoir ce qui se passe si ce script d’un botnet tombe sur un login valide, à priori je penche pour de l’envoi de spam.

En tout cas, voilà comment j’ai procédé pour limiter les ennuis :

Augmenté la fréquence de synchronisation de DenyHosts, à 5 minutes. Il y a une limite hardcodée de 50 hôtes à chaque sync, mais cela fait tout de même 15000 hôtes par jour à récupérer qui seront bloqués, en mettant un filet large de sélection, genre DOWNLOAD_THRESHOLD à 2 et SYNC_DOWNLOAD_RESILIENCY = 5h

Ensuite sur fail2ban, on peut mettre quelques filtres REGEX pour capturer ces tentatives de botnet sommes toutes basiques. Genre :

,<HOST>\): unknown user \(given password: 123456
,<HOST>\): unknown user \(given password: password
,<HOST>\): unknown user \(given password: web
,<HOST>\): unknown user \(given password: russ

Et en ajoutant quelques filtres sur les mots de passe basiques, on récupère un paquet d’adresse IP (j’en ai eu environ 70000 par jour !!) et avec un bon ban genre de plusieurs semaines, et ben voili voilou, bien tranquille, le nombre de de tentatives d’intrusions a complètement diminué, par un facteur 100.

Bon ban ! 

 

Bug sous libapache2-mod-perl2 (2.0.9-4)

Bon le package Debian libapache2-mod-perl2 (2.0.9-4) est planté depuis sa mise à jour, avec une impossibilité d’exécuter son script post installe correctement. Pas d’impact technique mais c’est ennuyeux sur l’exécution de APT-GET UPGRADE.

A surveiller cela pourrait être du a PHPMyAdmin, au package Apache2 lui même, ou un problème de configuration locale.