Toujours à mon habitude, j’essaye d’utiliser ce qu’a fait Debian pour moi. Point de compilation, de création de machin-bidule à la main lorsque ce n’est pas une absolue nécessité.

Pour le contexte, on va dire que le VPN va être installé sur une machine de type passerelle Internet-LAN. Pourquoi pas une Debian avec shorewall et 2 pattes : loc, net (et $FW of course). Je parlerai rapidement des modifications de firewall à la fin. Vous pouvez trouver une introduction à shorewall sur ma doc d’initiation à Debian.

Je vais développer en 3 parties : thèse, anti-thèse, foutaises, comme disait mon prof de philo au siècle dernier installation, paramétrage du serveur, paramétrage du client, firewalling. Ca fait 4 ? bien, au moins y’en a qui suivent.

Let’s go.

Installation de l’outil

Ca devient presque rasoir, on commence direct dans le feu de l’action :

aptitude install openvpn

Tout descend par dépendances, comme d’habitude.
Je n’ai pas pris de notes, mais je pense qu’à ce niveau là déjà, une interface réseau « tun0″ est créée. Le futur sous-réseau du VPN est 10.0.8.x. Le serveur n’est pas lancé car il n’a aucune conf. Ca veut dire /etc/openvpn/ vide ou pas loin. Et c’est tant mieux.

Paramétrage serveur

Rappel : permissions

On va jouer avec les clefs cryptées et les clefs publiques d’un outil donnant accès à l’intérieur de votre réseau. Faites un peu attention aux permissions des fichiers.

Clef privée = permission limitée au niveau de l’OS, root:root + chmod 600
Clef publique = root:root + chmod 644
Ce qui ne concerne que le service et son lancement = root:root + chmod 640

Notez que le service openvpn sera lancé par root même s’il tournera au nom d’un utilisateur « openvpn ».

Traditionnellement, les clefs privées ont un nom en .key, les certificats publics en .crt.
Notez bien les permissions de votre conf OpenVPN lorsqu’on l’aura monté et gardez ça à l’esprit tout le long :

serveur:/etc/openvpn# ls -l
total 40
-rw-r--r-- 1 root root  1176 2009-09-14 14:46 ca.crt
-rw------- 1 root root   245 2009-09-14 14:47 dh1024.pem
-rw------- 1 root root    16 2009-09-23 08:23 ipp.txt
-rw------- 1 root root   232 2009-09-23 08:32 openvpn-status.log
-rw-r----- 1 root root 10560 2009-09-22 17:02 server.conf
-rwxr-xr-x 1 root root  1352 2008-09-18 00:33 update-resolv-conf
-rw-r--r-- 1 root root  3813 2009-09-14 14:46 vpnserveur.crt
-rw------- 1 root root   887 2009-09-14 14:46 vpnserveur.key

En résumé, seules la clef publique de l’autorité de certification et la clef publique du serveur doivent être publiques.

Présentation rapide de easy-rsa

« easy-rsa » est un ensemble de scripts simplifiant votre vie pour gérer les certificats. Que ce soient ceux du serveur pour créer sa configuration ou ceux de vos postes clients.
Vous savez aussi sans doute qu’il vous faudra gérer votre base de certificats autorisés (et surtout révoqués). Lorsque le portable de votre collègue est oublié dans le train, il est intéressant d’être mis au courant dans la seconde pour révoquer le certificat en question. Sinon c’est la porte d’entrée dans l’entreprise, suivant le profil du voleur type qui a trouvé le portable.
Cet outil descend avec OpenVPN et l’ensemble des scripts se situe dans /usr/share/doc/openvpn/examples/easy-rsa/2.0/. Il y a une version 1.0. J’ai opté pour la 2.0. Je ne me suis pas trop documenté sur le sujet.

Il y a un tout petit peu de paramétrage à faire sur easy-rsa.
Je recommande de dupliquer le fichier /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars en /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars.maconf et de travailler dedans.
Je vous montre un « diff » entre le fichier d’origine et le mien. C’est le minimum syndical à renseigner :

serveur:/usr/share/doc/openvpn/examples/easy-rsa/2.0# diff -h vars vars.maconf
64,68c64,68
< export KEY_COUNTRY="US"
< export KEY_PROVINCE="CA"
< export KEY_CITY="SanFrancisco"
< export KEY_ORG="Fort-Funston"
< export KEY_EMAIL="me@myhost.mydomain"
---
> export KEY_COUNTRY="FR"
> export KEY_PROVINCE="France"
> export KEY_CITY="Petaouana"
> export KEY_ORG="MaBoite"
> export KEY_EMAIL="adminvpn@maboite.fr"

Notez : pour utiliser les scripts Easy-RSA, il faut à chaque fois positionner les variables d’environnement du fichier vars.maconf. Donc, à chaque nouvelle session dans laquelle vous jouez avec les scripts easy-rsa, il faudra commencer par la commande suivante :

. /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars.maconf #sans oublier le point au début !!!

.

Le répertoire où sont stockées les clefs générées (et d’autres choses, liste de certificats, certificats révoqués etc) est le sous-répertoire keys/. Inutile de préciser (?) que ce répertoire doit être archi-protégé :

serveur:/usr/share/doc/openvpn/examples/easy-rsa/2.0# ls -ld keys
drwx------ 2 root root 4096 2009-09-14 18:22 keys

Enfin, la première fois uniquement (ou tant que vous testez), vous pouvez nettoyer ce répertoire via la commande ./clean-all.

Création de l’autorité de certification

Maintenant que vos « variables » sont prêtes et chargées dans votre session, on attaque.
Bien évidemment, cette manip n’est à faire qu’une fois. Seule la manip de création de certificats pour vos clients (postes clients) sont à faire X fois.
L’autorité de certification est « un nom et des clefs » signant vos certificats. Un exemple connu est Verisign. Ici, on va signer nous-même. Sur un serveur web, ça ferait des warnings de certificats bidouilleux, ici on s’en fout.

./build-ca

Vous obtenez le baratin standard de génération de clefs, lisez ce qui y est dit et renseignez le « Common Name ». Le reste doit descendre du fait du fichier « vars » chargé au préalable. Pour « Common Name », mettez le nom de votre serveur.

Création de la clef Diffie-Hellman

La clef Diffie-Hellman est une clef permettant au client et au serveur de s’entendre sur une clef secrète pour crypter la conversation.
Si je me souviens bien, les clefs publiques/privées servent à l’initialisation de la communication, mais, étant lourdes en calculs, on opte pour un cryptage plus simple pour le reste de la communication. C’est la clef DH. En gros hein. Et pardon aux puristes. Ou dites moi si je me trompe complètement.

On la génère comme suit, grâce aux script Easy-RSA :

./build-dh

Rien à saisir, ça prend juste un peu de temps.

Génération du certificat serveur

On continue, pour le dernier élément du serveur : sa propre clef.

./build-key-server

(trop cool les scripts Easy-RSA non ?)
Ca sort aussi le baratin standard de génération de clefs. Vous devrez préciser le « Common Name », éventuellement un mot de passe (je ne l’ai pas fait, je suppose qu’il demanderait du coup un mot de passe au lancement du service openvpn ; ça peut être contraignant lors de reboot).
Par défaut, votre certificat sera valable 10 ans.
Ca termine par l’inscription du certificat dans la « base » :

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Création des certificats d’un client

Rappel : lorsque plus tard, vous créerez un autre certificat pour un autre PC, pensez à « sourcer » le fichier vars.maconf.
Le script de génération se lance comme suit :

./build-key pc123

Je suggère un nom éloquent rappelant ou bien le PC, ou bien la personne.
Là non plus, rien de sorcier : le « Common Name » sera le nom du PC et vous « committez » le certificat.

Création des certificats d’un client avec mot de passe

Tout pareil que le paragraphe du dessus, mais le script est ./build-key-pass pc123
Il faudra alors renseigner le mot de passe là :

Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

Rien à voir avec le « Challenge password » demandé plus tard.

La révocation de certificats

Si à ce niveau là de la configuration on n’a pas besoin de révoquer des certificats, ça deviendra obligatoire à mesure que les utilisateurs arriveront, partiront et perdront leur PC portables. Evidemment que c’est du vécu
La commande Easy-RSA est :

./revoke-full pc123

Il faut copier le fichier résultant, après chaque révocation :

cp keys/crl.pem /etc/openvpn/

Ce fichier est lu dès l’instant que vous avez mis en place l’option « crl-verify » dans votre fichier de conf serveur (voir plus haut).
Notez aussi qu’il est relu à chaque tentative de connexion. Pas besoin de recharger OpenVPN après une révocation. Juste de recopier le fichier à jour. Si vous pensez faire un lien symbolique, attention aux permissions (c’est l’utilisateur openvpn qui fait tourner openvpn). Je n’ai pas testé la solution par lien symbolique.

Vous pourrez consulter la liste des certificats révoqués grâce à la commande :

openssl crl -in /chemin/vers/keys/crl.pem -text

CRL = Certificate Revocation List

Lancement du service

A ce niveau là, on a généré tout ce qu’il faut, mais le service ne tourne pas.
Le contenu de votre sous-répertoire keys ressemble à ça :

serveur:/usr/share/doc/openvpn/examples/easy-rsa/2.0# ls -l keys/
total 80
-rw-r--r-- 1 root root  3813 2009-09-14 14:06 01.pem
-rw-r--r-- 1 root root  3698 2009-09-14 14:29 02.pem
-rw-r--r-- 1 root root  1176 2009-09-14 14:03 ca.crt
-rw------- 1 root root   887 2009-09-14 14:03 ca.key
-rw-r--r-- 1 root root  3698 2009-09-14 14:29 client_test.crt
-rw-r--r-- 1 root root   668 2009-09-14 14:29 client_test.csr
-rw------- 1 root root   887 2009-09-14 14:29 client_test.key
-rw-r--r-- 1 root root   245 2009-09-14 14:32 dh1024.pem
-rw-r--r-- 1 root root   205 2009-09-14 14:29 index.txt
-rw-r--r-- 1 root root    20 2009-09-14 14:29 index.txt.attr
-rw-r--r-- 1 root root    21 2009-09-14 14:06 index.txt.attr.old
-rw-r--r-- 1 root root   101 2009-09-14 14:06 index.txt.old
-rw-r--r-- 1 root root     3 2009-09-14 14:29 serial
-rw-r--r-- 1 root root     3 2009-09-14 14:06 serial.old
-rw-r--r-- 1 root root  3813 2009-09-14 14:06 vpnserveur.crt
-rw-r--r-- 1 root root   664 2009-09-14 14:05 vpnserveur.csr
-rw------- 1 root root   887 2009-09-14 14:05 vpnserveur.key

On y retrouve les clefs de l’autorité de certification (ca*), le certificat serveur (vpnserveur.crt et vpnserveur.key) et un futur poste client (client*.[crt|key]). Les fichiers .csr sont les demandes de signatures, étape intermédiaire de la création des certificats, masquée par l’enrobage de commandes d’Easy-RSA. Inutile par la suite
Il faut recopier (avec les bonnes permissions !!!) les fichiers suivants :

cp -p dh1024.pem vpnser*crt vpnser*key ca* /etc/openvpn

Ensuite, on va faire tourner le service sous un utilisateur/groupe sans droit, c’est mieux côté sécurité.

groupadd openvpn
useradd -d /dev/null -g openvpn -s /bin/false openvpn

Enfin, il faut créer le fichier de conf du serveur. Un exemple est donné dans le fichier /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz. Une fois dézippé et mis dans /etc/openvpn, on l’adapte.
Voici son contenu, sans les commentaires :

serveur:/etc/openvpn# egrep -v "^$|^#|^;" server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert vpnserveur.crt
key vpnserveur.key  # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.X.0 255.255.255.0"
push "dhcp-option DNS 192.168.X.Y"
push "dhcp-option DOMAIN maboite.net"
push "dhcp-option WINS 192.168.X.Y"
keepalive 10 120
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status openvpn-status.log
verb 3
;crl-verify crl.pem # j'ai triché, j'ai ajouté le ";" il n'aurait pas dû sortir vu la commande egrep passée. Voir ci-dessous.

Les 4 paramètres push route et push dhcp-option sont à adapter. Ce sont eux qui feront ajouter à votre PC client les règles de routages et DNS, domaine (et optionnellement WINS) à utiliser. Sinon, point de résolution de nom, point de routage depuis votre PC, tantôt vers sa connexion web, tantôt vers le VPN.
Suivant la configuration de votre passerelle, le simple ajout de ces push ne sera pas suffisant pour permettre à vos postes client VPN de rebondir de votre passerelle vers le LAN. Voir plus bas le chapitre dédié.
Enfin, le paramètre « crl-verify » prendra son importance avec les révocations de certificats (voir plus bas).Pour l’instant, il est en commentaire car j’ai noté que OpenVPN plantait (volontairement ?) lorsqu’on lui dit de tenir compte d’une liste de révocation et que cette liste n’existe pas, ou est un fichier vide. Ce sera donc à activer plus tard, après votre première révocation.

Ah, j’oubliais :

/etc/init.d/openvpn start

Vérifiez dans les logs que tout va bien. Et ifconfig qui doit avoir affecté une IP à tun0, probablement 10.8.0.1.

Paramétrage client (poste Windows dans mon cas)

On a généré un premier ensembles de clefs d’un poste client.
Dans le cas d’un PC sous Windows (cas à mon avis le plus courant lorsqu’il s’agit de fourni des portables d’appoint à des utilisateurs distants), installez OpenVPN avec le GUI.
Injectez (par un moyen sûr, éviter d’envoyer la clef cryptée par mail à votre destinataire) les fichiers suivants dans le répertoire C:\Program Files\OpenVPN\config :

ca.crt # et pas le .key !!!
client_test.key
client_test.crt

Puis créez un fichier de configuration client nommé nimportequoi.ovpn dans le même sous-répertoire config. Il contiendra la conf suivante, si on oublie les commentaires :

client
dev tun
proto udp
remote votre.serveur.vpn.votresociete.fr 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client_test.crt
key client_test.key
comp-lzo
verb 3

Enfin, lancez le GUI d’OpenVPN situé dans le sous-répertoire bin/ d’OpenVPN, bouton droit dans le « system tray » sur l’icône qui vient d’apparaitre, menu « Connect » et lisez ce qui passe pour commencer à débugger s’il y a un hic niveau réseau entre le PC portable et le serveur VPN. Attention à vos règles de firewalling en vigueur, que vous testiez de l’extérieur ou de l’intérieur (ce qui semble un peu stupide), vous pourriez ne pas être en mesure d’atteindre le service, d’où le chapitre ci-dessous.

Considérations de firewalling

Bon là, c’est bien beau, vous atteignez votre serveur VPN depuis l’extérieur, et encore, si vous avez bien ouvert la porte d’entrée vers le port UDP 1194 de votre serveur.
Mais pour l’instant, point de rebond vers le LAN. Et heureusement que ça ne marche pas par défaut.

Méthode gore pour tester vite fait

En activant l’IP Forwarding à la main et en définissant quelques routes entre votre réseau VPN et votre LAN, vous obtiendrez vite fait un résultat. Mais c’est pas terrible je trouve.
Activation de l’IP Forwarding comme un cochon :

echo 1 > /proc/sys/net/ipv4/ip_forward

Puis définition de routes. Plutôt que de donner un exemple qui ne sera pas le votre, tâchez plutôt de raisonner sur la liste des routes que vous avez et ajoutez celles qu’il faut, avec les commandes route, route add et route delete.

Méthode réfléchie pour shorewall

Si vous utilisez iptables, je ne peux rien pour vous. Enfin si, un conseil : songez à utiliser shorewall.
Si vous ne connaissez rien à shorewall, c’est le moment de vous y mettre. Mais dans ce cas, faites vous la main *avant* d’installer le VPN, quand même. Voyez ma doc Debian au besoin, il y a un chapitre consacré à shorewall.
Sinon, dans une conf shorewall à 2 pattes (net, loc), on la modifie pour qu’elle passe à 3 pattes. Dans un cas idéal (mais néanmoins courant), ça se passera comme ça :

• Ajout de la ligne vpn ipv4 dans /etc/shorewall/zones.
• Ajout de la ligne vpn tun0 detect dans /etc/shorewall/interfaces
• Ajout de la ligne eth0 tun0 dans /etc/shorewall/masq pour activer le Masquerading entre votre VPN et votre LAN, ici situé sur l’interface eth0
• Ajout de toutes les règles par défaut dans /etc/shorewall/policy, concernant la probable interdiction par défaut d’aller de n’importe quelle zone vers le VPN et réciproquement. Le VPN doit en effet, à mon avis, être un moyen de secours pour donner accès à quelques services internes, pas à tout le LAN. A base de vpn loc REJECT info + réciproque.
• Enfin, le vrai travail, l’ouverture du minimum d’autorisation entre toutes vos zones et le VPN. J’y consacre le paragraphe suivant.

Ouvertures minimum sur le firewall

En considérant net=eth1 ; loc=eth0 et vpn=tun0, voici ce qu’il faudra ajouter au minimum, à mon avis :
Déjà l’accessibilité du service VPN depuis le NET :

ACCEPT          net     $FW         udp     openvpn

Ensuite des règles du VPN vers le LAN :

ACCEPT          vpn     loc:$dns1      tcp     domain # sinon on ne touche pas le serveur DNS => pas de résol de nom => problème...
ACCEPT          vpn     loc:$dns1      udp     domain # je ne sais pas s'il faut le TCP ou l'UDP. Oops.
Ping/ACCEPT     vpn     loc # pratique pour du dépannage
ACCEPT          vpn     loc:$leserveurapplicatif1 # c'est un exemple
ACCEPT          vpn     loc:$leserveurapplicatif2 tcp 80 # un exemple plus restreint, limité au port http

Les variables « $dns1″ (par exemple), sont à définir dans /etc/shorewall/params, ou alors vous tapez l’IP en dur.

Et enfin quelques accès minimums vers la passerelle elle-même :

Ping/ACCEPT     $FW     vpn # pratique pour les tests
SSH/ACCEPT      vpn     $FW # pour les admins tout au moins ?
ACCEPT          vpn     $FW     tcp     80 # s'il y a des intranets à consulter (outil de supervision, par exemple)

A noter aussi, pour le Masquerading, de forcer l’activer (valeur « On ») ou de laisser tel quel (valeur « Keep ») l’IP forwarding. Ca se passe dans /etc/shorewall/shorewall.conf, paramètre IP_FORWARDING.
Il me semble que c’est ce paramètre qui force ou pas la modification du paramètre noyau /proc/sys/net/ipv4/ip_forward. Il me semble.

Voilà. Ca devrait marcher.
Evidemment, comme c’est fortement lié à toute votre infrastructure réseau, tout ce qui précède est plutôt un guide des trucs-à-pas-oublier-pour-que-ça-marche.

Divers

Ce que je n’ai pas abordé

• Testez avant de déployez !!!! notamment les certificats révoqués, et avec eux la CRL et l’option crl-verify.
• Il y a une notion de règles de routages paramétrables par certificat client. Ca peut être utile.
• Vous utilisez Orange Business Everywhere pour votre clef 3G ? attention, ça semble intercaler un proxy sur votre Internet Explorer. Résultat, l’accès à des Intranets via le VPN ne marchait pas. Firefox passait bien. Je n’ai pas creusé plus pour l’instant.

Comportement lors d’une connexion avec un certificat révoqué

Côté serveur, on voit cette discrète ligne dans /var/log/syslog :

Sep 23 11:57:49 gw ovpn-server[24224]: 192.X.Y.Z:1120 CRL CHECK FAILED: /C=FR/ST=France/L=Petaouana/O=SOCIETE/CN=pctest/emailAddress=adminvpn@chezmoi.fr is REVOKED

Côté client, c’est moins flagrant, on tourne en rond et tente de se reconnecter.
Peut-être qu’en montant le niveau de verbosité (paramètre verb), on en saurait plus. Mais à la limite, ça intéresse qui ? (à part l’utilisateur qui s’est fait révoquer son certificat par erreur).

Partitionnement par défaut

Le serveur arrive avec en gros un swap et une partition « / » de quasimment 1 To (la capacité de mon disque) et un /var (dans mes souvenirs) de quelques dizaines de Mo. C’est assez cool pour héberger une base de données, genre des gros fichiers dans /var/lib/mysql…
Aucune restriction type nosuid, noexec, nodev.
Donc je suggère d’abord une réinstallation en mode « je personnalise mes partitions ». L’interface web est curieuse, il faut d’abord affecter un peu de place à /boot, puis de la place (mais pas tout) à /. (pas slashdot, c’est un point pour finir ma phrase )
A ce moment là, l’interface vous permet de nommer et modifier n’importe que point de montage: /home, /var, /tmp, le swap. A votre convenance.
Pour ce qui est des options noexec, nodev, nosuid, que vous voulez peut-être positionner, il faudra modifier /etc/fstab à la main et rebooter ou faire des mount -o remount qui vont bien.

A la fin j’ai ça, dans le cas d’un serveur en RAID 1 logiciel (celui à 69 €, l’autre est en RAID 1 hard, je préfère). Remplacez mentalement /dev/md par /dev/sda si ça vous pose un problème existentiel.

/dev/md2        /       ext3    errors=remount-ro       0       1
/dev/md1        /boot   ext3    errors=remount-ro,nodev,nosuid,noexec   0       1
/dev/md3        /home   ext3    nodev,nosuid    1       2
/dev/md6        /tmp    ext3    nodev,nosuid    1       2
/dev/md7        /var    ext3    nodev   1       2
/dev/sda5       swap    swap    defaults        0       0
/dev/sdb5       swap    swap    defaults        0       0
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0

Sources logicielles (apt)

Il y a un miroir OVH. Je n’aime jamais trop ce concept, ne sachant pas si c’est à jour ou pas.
De toute manière, il manque le repository « volatile ». Quitte à l’ajouter, je suis revenu aux standards Debian, voici mon /etc/apt/sources.list :

deb ftp://ftp2.fr.debian.org/debian/ lenny main contrib non-free
deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free

Un petit aptitude update et aptitude safe-upgrade plus tard, vous voilà à jour.

Kernel

Le kernel par défaut est le 2.6.27.10-grsec-xxxx-grs-ipv4-32 pour un serveur 32 bits. Le patch grsec apporte des modifications de sécurité (mouais) au kernel standard.
Le truc louche est que je ne vois aucun linux-image installé via dpkg -l. J’ai tenté l’installation du dernier 2.6 packagé par Debian (le 2.6.26, via le paquet linux-image-2.6-686), ça a un peu foiré, j’ai lâché l’affaire.
J’ai un peu peur de l’upgrade de sécurité du kernel, qui viendra bien un jour ou l’autre. Pas de paquet qui a amené le noyau (!) et je suis sur les repos autres que les miroirs OVH. Bref à mon avis, le kernel est figé pour longtemps. EDIT: A priori, vu des commentaires, c’est comme chez dedibox : un serveur FTP mettant à jour les noyaux. Supeeeer. Il doit y avoir une mailing-list ou un newsgroup pour suivre les upgrades recommandés, j’espère. C’est le cas chez dedibox.

LILO vs. GRUB

Ils ont choisi LILO. Soit. Je n’ai pas osé mettre GRUB, de peur de foutre la zone avec le reboot en mode rescue. ou de faire sauter (peut-être) le KVM sur IP (ça m’étonnerait quand même). ‘Pas eu envie de tester.
Inconvénient de LILO : penser à taper lilo après un upgrade de noyau. Mais bon, vu la situation décrite ci-dessus…

Accès SSH

Evidemment, accès root autorisé, de toutes les IP.
J’ai changé tout ça : PermitRootLogin no et AllowUsers après avoir créé des utilisateurs locaux. Pour ce qui du classique changement de port, j’ai plutôt opté pour du bridage par IP source sur ce port. Faites comme vous voulez.
OVH peut se connecter en root via clef publique autorisée (installée avec la machine). Si le concept vous plait (et que vous ne virez pas la clef de authorized_keys), il serait judicieux de laisser passer le SSH pour l’IP source qu’ils utilisent (décrite dans le chapitre du firewall ci-après).
Le PermitRootLogin doit être largement incompatible avec ce principe, au passage. Mais bon, on le sait, le RootLogin, c’est mal.

Shorewall (ou iptables)

Là, c’est l’épisode « La mise en place du firewall ou si tu bloques le ping, j’te reboote ». Arg. La cocasse anecdote. Je vous raconte ça comme je l’ai vécu. Les conclusions pour éviter une galère potentielle seront donc à la fin. C’est plus marrant comme ça.
Donc, voici le truc.

(vous pouvez lire mon guide complet sur debian, notamment shorewall, à cette adresse : http://michauko.org/docs/debian_testing/

Après un aptitude install shorewall, il faut configurer Shorewall, avec le postulat de base « je bloque tout sauf ce qui m’intéresse ». Normal. J’ouvrirai le reste à mesure que j’installerai les services (MySQL, apache, mail…)

Les « templates » shorewall pour un serveur à une interface (c’est notre cas) sont amenés par le paquet shorewall-common, dans /usr/share/doc/shorewall-common/examples/one-interface/
Copiez donc tout le contenu dans /etc/shorewall/ et passez en revue tous les fichiers pour que ça corresponde à vos besoins : bridage du SSH sur quelques IP par exemple.
Attention à cette règle (policy) :

$FW             net             ACCEPT

Elle rend possible l’attaque réseau depuis votre machine si elle est compromise. Détailler chaque flux sortant peut permettre d’éviter ça, si votre machine a été compromise juste assez pour faire chier, mais pas assez pour être root, auquel cas l’intervenant fera mumuse avec votre shorewall de toute manière.
Si vous avez besoin d’un fichier « params » vide, il est donné là : /usr/share/doc/shorewall-common/default-config/params.
Une fois votre conf adaptée, modifiez /etc/default/shorewall => startup=1 et relancez shorewall. Testez votre connexion SSH sans perdre l’ancienne session, au cas où la conf n’accepte plus rien, suite à fausse manip…

Cocasse anecdote : une sonde de leur côté (OVH) a immédiatement détecté que mon serveur ne répondait plus au ping=> REBOOT quasi-instantané pour cause de défaillance. O_o woooow. Que ça détecte une « panne », admettons, que ça force un reboot, PUTAIN NON !!!!!
J’ai eu un ticket quelques instants après m’indiquant qu’il y avait un kernel panic et qu’ils l’avaient donc passé en mode rescue. Moi je veux bien, mais sur la console, y’avait bien écrit « reboot », et pas le bon gros figeage d’un « kernel panic ». Le type au téléphone m’avait confirmé quelques minutes avant qu’ils avaient forcé le reboot. Bref passons. Ca commence bien la relation client…
Je pense surtout que quelqu’un a eu un excès de zèle et sous couvert d’un ping qui ne répondait pas, m’a rebooté comme un porc la machine, « pour m’aider », en me la mettant en mode rescue. Ah ouais, super, ça m’aide à mort…
Quelques cris plus tard, un type du service des serveurs dédiés m’indique le « Guide OVH pour le firewall » (http://guides.ovh.net/fireWall). A priori, il me confirme que les machines de monitoring évoquées dans ce guide ne changent pas et qu’il n’y en a pas d’autres en terme de monitoring qui feraient que ma machine serait vu comme défaillante et qui ferait que le mec qui s’emmerde au mois de juillet dans la salle serveur prendrait un coup de chaud et me rebooterait le serveur. Pour m’aider.

Bref, il faut laisser passer le ping pour les machines suivantes : proxy.ovh.net, proxy.p19.ovh.net, proxy.rbx.ovh.net, ping.ovh.net et les 3 premiers octets de votre IP+250/251/249 (3 machines en plus donc).
Plus une machine pour le SSH si vous pouvez avoir besoin d’eux un jour.

Changez enfin les permissions 755 à 750 sur /etc/shorewall

Question : le « PermitRootLogin no » => peut-on quand même passer en mode rescue ? Je le pense, mais bon… car le pass du root est différent. C’est un autre OS qui boote, véritablement, avec uniquement un compte root. Si quelqu’un peut me confirmer ça en commentaire, merci.

Le guide OVH donne la syntaxe iptables pour tolérer le ping de tout ça. Si vous adorez ces longues lignes iptables inbuvables, c’est pour vous. Pour le reste, il y a mast shorewall.
Côté shorewall, avec les fichiers par défaut, il faut comprendre que tout traffic net -> $FW est bloqué par défaut, en « DROP info », sauf une règle spéciale pour le ping en « DROP simple » – pour éviter de pourrir les logs. J’ai donc ajouté avant cette règle l’autorisation pour les machines de supervision OVH. Ca donne donc :

/etc/shorewall/policy

Inchangé dans cet exemple :

#SOURCE         DEST            POLICY          LOG LEVEL       LIMIT:BURST
$FW             net             ACCEPT
net             $FW             DROP            info
net             all             DROP            info
# The FOLLOWING POLICY MUST BE LAST
all             all             REJECT          info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

/etc/shorewall/rules

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE         ORIGINAL RATE            USER/   MARK
#                                                       PORT    PORT(S)        DEST             LIMIT           GROUP

### PING
# ouverture pour monitoring OVH
ACCEPT          net:213.186.50.98       $FW     icmp    # proxy.ovh.net
ACCEPT          net:213.186.45.4        $FW     icmp    # proxy.p19.ovh.net
ACCEPT          net:213.251.184.9       $FW     icmp    # proxy.rbx.ovh.net
ACCEPT          net:213.186.33.13       $FW     icmp    # ping.ovh.net
ACCEPT          net:x.y.z.250       $FW     icmp    # specifique à mon IP : x.y.z.53
ACCEPT          net:x.y.z.249       $FW     icmp    # specifique à mon IP : x.y.z.53
ACCEPT          net:x.y.z.251       $FW     icmp    # specifique à mon IP : x.y.z.53
# des machines à moi :
ACCEPT          net:$une_machine     $FW     icmp
ACCEPT          net:$une_autre            $FW     icmp
#défaut :
Ping/DROP       net             $FW # le reste est en "DROP info". Là on va éviter des logs inutiles

### SSH
# moi, moi et moi :
ACCEPT          net:$une_machine     $FW     tcp     22
ACCEPT          net:$une_autre            $FW     tcp     22
# à la limite, eux :
ACCEPT          net:213.186.50.100      $FW     tcp 22  # cache.ovh.net, probablement inutile, pas de compte dans mon cas

### WEB, utiliser AllowWeb serait plus dans le coup non ?
ACCEPT          net                     $FW     tcp     80,443

### MAIL si besoin
ACCEPT          net                     $FW     tcp     25

#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

/etc/shorewall/params : exemple

# blabla...
#               net     eth0            130.252.100.255 routefilter,norfc1918
#
###############################################################################
une_machine=a.b.c.d
une_autre=e.f.g.h
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE

autres

Dans cet exemple, les fichiers « interfaces », « zones » etc sont bien tels quels.
Pensez au restart de shorewall et au test afin d’être sûr de toujours pouvoir venir en SSH sur votre serveur.

Autres trucs à faire avant d’aller plus loin

Je passe sur les softs que vous utiliserez ou non : postfix ou exim, snort, rkhunter…
Pensez à cron-apt, apt-listbugs, ntp…

Autre spécificité OVH

Le script /usr/local/rtm/bin/rtm qu’on trouve dans /etc/crontab. Un outil maison de monitoring. Admettons. C’est expliqué là : http://guides.ovh.net/RealTimeMonitoring

A plus tard pour compléter ce retour d’expérience. En bien je l’espère

(pas la peine de faire des commentaires de troll, je ne validerai pas)

J’ai mis à jour ma doc d’installation + kit de survie + gros sujets « serveur » à l’instant.
Elle est disponible au format Word (oui oui, je sais) et au format PDF (mais certains liens HTML dedans ne marchent pas, si quelqu’un sait pourquoi… généré avec PDFCreator depuis Word 2007)
Elle est destinée à des personnes connaissant un peu Linux et voulant installer un Linux qui a fait ses preuves, plutôt pour un usage serveur.

Le concept de cette n-ième mouture est le suivant :

• J’abandonne la partie graphique/bureautique => utilisez Ubuntu
• Premiers chapitres sur les quelques trucs à savoir sur Debian (différentes versions etc)
• Gros chapitre comparant, écran par écran, l’installation de « Etch mode expert », « Lenny mode expert » et « Etch mode normal ». Afin de montrer les différences avec la prochaine release d’une part, et la comparaison normal/expert d’autre part – pour ceux à qui cela ferait peur.
• Kit de survie : comment gérer les paquets, gérer son système – quelques spécificités Debian
• Firewall « shorewall » : tout pour faire rapidement une conf propre
• Serveur de mail : un exemple bien complet pour monter un serveur, de postfix à spamassassin, rulesemporium, tout ça
• Un exemple d’installation d’application LAMP classique : gallery2

Voilà. Vous pouvez me faire vos retours, vos impressions, tout ça.

=> Aujourd’hui, j’en parle pour bloquer cette saloperie d’outil qui peut apporter de gros ennuis au boulot

Pour rappel, c’est un VPN « zero-conf » qui permet à l’utilisateur nullissime en informatique (c’est-à-dire que vous n’avez rien besoin de connaître en info pour installer/utiliser ce truc) d’installer un VPN pour atteindre ses copains au boulot ou son PC chez lui. Au-delà de ça, ça peut rapidement se transformer en une passerelle entre un réseau bien sale (celui de l’utilisateur lambda chez lui, nul en informatique je le rappelle) et votre entreprise. D’où problèmes. D’où envie de donner des baffes.

Voici comment le bloquer (du moins maintenant il ne passe plus à mon boulot et pourtant il essaye – donc je dois avoir fait le tour de la question), tant au niveau shorewall – si l’accès Internet est direct – qu’au niveau squid si vos utilisateurs *doivent* passer par le proxy pour atteindre Internet.

Analyse à 2 balles du comportement de hamachi pour mieux le bloquer

Au départ, installez hamachi pour tester. Ca devrait se connecter sans problème. Je pense qu’il va chercher la conf proxy dans les paramètres de IE.
C’est typiquement le genre d’outils qui a prévu tout un tas de modes de connexions genre :
- essayer tout un tas de ports standards
- avoir plein de noms de machines pour atteindre le serveur par plusieurs chemins

MAIS, comme c’est un outil avec un point central (le serveur chez eux pour s’authentifier – puisque ça a une vocation commerciale, payante, tout ça), on peut à un moment donné repérer tous les serveurs centraux et les bloquer. C’est pas comme pour des protocoles décentralisés type peer-to-peer.
Bon après, s’ils changent leurs noms ou IP tout le temps, ça peut devenir pénible.

Une fois connecté, allez voir vos logs squid, vous devriez voir tout un tas de requêtes du style :

1221661590.889 350758 votre.ip.sur.lan TCP_MISS/200 3734 CONNECT ssl-24.hamachi.cc:443 - DIRECT/74.201.74.26 -

De là, avec quelques commandes hosts, genre :

for i in `seq -f '%02g' 1 40`
do
host ssl-$i.hamachi.cc
done

Ainsi que :

for i in `seq 1 255`
do
host 74.201.74.$i
done

Ce qui donne :

...
103.74.201.74.in-addr.arpa domain name pointer ns3.3amlabs.com.
104.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
105.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
106.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
...

Vous verrez qu’en gros, la plage IP 74.201.74.0/24 est à eux et qu’avec 4/5 noms de domaines génériques, vous pourrez tout bloquer.

Blocage niveau shorewall

En considérant que votre shorewall fonctionne bien, vous pouvez soit blacklister dans le fichier /etc/shorewall/blacklist (si vous avez bien activé l’option « blacklist » dans le fichier /etc/shorewall/interfaces), soit faire une règle dans /etc/shorewall/rules.
Dans « blacklist », ajoutez la ligne :

74.201.74.0/24

Ou, dans « rules », ajoutez :

DROP    lan     net:74.201.74.0/24      all

Relancez shorewall via /etc/init.d/shorewall reload

Blocage niveau Squid

Allez dans le fichier /etc/squid/squid.conf et à l’endroit où sont définies des « ACL », ajoutez celles-ci – c’est un exemple à adapter.

acl tout_mon_lan src 172.16.0.0/255.255.0.0
acl vilain_hamachi dstdomain .hamachi.cc .logmeinhamachi.com .logmein.com .3amlabs.com logmeinrescue.com logmeinrescue-enterprise.com
http_access deny tout_mon_lan vilain_hamachi

Ici je me base sur les noms de domaines, pas les IP. C’est un choix motivé par le fait que le client hamachi semble tenter des noms de machines, pas des IP. A voir si l’éditeur fait évoluer ça dans le temps.
Et pensez à recharger squid : /etc/init.d/squid reload

Validez que ça ne marche plus

Retestez la connexion à Hamachi. Vous devriez le voir s’exciter dans les logs squid sur quelques ssl-xx.hamachi.cc pris au hasard puis plus rien :

1221666080.309      0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-14.hamachi.cc:443 - NONE/- text/html
1221666199.615      0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-15.hamachi.cc:443 - NONE/- text/html
1221666283.816      5 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-13.hamachi.cc:443 - NONE/- text/html

En images, ça reste sur ça :