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 :
  - /proc/kmsg, utilisé par rsyslogd
  - le syscall "syslog" utilisé par dmesg
Peut-être aussi via /dev/kmsg, mais ce n'est pas le cas chez moi (https://github.com/lxc/lxcfs/issues/131).

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).

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.

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/ !

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;
       }

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 ! :)

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

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.

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)

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