Alors pour les gens qui utilisent encore POP et qui ont un Thunderbird qui se met à jour tout seul comme souvent sur les Windows, si subitement sans rien remarquer de différent et sans message d'erreur çamarcheplus™, la raison pourrait être que Thunderbird 78 désactive par défaut TLS < 1.2 et que certains fournisseurs comme ici Free n'ont pas mieux que TLS 1.1 sur POP !
Trois "solutions" toutes crades :
J'ai choisis la dernière solution, bien crade mais moins relou à distance… et entre un TLS troué ou pas de TLS sur une ligne FAI vers un service FAI… dans tous les cas c'est pas ouf.
Si seulement TB pouvait au minimum afficher un message d'erreur, même incompréhensible… on aurait au moins un point de départ…
J'ai voulu tester du let's encrypt (oui…) sur une VM Alpine. Apparemment il y a enfin un setup simple, qui fait ce qu'on veut et qui juste marche. Mais je n'ai pas encore pu tester le renouvellement auto évidemment.
Avec les paquets, on peut installer acme-client-plus et acme-client. Le dernier est le client ACME d'OpenBSD, écrit en C et avec pas mal de fontionnalités (mais pas les wildcard si j'ai bien compris). Le premier est un script shell et les quelques fichiers de conf pour qu'il renouvelle au besoin.
Plus rien à copier, mettre en place, installer, il suffit de faire un "acme-client-plus issue" et hop on a son certificat (une fois qu'on a corrigé nos erreurs de DNS/routage/config serveur web/…). Un peu comme le script que j'avais mis en place il y a longtemps, à la main. Là c'est pareil mais en tout prêt.
À voir au renouvellement… !
En faisant du debug sur un conteneur LXC, je me suis rendu compte qu'au milieu de syslog par exemple, il y avait des messages du noyau concernant l'hôte ou un autre LXC. J'ai trouvé ça pas top (même si pas très important).
Il y a apparemment deux facettes :
Le lien lié ici propose comment bloquer le syscall via les seccomp. Ça fonctionne.
Pour kmsg le lien précédent prétend que cela va casser des choses, j'ai tout de même voulu essayer. Par contre par défaut sur Debian Stretch, apparmor n'a pas l'air activé complètement, le module est là mais pas l'accès via proc (https://wiki.debian.org/AppArmor/HowToUse et aa-status). Je n'ai donc pas pu essayer de modifier cela (les autres restrictions, qui ont tout de même l'air de fonctionner malgré l'absence des paramètres cmdline sont dans /etc/apparmor.d/abstractions/lxc/container-base).
En attendant il suffit de cat /proc/kmsg depuis n'importe où pour tout savoir sur ce qu'il se passe sur le système côté noyau :P
Ah et aussi, ce n'est pas si simple que cela : https://lxadm.com/Lxc:_restricting_container_view_of_dmesg
D'autant que l'option est maintenant activée par défaut depuis Debian Stretch. En LXC root (pas non-privilégié donc) ça fonctionne tout de même (comme dit dans le lien github ci-dessus).
Si toi aussi tu as un fichier polkit (pklocalauthority) pour pouvoir monter des disques en CLI sans se compliquer la vie et sans pmount (je sais plus pourquoi c'était pas bon…), que donc tu utilises udisksctl, et que tout à coup le nom de l'action se prend un -other-seat parce qu'il y a une autre session existante en VNC, alors il suffit d'ajouter un gentil '*' au bout de l'action et zout :)
$ cat auto-mount.pkla
[Allow Automount]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2.filesystem-mount*
ResultAny=yes
ResultInactive=yes
ResultActive=yes
Problème avec des certifs x509 sur des ESXi pas mis à jour, une histoire de param DH trop faibles. C'est bien de check. C'est bien d'avertir. C'est pas forcément idiot de faire peur. C'est con d'empêcher de contourner (oui les gens le font sans réfléchir du coup mais il faut aussi pouvoir faire ce qu'on veut à un moment). Et quand t'es en interne, que t'as besoin d'administrer ça vite-fait et que l'alternative c'est le client lourd fenêtre-only, bah c'est moins pire.
Donc sous Firefox, ça se désactive (complètement du coup…) dans about:config, sous chromium via un param de ligne de commande.
Script perl qui regarde quels processus utilisent encore des libs qui ont disparu depuis leur démarrage (mises à jour).
Liste :
needrestart -r l -v
(le -v affiche de quelles libs il est question, et comment il est arrivé à la conclusion que ces services-là doivent être relancés (ou ignorés : cas d'un process lancé à la main en session utilisateur)).
Par exemple pour une instance picomon "ban" lancée par systemd :
[main] #183 exe => /usr/bin/python3.4
[Core] #183 is a NeedRestart::Interp::Python
[Core] #183 source is /usr/local/bin/picomon
[main] #183 is picomon@ban.service
On peut aussi directement lui faire relancer les services, avec -r i (ou rien, c'est par défaut). On a alors soit un debconf qui permet de sélectionner les service que l'on souhaite (tous pré-cochés sauf certains comme journald ou dbus), soit une ligne-question par services.
needrestart est packagé dans Debian (depuis Jessie et wheezy-backports) et intègre des hooks pour apt/dpkg.
Ci-lié un post où j'explique comment j'ai mis en place des certificats Let's Encrypt sur mon serveur.
En passant j'ajouterai que dans le cas d'un site mod_proxy d'apache, on peut sortir le dossier de vérification du proxy comme cela :
ProxyPass /.well-known/acme-challenge/ !
Création d'un réseau guest sur mon Netgear WNR3500L v2 flashé avec TomatoUSB, tout fonctionne (coupe deux fois les connexions, au VLAN car reboot comme prévu mais aussi au moment de créer le br1).
Je n'ai pas eu à jouer avec iptables comme demandé : ça fonctionne comme je veux de base (sortir vers l'extérieur autorisé, passer entre les réseaux internes bloqué). Ça se vérifie, les compteurs iptables augmentent bien un par seconde avec des ping de test (guest => principal, principal => guest, guest => dehors) :
355 29820 DROP all -- br1 br0 anywhere anywhere
=> le 355 augmente
46 3864 DROP all -- br0 br1 anywhere anywhere
=> le 46 augmente
40 3360 ACCEPT all -- br1 any anywhere anywhere
=> le 40 augmente
Voila voila, je suis prêt pour quand des gens viendront avec un win10 et que j'oserai pas dire que non mais je donne pas mon mot de passe à 'crosoft :P
Là j'en donnerai un autre…
En passant à nginx, ne pas oublier de réincorporer les blocages par htaccess à la config… ici un exemple pour dokuwiki.
Pour galette j'ai mis ça :
location ~ /(data|config|lib)/ {
deny all;
}
Si on veut faire confiance à un certificat auto-signé, le mettre dans /usr/local/share/ca-certificates/ et lancer update-ca-certificates. Attention uniquement *.crt est pris en compte.
J'avais denyhosts depuis le début sur mon serveur @home mais ça a été supprimé de jessie. Je me suis dit que je m'en fichais pas mal au final, c'est pas de la sécurité ou quoi c'est surtout pour pas se faire pourrir les logs.
Là j'ai dû plonger dans /var/log/auth.log au boulot et… ouah du spam en continu, c'est bien casse-pieds pour suivre. Le moment de se plonger dans fail2ban donc !
Bah c'est tout bête comme dit dans l'article cité, et ça a l'air plus évolué.
Exemple, on peut afficher le statut actuel du ban sur SSH :
$ sudo fail2ban-client status ssh
Status for the jail: ssh
|- filter
| |- File list: /var/log/auth.log
| |- Currently failed: 1
| - Total failed: 219
- action
|- Currently banned: 1
| - IP list: 45.114.11.50
- Total banned: 1
Pour ajouter des plages IP à ne pas bannir, on peut copier le jail.conf dans jail.local comme suggéré et juste laisser "ignoreip", pour override. Ensuite :
fail2ban-client reload ssh
et vérif :
fail2ban-client get ssh ignoreip
Pas mal le reload sélectif et la verif en CLI ! :)
Avec OpenSSH si on veut restreindre l'accès à un user selon son IP de connexion, on peut pas juste l'interdire de base puis l'autoriser dans un bloc Match. On peut feinter comme ça :
Match User sharegridftp Address 10.10.10.0/24
MaxAuthTries 6
Match User sharegridftp
MaxAuthTries 0
Attention, ordre de match important. Apparemment il semble prendre le premier dans l'ordre (pas spécifié dans le man).
Script bash de test de configuration SSL/TLS d'un serveur. Probablement moins complet que ssllab.com mais au moins c'est pas un service en ligne et la sortie est quand même joliment colorée et lisible.
Pour une discussion et des exemples de config, voir par exemple http://shaarli.guiguishow.info/?GPqmpA
Refaire le certif autosigné tout simple du paquet ssl-cert (par exemple si on a installé le paquet avant d'avoir mis le bon nom de machine) :
make-ssl-cert generate-default-snakeoil --force-overwrite
Une seule commande pour renew le certif SSL d'exim :
/usr/share/doc/exim4-base/examples/exim-gencert --force
Pas besoin de lancer la commande openssl donnée à la main : le script le fait.
À noter que ce sera (forcément) un certif auto-signé, et qu'il est créé pour 3 ans.
Enfin un article intéressant sur le problème de sécurité de bash. Là j'ai compris :)
Hier, renouvellement des certificats SSL d'ARN. On utilise des certifs StartSSL (gratuits). Sauf que après avoir remplacé le certif, j'ai eu une erreur bizarre que je ne connaissais pas à propos de OSCP. En fait le serveur OSCP de StartCom n'était pas encore à jour, donc les nouveaux certificats étaient refusés.
OCSP est une sorte de hack pour permettre plus facilement la vérification des certificats (en particulier, sans avoir une liste de révocation en local qui ne serait que difficilement à jour). Le client interroge à chaque fois un serveur pour savoir si le certif est (encore) valide. Mouais, ça veut donc dire que StartCom connait TOUS les gens qui se connectent à notre site.
FTR, l'erreur présentée par firefox :
Le serveur OCSP n'a pas de statut pour le certificat. (Code d'erreur : sec_error_ocsp_unknown_cert)
Et voila en quelques phrases de quoi faire taire tous ceux qui profitent de la faille OpenSSL pour dire que le logiciel libre c'est pas si sécure que ça :P
Bon tout le monde en parle, c'est donc pas spécialement intéressant à lier ici. Ce qui l'est c'est que j'ai galéré longtemps à le corriger chez moi. J'avais testé SPDY, un hack pour optimiser les chargements de pages en groupant les données (de mémoire), je l'avais désactivé mais le module SSL custom pour apache était toujours utilisé : mod_ssl_with_npn. Il m'a suffit de virer ça et hop enfin tranquille…
Je suppose que le module avec NPN a une libssl liée en statique, ce qui semble se confirmer :
module apache officiel : 177824o
mod_ssl_with_npn.so : 2100904o