CentOS 7 et le pare-feu firewalld

Quelques notes pour pouvoir se servir de l’interface du pare-feu de la CentOS 7 (ou de la RHEL 7). Les règles ne sont pas prises en tant réel, mais lors du rechargement des règles, avec l’option --reload ou systemctl restart firewalld.service.

Pour connaître la « zone » par défaut:
firewall-cmd --get-active-zones

Pour connaître l’activation du pare-feu:
firewall-cmd --state

Pour lister les règles de la zone public
firewall-cmd --zone=public --list-all

Pour ajouter un service de manière temporaire:
firewall-cmd --zone=public --add-service=http

Pour ajouter un service de manière permanente:
firewall-cmd --permanent --zone=public --add-service=http

Pour ajouter un port de manière permanente:
firewall-cmd --permanent --zone=public --add-port=80/tcp

Pour supprimer un port de manière permantente:
firewall-cmd --permanent --zone=public --remove-port=80/tcp

Pour recharger les règles du pare-feu:
firewall-cmd --reload

OpenSSL, le libre et le proprio, pas si simple

La faille HeartBleed a beaucoup fait parler d’OpenSSL et des logiciels libres. Pour certains, et c’est ce qui a motivé ce petit article, c’est la démonstration de l’insécurité du logiciel libre. Évidemment au profit du logiciel propriétaire. La réalité est quelque peu plus complexe.

La confiance

Tout est histoire de confiance. Quelque-soit la licence du logiciel qu’on utilise, il y a une relation de confiance sur le bon fonctionnement du logiciel. C’est implicite pour la plupart des utilisateurs, mais la question mérite qu’on s’y penche un peu. Surtout quand le logiciel qu’on utilise a pour rôle de garantir la confidentialité et l’intégrité de nos échanges.

Lorsqu’on utilise un logiciel, la plupart d’entre nous suppose que le logiciel fait seulement ce qu’il est supposé faire, et qu’il le fait bien. C’est ce que j’appelle la confiance implicite de l’utilisateur. Mais si je me pose la question de savoir si j’ai raison de lui faire confiance, les choses se compliquent très vites. Comment vérifier que le logiciel fait bien les choses ? (Ou qu’il n’en fait pas plus, ce qui revient au même pour la question de la confiance ?) Comment être sûr qu’OpenSSL n’est pas infesté de bugs d’implémentation par la NSA ?

C’est là qu’on commence à parler d’audits de sécurité. C’est là qu’on entend qu’il faudrait qu’OpenSSL subisse un audit de sécurité, mais que ça coute cher, et que personne n’a envie de payer pour ça. Pour autant, si OpenSSL était soumis à un audit de sécurité, ça ne fait que déplacer la problématique de la confiance. Si j’ai peur qu’OpenSSL ne permette l’écoute par la NSA, qui me dit que la société qui effectue l’audit ne laisse pas de coté une porte ou deux, au profit de la NSA ? Finalement, faire subir un audit à OpenSSL, ne fait que déplacer la confiance dans le logiciel, vers la société mandatée pour l’audit.

Et que le logiciel soit un logiciel libre ou un logiciel propriétaire ne change rien à ce déplacement de la confiance. Au final, je n’ai d’autre choix que de faire confiance, soit à l’éditeur du logiciel, soit à la société qui me garantit que le logiciel est correctement écrit.

La différence du logiciel libre

On voit que finalement, on est obligé, logiciel libre ou propriétaire, à devoir faire confiance au logiciel, ou à la société qui effectue l’audit.

D’ailleurs, comment la faille HeartBleed a-t-elle été découverte ? Il y a deux raisons principales à ça. La première est le contexte géopolitique actuel, qui après les révélations d’Edward Snowden, met en avant l’importance de solutions de chiffrements réellement solides et efficaces. La confidentialité ne tient qu’à un fil, et les logiciels apportant cette confidentialité attirent toute l’attention.

La seconde raison, directement liée, est la découverte depuis le début de l’année, de deux failles majeures dans des logiciels (libres eux aussi) effectuant ce chiffrement SSL/TLS. Le premier par Apple, le fameux bug « goto fail », et le second, du même acabit, dans le logiciel GNUTLS. Beaucoup de monde concentre donc son attention sur ces logiciels à y rechercher des erreurs. L’étude de ces logiciels est grandement facilité par le fait que leur code source est librement disponible. Sans aller jusqu’à un audit, toute personne sachant programmer un logiciel peut y jeter un œil. Juste sur une petite partie du code, sur un mécanisme qu’il connait, par exemple, sans être un spécialiste.

Dans le cas où le logiciel ne montre pas son code source, il faut analyser le fonctionnement du logiciel dans la mémoire de l’ordinateur, ce qui est beaucoup plus complexe, et demande des compétences élevées. Un étudiant, ou un développeur n’y jettera pas un œil curieux. Et cet étudiant, ce développeur, ne mettra pas le doigt sur un bug qui lui semble évident, et qui est passé au travers des yeux des autres.

En quoi la confiance est affectée par cet accès au code ?

Tout simplement que le logiciel peut être analysé par des entités qui n’ont rien en commun, et qu’on n’est pas obligé de faire aveuglément confiance dans une société d’audits. Et que si une entreprise choisit de ne pas faire confiance, elle a la possibilité de regarder par elle même le contenu du code source. Et c’est là que tout change, on n’est pas obligé de faire confiance dans une société ou une organisation, on peut vérifier par soi-même (malheureusement, on doit quand même faire confiance au matériel, mais c’est un autre débat).

Hélas, cette force de pouvoir vérifier par soi-même le fonctionnement du logiciel a endormi beaucoup de monde. Finalement, le code est disponible, je peux le vérifier si je veux, donc ça me va, j’estime (à tord) que je peux lui faire confiance. Il doit bien y en avoir d’autres qui ont vérifié ! Et on se retrouve à avoir beaucoup de sociétés utilisant le logiciel, à se dire que les autres ont du vérifier qu’il fonctionnait bien. Pour une entreprise de e-commerce, c’est tentant d’utiliser le logiciel comme une brique indispensable et de laisser aux autres la vérification. Finalement le logiciel n’a rien couté, et on lui fait confiance aveuglément. C’est dans cette situation que se trouve OpenSSL. Peu d’entreprises qui utilisent le logiciel participent au logiciel, que ce soit par don, ou par participation au projet.

Et les licences propriétaires ?

La problématique de la confiance est beaucoup plus simple. Utiliser le logiciel propriétaire, c’est choisir de faire confiance dans son éditeur. Sans possibilité de vérification. C’est un choix qui appartient à celui qui le fait, mais qui peut être problématique dans des contextes de sécurité nationale. Utiliser un logiciel propriétaire, c’est être obligé de faire confiance. On perd la possibilité du contrôle.

De plus, c’est la disponibilité du code source des logiciels libres qui a permis de détecter, et de corriger, les problèmes rencontrés depuis le début de l’année. Les erreurs de programmation des logiciels propriétaire ne sont pas visibles en dehors de l’entreprise. Pour ces 3 bugs trouvés dans les logiciels de chiffrement libres, combien ont été oubliés dans les logiciel propriétaires ? Comment s’en assurer ?

Déploiement d’un OpenStack chez Online point par point

Les pré-requis

Un serveur, pour commencer. Ici c’est un serveur Dedibox LT2014 que j’ai choisi. On lui ajoute le support Business pour avoir un bloc d’IP RIPE /27.

IP du serveur: 1.2.3.4 (c’est fictif hein)

IP RIPE: 2.4.5.32/27 (fictif aussi)

Installation du serveur

L’installation a été faite avec une CentOS 6.4.

Partitionnement

  • / :20 Go
  • /boot : 2 Go
  • swap : 16 Go

Post-installation

L’installation de CentOS fait apparaître les biosdevname, ce qui veut dire que la première interface réseau n’est pas eth0 mais a un nom correspondant à son emplacement physique (em1 pour une carte embarquée (embedded) sur la carte mère).

Vu que j’ai em1 et pas eth0 et que ça va perturber mes scripts d’installation, on va revenir à une configuration traditionnelle, eth0 et eth1 pour les interfaces réseau.

Pour ça, on supprime le paquet biosdevname

yum remove biosdevname

ensuite on modifie la configuration des interfaces pour qu’elle reprenne les nom traditionnels. Pour ça on renomme /etc/sysconfig/network-scripts/ifcfg-em1 en /etc/sysconfig/network-scripts/ifcfg-eth0.

mv /etc/sysconfig/network-scripts/ifcfg-em1 /etc/sysconfig/network-scripts/ifcfg-eth0

On fait de même avec em2 en eth1

mv /etc/sysconfig/network-scripts/ifcfg-em2 /etc/sysconfig/network-scripts/ifcfg-eth1

on remplace em1 par eth0 dans /etc/sysconfig/network-scripts/ifcfg-eth0, et pareil pour em2 et eth1.

sed -i 's/em1/eth0/g' /etc/sysconfig/network-scripts/ifcfg-eth0
sed -i 's/em2/eth1/g' /etc/sysconfig/network-scripts/ifcfg-eth1

Je n’ai pas eu à virer les entrées dans /etc/udev/rules.d/70-persistent-net.rules car le fichier était inexistant, mais s’il existe, autant effacer son contenu.

On redémarre le serveur, et on vérifie que les interfaces réseaux sont bien eth0 et eth1 (eth1 est down par défaut).

Installation de quelques paquets utiles

Ça c’est ma préférence personnelle, mais j’aime bien avoir screen sous la main, surtout quand j’ai une connexion a un timeout.

yum install -y screen

Installation d’Openstack

Là, c’est du très classique. J’utilise la méthode décrite sur le blog et plus à jour sur http://openstack.redhat.com/.

yum install -y http://rdo.fedorapeople.org/rdo-release.rpm

puis

yum install -y openstack-packstack

Maintenant j’installe OpenStack en précisant mon bloc d’IP en tant qu’IP à utiliser pour le tenant demo. C’est cette opération que je conseille de lancer dans un screen.

packstack --allinone --provision-demo-floatrange=2.4.5.32/27

Et on va prendre le café… Il y en a pour 15-20 minutes environ.

Post-installation OpenStack

Ça serait trop facile si on s’arrêtait là…

Configuration du proxy VNC

Pour qu’on puisse accéder à la console des VMs, on doit modifier l’adresse d’écoute du proxy VNC. Pour ça, on va modifier la ligne nonvcproxy_base_url du fichier /etc/nova/nova.conf, avec l’IP de la machine.

novncproxy_base_url=http://1.2.3.4:6080/vnc_auto.html

Proxy-ARP

Ensuite on va activer le proxy ARP sur l’interface eth0 pour que la machine relaie bien les paquets du bloc d’IP sur le switch virtuel des VMs.

echo net.ipv4.conf.eth0.proxy_arp=1 >> /etc/sysctl.conf

Et ensuite ?

On n’a plus qu’à profiter de notre installation. En se connectant avec l’utilisateur demo sur l’interface web (le mot de passe est dans le fichier /root/keystonerc_demo) on peut modifier les groupes de sécurité, créer une instance, lui attribuer une IP flottante et se connecter dessus.

On doit aussi reconfigurer le stockage qui est actuellement en LVM sur un fichier de 20 Go. Mais je laisse ça pour plus tard, le plus difficile est passé.

Si on veut être un minimum sérieux, on va maintenant basculer l’interface web en SSL, je ferai peut être un article là dessus plus tard.

Installation rapide d’un OpenStack

L’existant

Pour le moment, la maquette d’OpenStack avec laquelle je m’amuse régulièrement était basée sur Ubuntu Server 12.04. J’ai dû faire quelques scripts (essentiellement bash) pour automatiser l’installation et pouvoir rapidement remettre en fonctionnement une plateforme que j’aurais pu casser.

Bien que la solution fonctionne plutôt bien, elle n’est pas vraiment adaptée à un test-run suivi d’une mise en production, et la maintenance des scripts me prend pas mal de temps. En plus, à chaque évolution d’OpenStack, je recommence tout le boulot. Intéressant, mais pas tout à fait ce que je voudrais. C’est alors que je suis tombé sur RDO de RedHat.

Comme RedHat connaît très bien OpenStack (c’est le plus gros contributeur), ils ont choisi de packager proprement la suite logicielle. Contrairement à ce qui est fait sous Ubuntu, un ensemble de scripts puppet sont là pour automatiser la configuration d’OpenStack, car c’est vraiment la partie casse-pied à réaliser, celle qui est essentiellement faite avec mes scripts shells.

On repart de zéro

Comme je n’ai rien d’important sur ma maquette OpenStack, je vais tout effacer et repartir de zéro. Donc, en point de départ:

  • Un serveur OVH (petit Q6600 avec 4Go de RAM, rien d’extraordinaire). Il est indispensable que le processeur possède les extensions de virtualisation. Les fameuse instructions VT (ou SVM sur AMD).
  • Quelques IP, je supposerai que j’ai le range 1.2.3.0/24

Réinstallation

Via l’interface OVH, je lance une réinstallation complète du serveur, sur une CentOS, 64 bits et en prenant le noyau de la distribution.

Une fois l’installation effectuée, on fait le boulot habituel, création d’un utilisateur, ajout de l’utilisateur dans les sudoers, mise à jour du serveur, et ajout de clés ssh pour s’y connecter facilement. Je ne détaillerai pas cette partie là.

Ajout du dépot RDO

On se connecte sur le serveur et on ajoute le dépôt:

sudo yum install -y http://rdo.fedorapeople.org/openstack/openstack-grizzly/rdo-release-grizzly.rpm
 Je n’ai pas testé, mais en remplaçant grizzly (la dernière version « stable » de OpenStack) par havana, on devrait accéder à la pré-release, la prochaine version encore en cours de développement.

On installe alors le paquet pour tout installer et configurer:

sudo yum install -y openstack-packstack

Il suffit alors de lancer le script de configuration

packstack --allinone --os-quantum-install=n

Ici, l’installation sera sur un seul serveur, d’où le « –allinone » et sans installer le réseau quantum. On n’a plus qu’à aller chercher un café, l’installation, après avoir demandé le mot de passe root du serveur, va tourner pendant 15 à 20 minutes. On notera que le système va également installer nagios pour superviser l’infrastructure. Les paramètres et mots de passe sont soit dans le /root/keystonerc_admin soit dans les logs de l’installation /root/packstack-answers-DATE.txt.

Bien que l’installation semble terminé, ça peut fonctionner mais notre range d’IP n’est pas configuré. Packstack configure un range en 10.quelquechose, on va devoir le supprimer pour mettre le nôtre. Pour ça, on source le fichier rc:

. /root/keystonerc_admin

on peut alors supprimer l’ancien range

nova floating-ip-bulk-delete 10.3.4.0/22

On ajoute notre range

nova floating-ip-bulk-create 1.2.3.0/24

Et on vérifie qu’il est bien présent:

nova-manage floating list

Connexion à l’interface

On n’a plus qu’à lancer un navigateur sur l’URL http://IP.DU.SERVEUR/  pour s’identifier avec l’utilisateur admin et le mot de passe de la variable OS_PASSWORD du fichier /root/keystonerc_admin

Évidemment il reste du boulot, ajouter des images, créer les utilisateurs, mais la plateforme est là et on pourra très facilement et rapidement ajouter des nœuds d’instances au besoin.

L’essentiel de la documentation est sur le site http://openstack.redhat.com/, et je n’ai rien fait d’autre que de suivre le tutoriel du site pour mettre en place ma maquette.

debconf: error: Cannot find a question for…

Ah, ça faisait longtemps que je n’étais pas tombé sur un bug Debian…

Je suis entrain de tester des scripts pour automatiser des installations. Pour que l’installation d’un paquet ne me pose pas de questions, je remplis préalablement la base debconf à l’aide d’un debconf-set-selections (dont les réponses ont été extraites à l’aide d’un debconf-get-selections | grep paquet ).

Jusqu’ici tout va bien sauf que de temps en temps, me remplissage de la base plante avec un joli

error: Cannot find a question for .....

Il s’agit bel et bien d’un bug Debian ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487300 ) ouvert depuis 2008. La solution est relativement simple, un script existe pour ça. Il « suffit » de lancer le script

/usr/share/debconf/fix_db.pl

et tout remarche comme prévu. Encore fallait-il le savoir…