Category Archives: Linux

Proxmox / OpenVZ : réseau public + privé

Logo Proxmox

Proxmox Virtual Environment est un serveur open source de virtualisation, basé sur KVM et OpenVZ.

Il permet ainsi sur un serveur (host) physique de disposer de plusieurs machines virtuelles (VM). Dans le cas d’hébergement web, on mettra par exemple 1 VM pour Apache/PHP, 1 VM pour MySQL, etC.

Si vous utilisez ce mode de fonctionnement sur internet (et non en réseau local), un inconvénient majeur est le fait de nécessiter une IP publique pour chaque VM si vous souhaitez pouvoir y accéder directement depuis l’extérieur.

C’est le cas par exemple pour un serveur dédié que vous pouvez louer chez OVH (Kimsufi inclus) ou autre : vous disposerez dans le meilleur des cas, outre l’IP du host physique, de 3 IP (failover) pour vos VM. Dépassées ces 3 VM, vous ne pourrez donc plus leur assigner d’IP publique.

La meilleure solution consiste alors à utiliser du NAT (oui, le même que sur vos routeurs à la maison) : il est possible grâce à iptables de définir des redirections de ports depuis le host physique vers des VM sans IP publique.

Configuration initiale

Il vous faut tout d’abord choisir une plage d’IP non routées sur Internet type 192.168.x.x. Partons avec 192.168.0.0/24 (soit 192.168.0.1 à 192.168.0.255).

Configurez votre VM en mode « réseau virtuel » VENET avec l’IP de votre choix définie dans la range définie précédemment, prenons 192.168.0.11.

Démarrez votre VM : vous devriez pouvoir y accéder depuis votre host (ping, connexion SSH si serveur installé).

Il vous reste deux dernières commandes à lancer pour permettre à vos VM de communiquer avec l’extérieur :

echo 1 > /proc/sys/net/ipv4/ip_forward # On autorise le host à transmettre des données extérieures aux VM internes
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o vmbr0 -j MASQUERADE # On active le NAT, en sortie via l'interface vmbr0 (à modifier si besoin)

Redirection de ports

Il vous reste à mettre en place les redirections de ports souhaitées. Par exemple, si nous souhaitons que le port 8080 de notre host redirige vers le port 80 de notre VM 192.168.0.11 :

iptables -t nat -A PREROUTING -i vmbr0 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 192.168.0.11:80

Si vous avez un serveur qui écoute sur le port 80 de votre VM, essayer maintenant d’accéder à votre host sur le port 8080.

Reverse Proxy

Malheureusement, la redirection de ports sera très vite limitante si vous souhaitez par exemple avoir plusieurs VMs hébergeant un serveur web.

Dans ce cas de figure, une solution existe : l’utilisation d’un reverse proxy (type Apache).

Son fonctionnement est simple : il est positionné en frontal HTTP et/ou HTTPS sur votre host, et redirige les requêtes vers les différentes VM (sur leurs IP locales) en fonction du nom de domaine.

Pour mettre en place un reverse proxy de ce type, rien de plus simple également ; nous allons utiliser le serveur HTTP Apache. Première étape, l’activation du mod_proxy :

sudo a2enmod proxy

Créez maintenant un fichier /etc/apache2/sites-available/monsite :

<IfModule mod_ssl.c>
 <VirtualHost *:80>
  ErrorLog /var/log/apache2/error.log
  CustomLog /var/log/apache2/access.log combined
  <Proxy https://192.168.0.11/>
   Order Deny,Allow
   Allow from all
  </Proxy>
  ServerName mon.domaine.fr
  ProxyRequests Off
  ProxyPass / https://192.168.0.11/
  ProxyPassReverse / https://192.168.0.11/
 </VirtualHost>
</IfModule>

Enregistre le fichier puis activez le site nouvellement créé et redémarrez Apache :

sudo a2ensite monsite
sudo service apache2 restart

Il ne vous reste plus qu’à tester dans votre navigateur que le domaine défini dans votre fichier de configuration Apache redirige bien vers le serveur web de votre VM.

Dovecot : régénérer des certificats SSL

Après avoir testé plusieurs outils dont Courier [Imap Server], sans jamais en être complètement satisfait, j’ai vite été conquis par Dovecot, et notamment son support des règles de filtrage Sieve.

Si vous utilisez comme moi la version disponible dans les dépôts Ubuntu/Debian, en IMAPS (IMAP over SSL, port tcp/993), le certificat auto-généré n’est valable que 365 jours, vous affichant un joli message d’erreur à la fin de sa validité.

Afin de le renouveller, voici une procédure très simple issue du « mkcert.sh » fourni dans les sources de Dovecot. Il vous suffit d’exécuter les commandes ci-après :

$ sudo service dovecot stop
$ sudo mv /etc/ssl/certs/dovecot.pem /etc/ssl/certs/dovecot.pem.bak
$ sudo mv /etc/ssl/private/dovecot.pem /etc/ssl/private/dovecot.pem.bak
$ sudo openssl req -new -x509 -nodes -out /etc/ssl/certs/dovecot.pem -keyout /etc/ssl/private/dovecot.pem -days 365
$ sudo chmod 0600 /etc/ssl/private/dovecot.pem
$ sudo openssl x509 -subject -fingerprint -noout -in /etc/ssl/certs/dovecot.pem
$ sudo service dovecot start

Si vous souhaitez que votre certificat soit valable plus d’un an, vous pouvez modifier la variable « days » dans la première commande OpenSSL.

Authentification en 2 étapes sous Linux (SSH/PAM) avec Google Authenticator

Logo Google Authenticator

Logo Google Authenticator

Depuis plusieurs mois déjà, les utilisateurs d’un compte Google ont la possibilité de mettre en place une vérification en 2 étapes lors de leur connexion (2-steps authentication), en passant par cette page, permettant ainsi d’ajouter une couche de sécurité supplémentaire à leur compte.

La méthode la plus simple afin de générer le code temporaire nécessaire à la 2ème étape d’authentification est d’utiliser l’application mobile (Android, iOS et Blackberry) open source Google Authenticator.

Google propose également un module PAM permettant de mettre en place une authentification en 2 étapes sur un poste Linux / Ubuntu.

Connectez-vous à votre poste avec le compte que vous souhaitez sécuriser et depuis une console téléchargez libpam : http://code.google.com/p/google-authenticator/downloads/list puis décompressez l’archive.

Quelques librairies sont à installer afin de permettre la compilation du module et la génération d’un QR Code :

sudo apt-get install libpam0g-dev libqrencode3
cd libpam-google-authenticator-*
make
sudo make install

Lors de l’installation, plusieurs questions vous serons posées, lisez-les avec attention afin de sélectionner l’option adaptée à votre contexte pour chacune d’entre elles.

Installez l’application mobile Google Authenticator sur votre téléphone (version Android sur Google Play, version iOS sur l’App Store) puis ajoutez votre compte en scannant le QR Code qui est apparu dans votre console (ou visible depuis le lien qui vous a été fourni) : une nouvelle ligne apparaît donc dans votre application mobile avec un nouveau code toutes les 30 secondes.

Reste maintenant à rendre obligatoire l’utilisation du module libpam-google-authenticator lors d’une connexion avec votre compte.

Le plus simple ici est d’ajouter la ligne suivante à la fin de votre fichier /etc/pam.d/common-auth (sans oublier d’en faire une copie de sauvegarde au préalable) :

auth required pam_google_authenticator.so

Si vous vous connectez à votre poste via SSH, il est également nécessaire de modifier les deux paramètres de configuration suivants dans votre /etc/ssh/sshd_config :

ChallengeResponseAuthentication yes
UsePAM yes

Redémarrez ensuite votre serveur SSH.

Par défaut, les codes générés sont basés sur l’heure, il est donc impératif que votre téléphone (sur lequel sera généré le code) et votre ordinateur soient à la bonne et même heure (synchronisation NTP). Veillez également par sécurité à noter les codes de secours forunis permettant de se connecter en cas de perte de votre mobile par exemple.

Vous pouvez désormais tester cette authentification en 2 étapes en vous connectant via une console, SSH ou Gnome (GDM) par exemple, qui vous demdanderont le code de vérification. Par défaut, il vous sera également demandé lors d’un sudo.

Deux petites remarques pour l’instant d’après mon expérience :

  • Si vous utilisez une clé SSH pour vous connecter (avec mot de passe, pas testé sans), le code de vérification ne vous sera pas demandé
  • Cette authentification en 2 étapes peut ne pas être supportée par certains clients ou avoir des comportement hasardeux, comme avec Proftpd par exemple qui se contente du seul mot de passe

Attention, en cas de mauvaise manipulation, votre accès pourrait être bloqué. Je ne pourrai en aucun cas en être tenu pour responsable.

Colorez votre shell prompt Ubuntu

Par défaut, le shell prompt sous Ubuntu est extrêmement (trop) sobre.

Pourtant, il est très simple d’avoir un prompt coloré comme c’est le cas par défaut sous Gentoo : il suffit d’éditer votre fichier .bashrc :

$ nano ~/.bashrc

Autour de la ligne 39, vous devriez avoir :

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
force_color_prompt=yes

Il vous suffit de décommenter la ligne 39 et d’enregistrer votre fichier.

Rechargez votre terminal, et miracle, votre prompt est désormais coloré :

Shell prompt coloré sous Ubuntu

Si vous souhaitez aller plus loin dans la personnalisation du prompt, vous pouvez modifier la valeur de PS1 dans le même fichier .bashrc, normalement ligne 53, à l’aide de cet article : http://www.gentoo.org/doc/en/articles/prompt-magic.xml.