27 juin 2017

CentOS 7 : désactiver firewalld et réactiver iptables

toolsEn plus de systemd, RHEL 7 et CentOS 7 disposent d'une nouvelle interface de pare-feu : firewalld. Bien qu'il fasse plutôt bien le boulot, je me suis trouvé dans des cas où j'avais du mal à lui faire faire ce que je voulais. En fait dès l'instant où j'ai commencé à jouer avec des interfaces tun, des zones et de la retransmission de paquets, j'ai commencé à avoir des difficultés. En attendant de les résoudre, j'ai noté que je pouvais revenir au fonctionnement précédent, et piloter iptables directement.

Désactivation de firewalld

Commençons par arrêter firewalld, et s'assurer qu'il est bien coupé :

[root@test ~]# systemctl stop firewalld.service
[root@test ~]# systemctl status firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)

Jun 27 10:27:00 test.anotherhomepage.org systemd[1]: Starting firewalld - dynamic firewall daemon...
Jun 27 10:27:00 test.anotherhomepage.org systemd[1]: Started firewalld - dynamic firewall daemon.
Jun 27 10:27:25 test.anotherhomepage.org systemd[1]: Stopping firewalld - dynamic firewall daemon...
Jun 27 10:27:25 test.anotherhomepage.org systemd[1]: Stopped firewalld - dynamic firewall daemon.

Bien sûr, cela veut dire qu'à partir de maintenant, la machine n'est plus protégée par le pare-feu.

Ensuite, on désactive son démarrage automatique :

[root@test ~]# systemctl disable firewalld.service

Si vraiment on ne souhaite plus pouvoir démarrer firewalld par accident, on peut le masquer :

[root@test ~]# systemctl mask firewalld.service
Created symlink from /etc/systemd/system/firewalld.service to /dev/null.

Maintenant c'est pas tout, mais faut remettre un pare-feu.

Activation d'iptables

Pour activer iptables, c'est très simple, commençons par installer le paquet "iptables-services" :

[root@test ~]# yum -y install iptables-services
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.imt-systems.com
 * extras: mirror.netcologne.de
 * updates: mirror.ratiokontakt.de
Resolving Dependencies
--> Running transaction check
---> Package iptables-services.x86_64 0:1.4.21-17.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================================================================================================================================================================================
 Package                                                         Arch                                                 Version                                                       Repository                                          Size
=============================================================================================================================================================================================================================================
Installing:
 iptables-services                                               x86_64                                               1.4.21-17.el7                                                 base                                                50 k

Transaction Summary
=============================================================================================================================================================================================================================================
Install  1 Package

Total download size: 50 k
Installed size: 24 k
Downloading packages:
iptables-services-1.4.21-17.el7.x86_64.rpm                                                                                                                                                                            |  50 kB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : iptables-services-1.4.21-17.el7.x86_64                                                                                                                                                                                    1/1
  Verifying  : iptables-services-1.4.21-17.el7.x86_64                                                                                                                                                                                    1/1

Installed:
  iptables-services.x86_64 0:1.4.21-17.el7

Complete!

Ensuite, on l'active dans systemd :

[root@test ~]# systemctl enable iptables
Created symlink from /etc/systemd/system/basic.target.wants/iptables.service to /usr/lib/systemd/system/iptables.service.

On peut alors le lancer :

[root@test ~]# systemctl start iptables

Comme pour RHEL 6 et CentOS 6, la configuration se trouve dans le fichier /etc/sysconfig/iptables, et dispose d'un jeu de règles n'ouvrant la voie qu'au ping et à SSH. La machine est, à partir de cet instant, de nouveau protégée par un pare-feu.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : velacreations - tools.

22 mai 2017

systemd : reconfigurer une unité de service

bricolage bumperDans le billet précédent, j'ai abordé haveged et je terminais sur le fait que certains paramètres pouvaient être accessibles. Cela ne semble pas forcément évident, car si on regarde la liste des fichiers du paquet RPM, on n'y trouve aucun fichier de configuration :

$ rpm -ql haveged
 /usr/lib/systemd/system/haveged.service
 /usr/lib64/libhavege.so.1
 /usr/lib64/libhavege.so.1.1.0
 /usr/sbin/haveged
 /usr/share/doc/haveged
 /usr/share/doc/haveged/AUTHORS
 /usr/share/doc/haveged/COPYING
 /usr/share/doc/haveged/ChangeLog
 /usr/share/doc/haveged/README
 /usr/share/doc/haveged/havege_sample.c
 /usr/share/man/man8/haveged.8.gz

De plus, si on regarde le processus lancé, on remarque que certaines options sont précisées sur la ligne de commande :

$ ps auxwww | grep haveged | grep -v grep
root     22470  0.0  0.7  12132  3824 ?        Rs   May16   0:00 /usr/sbin/haveged -w 1024 -v 1 --Foreground

Allons un peu plus loin, le paquet contient un fichier "haveged.service" :

$ cat /usr/lib/systemd/system/haveged.service
[Unit]
Description=Entropy Daemon based on the HAVEGE algorithm
Documentation=man:haveged(8) http://www.issihosts.com/haveged/

[Service]
Type=simple
ExecStart=/usr/sbin/haveged -w 1024 -v 1 --Foreground
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

Il ne faut pas succomber à la tentation de modifier directement ce fichier, car une possibilité plus propre existe : la documentation officielle RHEL 7 nous apprend ainsi comment créer un fichier de configuration pour le service.

Dans ce cas précis, je souhaite augmenter la valeur de l'argument -w à 2048. Pour l'anecdote, cette option permet d'augmenter l'utilisation de haveged en définissant une taille minimale du réservoir d'entropie. Nous allons donc d'abord créer un répertoire de configuration de service systemd, puis le fichier lui-même :

# mkdir /etc/systemd/system/haveged.service.d/
# vi /etc/systemd/system/haveged.service.d/custom_args.conf

Bon, peu importe le nom du fichier tant qu'il a pour extension ".conf", mais il est malgré tout préférable de lui donner un nom explicite (en clair, faites ce que je dis, pas ce que je fais).

Nous allons dans ce fichier redéfinir la directive ExecStart, puisque c'est celle qui définit l'option à modifier. Par contre, petite subtilité, cette directive doit être vidée pour être redéfinie. Le fichier a donc cette allure :

[Service]
ExecStart=
ExecStart=/usr/sbin/haveged -w 2048 -v 1 --Foreground

Il faut maintenant recharger les unités avant de redémarrer le service haveged :

# systemctl restart haveged.service
Warning: haveged.service changed on disk. Run 'systemctl daemon-reload' to reload units.
# systemctl daemon-reload
# systemctl restart haveged.service
# ps auxwww | grep haveged | grep -v grep
root     23074  2.4  0.7  12132  3836 ?        Ss   04:02   0:00 /usr/sbin/haveged -w 2048 -v 1 --Foreground

Le démon haveged est alors lancé avec une valeur de 2048 pour l'option -w.

Dernier petit détail, SELinux. J'ai testé cette manipulation sur un système configuré en "enforcing", l'édition du fichier s'est donc faite dans le bon contexte. Au cas où certains se demandent comment sont les labels, les voici :

# ll -Z -d /etc/systemd/system/haveged.service.d
drwxr-xr-x. root root unconfined_u:object_r:systemd_unit_file_t:s0 /etc/systemd/system/haveged.service.d
# ll -Z /etc/systemd/system/haveged.service.d/custom_args.conf
-rw-r--r--. root root unconfined_u:object_r:systemd_unit_file_t:s0 /etc/systemd/system/haveged.service.d/custom_args.conf

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Katie Hargrave - bricolage bumper.

18 mai 2017

Haveged : ajouter de l'entropie à son VPS Linux

EntropyEntre deux bidouilles NetBSD, je me suis retrouvé à des bidouilles Linux. Plus particulièrement en jetant un œil à une certaine documentation utile, j'ai pu lire :

Les clés doivent être générées dans un contexte où la source d’aléa est fiable, ou à défaut dans un environnement où suffisamment d’entropie a été accumulée.

Et là, on commence à se poser des questions : qu'est-ce que l'entropie ? Pourquoi faut-il une source fiable ? Comment avoir une meilleure entropie ?

Entropie et aléa

Pour résumer, disons que l'entropie c'est la qualité de la génération de nombres aléatoires. C'est un raccourci assez grossier j'en conviens, mais cela évitera d'écrire ou de paraphraser des pavés mathématiques.

Mais alors, pourquoi générer des nombres aléatoires ? Tout simplement parce que cela fait partie de nombreuses bases d'outils cryptographiques, comme par exemple la génération de clés SSH. C'est d'ailleurs l'occasion d'aborder la question du risque qu'on prend si on ne génère pas assez d'aléa dans notre exemple : il devient possible de générer deux fois le même couple de clés SSH, et par conséquent, que quelqu'un soit en mesure de se connecter à une machine à laquelle il ne devrait pas avoir accès.

Si vous pensez que cela n'arrive jamais, il suffit de se rappeler la vulnérabilité OpenSSH Debian. En 2008, la version Debian d'OpenSSL s'est trouvée modifiée, et a eu pour conséquence un très faible nombre de possibilités pour générer des clés SSH. La preuve ? On peut trouver sur cette page l'intégralité des clés DSA (1024 et 2048 bits) et RSA (1024 à 4096 bits) possibles via cette version vulnérable. J'admets volontiers que c'est un cas extrême, mais il a le mérite d'être assez parlant.

Bref, tout ça pour dire que plus on a d'entropie, mieux c'est.

Mesurer la qualité de l'entropie

Pour mesurer la qualité de l'entropie, c'est très simple :

$ cat /proc/sys/kernel/random/entropy_avail
175

On voit que cela renvoie un nombre, qui désigne la quantité de nombres aléatoires générés. On dit que ce nombre est la taille de notre réservoir d'entropie. Et donc, plus il est grand, mieux c'est. Sauf que là, 175 sur une VM Vagrant CentOS 7, bein c'est pas glorieux.

Une autre manière de mesurer l'entropie consiste à utiliser l'outil rngtest (disponible dans le paquet rng-tools pour CentOS). Celui-ci va lancer un certain nombre de tests utilisant le standard FIPS-140.

Par exemple :

$ cat /dev/random | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 96
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=0.000; avg=0.000; max=0.000)bits/s
rngtest: FIPS tests speed: (min=0.000; avg=0.000; max=0.000)bits/s
rngtest: Program run time: 21307295 microseconds

Et là, ce n'est toujours pas glorieux, car j'ai arrêté l'exécution faute de patience.

Avant de remédier à ce problème, comparons avec une machine physique notre premier indicateur :

$ cat /proc/sys/kernel/random/entropy_avail
3217

On peut aussi constater que le problème d'entropie affecte particulièrement les machines virtuelles. Cela s'explique surtout par le fait qu'elles disposent de beaucoup moins d'éléments qu'une machine physique, et donc moins d'éléments à lire pour espérer y trouver de l'aléa.

Bon, ce n'est pas tout, mais il est temps de remédier à ce problème d'entropie sur cette VM !

Haveged : générateur d'entropie en espace utilisateur

Haveged est un logiciel qui se présente sous la forme d'un démon qui reste en espace utilisateur. Il tire son nom de l'algorithme qu'il utilise, HAVEGE (HArdware Volatile Entropy Gathering and Expansion).

Côté installation, rien de plus simple, il suffit, pour CentOS, d'avoir accès au dépôt Fedora EPEL. Une fois que c'est fait, un simple yum -y install haveged suffit à disposer du logiciel.

Comme il s'agit d'un démon, il faut le démarrer. Sous CentOS 7, cela se fait via systemd :

# systemctl start haveged.service

Et voilà ! Bon d'accord, cela fait peu. Maintenant, vérifions que notre entropie augmente :

$ cat /proc/sys/kernel/random/entropy_avail
 1779

Voilà qui est mieux. Vérifions aussi avec rngtest :

$ cat /dev/random | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.057; avg=17.351; max=25.915)Mibits/s
rngtest: FIPS tests speed: (min=44.564; avg=139.836; max=161.640)Mibits/s
rngtest: Program run time: 1237535 microseconds

Dans ce dernier cas, la récupération des informations fut quasi-instantanée ! On peu d'ailleurs noter le nombre de tests réalisés avec succès, qui correspond mieux à nos attentes.

Pour ce qui est d'activer haveged au démarrage, il ne faut pas oublier la commande systemctl qui va bien :

# systemctl enable haveged.service
 Created symlink from /etc/systemd/system/multi-user.target.wants/haveged.service to /usr/lib/systemd/system/haveged.service.

Selon les distributions, certains paramètres supplémentaires sont accessibles, mais cela fera l'objet d'un autre article ;)

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : teatimer - Entropy

14 sept. 2015

installation minimaliste de CentOS 7

Mieux vaut tard que jamais, j'ai commencé à jouer un peu avec CentOS 7 ! Bien que celle-ci regorge de fonctionnalités et de mécanismes intéressants, elle amène beaucoup de paquets logiciels. J'ai donc commencé par regarder ce que je pouvais retirer comme paquets, et à préparer une section _packages_ minimaliste, bien plus que l'image iso "minimal install" fournie par les miroirs. Cette liste de paquets retirés peut se voir complétée par une liste de paquets à installer, mais il s'agit d'un choix personnel. Qu'ai-je donc retiré ? Et bien c'est simple, comme il s'agit généralement d'une installation sur une machine physique ou virtuelle reliée en réseau filaire et disposant d'une adresse IP fixe (sauf lors de l'installation), j'ai retiré tous les firmwares possibles de matériel que je n'utilise probablement pas, comme les cartes Wifi. J'ai aussi enlevé, usage serveur oblige, des paquets liés au son (alsa). Un choix discutable, j'ai retiré man et les pages de manuel de base : je considère, en particulier si la machine est "en production", que la documentation n'a rien à faire à cet endroit. Je n'ai, par contre, rien à redire à l'installation des pages de manuel sur une machine de test. De plus, comme j'utilise le système de fichiers proposé par défaut (xfs), j'estime ne pas avoir besoin des outils pour gérer les systèmes ext2-3-4 ou btrfs.

Voici donc, la liste :

%packages --nobase
@core
-NetworkManager
-NetworkManager-team
-NetworkManager-tui
-aic94xx-firmware
-alsa-firmware
-alsa-lib
-alsa-tools-firmware
-atmel-firmware
-avahi-autoipd
-avahi-libs
-b43-openfwwf
-bfa-firmware
-biosdevname
-btrfs-progs
-dhclient
-dmidecode
-dnsmasq
-dracut-network
-e2fsprogs
-e2fsprogs-libs
-gnutls
-kexec-tools
-ipw2100-firmware
-ipw2200-firmware
-ivtv-firmware
-iwl100-firmware
-iwl1000-firmware
-iwl105-firmware
-iwl135-firmware
-iwl2000-firmware
-iwl2030-firmware
-iwl3160-firmware
-iwl3945-firmware
-iwl4965-firmware
-iwl5000-firmware
-iwl5150-firmware
-iwl6000-firmware
-iwl6000g2a-firmware
-iwl6000g2b-firmware
-iwl6050-firmware
-iwl7260-firmware
-libertas-usb8388
-man
-man-db
-mariadb-libs
-postfix
-ql2100-firmware
-ql2200-firmware
-ql23xx-firmware
-ql2400-firmware
-ql2500-firmware
-rt61pci-firmware
-rt73usb-firmware
-snappy
-teamd
-tuned
-virt-what
-wpa_supplicant
-xorg-x11-drv-ati-firmware
-zd1211-firmware

Il y a de fortes chances que pour une machine vraiment en production, j'ai besoin d'un MTA, mais à moins de prévoir une configuration dès l'installation, postfix fait aussi partie des exclus. De cette manière, non seulement le système s'installe rapidement, mais il démarre aussi rapidement ! On arrive à un total inférieur à 220 paquets. Cela peut varier pour vous en particulier si vous installez un système avec du RAID logiciel, qui nécessitera l'installation de mdadm.

Et vous, est-ce que vous retireriez d'autres paquets ?

17 déc. 2014

CentOS Dojo Paris talk

EN

Following my previous post about the CentOS Dojo in Paris last August, the recording of my talk is now online : Discovering and using etckeeper. Many thanks to InfoQ for hosting the video !

FR

Suite à mon billet précédent sur le CentOS Dojo à Paris en Août dernier, l'enregistrement de ma présentation est maintenant disponible : Discovering and using etckeeper. Merci beaucoup à InfoQ pour l'hébergement de la vidéo !

Propulsé par Dotclear