Une interface dummy est un type particulier d’interface réseau.
Par défaut le noyau linux ne permet d’en créer qu’une seule, pour en créer plusieurs il suffit de (re)charger le module dummy comme suit (ici on permet d’en créer 2) :
/sbin/modprobe dummy numdummies=2
Quelques notes sur l’utilisation de docker.
Je ne vais pas détailler ici ce qu’est docker ni à quoi ça peut servir, il y a suffisamment d’articles sur le net. Pour faire simple, docker est un système de gestion de conteneurs.
Un Dockerfile est un fichier d’instructions permettant de créer une image. Il doit toujours s’appeler Dockerfile.
# fenrir/test # Debian latest # Test image # # VERSION 0.0.1 # FROM debian:latest MAINTAINER Fenrir <mon.addresse@de.messagerie> ENV DEBIAN_FRONTEND noninteractive # Install ssh RUN apt-get update && apt-get install -y -q ssh # Configure ssh RUN mkdir /var/run/sshd RUN echo 'root:password' | chpasswd RUN sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config RUN rm /etc/ssh/ssh_host_*_key.pub # Start ssh server CMD ["/usr/sbin/sshd", "-D"] # Expose port EXPOSE 22
Les images sont les briques de bases de docker, on peut voir une image comme un instantané d’un système avec sa configuration et ses applications. C’est à partir de ces images que sont créés les conteneurs, mais une image peut aussi servir de base pour une autre image (comme dans le Dockerfile ci-dessus).
C’est principalement ça qu’on manipule, un conteneur est une branche exécutable d’une image. Les bonnes pratiquent veulent qu’un conteneur soit jetable à tout moment sans perte de données, dit autrement, un conteneur ne devrait rien contenir d’autre que ses programmes. Tout ce qui est données (par exemple les pages d’un site web et le contenu de sa base de données) devraient être en dehors du conteneur, par exemple dans des volumes.
On vient de dire qu’un conteneur doit être jetable, il faut donc enregistrer les données dans un endroit persistant, on peut le faire de plusieurs manières, les plus courantes sont :
Une bonne pratique consiste à utiliser un conteneur dédié, car ça offre quelques facilités
Il existe de nombreuses interfaces pour manipuler les conteneurs, mais il est préférable de commencer par utiliser les commandes car dans la plupart des cas c’est :
Ci dessous les commandes courantes, pour la liste complète : Docker CLI
Les valeurs entre <> sont à adapter (sans les chevrons)
nb : la plupart des commandes disposent d’options, vous pouvez les obtenir avec :
docker <commande> --help
docker images
docker search <terme à rechercher>
docker pull <nom de l'image>
docker rmi <nom ou ID de l'image>
docker build -t <nom de l'image> </chemin/vers/le/dockerfile/.>
docker commit <nom ou ID du conteneur> <nom de l'image>
docker ps
docker create --name <nom ou ID du conteneur> <nom de l'image>
docker run --name <nom ou ID du conteneur> <nom de l'image>
-p <port de l'hôte:port du conteneur>
-v <dossier de l'hôte:dossier dans le conteneur>
docker attach <nom ou ID du conteneur>
docker exec <nom ou ID du conteneur> <commande à exécuter>
docker inspect <nom ou ID du conteneur>
docker kill <nom ou ID du conteneur>
docker rename <nom ou ID du conteneur> <nom de l'image>
docker start <nom ou ID du conteneur>
docker stop <nom ou ID du conteneur>
docker restart <nom ou ID du conteneur>
docker top <nom ou ID du conteneur>
docker diff <nom ou ID du conteneur>
docker rm <nom ou ID du conteneur>
docker run -i -t --name mon-conteneur -d debian:latest /bin/bash
docker exec mon-conteneur ls /etc
docker attach mon-conteneur
Juste un article lié à l’actualité (Poodle &co) et sur les mesures à prendre sur nos serveurs SSL/TLS.
SHA-1 : datant de 1996, encore considéré comme fiable, cette fonction de hash, largement utilisée pour signer des certificats, et plein d’autres choses, va être dépréciée. Google et Microsoft ont en effet annoncé qu’ils allaient progressivement refuser les certificats signés avec SHA-1 dans leurs navigateurs respectifs et recommandent d’utiliser SHA256.
=>c’est une bonne nouvelle pour notre sécurité, non pas parce que SHA256 est plus fiable que SHA-1, mais parce que ça va obliger de nombreuses autorités de certifications à renouveler leurs certificats d’autorités et les administrateurs à faire de même pour leurs certificats serveurs.
Je vous laisse chercher pourquoi ce surcroit de travail devrait être une bonne chose …
Poodle : datant de 1996 lui aussi, SSLv3 vient probablement de casser sa pipe, une faille protocolaire permet de déchiffrer tout ou partie d’une connexion HTTPS. Comme la faille concerne le protocole et pas une implémentation, la correction est assez simple, il suffit de désactiver la prise en charge de SSLv3.
C’est une très bonne nouvelle, on va enfin pouvoir se débarrasser d’Internet Explorer 6 (ce dernier ne prend pas en charge le TLS).
Vivement qu’on trouve une faille dans TLS1 afin de faire sauter les versions 7 et 8, voir même 9 et 10 (puisque que TLS 1.1 et 1.2 y sont désactivés par défaut)
Google et Microsoft ont annoncé qu’ils allaient progressivement refuser les certificats signés avec SHA1 dans leurs navigateurs respectifs et recommandent d’utiliser SHA256.
Les certificats déjà publiés ne devraient pour la plupart pas être concernés, mais si vous avez un certificat à générer à partir de maintenant, il vaut mieux directement le signer en SHA256.
Vérifiez bien que votre autorité de certification a fait de même avec ses chaines de certifications!
Par défaut, OpenSSL utilise SHA-1 pour générer une demande de certificat (CSR), pour utiliser SHA256 il suffit d’ajouter default_md = sha256 dans la section appropriée du fichier de configuration ([ ca ] et/ou [ req ] selon l’usage), ou d’ajouter -sha256 dans la ligne de commande.
Pas besoin de détailler, il est temps de débrancher les ancêtres.
La suite indique comment faire pour quelques logiciels serveur de qualité :
Configuration avec une bonne compatibilité :
keepalive_timeout 70; ssl_session_cache shared:ssl_session_cache:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers 'AES256+EECDH:AES256+EDH:AES128+EECDH:DES-CBC3-SHA';
Le dernier cipher permet la compatibilité avec IE 8 sur XP, n’hésitez pas à le supprimer.
Pour plus de sécurité on peut générer une clef de session plus forte :
openssl dhparam -out dh-2048.pem 2048
On l’utilise avec la directive :
ssl_dhparam /etc/nginx/dh-2048.pem;
Si le site est uniquement en HTTPS, on peut l’indiquer aux navigateurs compatibles via l’entête HSTS , ainsi ils ne tenteront plus (pendant la durée indiquée) d’accéder à votre site en HTTP :
add_header Strict-Transport-Security "max-age=15984000";
Configuration avec une bonne compatibilité :
SSLCompression Off SSLProtocol all -SSLv2 -SSLv3 SSLHonorCipherOrder on SSLCipherSuite 'AES256+EECDH:AES256+EDH:AES128+EECDH:DES-CBC3-SHA'
Pour l’HSTS :
Header set Strict-Transport-Security "max-age=15984000"
smtpd_tls_protocols=!SSLv2,!SSLv3 smtp_tls_protocols=!SSLv2,!SSLv3
ssl_protocols = !SSLv2 !SSLv3
Forcer une vérification des disques au prochain démarrage :
touch /forcefsck