Bonnes pratiques SSL

La configuration apache ci-dessous devrait vous prémunira des dernières turpitudes liées à OpenSSL et vous permettra d’obtenir un bon score à ssllabs ou testssl.sh

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+AESGCM EECDH EDH+AESGCM EDH+aRSA HIGH !MEDIUM !LOW !aNULL !eNULL !LOW !RC4 !MD5 !EXP !PSK !SRP !DSS !3DES"
SSLHonorCipherOrder on

En ce qui concerne postfix:

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = high
smtpd_tls_exclude_ciphers = aNULL, MD5, 3DES, DES, RC

Sources:
– https://testbit.eu/apache-sslciphersuite-without-poodle/
– http://www.bortzmeyer.org/drown.html

Merci d’ailleur à @bortzemeyer de m’avoir fait découvrir http://testssl.sh/

 

Vérifier la validité de ses certificats SSL avec nagios

nagios_screen

Rien de plus honteux pour un sysadmin de laisser passer la date de validité des certificats SSL et de se retrouver avec des services mail en carafe, des vpn inutilisables et des messages « ce site n’est pas sécurisé » sur l’intranet client.

C’est particulièrement vrai si on utilise les services de letsencrypt.org, qui propose des certificats avec une très courte durée de validité, même si des rappels par email sont régulièrement reçus.

L’automatisation de cette vérification par Nagios est assez simple:
1. Installer le plugin adéquat.
2. Définir une nouvelle commande.
3. Définir un nouveau service.

En ce qui concerne mon installation:

  • Mes plugins personnalisés sont stockés dans /etc/nagios/Opendoor/Plugins
  • Mes définitions de commandes sont dans /etc/nagios/Opendoor/commandes.cfg
  • Mes définitions de services dans /etc/nagios/Opendoor/services.cfg
  • Bien évidemment, le répertoire /etc/nagios/Opendoor fait l’objet d’une directive cfg_dir dans le fichier de configuration principal /etc/nagios/nagios.cfg

Installer le plugin:

git clone https://github.com/matteocorti/check_ssl_cert.git
cp check_ssl_cert/check_ssl_cert /etc/nagios/Opendoor/Plugins/check_ssl_cert

Définir une nouvelle commande:

define command{
        command_name    check_cert_validity
        command_line    PATH_TO/check_ssl_cert --noauth -H $ARG1$ --warning 30 --critical 10
        }

Définir un nouveau service:

define service
        host_name               gelatine
        service_description     check certificate validity
        use                     lazy-service
        check_command           check_cert_validity!pad.opendoor.fr!
        }

Remarque:

  • lazy-service est une définition de service personnalisée, avec une
    fréquence de vérification moins importante. Vous pouvez-utiliser generic-service à la place.
  • host_name désigne la machine hébergeant le ou les sites
  • La commande prend en paramètre le nom du site dont on souhaite vérifier le certificat.

# vim: set filetype=dokuwiki:

Changer le port d’écoute de SSH sans se prendre les pieds dans le tapis SELinux

Changer le port d’écoute de vos serveurs SSH, c’est de la sécurité par l’obscurité, mais au moins, vos logs d’accès ne seront pas pollués par toutes les tentatives de connexion effectués par tout le bot du grant Ternet.
ssh
En pratique c’est simple, il suffit:

  1. d’avoir une directive Port 4242 dans le fichier /etc/ssh/sshd_config
  2. d’ouvrir votre pare-feu ( firewall-cmd –permanent –add-port 4242/tcp ; firewall-cmd –reload )
  3. de relancer votre service (systemctl restart sshd)
  4. de vous assurez que vous pouvez bien vous connecter sur le nouveau port (ssh serveur -p 4242)

Si vous êtes courageux et que vous n’avez pas désactivé SElinux, ça coincera à l’étape 3 (le service ne redémarrera pas, SELinux ne lui permettant pas d’ouvrir ce port).

Il faudra associer votre port au type selinux ssh_port_t à l’aide de la commande suivante:

semanage port -a -t ssh_port_t -p tcp 2222

Suivre ses modifications de configuration avec etckeeper et git

Un logiciel de suivi de version permet de conserver toutes les versions d’un même fichier. Chaque modification est accompagné d’un message de « commit » expliquant la nature de la modification.

Indispensable pour les développeurs, cet outil peut s’avérer intéressant pour un sysadmin soucieux de tracer les modifications apportées à son système :

  • connaître l’historique des modifications du fichier /etc/httpd/conf/httpd.conf
  • ne plus avoir à faire une copie de sauvegarde « au cas où » avant une modification de configuration
  • Pouvoir revenir rapidement à la « dernière bonne configuration connue »
  • Savoir qui est à l’origine de la boulette dans la conf de bind (et donc qui va payer l’apéro à midi)

Continuer la lecture de « Suivre ses modifications de configuration avec etckeeper et git »