Packages requis:

• comgt pour gérer la partie code PIN;
• ppp pour la partie connexion à Internet;
• gsm-utils pour la partie envoyer/recevoir des SMS

Problème standard avec les clefs 3g:
Quand on les sorts de l’emballage et qu’on les branche sur un linux, on ne trouve pas la clef (pas de /dev/ttyUSBX, pas de /dev/ttyACMX ou /dev/nzX ou …).
Elles sont vues dans le meilleurs des cas comme un support de stockage ou un CD-ROM que l’on peut monter pour y trouver en général le mode d’emploi, les drivers windows et mac et les petits softs qui vous pourrissent le système.
Avec la Nokia CS-10, on contre ça avec un script et une règle udev qui désactivent et « éjectent » ce périphérique non voulu:
Le script (nokia-zerocd) se mets dans /lib/udev (avec les bons droits: 0755), et est assez basique:

#!/bin/sh
if [ -f /etc/udev/nokia-zerocd-noeject ]
then
exit 1
fi
minor=$(echo $2 | sed ‘s/.[0-9]*\.//’)
major=$(echo $2 | sed ‘s/\.[0-9]*$//’)
if [ "$major" -gt "0" ] || « $minor » -gt « 10″ ]
then
exit 1
fi
exit 0

La régle udev (99-nokia-zerocd.rules) se met dans /etc/udev/rules.d (avec les bons droits: 0644):

SUBSYSTEMS== »usb », SYSFS{idVendor}== »0421″, SYSFS{idProduct}== »060c », ACTION== »add », PROGRAM== »nokia-zerocd %M %s{serial} », RUN+= »/usr/bin/eject -s %k », OPTIONS+= »last_rule »

Il suffit ensuite de recharger les règles udev: sudo /etc/init.d/udev restart.

Maintenant, on peut brancher la clef (où l’on a pensé à insérer la SIM), et elle devrait bien être détectée au bout de quelques secondes (on devrait trouver deux nouveaux devices: /dev/ttyACM0 et /dev/ttyACM1).

Activer/Connecter la carte au réseau 3g:
Cela se fait assez facilement, avec la commande comgt:

# comgt -d /dev/ttyACM0
Enter PIN number: XXXX

Waiting for Regestration..(120 sec max)..
Registered on Home network: « Orange F »,2
Signal Quality: 19,0

Maintenant, on peut se servir de la clef pour envoyer/recevoir des SMS ou se connecter à Internet.

La partie simple: envoyer un SMS

gsendsms -d /dev/ttyACM0 0612345678 « mon message »

La partie plus « complexe »: se connecter à internet

Cette partie est plus complexe parce qu’il faut savoir que ces modems ne supportent pas tous le même jeu de commandes AT, donc, tout ce qui suit ne fonctionnera pas forcément avec d’autres modem (il faudra sûrement adapter le nom du device et une partie des commandes AT qui permettent d’initialiser le modem).

A la fin du fichier /etc/ppp/pap-secrets, ajouter une ligne (adapter en fonction de votre cas):

orange * orange

Créer le fichier /etc/ppp/peers/orange (vous pouvez l’appelez autrement) en pensant à adapter le nom du device, le nom d’utilisateur et le débit du device à votre cas:

ipcp-restart 7
lcp-echo-failure 99
lcp-echo-interval 0
lcp-restart 10
connect ‘/usr/sbin/chat -v -e -f /etc/ppp/peers/orange.chat’
/dev/ttyACM0
460800
crtscts
noipdefault
defaultroute
ipcp-accept-local
ipcp-accept-remote
noipx
noccp
usepeerdns
nodeflate
novj
novjccomp
nobsdcomp
nopredictor1
nopcomp
noaccomp
noauth
user orange

Créer le fichier /etc/ppp/peers/orange.chat (vous pouvez l’appeler autrement, mais penser à modifier le fichier précédent):

 » ATZ
OK-AT-OK « ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0″
OK-AT-OK ‘AT+CGDCONT=1, »IP », »orange-mib », »",0,0‘
OK-AT-OK ‘ATD*99***1#‘
CONNECT ‘\d\c’

ATTENTION!
Le numéro de téléphone n’a manifestement pas d’importance (*99#, *99*1# marcheraient aussi bien) et ne dépend manifestement pas de l’opérateur (il est juste là parce qu’il en faut un), par contre, la commande AT qui permet de le composer peut changer d’une clef et d’un opérateur à l’autre (ATDnum ou ATDTnum en général).
La ligne CGDCONT dépend de votre opérateur et de votre abonnement, à vous de trouver la bonne . Celle de cette exemple marche bien pour un abonnement orange pro avec forfait data.
La première ligne devrait être la même partout, par contre, entre la première et les 3 dernières, ça peut-être totalement différent

Notes en vrac:

• La même chose doit pouvoir marcher en branchant le téléphone en USB et en le configurant en mode modem
• Si vous connecter le téléphone via bluetooth, le device devrait s’appeller /dev/rfcommX
• En GPRS (2g), la vitesse du device est souvent 115200 bauds (pas comme les 460800 de la 3g/umts/hsdpa)

Il y a 3 méthodes courantes pour commencer à jouer avec les chroot ssh/sftp :

• Héberger un serveur SSH en chroot normal : c’est chiant. Créer un « home », reproduire un minimum d’arborescence standard, d’utilisateurs etc.
• Utiliser rssh comme shell alternatif, c’est un shell qui limite l’utilisateur à du SFTP, SCP, CVS, RSYNC etc. On choisit ce qu’on veut tolérer. Mais, l’utilisateur peut quand même se promener dans le système (tout « / »).
• Enfin, ce que je vais décrire : utiliser la fonctionnalité de « chroot » intégrée aux serveurs SSH (serveur ssh >= 4.8, donc n’importe quel SSH d’une Debian stable de nos jours). On va simplement brider quelques comptes et mettre quelques permissions bien senties.

Adaptation d’un utilisateur

Le mieux est de prévoir large : on risque d’avoir plusieurs clients/fournisseurs qui voudront accéder.
On va donc créer un groupe des utilisateurs SFTP seulement, nommé « sftpusers ».
Je crée un utilisateur pour mon client, nommé xfer1, en changeant son home :

xfer1:x:1011:1012:Transfert client1,,,:/transferts_partenaires/xfer1/:bin/bash

Notez que le groupe 1012 est le groupe « sftpusers » :

$ id xfer1
uid=1011(xfer1) gid=1012(sftpusers) groupes=1012(sftpusers)

Création du répertoire d’échange, permissions

On crée l’arborescence qui va servir de home bidon à tout ces utilisateurs :

$ mkdir --parents /transferts_partenaires/xfer1/
$ chown -R root:sftpusers /transferts_partenaires/
$ chmod -R 750 /transferts_partenaires/

Les permissions ci-dessus sont hyper importantes. Le serveur SFTP refusera la connexion si le home de ces utilisateurs n’est pas en écriture uniquement pour le root ! Donc oui, en l’état, notre utilisateur xfer1:sftpusers ne peut pas écrire dans son home. Il pourra lire, ce qui peut être suffisant si vous lui mettez simplement des fichiers à disposition. Mais pour écrire, il faudra créer un sous-répertoire, genre « upload ».

mkdir /transferts_partenaires/xfer1/upload/
chown xfer1:sftpusers /transferts_partenaires/xfer1/upload/
chmod 700 /transferts_partenaires/xfer1/upload/

Déclaration du compte en SFTP uniquement

Enfin, on paramètre le serveur SSH comme suit. Modifiez votre fichier /etc/ssh/sshd_config :

# param par défaut, on change : Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem     sftp   internal-sftp -f AUTH -l VERBOSE

# plus loin...
Match Group sftpusers
        ChrootDirectory /transferts_partenaires/%u
        ForceCommand internal-sftp
        AllowTcpForwarding no
        GatewayPorts no
        X11Forwarding no

A noter que les AllowUsers/DenyUsers s’appliquent toujours. L’utilisateur xfer1 – ou plutôt les utilisateurs du groupe sftpusers – doivent être autorisés d’une manière ou d’une autre.
A noter aussi la beauté du geste avec le « %u » pour indiquer le nom de l’utilisateur.

Ensuite vous recharger le serveur SSH et testez les connexions SFTP et SSH-qui-passent-pas, sans oublier la distinction lecture/écriture.

Pourquoi donc me direz-vous ? simplement parce-que dans l’éventualité où faire bouger le prestataire en face de vous (celui qui héberge le serveur SSH) coûterait trop d’énergie, on va supposer qu’on ne peut pas facilement faire avaler notre clef publique à l’hébergeur du serveur SSH.

Bref, la commande traditionnelle est :

sftp utilisateur@serveur
Connecting to serveur...
utilisateur@serveur's password:
sftp>

J’ai trouvé une méthode simple : utiliser le client SFTP de « PuTTY ».
Je pensais au départ utiliser celui de « lftp » et sauvegarder ma connexion (avec mot de passe) en bookmark, mais comme mon login dans l’histoire est un utilisateur de domaine windows (ouais, le serveur SSH en face est sous windows O_o), y’a un \ dans le login et même en le doublant, lftp semble mal le digérer, ben j’étais aussi bloqué.

Bref, en installant les outils de PuTTY :

aptitude install putty-tools

On peut alors taper :

psftp -pw mon_pass utilisateur@serveur
Using username "utilisateur".
Remote working directory is /
psftp>

Attention : le mot de passe est en clair dans la ligne de commande, donc dans les processus etc etc. Donc c’est pas idéal comme condition.
Enfin, je n’ai pas mis le paramètre -b pour mon batch, car ce n’est pas le propos là.

Préparez le serveur

Le paquet qui va bien

Sur le serveur, installez le paquet « ntp ». Faisant office de serveur, il se met à jour (donc il fait office de client, si je ne dis pas connerie). Pas la peine donc d’installer « ntpdate » qui est un autre client possible.
Les options du serveur sont dans /etc/default/ntp.conf, j’en parle un peu plus bas. Lisez le man.
Les paramètres de /etc/ntp.conf sont :

serv:~# egrep -v "^#|^$" /etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 0.debian.pool.ntp.org iburst dynamic
server 1.debian.pool.ntp.org iburst dynamic
server 2.debian.pool.ntp.org iburst dynamic
server 3.debian.pool.ntp.org iburst dynamic
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
restrict 10.0.0.0 mask 255.0.0.0 nomodify notrap

J’ai juste ajouté la plage 10.0.0.0 (c’est un exemple) pour autoriser mon LAN à joindre ce serveur.

Firewalling ?

Il faudra ouvrir en sortie le port « ntp » (123), en UDP, depuis le serveur vers les serveurs amonts. Si c’est la liste par défaut de /etc/ntp.conf, à savoir les « *.pool.ntp.org », c’est une longue liste, amenée à évoluer dans le temps je suppose. A vous de voir comment faire. Le plus simple : ouvrir UDP/123 vers le web, point.
Pour que les clients joignent votre serveur, c’est pareil, il faudra ouvrir le LAN vers votre passerelle, port UDP/123.

Testez

Je recommande d’ajouter -l /var/log/ntp.log dans les options du fichier /etc/default/ntp, soit :

NTPD_OPTS='-g -l /var/log/ntp.log'

Puis de redémarrer le service via :

/etc/init.d/ntpd restart

Vous verrez dans /var/log/ntp.log si votre serveur se met à jour, de combien de temps etc. Pensez à enlever ce log ou sinon à mettre en place une rotation de logs qui va avec.
Ca ressemble à ça :

13 Nov 11:19:30 ntpd[18381]: synchronized to 91.121.121.160, stratum 2
13 Nov 11:19:30 ntpd[18381]: time reset -0.169417 s
13 Nov 11:19:30 ntpd[18381]: kernel time sync status change 0001
13 Nov 11:23:57 ntpd[18381]: synchronized to 91.121.121.160, stratum 2
13 Nov 11:31:29 ntpd[18381]: synchronized to 91.121.86.143, stratum 2
13 Nov 11:35:30 ntpd[18381]: time reset +0.189846 s
13 Nov 11:35:50 ntpd[18381]: synchronized to 91.121.121.160, stratum 2
13 Nov 11:40:06 ntpd[18381]: synchronized to 81.19.16.225, stratum 2
13 Nov 11:42:57 ntpd[18381]: synchronized to 91.121.121.160, stratum 2

On est maintenant prêt à dire à notre LAN d’aller taper sur ce serveur pour régler l’heure.

Les postes Windows

Le service W32Time (« Horloge Windows ») est en automatique par défaut depuis Windows XP. Il s’appuie sur le paramètre qu’on trouvera dans la clef de registre HKLM/SOFTWARE/Policies/Microsoft/W32Time/Parameters. La clef est « NtpServer ».
Il faut donc mettre à jour cette clef, d’une manière ou d’une autre.

…via des GPO

Si vous êtes en domaine Windows, le réglage est ici :

En gros, vous indiquez le nom de votre serveur.
Vous pouvez forcer la mise à jour des GPO sur un poste, pour tester, via gpupdate /force.

En pas GPO (domaine Samba-sans-GPO, Workgroup etc)

Il faut modifier la clef mentionnée plus haut, d’une manière ou d’une autre ; et probablement relancer le service « Horloge Windows ».

Sous Windows, comment tester

Le service Windows ne raconte rien et les « event logs » systèmes, c’est chiant.
Je suggère sur le serveur, un joli tcpdump qui vous montrera qui fait quoi :

serv:~# tcpdump -i eth0 dst port ntp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:14:49.071538 IP pc315.maboite.fr.ntp > imag.imag.fr.ntp: NTPv3, symmetric active, length 48
15:14:49.172627 IP imag.imag.fr.ntp > pc315.maboite.fr.ntp: NTPv3, symmetric active, length 48
15:15:29.305824 IP pc666.maboite.fr.ntp > serv.maboite.fr.ntp: NTPv3, symmetric active, length 48
15:15:29.306158 IP serv.maboite.fr.ntp > pc666.maboite.fr.ntp: NTPv3, symmetric active, length 48

Là, on voit un « pc315″ qui continue de demander à l’extérieur (le firewall l’autorise pour l’instant) et un pc666 qui a prit le pli.

Les postes Linux

Installez le paquet « ntpdate » et planifiez ntpdate-debian en crontab. Le manuel explique : ntpdate-debian utilise le fichier /etc/default/ntpdate pour la configuration (liste des serveurs de temps etc). Il contient, sans les commentaires :

NTPDATE_USE_NTP_CONF=yes
NTPSERVERS="0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org"
NTPOPTIONS=""

Mais, dans ce cas, à cause du « yes », il utilise la conf de l’éventuel /etc/ntp.conf installé via le serveur NTP (paquet ntp). Comme on ne l’a pas mis sur les clients (ça sert à rien de faire tourner un serveur NTP), il faut donc soit passer NTPDATE_USE_NTP_CONF à « no », soit ne pas planifier ntpdate-debian, mais ntpdate avec une tartine de paramètres.
Si vous mettez « no », il faudra indiquer dans NTPSERVERS au moins / uniquement votre serveur du LAN. J’ai constaté qu’avec le nom de machine, ça ne passait pas. Mais avec l’IP, c’est OK. A creuser.

Pigé ? moi-même, je me perds régulièrement là-dedans.

Vite, iptables doit pouvoir m’aider. Je suis une buse en QoS, mais bon, j’ai confiance en Google

Après quelques recherches, je suis tombé sur LARTC, Linux Advanced Routing & Traffic Control. En quelques mots, une bande de fous-furieux qui aiment les lignes de commandes compliquées (à côté de ça, iptables est un joujou) pour faire de la QoS.
Y’a un howto super complet : http://www.traduc.org/docs/howto/vf/lartc.html. Pas le temps, ça sent le sujet compliqué et vaste. On verra plus tard.

Là je veux juste limiter le trafic entre mon proxy et ce p~!?[n de serveur WSUS.

J’ai trouvé 3 lignes magiques ici (après avoir survolé le man tc histoire de suivre le loin ce que je fais) :

tc qdisc add dev eth0 root handle 1: cbq avpkt 1000 bandwidth 10mbit
tc class add dev eth0 parent 1: classid 1:1 cbq rate 400kbit allot 1500 prio 5 bounded isolated
tc filter add dev eth0 parent 1: protocol ip prio 16 u32 match ip dst 192.168.1.2 flowid 1:1

Je voulais limiter le trafic vers 192.168.1.2 via eth0 à 50 kB/s, soit en gros 400 kbit/s.
Pour annuler, j’ai « annulé » les commandes, si je peux dire. Sans être trop sûr de moi, j’ai simplement tenté ça :

tc filter del dev eth0 parent 1: protocol ip prio 16 u32 match ip dst 192.168.1.2 flowid 1:1
tc class del dev eth0 parent 1: classid 1:1 cbq rate 400kbit allot 1500 prio 5 bounded isolated
tc qdisc del dev eth0 root handle 1: cbq avpkt 1000 bandwidth 10mbit

Je n’ai pas vu d’effet de bord (genre, tout bloqué ou rien qui ne se rétablit une fois le tc annulé). Donc on va dire que c’est probablement un peu crade, que je n’y comprends pas tout, mais que ça marche.

Voilà, si ça peut vous servir, j’en suis content.
noob-powered

Gros guide de mise en place de Nagios sur Debian, avec comme principal objectif de vous amener petit à petit à monitorer tout ce qu’on peut imaginer sur un parc de serveurs Linux, Windows, des équipements réseaux etc. Ca part d’un exemple bien détaillé (je l’espère) pour bien faire comprendre les principes et l’esprit Nagios pour espérer à la fin, vous avoir donné de quoi évoluer facilement pour ajouter n’importe quel test.
Au départ, je voulais faire un guide super complet, mais avec Nagios, on ajoute des tests tous les jours, pour ainsi dire. Bref, ça fait 3 mois que j’attendais pour faire ce guide. Finalement je l’écourte un peu et j’ajouterai (peut-être) des chapitres plus tard sur ce blog.
Après un premier exemple bien complet, je donne des exemples rapides de contrôles courants.

J’ai eu l’idée de rédiger cet article sachant que je ne connaissais rien à Nagios (rien de sa mise en place, rien des fichiers de conf, rien de sa syntaxe, rien des outils de base, rien des plug-ins supplémentaires et rien des contributions à gogo sur le web etc). L’intérêt, n’y connaissant rien justement, est que j’explique pas à pas, notamment les principes de l’outil pour comprendre comment le configurer, en détaillant parfois toutes les panneaux que j’ai pu me prendre, mais en donnant la solution rapidement

A la fin, je donne mes fichiers de conf, un peu anonymisés et allégés, ils peuvent vous servir pour de la mise en place de certains morceaux ou pour vous guider dans la syntaxe. Exemple, vous voulez surveiller vos serveurs DNS, cherchez le mot « dns » dans tous les fichiers, comprenez ce qui y est fait et copiez-collez-modifiez les bons blocs. Reste à changer les noms de hostname Hum, ça, ce sera plus tard lorsque j’aurai complété par d’autres articles (cf. ci-dessus), je n’ai pas trop le temps, et sinon, je ne publierai jamais cet article… il traîne depuis 3 mois…

Je ne compte pas faire de l’ombre à Nicolargo (passionné du sujet Nagios) mais mon approche est différente : je pars de ce que Debian a fait pour moi, pas des sources à compiler pour avoir l’absolue dernière version. Les répertoires de configuration et de chemins des binaires sont différents, tous les plug-ins classiques sont directement disponibles.
Après, une fois l’outil fonctionnel sur quelques cas, ça reste du Nagios pur. Allez voir son site, il y a de bonnes docs et le forum peut aider aussi. Sans compter d’autres sites d’outils de monitoring complémentaires, notamment http://www.monitoringexchange.org/, et évidemment la doc officielle qui est très bien foutue. J’y ferai référence autant de fois que j’y penserai.

La version actuellement packagée sous Debian « stable » (Lenny) est Nagios 3.0.6. Comme d’habitude avec Debian, un peu en retard sur la version officielle, mais il y a d’autres intérêts à utiliser tout de même la version packagée, à mon avis.

Installation

Sur un air d’aptitude install

Ca commence sur un air connu par un aptitude install nagios3. A noter que ça descend par dépendance 3 paquets nagios-plugins* qui contiendront tout un tas de plugins (contrôle de LDAP, de mail, de MySQL, de MRTG, de serveur FTP…).
Une remarque pendant l’installation (pour le chapitre suivant) :

[...]
Get:10 ftp://ftp.fr.debian.org lenny/main nagios3-doc 3.0.6-3 [2034kB]
[...]
serious bugs of nagios3-common (-> 3.0.6-3) 
 #519341 - nagios3-common: missing "then" in nagios3-common.prerm (Fixed: nagios3/3.0.6-4)
[...]

On voit aussi passer ces plugins :

[...]
Creating config file /etc/nagios-plugins/config/http.cfg with new version
Creating config file /etc/nagios-plugins/config/load.cfg with new version
Creating config file /etc/nagios-plugins/config/mail.cfg with new version
[...]

Lisez de préférence tous les fichiers README.Debian des répertoires /usr/share/doc/nagios3 et /usr/share/doc/nagios-plugins. Il y a 2/3 infos importantes, mais je les reprends au fil de l’eau dans la suite de l’article.

Droits d’accès à l’interface web de Nagios

Les README.Debian habituels qu’on trouve dans /usr/share/doc/nagios* parlent du truc et indiquent qu’on doit avoir une question posée pendant l’installation. Vu le bug mentionné plus haut par apt-listbugs (c’est quoi ?), je ne m’étonne qu’à moitié de n’avoir pas vu passer de « fenêtre » (ncurses) pendant l’installation. Doc pas à jour ou vrai bug. Bon bref, il faut rectifier le tir.

On voit dans /etc/apache2/conf.d/nagios3.conf que les droits sont gérés par htaccess (voir directive AuthUserFile)dans /etc/nagios3/htpasswd.users. Or, ce fichier n’existe pas, on doit donc le créer.

htpasswd -c /etc/nagios3/htpasswd.users nagiosadmin

Le nom nagiosadmin semble important pour éviter certains ennuis (de ce que j’en ai lu, mais je ne sais plus où, peut-être là).
Enfin, vérifiez les droits sur le fichier en question, idéalement, il faut :

chown root:www-data /etc/nagios3/htpasswd.users
chmod 640 /etc/nagios3/htpasswd.users

Et recharger apache via /etc/init.d/apache2 reload.
L’adresse d’accès doit être http://votre.serveur/nagios3/.

Principe de base et cheminement de ma doc

Une fois qu’on a pataugé un peu, il en ressort quelques grands principes pour gagner en autonomie et arriver à pondre du fichier de conf au kilomètre ou savoir où regarder pour trouver un plug-in tiers, le mettre en place, l’utiliser et même l’adapter.
Quelques grandes idées pour démarrer :

• Nagios appelle des scripts permettant de contrôler un élément particulier (ou plusieurs d’un coup) : contrôler un service, les espaces disques, la charge CPU, la réponse d’un site web, la charge d’un port de switch etc
• On a des modèles d’appels de scripts, nommés en général « check_quelquechose » permettant de comprendre les paramètres pour un contrôle donné (valeurs limites, nom du truc à regarder
• Il faudra déployer des agents pour certains contrôles, notamment pour contrôler du Windows. En gros, pour obtenir des informations qui sont récupérables par un traitement local uniquement, pas à distance. Normal me direz-vous. Ces agents sont des à côtés du projet Nagios. Mais il y a déjà tout ce qu’il faut.
• Il va falloir décrire nos machines une à une et ce qu’on contrôle pour chacune (forcément, c’est pas magique comme outil). On pourra faire des groupes de machines et y associer des contrôles appliqués à ces groupes. Exemples : toute machine hébergeant un serveur web aura de base un contrôle vérifiant le port 80 ; toute machine Windows aura de base un contrôle sur la nécessité d’applications de patchs, un contrôle sur l’espace disque etc…

Dans cette doc, je vais décrire chaque sujet dans l’ordre dans lequel j’ai mis en place les contrôles, souvent en partant de la doc officielle (parfois pas exactement à jour) puis en adaptant au contexte Debian qui a, comme d’habitude, pré-mâché certaines choses (mise à dispo de scripts, « modèles » pour tel type de machine, de switchs etc).
Je voulais avant tout contrôler un peu tous ces jolis serveurs Windows qui sont peu bavards en général (ou qui racontent uniquement des trucs dont on se fout)… Donc il y a une bonne partie sur l’interfaçage avec Windows ; cas somme toute courant je pense.
Du coup, je dissémine des informations malgré moi à mesure de ma compréhension (lorsque j’ai « appris » Nagios) ; et surtout en ayant rédigé la doc quelques mois après (hum).

Bon, en bref, Nagios est un outil tout sauf clef-en-main (sauf peut-être si vous optez pour un système comme FAN, mais vous aurez un système dédié « limité » à Nagios&co je suppose)
Le paramétrage est long et on en ajoute chaque jour.
Pour le planning pour le patron, prévoyez large. Mise en place et premiers résultats quelques heures tout au plus, paramétrage plus poussé : quelques semaines. Plus on en découvre, plus on monitore de choses. On corrige les problèmes et on en anticipe d’autres grâce à Nagios. Bref, le bonheur avec reporting pour le patron. A la fin, on commence à écrire ses propres scripts, en n’importe quel langage.

Ah au fait, attention aux alertes par mail. Nagios vous dit tout : « tel service est tombé », « tel service est toujours KO », « tel service est revenu ». Multiplié par le nombre de service et de machines, ça fait des mails à la pelle. Faudra prévoir des règles de tri dans un premier temps…

C’est parti

Surveillance des basiques de serveurs Windows (NT, 2000, XP, 2003 et +)

Oui les libristes vont encore perdre du temps à critiquer le fait que je parle de Windows-le-mal-incarné d’abord. Economisez-vous. Mon point de vue est que justement, Nagios aide très bien à monitorer « du windows » là où Windows est quand même à chier niveau remontées d’alertes, en standard. Autant, un Linux un tant soit peu configuré vous remonte déjà plein de choses par mail, par exemple, qu’il ne sera pas forcément la peine d’aller contrôler par Nagios.

Installation et 1er paramétrage de l’agent NSClient++

Si vous voulez la doc officielle, commencez par là (http://nagios.sourceforge.net/docs/3_0/quickstart.html) et enchainez sur http://nagios.sourceforge.net/docs/3_0/monitoring-windows.html.
Il faut donc télécharger et déployer un agent windows pour Nagios. Disponible en 32, 64 bits. Je pense qu’il y en a plusieurs, j’ai opté pour celui-ci, qui m’a l’air complet : http://sourceforge.net/projects/nscplus.
Lorsque ça marchera pour une machine, il n’y aura qu’à déployer l’agent à distance et injecter le fichier de conf NSC.ini qui va bien sur chaque machine. Pensez aux outils sysinternals.com microsoft, notamment les PSTools et psexec. C’est pratique pour automatiser.

L’agent apporte une interface entre l’appelant Nagios et un serveur Windows. Il apporte aussi de base quelques outils pour effectuer une certaine batterie de tests. Le paramétrage des tests que l’on veut se fait sur le serveur Nagios, pas du côté de l’agent Windows.
Si on veut ajouter un test qui n’est pas prévu par cet agent, il faudra écrire un script, sous windows cette fois, et le définir dans l’agent, qui sert de relai, en gros. On le verra plus bas avec le contrôle des patchs Windows en attente d’installation.

Bref, une fois NSClient++ installé, la doc dit d’aller trafiquer les options du service Windows qu’on vient d’installer. Dans les propriétés du service, allez dans l’onglet « Connexion / Log on » et cocher la case pour autoriser à « interagir avec le bureau ».

Maintenant il faut ajuster un peu le fichier de paramétrage de l’agent, C:\Program Files[ (x86)]\NSClient++\NSC.ini. Sachant que je vais y revenir plus tard pour NRPE (voir plus bas), si c’est la galère pour déployer le fichier sur vos machines, attendez un peu pour le faire une seule fois (cherchez plus bas dans l’article NRPE). Enfin bon, commencez par un serveur avant de généraliser un truc qui ne fonctionne pas.

Dans la section [modules], décommenter comme suit (tout sauf CheckWMI.dll et RemoteConfiguration.dll) :

[modules]
;# NSCLIENT++ MODULES
;# A list with DLLs to load at startup.
;  You will need to enable some of these for NSClient++ to work.
; ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
; *                                                               *
; * N O T I C E ! ! ! - Y O U   H A V E   T O   E D I T   T H I S *
; *                                                               *
; ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
FileLogger.dll
CheckSystem.dll
CheckDisk.dll
NSClientListener.dll
NRPEListener.dll
SysTray.dll
CheckEventLog.dll
CheckHelpers.dll
;CheckWMI.dll
;
; RemoteConfiguration IS AN EXTREM EARLY IDEA SO DONT USE FOR PRODUCTION ENVIROMNEMTS!
;RemoteConfiguration.dll

Dans la partie [NSClient], attribuer un port d’écoute (celui par défaut à priori) et dans la section [Settings], à voir si vous voulez un mot de passe. Je n’en ai pas mis, j’ai limité l’écoute à l’adresse IP de mon serveur Nagios ; pratique dans ce cas simple avec un seul serveur de monitoring.

[...]
[NSClient]
[...]
port=12489
[...]
[Settings]
[...]
;password=secret-password
allowed_hosts=192.168.y.x
[...]

Notez la section [log] qui peut être pratique quand rien ne fonctionne et qu’il faut comprendre ce que NSClient reçoit de Nagios.

Redémarrez le service, le client est prêt.

Premier morceau de config Nagios, la théorie

Maintenant on va indiquer à Nagios d’aller voir ce qu’il se passe là-bas et quels tests de base effectuer pour une « machine windows ».
On va partir d’un modèle de configuration de poste Windows fourni par Debian et définir notre machine, appelée « mamachine ».
Là ça fait un peu mal au crâne la première fois, mais une fois le concept compris, vous pondrez des fichiers de conf Nagios au kilomètre. En effet, c’est le chapitre où on fait le baptême du feu dans la syntaxe Nagios. J’espère être clair dans ces prochains chapitres.

L’organisation en terme de fichiers dans /etc/nagios3/conf.d/ est complètement libre. Vous pouvez tout mettre dans un seul fichier ou couper par site (par exemple), ou encore séparer la déclaration des machines de celle des groupes de machines, mettre la définition de vos propres services à part ou proche des groupes de machines auxquelles ces services se rapportent etc.
C’est votre choix, à la fin, Nagios intègrera l’ensemble des directives de configuration de « conf.d » (ainsi que des plugins, tout ceci est configuré en amont par Debian dans /etc/nagios3/*conf) et hurlera au « reload » si vous vous êtes trompés.
C’est d’autant plus libre qu’en géréral, il y a plusieurs manières d’organiser les choses pour arriver à un même résultat. Premier exemple ci-dessous : est-ce que je dis que « mamachine » appartient au groupe (hostgroup) « windows-servers » ou est-ce que je dis que le groupe « windows-servers » contient comme membre (members) « mamachine ». A vous de voir.
Je mets les mots-clefs Nagios entre parenthèse et en italique pour faire l’association « bon français »- »mot-clef Nagios ».

Donc, pour une conf de base pour tester une machine via NSClient++, je prends le « groupe » Windows (qu’on complètera plus tard) et je crée une machine « mamachine » appartenant à ce groupe. Ce qu’on appelle ici un « groupe » est un « ensemble des machines auxquelles un certains nombre de tests communs seront appliqués ». C’est un « hostgroup ». Debian a déjà affecté plusieurs tests à ce groupe. C’est pratique.
L’idée sera d’ajouter par la suite au groupe (hostgroup) « windows-servers » d’autres les tests qui sont communs à tous les Windows : présence de patchs WSUS par exemple. Par exemple, on n’ajoutera pas le contrôle du disque F: qui n’existe peut-être pas sur tous les serveurs. Là il faudra faire par machine, ou alors un groupe « des machines ayant un disque F: ». C’est votre choix.

Attention, la notion de « template » dans Nagios est différente, c’est réellement un modèle qui définit d’autres informations sous-jascentes. On n’y touchera pas (il me semble). Il y a des templates « windows » (nommés windows-server, et pas windows-servers qui est le groupe de machine windows, vu ? ), mais aussi par exemple un « template » de service nommé generic-service sur lequel on se base pour déclarer un service.

Premier morceau de config Nagios, la pratique

Alors, je localise le groupe (hostgroup) « windows-servers » pré-mâché par Debian. On va l’utiliser car il amène en standard les contrôles de base : espace disque, charge CPU…

srvnag:/etc/nagios3/conf.d# dpkg -S windows.cfg
nagios3-common: /usr/share/doc/nagios3-common/examples/template-object/windows.cfg
srvnag:/etc/nagios3/conf.d# cp /usr/share/doc/nagios3-common/examples/template-object/windows.cfg template-windows.cfg

Ce fichier contient, sans les commentaires standards mais avec les miens et une fois un peu remodelé, ceci :

define host{ ; définition d'une machine basée sur le template "windows-server", nommé ci-dessous
        use             windows-server  ; Inherit default values from a template
        host_name       mamachine       ; The name we're giving to this host
        alias           C est mamachine       ; A longer name associated with the host
        address         192.168.x.y     ; IP address of the host
        ; #hostgroups windows-servers ; voir ci-dessous
}

Cette dernière ligne (hostgroups) aurait permis de dire « mamachine » appartient au groupe (hostgroup) « windows-servers » (donc elle hérite de tous ses tests). Dans mon cas, j’ai plutôt décidé de définir la liste des membres (=machines = « host ») d’un groupe (hostgroup) dans la définition de ce groupe. Voir ci-dessous.
J’ai adapté les tests fournis par Debian pour le groupe « windows-servers » (qui ne contient qu’une machine pour l’instant). Voici le fichier résultant :

### Déclaration du groupes windows-servers auquel on affectera les tests communs à tous les windows
define hostgroup{
        hostgroup_name  windows-servers ; Mes serveurs windows
        alias           Windows Servers ; Long name of the group
}

### Définition des SERVICE que l'on va associer au groupe windows-servers
# Create a service for monitoring the version of NSCLient++ that is installed
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     NSClient++ Version
        check_command           check_nt!CLIENTVERSION
}
# Create a service for monitoring the uptime of the server
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     Uptime
        check_command           check_nt!UPTIME
}
# Create a service for monitoring CPU load
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     CPU Load
        check_command           check_nt!CPULOAD!-l 5,80,90
}
# Create a service for monitoring memory usage
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     Memory Usage
        check_command           check_nt!MEMUSE!-w 80 -c 90
}
# Create a service for monitoring C:\ disk usage
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     C:\ Drive Space
        check_command           check_nt!USEDDISKSPACE!-l c -w 80 -c 90
}
# Create a service for monitoring the W3SVC service
# c'est un exemple gardé en commentaire pour la syntaxe check_nt de contrôle d'un service, voir plus bas
;define service{
;        use                     generic-service
;        host_name               mamachine
;        service_description     W3SVC
;        check_command           check_nt!SERVICESTATE!-d SHOWALL -l W3SVC
;}
# Create a service for monitoring the Explorer.exe process
# c'est un exemple gardé en commentaire pour la syntaxe check_nt de contrôle d'un processus, voir plus bas
;define service{
;        use                     generic-service
;        host_name               mamachine
;        service_description     Explorer
;        check_command           check_nt!PROCSTATE!-d SHOWALL -l Explorer.exe
;}

Voilà. Si vous rechargez Nagios via /etc/init.d/nagios3 reload, ben ça plante !!!
Je décris ça juste après avoir décrit « check_command » histoire de finir l’initiation à la conf de base et aux problèmes pénibles du début :/.

Autres principes à comprendre de cet exemple

Qu’y a-t-il d’autre d’important dans cette configuration pour comprendre le principe de Nagios ? le mot-clef « check_command » bien sûr. Lors de la définition d’un service, la directive check_command est celle qui explique à Nagios comment effectuer le test et quels paramètres on lui passe. Les paramètres sont séparés par le « ! ». Le premier argument est le nom de la commande (command) Nagios (et pas du script appelé, pas encore, qui lui s’appelle command_line).

Exemple :

        check_command           check_nt!MEMUSE!-w 80 -c 90

On voit les valeurs d’alertes warning et critical pour la charge mémoire utilisée, en pourcentage. On retrouvera souvent les mêmes noms d’arguments alors que les scripts n’ont rien à voir entre eux (-w pour seuil de warning etc). Il doit y avoir une sorte de norme dans le développement de ces scripts, je suppose.

Pour comprendre le lien entre la command et le script effectivement appelé sur l’OS, voici :

srvnag:/etc/nagios-plugins# grep -r command_name * | grep check_nt
config/nt.cfg:  command_name    check_nt
[...]

On y voit l’association entre cette commande Nagios et la commande OS appelée :

srvnag:/etc/nagios-plugins/config/cat nt.cfg
define command {
        command_name    check_nt
        command_line    /usr/lib/nagios/plugins/check_nt -H '$HOSTADDRESS$' -v '$ARG1$'
# cette ligne est erroné d'ailleurs, on le verra plus tard.
}

La commande (command) check_nt appelle donc le script /usr/lib/nagios/plugins/check_nt.
C’est avec lui qu’il faudra jouer pour « tester certains tests » en ligne de commande, avant de comprendre pourquoi ils plantent depuis Nagios mais pas depuis la ligne de commande. C’est un cas courant..
Bon revenons au bug qui m’occupait et qui devrait aussi vous occuper, à priori un problème lors du reload (je n’ai plus le message précis), mais on comprend que :

Il manque le template windows-server

J’ai dit le template « windows-server », pas « windows-servers » qui est un hostgroup, j’insiste.
En effet, ce template est fourni dans les packages Debian, mais pas chargé par défaut. En cherchant un peu, on le trouve ici : /usr/share/doc/nagios3-common/examples/template-object/templates.cfg.gz.
Mais si on le gunzip et qu’on le place dans /etc/nagios3/conf.d, il y a doublon de définition de generic-service comme le montre encore un reload qui plante. Ca se confirme avec cette commande :

srvnag:/etc/nagios3/conf.d# egrep "name[[:space:]]+generic-service" *
generic-service_nagios2.cfg:        name                            generic-service ; The 'name' of this service template
templates.cfg:        name                            generic-service   ; The 'name' of this service template

Deux fichiers définissent « generic-service ». Les emmerdes continuent.

Donc, je reprends le minimum du template générique, dans mon cas, « windows-server », on verra plus tard si j’ai besoin de quelque chose d’autre de ce super-template. Je crée donc ce fichier, tout au moins j’ajoute ce bout de code quelque part dans ma conf Nagios :

srvnag:/etc/nagios3/conf.d# cat windows-server_from_templates-gz.cfg
define host{ ; oui ça passe par un "host" pour définir ce modèle de machine "windows-server"
        name                    windows-server  ; The name of this host template
        use                     generic-host    ; Inherit default values from the generic-host template
        check_period            24x7            ; By default, Windows servers are monitored round the clock
        check_interval          5               ; Actively check the server every 5 minutes
        retry_interval          1               ; Schedule host check retries at 1 minute intervals
        max_check_attempts      10              ; Check each server 10 times (max)
        check_command           check-host-alive        ; Default command to check if servers are "alive"
        notification_period     24x7            ; Send notification out at any time - day or night
        notification_interval   30              ; Resend notifications every 30 minutes
        notification_options    d,r             ; Only send notifications for specific host states
        contact_groups          admins          ; Notifications get sent to the admins by default
        hostgroups              windows-servers ; Host groups that Windows servers should be a member of
        register                0               ; DONT REGISTER THIS - ITS JUST A TEMPLATE
}

Bien sûr, on comprend que ce template dépend lui-même du template « generic-host », mais, ce « generic-host » est dans les templates de base de /etc/nagios3/conf.d/. Pas de problème cette fois.
Là, le restart de Nagios devrait bien se passer hop, connexion à l’interface. Moi perso, j’y ai vu une tartine de trucs avec des warnings, des « critical », des machins à hurler partout. Surtout des trucs à débugger en fait. Ce qu’on va faire en expliquant.

Attention les remontées par mail vont commencer (par défaut root@localhost). Faites ce qu’il faut pour récupérer ces mails.

Bug « missing -l parameters »

Le premier bug relevé fût donc un résultat de commande « missing -l parameters » dans ̉l’interface web̉ de Nagios.
Pour débugger, il faut en revenir à la ligne de commande comme montré brièvement plus haut. Si on exécute le vrai binaire /usr/lib/nagios/plugins/check_nt, ça marche. Depuis Nagios, ça ne marche pas. Tiens tiens.
Demandez l’aide pour apprendre à utiliser ce plug-in en ligne de commande :

srvnag:/etc/nagios-plugins# /usr/lib/nagios/plugins/check_nt
check_nt: Could not parse arguments
Usage:check_nt -H host -v variable [-p port] [-w warning] [-c critical][-l params] [-d SHOWALL] [-t timeout]

Vous pouvez faire un /usr/lib/nagios/plugins/check_nt --help pour une doc plus complète.
Si vous jouez avec l’outil en ligne de commande, ça marche pourtant, exemple :

srvnag:/etc/nagios-plugins# /usr/lib/nagios/plugins/check_nt -H mamachine_ou_son_IP -v MEMUSE -p 12489 -w 80 -c 90
Memory usage: total:3945.26 Mb - used: 1287.70 Mb (33%) - free: 2657.56 Mb (67%) | 'Memory usage'=1287.70Mb;3156.21;3550.73;0.00;3945.26

Il y a deux problèmes. D’abord Nagios n’est pas configuré pour tolérer l’appel à des scripts « extérieurs » (raison sécuritaire). Ensuite, la command check_nt est mal définie (gasp !). J’en parlais plus haut.

Le README.Debian le disait, et dans notre cas on en a besoin, il faut autoriser Nagios a appeler des scripts extérieur. Il faut positionner set check_external_commands=1 dans /etc/nagios3/nagios.cfg. Ensuite, il faut modifier quelque chose dans dpkg pour qu’une manip soit retenue après mise à jour/upgrade de nagios par aptitude :

srvnag:/etc/nagios3# /etc/init.d/nagios3 stop
Stopping nagios3 monitoring daemon: nagios3
.
srvnag:/etc/nagios3# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
srvnag:/etc/nagios3# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
srvnag:/etc/nagios3# /etc/init.d/nagios3 start
Starting nagios3 monitoring daemon: nagios3/etc/init.d/nagios3: line 64: kill: (19130) - No such process.

A noter, j’ai vu plusieurs fois un problème de PID non trouvé, on dirait que le fichier /var/run/nagios3/nagios3.pid n’est pas purgé à l’arrêt de Nagios ; pas grave.

Enfin, on modifie la command check_nt. Le « missing -l parameters » signifie bien qu’on n’a pas passé le paramètre « -l » au binaire check_nt, paramètre obligatoire pour certains tests. En fait, dans /etc/nagios-plugins/config/nt.cfg, l’appel à check_nt est défini comme suit :

        #command_line    /usr/lib/nagios/plugins/check_nt -H '$HOSTADDRESS$' -v '$ARG1$'

Mais souvent, dans les services associés à notre hostgroup windows-servers, on voit qu’un deuxième paramètre est passé. Le fameux « -l ». C’est simplement que la définition de la commande (command_line) ne s’occupe de récupérer qu’un seul paramètre…
Je suggère donc de modifier /etc/nagios-plugins/config/nt.cfg comme suit :

gw:/etc/nagios-plugins/config# cat nt.cfg
# 'check_nt' command definition
define command {
        command_name    check_nt
        #command_line    /usr/lib/nagios/plugins/check_nt -H '$HOSTADDRESS$' -v '$ARG1$'
        command_line    /usr/lib/nagios/plugins/check_nt -H $HOSTADDRESS$ -p 12489 -v $ARG1$ $ARG2$
}

Reload de Nagios. Enfin les premiers testent passent !
Pour dire vrai, je suis passé par un stade intermédiaire de « wrong -l argument ». J’ai forcé l’appel du port (-p 12489) dans la command_line pour régler le problème. Si vous voulez rendre ce port variable, à vous de modifier la définition des services (dans les define service) appelant check_nt pour passer un n-ième argument.
J’ai aussi fait sauter les apostrophes, ça me faisait des trucs bizarres.
FIXME : si quelqu’un sait comment activer une trace qui permet de savoir comment a été appelée telle ou telle commande par Nagios, ce serait cool ça permettrait de débugger plus facilement. J’ai tenté plusieurs niveaux de débuggage, sans succès.

Ouf, premiers tests fonctionnels. Vite, d’autres !

Ca marche, c’est pas trop tôt. Quelques suggestions tirées de ce qui précède :

• Dans /etc/nagios-plugins/conf.d/, il y a plein de noms de commandes à lire, pour voir ce qu’on va pouvoir rapidement contrôler. Exemple : contrôler un port https, avec ou sans authentification (plusieurs commandes dispo).
• Dans /usr/lib/nagios/plugins/, il y a le pendant en terme de binaires. C’est bien de se familiariser avec ceux qu’on compte utiliser pour être sûr de savoir les utiliser en ligne de commande avant de s’ajouter des bugs en les définissant mal dans la conf Nagios.

Je considère par la suite que vous avez bien assimilé ce qu’on vient de voir et que vous êtes maintenant parés pour créer de la configuration Nagios à grand coup de grep et de copier-coller d’exemples. Je vais pouvoir donner des bouts de codes en vrac, par thème.

C’est reparti.
C’est là où j’aurais voulu faire une doc méga-complète, mais c’est impossible. J’ajouterai donc plus tard des chapitres lorsque j’estimerai que tel ou tel sujet n’était pas trivial à mettre en place ou qu’il y a un concept fort que je n’ai pas abordé.

Contrôle DHCP

Plus exactement, « tester si le serveur DHCP est en mesure d’attribuer des IP » (plage pleine ? service KO ?).
Je considère ici mon serveur Nagios comme un simple ordinateur client DHCP sur le réseau (ou une partie du réseau). En exécutant un script, l’outil check_dhcp simulera une demande de bail et vérifiera que tout se passe bien.
En lisant /etc/nagios-plugins/config/dhcp.cfg, vous voyez vite que la command_line attend un paramètre, l’adresse du serveur DHCP. Donc, en ajoutant quelque part dans votre /etc/nagios3/conf.d/quelquechose.cfg les lignes suivantes, on met en place le contrôle DHCP :

define service {
        use     generic-service
        host_name mon_serveur_dhcp ; ou alors vous raisonnez par hostgroups, au choix
        service_description     Reponse du DHCP
        check_command           check_dhcp
}

En ayant bien sûr défini « mon_serveur_dhcp » dans un bloc define host quelque part.
Notez qu’il y a aussi un check_dhcp_interface, qui d’après /usr/lib/nagios/plugins/check_dhcp --help permet de spécifier une interface particulière.

Ce contrôle est un bon exemple car il faut qu’il soit lancé avec les droits root – ou en sudo – car le principe, je suppose, doit être de forger des paquets pour déclencher une attribution de bail du serveur DHCP ; et forger des paquets => droit root, un peu comme l’outil de scan de port « nmap » dans certains types de scans. Lire /usr/share/doc/nagios-plugins/README.Debian à ce propos. Ca raconte de faire :

dpkg-statoverride --update --add root nagios 4750 /usr/lib/nagios/plugins/check_dhcp

Sinon, vous aurez un joli Warning: This plugin must be either run as root or setuid root. dans l’interface Nagios.
Dans mon cas, le serveur DHCP est un Windows (ah, j’te parle plus). J’ai donc aussi installé le client NSC++ sur cette machine afin de pouvoir remonter de base tous les autres indicateurs. En effet, j’ai déclaré « mon_serveur_dhcp » dans la catégorie windows-servers, donc il récupère de base tous les tests concernant le groupe « windows-servers », contrôle des disques, RAM, blablabla.
Hop, un test de plus.

Zoom sur les groupes de machines

J’en parle tout de suite car il y a déjà des groupes (hostgroups) définis dans /etc/nagios3/hostgroups_nagios2.cfg. Notamment les machines « pingables ». Je trouve que c’est une bonne idée d’ajouter des groupes type « les serveurs web » ou « les serveurs de mail ». Même si pour l’instant vous n’avez pas encore défini de service (define service) pour ces groupes, ça permet de s’organiser et de prévoir la distribution automatique de plein de tests à mesure qu’on déclare nos host et qu’on les affecte à ces groupes (hostgroup), et non pas aux machines.

Au passage, avec un bon dpkg -S base/debian.png et un grep qui va bien, vous allez vite localiser le bout de configuration qui permet d’affecter des icones aux types de serveurs, pour faire joli dans l’interface.

Droits d’utilisateurs, contacts

Pour créer un utilisateur en lecture (votre patron par exemple, il faut le limiter, pour pas qu’il fasse n’importe quoi depuis l’interface), le mieux est de lire http://nagios.sourceforge.net/docs/3_0/cgiauth.html. Attention, c’est fourbe car le menu de replanification – par exemple – de test de service est disponible pour tous les utilisateurs, mais c’est après validation de l’action qu’on voit que la personne n’a bien pas le droit de lancer une planification de tests.

Dans le cas d’une installation énorme de serveurs, il est possible d’affecter des contacts à tel ou tel serveur. Vous pouvez aussi donner les droits de supervision à une personne sur un certain ensemble de contrôles uniquement, ce genre de trucs.
Car la liste peut être longue une fois déclarés une 20aine de serveurs triés en X catégories…

Vue par service

Dans l’interface web de Nagios, vous avez sûrement trouvé le menu qui permet d’avoir un aperçu par hostgroup. On peut aussi créer une vue par service. Exemple, j’ai mis plein de contrôles de « services publics », à savoir la réponse d’un FTP distant, la présence d’un serveur web distant, la réponse spécifique (recherche d’un mot dans un page web reçue) etc. J’estime que tout ça représente un ensemble, mes « services publics dont j’aimerais être sûr qu’ils sont bien online à tout moment sinon on perd nos clients ».
Je vais donc définir un « groupe de service » (servicegroup) rassemblant des couples (machine , service).

Plus précisemment, il s’agit de lister des couples (host_name d’un host , service_description d’un service).
Petit exemple :

define servicegroup {
        servicegroup_name       public-services
        alias                   Services Internet
        members                 srvweb,Check URL non signee,ftpext,Check FTP ; les fameux couples host/service
}

Je suppose ici que les define host « srvweb » et « ftpext » sont définis, ainsi que les define service « Check FTP » et « Check URL non signee » ; ces exemples seront donnés plus bas dans cette doc.
Pour les services, il s’agit bien de leur description longue, pas de leur nom.
Ainsi, dans le menu « servicegroup overview », vous verrez un groupe « Services Internet » vous donnant d’un coup d’oeil l’état de tous vos services publics/web.

Contrôle de services Windows

Exemple pour un serveur Exchange ou pour une base Oracle, je veux être sûr que tous les services associés sont en cours d’exécution.
Bon cette fois, je passe sur les groupes de machines Oracle qu’on pourrait créer. Là le but est d’appréhender le contrôle de services Windows via NSClient++.

Exemple avec Exchange

Si je vous suggère de tester la commande suivante, vous allez vite comprendre :

srvnagw:/usr/lib/nagios/plugins# ./check_nt -H mon_serveur_exchange -p 12489 -v SERVICESTATE -d SHOWALL -l MSExchangeIS,MSExchangeMTA,SMTPSVC,RESvc,W3SVC

La liste des noms technique des services s’obtient en double-cliquant sur le nom d’un service Windows, dans ses propriétés.
Reste à définir le service et la commande qui va bien et à l’affecter à votre serveur ou votre groupe de serveurs Exchange.
Voir plus bas mes exemples si vous êtes paumés.

Ce qui est bien avec cet agent NSClient++, c’est que ça marche pour n’importe quel service. Ci-dessous, on découvre que ça marche aussi pour perfmon .

Exemple avec l’anti-virus Sophos, remarque sur la syntaxe

Attention, certains services ont des espaces dans leur nom.

• Pour les nommer/utiliser en ligne de commande, il faut un backslash \
• Pour les nommer/utiliser depuis Nagios, il faut 2 backslash \

Exemple :

define service {
        use generic-service
        hostgroup_name          sophos-servers
        service_description     Svc SOPHOS server
        check_command           check_nt!SERVICESTATE!-d SHOWALL -l Sophos\\ Agent,Sophos\\ Certification\\ Manager,Sophos\\ EMLibUpdate\\ Agent,Sophos\\ Enterprise\\ Manager\\ Scheduler,Sophos\\ Management\\ Service,Sophos\\ Message\\ Router
}

Pour tester ce check_nt en ligne de commande, un seul \ suffirait.

Exemple de surveillance des services Oracle

Ben c’est la même chose, un gros check_nt!SERVICESTATE!-d SHOWALL -l blabla où « blabla » est la liste de noms de noms instances Oracle, du listener etc.

Contrôle de perfmon

Dans la lignée de ce qui précède, si vous voulez surveiller des indicateurs perfmon de serveurs Windows, c’est jouable.
Notez que perfmon permettant de surveiller à peu près n’importe quoi sur Windows (charge réseau par exemple), ce test peut être une variante d’un test de charge via SNMP ; en ce qui concerne la charge réseau. Pour d’autres indicateurs de perfmon, il n’y a que NSClient++ je suppose, ou un script dédié.
Notamment, vous pouvez contrôler la taille des files d’attente du serveur Exchange monitoré précédemment.
Je ne m’étends pas, mais il faut appeler check_nt avec « -v COUNTER » et le nom des indicateurs que l’on veut suivre.

Contrôle de switchs

Les informations sont décrites là : http://nagios.sourceforge.net/docs/3_0/monitoring-routers.html.
Il faut être un peu habitué à SNMP, ou alors c’est l’occasion de s’y mettre. Il faut savoir activer le SNMP sur un switch et connaître quelques OIDs.
Ceci dit attention, vous pourrez tester l’état de certains ports, l’uptime d’un switch. Mais pour contrôler la bande passante du trafic d’un port, il n’y a pas d’OID. Il faudra écrire votre script vous-même ou alors, interfacer avec Cacti qui lui stocke l’historique des informations de compteurs de trafic, permettant ainsi de calculer des vitesses moyennes. Je suis dessus là, donc j’en parlerai sûrement de ce ces 4.
Le principe est le suivant :

• Il faut activer le « requêtage » SNMP sur le routeur en question, définir une « communauté » (si autre que « public »), un éventuel mot de passe (si SNMP v3)
• S’inspirer ensuite du modèle de conf générique des switchs dispo ici : /usr/share/doc/nagios3-common/examples/template-object/switch.cfg
• Reprendre le template generic-switch (et uniquement lui) de /usr/share/doc/nagios3-common/examples/template-object/templates.cfg.gz
• Lire http://fr.wikipedia.org/wiki/Snmp
• Lire http://doc.ubuntu-fr.org/snmp pour comprendre rapidement les MIB
• Tester en ligne de commande pure d’abord, avec check_snmp

Pour activer le SNMP sur un 3com type 4400, l’attaquer en telnet (menu system management snmp community) car ce n’est pas accessible en interface web. Pour un netgear, c’est gérable par l’interface web du switch (ou alors ça dépend de la version du firmware, j’ai déjà vu ça aussi). On peut limiter à une interface IP, par exemple le serveur Nagios exécutant la requête.

Appel à un script tiers, sous Windows : contrôle des patchs en attente

Truc très pratique, au lieu d’aller voir dans WSUS-qui-rame-et-qui-est-à-moitié-pratique.
On va utiliser NRPE, un agent qui tournera localement sur la machine distante et qui permettra d’exécuter des scripts. Ca tombe bien NSClient++ peut assurer ce rôle, du moment qu’on a décommenter NRPEListener.dll, voir plus haut dans la doc.
Nagios appellera donc NRPE qui appellera un script (ici un .wsf). Au niveau des alertes NAgios, on obtiendra des « warnings » et « critical » suivant la nature des patchs.
J’utilise le script suivant (ou celui là, je ne sais plus, essayez les deux).
Placez les par exemple sur C:\ du serveur à monitorer.

Conf NRPE pour patchs Windows

Dans la section [NRPE] du fichier NSC.ini d’un serveur à monitorer, j’ai dû paramétrer les choses suivantes :

;# COMMAND ARGUMENT PROCESSING
;  This option determines whether or not the NRPE daemon will allow clients to specify arguments to commands that are executed.
allow_arguments=1

;  This option determines whether or not the NRPE daemon will allow clients to specify nasty (as in |`&><'"\[]{}) characters in arguments.
allow_nasty_meta_chars=1

allowed_hosts=192.mon.nag.ios

Et dans la section [NRPE Handlers], comprenez "les commandes autorisées via NRPE", j'ai simplement créé une commande appelée (au niveau de NSClient/NRPE) "windows_updates" :

command[windows_updates]=c:\\windows\\system32\\cscript.exe //NoLogo //T:120 c:\\check_windows_updates.wsf /w:0 /c:1
;# RESTE du blabla pour que vous situiez l'endroit
;# COMMAND DEFINITIONS
;# Command definitions that this daemon will run.
;# Can be either NRPE syntax:
;command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10

Attention aux doubles backslashs/slashs etc.
Rechargez le service NSClient++.
Je suppose que le port par défaut (5666) est accessible depuis NAgios vers votre serveur.

Conf Nagios pour patchs Windows

Si tous vos serveurs Windows sont équipés du script et que la conf NRPE dans NSClient++ est bonne pour chacun, vous pouvez ajouter quelque part dans /etc/nagios3/conf.d/ ce bout de code :

define service{
        hostgroup_name          windows-servers
        use                     generic-service
        service_description     Windows Update
        check_command           check_nrpe_1arg!windows_updates
}

Si vous n'avez qu'une machine (pour tester), pensez à utiliser host_name toto au lieu de hostgroup_name.

Ensuite, on va définir un test Nagios qui appelle la commande "windows_updates" via NRPE. Le nom windows_updates est bien celui reprit dans la conf NSC.ini, section [NRPE Handlers].
Après quelques tests, j'ai dû recréer mon propre passage d'argument à check_nrpe, script qui d'ailleurs vient normalement avec les plugins de Nagios. Voyez :

monnagios:/etc/nagios-plugins/config# cat check_nrpe.cfg
# this command runs a program $ARG1$ with arguments $ARG2$
define command {
        command_name    check_nrpe
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
}

# this command runs a program $ARG1$ with no arguments
define command {
        command_name    check_nrpe_1arg
#JACQUES
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -t 60
        #command_line   /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

Notamment en ajoutant un timeout (-t) plus long et en supprimant le 2è argument.
Comme d'habitude, pour inventer cela, il faut jouer avec la commande /usr/lib/nagios/plugins/check_nrpe directement. Et commencer par jouer localement avec le script .wsf (sur la machine Windows, donc), histoire de vérifier que tout va bien et de débugger pas à pas votre bazar (script mal placé, NRPE mal configuré, Nagios mal paramétré pour ce test etc).

Voilà, normalement ce test fonctionne aussi.

Trucs en vrac

Par manque de temps et impossibilité de faire un guide "complet", je note 2/3 idées en vrac :

Attention après un /etc/init.d/nagios3 reload : temps de latence (tests en pending) et lorsqu'un test échoue, il est replanifié pour X minutes plus tard. On peut forcer sa réexécution, mais il faut y aller mollo et ne pas être trop impatient.

Il reste tant à dire : la dépendance entre services, la carte des machines, les prévisions de downtime de machines (pour éviter les mails et alertes inutiles), la fréquence des tests.
Mais là, maintenant que vous avez la base, vous allez pouvoir facilement lire n'importe quelle doc (je veux dire, même celles où très peu de choses sont expliquées) pour peaufiner votre installation. J'espère.

A+

(enfin c'est publié, youhou.... ; j'espère que le tout reste cohérent et utile vu que ça a été écrit en plein de fois et à différents moments de mon apprentissage Nagios)

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).

Port knocking :
- tant que votre poste client n’a pas fait une bonne séquence au guichetier (knock-daemon , tel ou tel service est bloqué pour votre IP, via iptables.
- à la fin, vous jouez une séquence pour fermer, ou pas.

Bon j’avoue, je n’ai pas testé. M’enfin, ça doit marcher tout ça. A voir, comme avec le genre fail2ban, si ça ne peut pas être utilisé pour provoquer des dénis de service – le genre je fais bannir/fermer telle IP que je ne suis pas, évidemment.

Ca + du changement de port sur certains services (SSH notamment), et votre machine devrait être une tombe, normalement. Reste les services publics (http…) pour chercher une faille.

(et puis si vous adorez mon site, ce dont je ne doute pas, voici mon flux – façon de parler ; mais je doute que vous aviez besoin de mon aide pour le trouver)

Bonnes vacances

Je vous décris la manip en tenant compte du bug Microsoft qui va avec (ou de la feature de sécurité, appelez ça comme vous voulez).
Le bug est le suivant : impossible d’accéder à un partage (fichier ou imprimante) en utilisant un alias (CNAME) d’une machine sur Windows serveur (au moins 2000 et 2003).

Voici comment faire.

Sur votre DNS, créez le CNAME qui pointe de mon_serveur_d_impression et rechargez-le.
Testez, ça ne marche pas : net view vraisrv1 affiche les partages et net view mon_serveur_d_impression n’affiche rien et crie au scandale avec un message complètement inapproprié :

C:\>net view mon_serveur_d_impression
L'erreur système 52 s'est produite.

Vous n'étiez pas connecté car il y avait un nom en double sur le réseau. Allez dans Système dans le Panneau de configuration et modifiez le nom de l'ordinateur et essayez à nouveau.

Appliquez donc la correction décrite ici : http://support.microsoft.com/?kbid=281308, à savoir, ajoutez une clef « DisableStrictNameChecking » à valeur 1 dans la base de registre, à l’emplacement « HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters ». A faire sur le serveur « vraisrv1″, celui pour lequel on veut créer un alias.
Redémarrez le service « Serveur » (correspondant à LanmanServer) – ça, c’est pas dit dans la doc Microsoft – ou, plus simplement redémarrez le serveur. Car le service « Serveur » est central et il y a pas mal de dépendances.

Ensuite, le net view mon_serveur_d_impression fonctionnera, ou, plus simplement, le « Démarrer -> Exécuter -> \\mon_serveur_d_impression »

Avec un nom comme « DisableStrictNameChecking », on pourrait presque croire que c’est un paramètre de sécurité…. ils sont forts au marketting Windows. Je vois d’ici le transparent Powerpoint lors d’une grand-messe : « nous avons permis un paramètre laxiste pour permettre de ne plus contrôler le nom réel du serveur ». Traduction : « on a corrigé un bug bien moisi qu’on trouvé des admins sachant gérer un DNS et ayant compris à quoi ça sert ».

    Bonjour à tous,

    Suite à une demande récurrente, et visiblement partagée par un certain nombre d'organisme, nous créons une nouvelle catégorie : "social_networks".

    Elle permettra de filtrer plus spécifiquement les sites de réseaux sociaux, en ne les incluant pas dans des catégories finalement inadaptées.

    Nous essayerons, tant que faire ce peut, de sortir les sites complets des autres catégories (par exemple facebook de la catégorie blog).

    Cordialement 

FIN

Pour faire suite à l’article sur la mise en place de Privoxy pour faire sauter les pubs dans toute votre société (ou chez vous sur votre petit réseau local), voici un complément : le filtre d’URL par catégorie.

J’ai eu l’occasion de jouer avec SquidGuard à travers un serveur IPCOP mis en place par mes soins dans l’école primaire de mon village, avec la bénédiction du Ministère de l’Education. Ca marche pas mal, il faut avouer. N’ayant pas de moyen, une école optera certainement pour des listes de filtrages gratuites. Si une seule était à retenir, ce serait celle de l’Université de Toulouse.

Deux objectifs possibles :

• éviter les abus en entreprises :sites sociaux à la facebook, vidéos à gogos, porno et autres contre-productivités sur le clavier etc…
• filtrer les sites pour vos enfants (lisez ça aussi, ça donnera d’autres pistes)

Mise en place sur Debian

Installation et docs de base

Contrairement à pas mal d’outils sous Debian, l’installation ne fait rien en soit, elle amène simplement de l’outillage et la plus grosse part est après.
Commencez par installer le logiciel, via un classique aptitude install squidguard.
Evidemment, votre squid est déjà en place et fonctionnel.

Pensez à lire le fichier /usr/share/doc/squidguard/README.Debian ; c’est d’ailleurs une règle générale après une installation de paquet Debian, mais surtout pour SquidGuard qui, après l’installation, ne fait rien tout seul.

Principes de fonctionnement

Je décris le principe avant de foncer la tête dans le guidon.

SquidGuard est simplement une sorte d’extension à base de scripts et d’ACL Squid pour filtrer des URL en se basant sur des domaines et des expressions régulières d’URL
Lui même n’apporte aucun niveau de filtrage et il faudra aller chercher une liste à jour de sites. C’est là toute la difficulté.
J’arrête tout de suite ceux qui pensent bloquer facebook.com en écrivant une ACL bidon genre deny blabla facebook.com dans Squid. Entre les sites genre how-to-un-unblock-facebook.com et les « redirectors » genre proxies anonymes, ce sera impossible. D’où l’aide de listes, payantes ou non, robotisées ou non, mises à jour régulièrement ou non.
Soit vous payez une liste type urlblacklist.com, soit vous optez pour une gratuite, mais néanmoins efficace, comme celle de l’Université de Toulouse, cf. plus haut. Sinon, allez voir là – je n’ai pas testé les 2 premiers liens.

La README évoqué ci-dessus parle d’un paquet « chastity-list », apt-cache search chastity n’ayant rien donné, je n’ai pas cherché plus loin.

Une fois la liste choisie, vous obtiendrez généralement des fichiers textes, classés par catégories. Il faut les transformer en base de données type Berkeley-machin (fichiers .db) pour qu’ils soient efficaces en mémoire.
Ce sera évidemment à scripter automatiquement toutes les nuits (nouvelles listes => nouveaux .db => rechargement de Squid).
A noter que les fichiers .db seront générés par SquidGuard uniquement lorsqu’il verra que vous utilisez telle ou telle catégorie dans /etc/squid/squidGuard.conf. SquidGuard n’ira pas compiler les bases inutilisées (ce qui prend du temps sur des grosses listes, genre « adult » (=porno))

Enfin, vous ajouterez les catégories qui vous intéressent en ayant pris soin de créer une belle page qui indique à l’utilisateur pourquoi tel site est bloqué (je suis sympa, je vous fournis un tel script minimaliste ; en gros une correction de celui fourni dans le package SquidGuard qui est passablement foireux)

Je ne parle pas des aspects communication en entreprise : filtrer les sites aura sûrement un impact important sur le moral des troupes, fonction du gain de bande passante, fonction de la productivité

Mise en place pratique

J’illustre la suite par le blocage de la catégorie « hacking », où l’on pourra tester par exemple www.warez.com, à partir des listes de l’Université de Toulouse

Récupération de la liste de l’Université de Toulouse

La base : récupérez soit une catégorie, soit la totalité (je pars sur cette option). Voyez l’explication de chaque catégorie ici.

mkdir /root/squidguard
cd /root/squidguard
wget ftp://ftp.univ-tlse1.fr/blacklist/blacklists.tar.gz
tar xzvf blacklists.tar.gz
mv blacklists/* /var/lib/squidguard/db/
chown -R  proxy:proxy /var/lib/squidguard/db/

Choix d’une catégorie

Dans /etc/squid/squidGuard.conf, on va toucher le minimum. Ajoutez n’importe où :

dest hacking {
   domainlist hacking/domains
   urllist hacking/
   log guard_hacking.log
}

Pour savoir si une catégorie contient des « domaines », des « URL » ou des « expressions », allez voir dans /var/lib/squidguard/db/la_categorie/. En effet, seules quelques catégories ont des « expressions », il s’agit avant tout des catégories de pubs. Je considère que privoxy est là pour ça. Donc je n’ajoute pas expression hacking/expressions (même pas sûr de la syntaxe). Pour m’assurer que les « expressions » sont utilisées uniquement pour la pub, j’ai fait ça et vu des fichiers de taille 0 ou non-existant pour la plupart des catégories :

srv:/var/lib/squidguard/db# ls -l */expres*
-rwxr-xr-x 1 proxy proxy  57 2006-05-10 07:47 ads/expressions
-rw-r--r-- 1 proxy proxy   0 2005-10-18 16:51 adult/expressions
-rw-r----- 1 proxy proxy   0 2002-11-06 14:08 aggressive/expressions
-rw-r----- 1 proxy proxy   0 2002-11-06 14:08 agressif/expressions
-rw-r--r-- 1 proxy proxy   0 1999-03-04 08:07 forums/expressions
-rw-r--r-- 1 proxy proxy   0 1999-03-04 08:07 mail/expressions
-rw-r--r-- 1 proxy proxy  42 2009-03-19 10:42 malware/expression
-rw-r--r-- 1 proxy proxy  47 2009-03-20 13:30 malware/expressions
-rw-r--r-- 1 proxy proxy   0 2005-10-18 16:51 porn/expressions
-rw-r--r-- 1 proxy proxy   0 1999-10-06 17:37 proxy/expressions
-rwxr-xr-x 1 proxy proxy  57 2006-05-10 07:47 publicite/expressions
-rw-r--r-- 1 proxy proxy   0 1999-10-06 17:37 redirector/expressions
-rw-r--r-- 1 proxy proxy 123 2005-06-14 21:33 strict_redirector/expressions
-rw-r--r-- 1 proxy proxy 505 2006-05-23 22:05 strong_redirector/expressions
-rw-r----- 1 proxy proxy   0 2002-11-06 14:08 violence/expressions
-rw-r--r-- 1 proxy proxy   0 1999-04-19 14:04 warez/expressions

Ensuite, on indique à SquidGuard (donc à Squid) comment réagir pour cette catégorie. Modifier la section acl {} du fichier /etc/squid/squidGuard.conf pour qu’il y ait ça (gardez ou non la palanquée de lignes de commentaires) :

acl {
   default {
      pass !hacking all
      redirect http://srv/cgi-bin/squidGuard-simple.cgi?clientaddr=%a&srcclass=%s&targetclass=%t&url=%u
   }
}

Si vous voulez bloquer plusieurs catégories, ce sera à base de pass !hacking !adult !blabla all.
Notez dans la section acl {} l’adresse de redirection utilisée : une page spéciale hébergée sur le serveur, nommée squidGuard-simple.cgi. Il faut maintenant la mettre en place.
A noter aussi, il me semble que de base, la ligne « redirect » contient des « + » à la place des « & » pour passer les arguments. J’ai pas bien pigé, j’ai toujours vu des « & » et avec les « + », ça ne marchait pas.

Redirection vers une page spéciale

• Attention, j’ai ouï dire que si le script n’était pas là, ça passait silencieusement et la requête aboutissait malgré la demande de blocage. Je n’ai pas testé, j’ai surtout testé une URL de chaque catégorie que je suis censé bloqué.
• Je considère que votre site web est configuré pour que /cgi-bin/ soit en un « Alias » de « /usr/lib/cgi-bin/ », c’est en général défini dans la configuration par défaut d’Apache2 et vous pouvez vous en assurer rapidement avec cette commande grep cgi-bin /etc/apache2/sites-enabled/* pour voir si ça répond – en gros.
• La liste des variables que l’on peut passer au script de redirection est donnée dans la doc HTML, /usr/share/doc/squidguard/CONFIGURATION.html

Deux scripts sont fournis par le mainteneur du paquet Debian pour nous donner une trame pour l’écriture du script de redirection – le script qui dira « accès bloqué blabla, si vous pensez que c’est une erreur, contactez l’administrateur blabla ». Ils sont là :

srv:/var/lib/squidguard/db# dpkg -S squidGuard*.cgi
squidguard: /usr/share/doc/squidguard/examples/squidGuard.cgi.gz
squidguard: /usr/share/doc/squidguard/examples/squidGuard-simple.cgi.gz

Le premier est apparement plus complet, prévu pour du multi-langues etc, mais récupère comme un pied les variables qu’on lui passe. J’ai opté pour l’autre car rapidement, j’ai pu mettre en place une page qui indiquait clairement et simplement le site bloqué, la catégorie, l’IP du demandeur et donnait le mail de contact de l’administrateur.
Donc soit vous optez pour ces scripts, soit pour le mien fourni ici, basé sur le 2è script, traduit en français et épuré de certains trucs inutiles. Voyez :

On est fin prêt pour un test grandeur nature.

Relance de Squid via la compilation des listes de blocage

Lancez la commande /usr/sbin/update-squidguard pour contrôler les droits sur les fichiers de /var/lib/squidguard/db/ et générer les .db.
Attention, sur la liste « adult » (environ 1 million de domaines), ça peut prendre quelques minutes.
Ce script recharge Squid.
Testez un site de la catégorie « hacking », exemple www.warez.com

Script de mise à jour automatiques des listes

Voici un script que j’ai mis en crontab pour automatiser la récupération de la liste de l’Université de Toulouse (si mise à jour), la mise à jour qui va bien, création de .db et relance de Squid.

srv:~# cat /root/squidguard/update_toulouse.sh
#!/bin/sh
cd /root/squidguard
wget -N ftp://ftp.univ-tlse1.fr/blacklist/blacklists.tar.gz
rm -rf blacklists
rm -rf /var/lib/squidguard/db/*
tar -xzvf blacklists.tar.gz
# proprio et perm fixées de toute manière par update-squidguard
chown -R proxy:proxy blacklists
mv blacklists/* /var/lib/squidguard/db/
/usr/sbin/update-squidguard
# A priori, si le site est down ou connx internet HS, on reutilisera le .tar.gz actuel
# donc pas de risque de se retrouver avec une base vide

Mettez les droits d’exécution via chmod u+x /root/squidguard/update_toulouse.sh et collez ça dans la crontab :

0 3 * * 1-5     root    /root/squidguard/update_toulouse.sh

Ca devrait rouler !

Divers

Log des accès interdits

J’ai passé sous silence la ligne « log guard_hacking.log ». Elle est optionnelle et permet de garder ou non une trace des accès interdit, par catégorie. A voir, vie privée des gens, tout ça. J’ai choisi de la nommer quelque_chose.log car ce fichier ira directement dans /var/log/squid/ et sera donc « logrotaté » naturellement comme tous les logs Squid, via ce qu’on trouve en standard dans le logrotate de Squid, /etc/logrotate.d/squid, à savoir : /var/log/squid/*.log
Vu ?

Plages horaires

Vous noterez que la conf simpliste ici peut être étoffée, dans le fichier /etc/squid
/squidGuard.conf, vous avez tous les commentaires nécessaires, notamment pour faire du [dé]blocage par plages horaires.

D’autres compléments pour Squid ?

Après Privoxy, il faudrait un 3è article maintenant sur HAVP. Je vais y penser éventuellement.

Générer la conf pour toutes les catégories

Ne réutilisez pas le résultat brutalement, vous bloqueriez même Google, car il est listé dans ce qui ressemble plus à une whiteliste propre à l’Université de Toulouse, la catégorie « liste_bu ».
Afin d’obtenir la liste complète des déclarations de catégories pour squidGuard.conf, vous pouvez utiliser celà :

srv:/var/lib/squidguard/db# for i in `find . -maxdepth 1 -type d|awk -F'/' '{print $2}' | sort`
do
	echo -e dest $i {
	echo -e \\t"domainlist $i/domains"
	echo -e \\t"urllist $i/urls"
	echo -e \\t"log guard_$i.log"
	echo }
done

La conf de base de calamaris fonctionne bien (encore qu’il ne faut pas avoir trop modifié le format de ses logs Squid). Cependant, il y a une option intéressante documentée dans /usr/share/doc/calamaris/README.Debian, qui permet de générer des graphiques associés aux reportings tableaux.
La doc dit de penser à installer le paquet libgd-graph-perl.
Ce qu’elle ne dit pas, c’est de corriger un bug connu, décrit ici, pour lequel un patch est proposé et corrige effectivement le problème.

Le symptome du bug est le suivant :

bla:# /etc/cron.daily/calamaris
Use of uninitialized value in concatenation (.) or string at /usr/bin/calamaris line 4083, <> line 22053.
Use of uninitialized value in concatenation (.) or string at /usr/bin/calamaris line 4115, <> line 22053.
Use of uninitialized value in concatenation (.) or string at /usr/bin/calamaris line 4115, <> line 22053.
Can't call method "png" on an undefined value at /usr/bin/calamaris line 4128, <> line 22053.

En attendant mieux… car le développeur de calamaris semble avoir d’autres chats à fouetter

Pour appliquer la correction, téléchargez le patch et appliquez-le :

cp -a /usr/bin/calamaris /usr/bin/calamaris.orig
patch calamaris /your/downloaded/calamaris.patch

Et voilà :

Let’s go
En relisant l’article, je vois que c’était vraiment vulgarisé pour être accessible au plus grand nombre, pardonnez donc les imprécisions techniques et le baratin simplifié – MERCI

–

J’ai écrit ce document pour 2 raisons. La première est que j’en ai marre d’expliquer sans cesse à mes amis cette méthode, la deuxième est que c’est vraiment une méthode très pratique, puissante et qui n’a que quelques limitations (et encore – voir chapitre à venir : VPN sur SSH).

1. Avez-vous besoin de SSH au boulot ?

Vous êtes 8h par jour au boulot et le proxy chargé de la sécurité de l’entreprise se charge surtout de vous bloquer quelques sites web et quelques protocoles réseaux à priori non professionnels. En gros, il vous emmerde à longueur de temps et vous aimeriez pouvoir faire les choses suivantes depuis votre boulot :

• Lire vos mails en POP, IMAP (par un client mail classique plutôt que via le web et l’interface nullissime de votre fournisseur).
• Utiliser Jabber, ICQ, MSN (ou autre protocole) depuis le boulot pour pouvoir rester en contact avec belle-maman.
• Prendre le contrôle à distance (VNC, pcAnywhere etc) de votre PC perso avec sa ligne ADSL pour faire je ne sais quoi. D’autant plus que des outils comme VNC ne gèrent tout simplement PAS les proxys.
• Suivre les résultats du football ou consulter un site d’actualités – en général le proxy bloque largement les sites foot, jeux, facebook et bien d’autres.
• et plein d’autres choses encore…

Dans ce document, je présenterai le concept ainsi que la mise en oeuvre de la solution (sous Linux ou Windows).

2. Principe général

SSH est un outil qui permet de se connecter à une machine distante en mode texte. Sous Linux, on accède à un shell, sous Windows, on pourra voir ça comme l’accès à une fenêtre DOS, à priori pas très utile, certes. Ca ressemble donc de loin à une connexion telnet, sauf que c’est laaaaargement plus sécurisé (je n’en débattrai par ici mais vous pouvez me croire sur parole) et beaucoup plus puissant.
SSH permet notamment de faire du transfert de fichiers (SFTP) et surtout, des tunnels de communication, dans les deux sens (vous comprendrez plus tard). Un tunnel va servir à encapsuler (capturer) des flux réseaux entre le SSH client (votre PC en entreprise avec accès web restreints qu’on veut contourner) et votre serveur SSH (votre PC à la maison avec ADSL branché 24/24).

Tout se résume à ça : le client SSH établit une connexion avec le serveur SSH à travers le proxy en utilisant une connexion autorisée par le proxy (méthode CONNECT vers un port autorisé). Ensuite, grâce à ça, des tunnels vous permettront de faire passer presque n’importe quoi à travers le proxy (voir chapitre 4 sur les limitations de ce système).

Le client SSH que j’utilise est putty (premier lien sur google), c’est un client libre, gratuit etc, qui permet de faire du telnet, du ssh et surtout d’utiliser les fonctionnalités de ssh, les tunnels par exemple. Il sait aussi se connecter à travers un proxy.

3. Mise en place

3.1. Côté serveur SSH

Chez vous, il faut d’abord installer un serveur SSH.

3.1.1. Installation

Sous Linux, vous trouverez forcemment un paquet correspondant à votre distribution. Exemple sous Debian, tapez « apt-get install ssh » et ça devrait le faire.

Sous Windows, c’est moins simple. Je ne connais pas d’implémentation libre directement fonctionnelle sous Windows. Et comme vous n’allez quand même pas payer la version payante de www.ssh.com, vous devrez utiliser www.cygwin.com pour installer un « environnement Linux dans votre Windows ». Cet environnement comprend ensuite la plupart des outils Linux, dont OpenSSH bien sûr. Deux options (au moins) s’offrent à vous :

• Installer cygwin de manière classique avec ce qu’il faut, notamment le paquet ssh (il vous faudra lire un peu de doc à priori).
• Utiliser le projet sshwindows qui propose un programme d’installation global comprenant un cygwin minimaliste et sshd associé. Je n’ai pas testé personnellement cette solution.

Présentation barbare de l’installation de cygwin : dans les grandes lignes, vous téléchargez le setup.exe puis vous choisissez un miroir de téléchargement, vous installez le minimum vital (par défaut je crois) et vérifiez bien que le paquet ssh est inclus. Au final, vous obtenez une sorte de raccourci façon « fenêtre DOS », sauf que vous êtes dans un environnement Linux et disposez de sa panoplie d’outils en ligne de commande et même graphique si vous cherchez bien (pour peu que vous ayez installé les paquets qu’il faut).

3.1.2. Génération des clefs

Si vous ne connaissez pas le principe d’authentification par clefs de SSH, sachez juste que vous devez générer une paire de clefs cryptées utilisées pour la communication entre le serveur et les clients. Même si dans ce document je ne vais pas détailler l’authentification par clefs, mais juste par mot de passe, cette paire de clefs est nécessaire pour l’identification du serveur et pour les premières étapes de l’établissement de la connexion (par mot de passe).
Si vous avez installé SSH sous Debian, le programme d’installation génère automatiquiment les clefs, pour les solutions, je ne sais pas. Sous cygwin par exemple, vous devrez donc générer ces clefs via la commande « ssh-keygen -t dsa ». Vous pourrez voir ces clefs dans « /etc/ssh », les fichiers sont ssh_host_dsa_key*.

3.1.3. Etape supplémentaire pour Cygwin

Un détail sous cygwin (encoooooore), il faut que vous lisiez les docs pour savoir comment lancer le serveur SSH en tant que service Windows plutôt qu’à la main le matin en partant au boulot… (cherchez des infos sur le programme cygrunsrv.exe). Pour la version « packagée » par le projet sshwindows, je ne sais pas, lisez la doc.

Sous Linux, ce sera forcemment fait automatiquement.

3.1.4. Changement du port du serveur SSH

SSH tourne sur le port 22 par défaut et vous pouvez être quasimment sûr que le proxy du boulot bloque ce port. Donc vous ne pourrez pas atteindre votre serveur depuis chez vous. Ajoutez donc dans le fichier de configuration de sshd (/etc/ssh/sshd_config) une ligne « Port 443 » après la ligne « Port 22 » ou remplacez cette dernière. Redémarrez le service. On choisit le port 443 car c’est le port https par défaut et le proxy du boulot tolèrera forcemment ce port (au pire, prenez le port 80, http). De plus, https et SSH présentent des similitudes (la couche SSL) et donc utiliser le port 443 a l’avantage d’être plus discret (voir chapitre 4.2.).
Si votre firewall le tolère, vous pouvez aussi faire un forward du port 443 vers le 22 en ne laissant que la ligne « Port 22 » dans sshd_config.

3.1.5. Votre firewall

Enfin, vous avez certainement chez vous un firewall, n’oubliez pas d’ouvrir le port 443 ou 22 (voir chapitre précédent).
Vous avez très probablement aussi une adresse IP dynamique et donc il faut que vous vous trouviez un nom de domaine (essayez www.dyndns.org, ils ont un service gratuit et vous aurez un nom du style chezmoi.dyndns.org mis à jour à chaque reconnexion de votre ADSL). Sinon, vous devrez récupérer votre adresse IP tous les matins et priez pour que l’ADSL ne tombe pas auquel cas vous risqueriez de changer d’IP.

Je suppose maintenant que votre serveur est lancé, accessible depuis l’extérieur et qu’il fonctionne correctement.

3.2. Côté client SSH

3.2.1. Récupération des paramètres proxy

Pour les utilisateurs d’Internet Explorer, allez dans Outils -> Options Internet -> Connexions -> Paramètres réseaux. Vous aurez 2 possibilités, soit l’adresse et le port sont directement écrit :

Soit votre entreprise utilise un script d’autoconfiguration :

Dans ce dernier cas, téléchargez ce script en recopiant l’adresse dans votre navigateur. Ouvrez-le, c’est un fichier texte. C’est simple à comprendre et en général, les dernières lignes vous donnent le proxy qui permet d’atteindre les sites extérieurs (Internet). La fin ressemble à quelque chose comme « PROXY host:port ».

Si vous utilisez un autre navigateur (je l’espère pour vous , vous saurez sûrement où trouver ces informations.

3.2.2. Installation de putty (client SSH)

Téléchargez putty. Il n’y a pas d’installation, pas besoin d’être admin de son poste. Vous n’avez besoin que de putty.exe sinon prenez le zip qui contient tous les binaires. Le paramétrage se fait comme suit :

Vous saisissez dans le menu « Session » l’adresse du PC chez vous (IP ou DNS), précisez le protocole SSH et modifiez le port où tourne le serveur SSH (443 à priori – voir chapitres précédents).

Dans le menu « Connection », activez l’envoi de paquets vides réguliers, toutes les 10 secondes par exemple. La connexion SSH se faisant via la méthode CONNECT (comme pour du https), le proxy risque fort de la couper régulièrement si aucun trafic n’est généré.

Dans le menu « Proxy », vous indiquez le type de proxy, à priori HTTP, son adresse, son port et l’utilisateur/mot de passe si besoin. La ligne « telnet command » représente en gros le début de la communication entre putty et le proxy pour permettre la connexion au serveur distant (le PC chez vous). Tentez la ligne suivante : « connect %host %port HTTP/1.1\nHost: %host » si la ligne par défaut ne fonctionne pas.

Enfin, dans le menu « SSH », vous précisez que vous utilisez le protocole en version 2 et activez la compression – c’est toujours ça de gagné.

Retournez dans le menu « Session », donnez un nom à votre session et faites « Save » à nouveau. Puis « Open ».

3.2.3. Le moment de vérité

Faites « Open », si tout va bien, vous obtiendrez un écran du genre :

Connectez vous et ça roule. Dans les autres cas, vérifiez bien les informations saisies et éventuellement changez le type de proxy. Parmi les 25 entreprises que j’ai pu visiter (grandes multinationales comprises), seules 2 ont refusé cette connexion, la première car le proxy était un logiciel merdico-archaïque de Microsoft qui avait déjà du mal à fonctionner normalement avec IE, la deuxième car le proxy était buggé et avait l’air de ne pas respecter le protocole « normal » entre putty et le serveur ssh (d’après les traces que j’ai analysées, le serveur SSH était atteint puis tout partait n’importe comment).

A ce niveau là, si la connexion est établie et que vous pouvez accéder à votre machine, c’est banco, vous pourrez « tuyauter » n’importe quoi via SSH

3.3. Les tunnels

3.3.1. Créer un port mapping

Dans le menu « Tunnels », créez un tunnel vers vos serveurs de messagerie (ATTENTION, lisez le chapitre 4.1.3 à propos du forward de messagerie) :

Cette fois-ci, lorsque la fenêtre putty sera ouverte et que vous serez signé sur le serveur SSH, il y aura eu création d’un port mapping du port local 10110 du poste client vers le port 110 du serveur POP de votre provider (le tout via le relai SSH . Idem pour les ports 10025/smtp:25. J’ai choisi des numéros de ports locaux (10110 et 10025) différents des vrais ports notamment pour la compréhension. Rien (ou presque) ne vous empêcherait de mapper les port 25 et 110 vers les ports 25 et 110 des serveurs POP et SMTP de monprovider.com.

Ca veut dire que si un programme de messagerie (mozilla, thunderbird, outlook express, lotus notes etc) s’adresse à votre propre machine (localhost) sur le port 10025, c’est bien le serveur SMTP de monprovider.com:25 qui répondra. Idem pour le port 10110/110, c’est le serveur POP qui répondra. A partir de là, configurez votre client mail en indiquant que les serveurs POP et SMTP de monprovider.com sont respectivement localhost (sur port 10110) et localhost (sur port 10025).
Lorsque le client mail fera une requête, c’est putty qui interceptera la communication et dira au serveur d’effectuer la requête à partir de l’autre bout du tunnel vers le serveur:port précisé. Et voilà ! (j’espère que c’est clair

Attention : vérifiez bien que votre client mail n’utilise aucun proxy pour les connexions locales ! (exemple : « outlook express » utilise la configuration de IE, veillez bien à cocher dans IE la case qui précise de ne « pas utiliser de proxy pour les connexions locales », ça devrait être fait par défaut).

Avec un beau schéma, ça donne ça :

Maintenant que vous savez faire ça, vous pouvez mapper n’importe quoi et vous coimprendrez rapidement que le port mapping n’est pas la solution pour tous les problèmes. Exemple, si vous voulez faire de l’IRC, le serveur que vous joindrez ne sera pas toujours le même suivant les réseaux que vous voulez utiliser.

3.3.2. Tunnel dynamique (pour ICQ par exemple)

La limitation des port mapping apparaît rapidement car il faut définir absolument toutes les connexions dont vous avez besoin, ce qui peut être très lourd. Imaginez que vous vouliez mapper certains sites web interdits, comme www.pleindetrucsinterdits.com. Vous n’avez qu’à créer un port mapping du style « localhost:12345 -> www.pleindetrucsinterdits.com:80 ». Ca fonctionne – pas dans tous les cas à cause des « virtual hosts » (Merci Toine) – mais il ne faut pas avoir 50 sites à mapper sinon c’est l’enfer.

Une autre limitation est que vous ne pouvez tout simplement pas de cette manière vous connecter à certains services comme ICQ par exemple : en effet, vous pourriez faire un port mapping vers le serveur d’authentification login.icq.com:5190 par exemple, mais le reste de la communication ne se fera pas car il y a ensuite tout un tas de ports dynamiques alloués qui entrent en jeu. Impossible donc.

La solution est le mapping dynamique. En gros, vous créez un port d’écoute (port 1080 dans la suite du texte) qui se charge de prendre toute trame réseau qui rentre telle quelle et de la « faire exécuter » depuis l’autre bout du tunnel. Ca ressemble à un proxy n’est-ce pas ? En effet, c’est bien un service que l’on utilise pour contacter n’importe quel site/port inaccessible depuis le réseau où l’on est. C’est pas beau ça ?
Ca veut notamment dire que dans l’application qui doit utiliser ce « proxy », vous devez préciser que le nouveau proxy est localhost:1080 et non pas le proxy de l’entreprise.

Dans putty, créez un tunnel « Dynamic » sur le port 1080 par exemple :

Ca donne ça :

Et globalement, on peut donc schématiser ça comme ça :

ATTENTION : une fois ce système mis en place, n’oubliez pas de dire à l’application concernée que le proxy pour sortir n’est plus le proxy de l’entreprise mais le « proxy » de type SOCKS 4 (si vous avez besoin de le préciser) situé sur localhost, port 1080 ! Pigé ?

(MAJ 2009)
Si vous n’arrivez pas à faire utiliser ce proxy à votre navigateur, pourquoi ne pas installer un vrai proxy sur votre serveur relai et le mapper via un tunnel normal ? (un « squid » local à votre serveur relai fera l’affaire)

3.3.3. Tunnel remote ? Ou comment exporter un serveur local (interne) vers l’extérieur

Enfin, sur l’interface de putty, vous avez peut-être remarqué une fonctionnalité inexplorée jusqu’à présent : les tunnels « remote », par opposition aux tunnels « locaux ». Ca permet non pas de mapper un port local vers un couple machine/port distant mais de faire l’inverse : mapper un couple machine/port local vers un port distant (sur la machine PC ADSL). Vous ne voyez pas à quoi ça peut servir ? Lisez la suite :

Attention : c’est mal de faire ça car ça vous permet de rendre accessible un serveur d’Intranet (par exemple) à partir de votre machine extérieure (PC ADSL) et donc potentiellement accessible à tout le monde depuis le web si vous ne faites pas attention à votre configuration réseau !

4. Compléments d’informations

4.1. Limitations

4.1.1. Bande passante

Gardez à l’esprit que vous faites tout passer par la machine chez vous, certainement plus lente en débit que l’accès web de l’entreprise notamment pour l’upload (le retour de communication de votre PC ADSL vers putty). Donc si vous mappez des sites web interdits, ne vous étonnez pas si ça raaaaame, surtout si votre client favori de peer-to-peer tourne plein pot…

4.1.2. Jouer en réseau ?

Décidemment, votre boulot vous passionne… Bon désolé, c’est pas possible. La plupart des jeux en réseaux fonctionnent en mode non connecté (UDP) et c’est pas possible de relayer de l’UDP avec cette solution. Si vous voulez quand même, cherchez des infos sur un soft qui s’appelle ZeBeDee, j’avais pas eu le temps de creuser à l’époque.

(MAJ 2009) Sinon, pensez VPN, hamachi…

4.1.3. Remarques sur la messagerie

A propos du mapping vers des serveurs de messagerie, notez que les fournisseurs bloquent en général l’accès à leur propre SMTP si l’IP émettrice n’est pas sur une plage appartenant à l’opérateur. Pour éviter le spam d’inconnus. Donc évitez de passer par le SSH d’un copain ayant son accès web chez un autre fournisseur pour atteindre votre SMTP, ça risque de ne pas fonctionner. Exemple : vous voulez utiliser le SMTP de wanadoo en passant par une passerelle SSH chez Nerim.

Dans le même ordre d’idées, il faut en général faire du POP avant de pouvoir envoyer un mail, ça s’appelle pop before smtp me semble-t-il et c’est aussi fait pour s’assurer à peu près que l’adresse IP de l’émetteur du mail n’est pas un inconnu car il s’est authentifié par un login/password pour accéder au POP.

4.2. « Légalité » de la chose

Si vous avez peur qu’un gros baraqué de l’équipe réseaux débarque dans votre bureau en disant « qui c’est l’abruti qui fait du SSH ? », n’ayez pas peur.
Premièrement, la connexion au serveur SSH ne se traduit que par une ligne dans les logs du proxy, une ligne du style « CONNECT votrenom.dyndns.org:443 », exactement comme si vous vous connectiez au site https de votre banque. C’est même mieux vu qu’il n’y aura qu’une ligne alors que pour un vrai site web en http(s), il y a aura une ligne par ressource (image, page web etc).
Deuxièmement, au niveau volumétrie de données échangées, étudions l’exemple de la lecture de vos mails : on utilise grâce au tunnel SSH un protocole dédié à la lecture de mail et l’envoi (POP/SMTP). Ca consommera laaaaaaaargement moins de bande passante que de lire les même mails par l’interface web (bourrée de pubs par exempe). De plus, comme ça ramera moins que le chargement complet de pages web, vous mettrez moins de temps à lire vos mails.
Rassuré ?
Une nuance tout de même, si un psychopathe réalise qu’il s’agit de SSH sur port 443 et non de HTTPS, il devrait se poser des questions tout de même. Je n’ai pas encore rencontré de tels psychopathes.

Enfin, rappelez vous quand même la charte informatique que vous avez signée en rentrant dans votre entreprise.

4.3. Partage de tunnels ?

Si vous souhaitez faire profiter de votre tunnel un collègue qui tient absolument à suivre aussi le match de football bloqué par le proxy, regardez les options de putty/ssh pour permettr l’accès aux ports mappés depuis autre part que votre poste local. Exemple : votre collègue entrerait l’adresse ip de votre machine et un port mappé pour accéder à un site web particulier…

4.4. Bug dans putty

Je ne sais pas si ce bug est toujours d’actualité, mais à un moment donné, il fallait absolument mettre le tunnel dynamique en dernier dans la liste des tunnels, sinon il ne fonctionnait pas.

4.5. Transfert de fichier ?

Installez filezilla, il permet de faire du SFTP. Vous n’aurez pas besoin de tunnels SSH mais je tenais à signaler cet outil, libre, gratuit etc etc.
Il vous suffit de déclarer le proxy de l’entreprise dans les préférences puis de créer une connexion de type SFTP (changez le port en 443) et le tour est joué.

Sinon, sous Windows, le produit commercial « Total Commander » permet d’utiliser votre tunnel dynamique (SOCKS 4).

4.6. Méthodes alternatives

Si SSH ne vous plait pas (pauvre fou), vous pouvez toujours vous renseigner sur les outils suivants : httport, httptunnel (linux only je crois). Ils font un peu le même genre de choses, mais en laaaaaaaargement moins bien.
Les deux encapsulent votre trafic réseau dans des trames HTTP, c’est lourd, c’est lent etc. Le seul avantage de httport est que les éditeurs vous fournissent des serveurs (htthost) publics, donc pas besoin d’avoir un serveur relai chez vous ou chez un ami, mais ils rament, sauf si vous payez Quitte à mettre en place un outil pour faire relai, optez pour SSH !
(MAJ 2009)
A noter stunnel pour faire du tunnel SSL pur (si votre admin réseau a grillé votre communication SSH sur un port SSL…
(MAJ 2009)
Quelques liens récemment donnés par Toinator et que je n’ai pas creusé. Lui oui, c’est du lourd apparement.
Un bon gros guide :
http://dag.wieers.com/howto/ssh-http-tunneling/
sslh : en PERL (fixme : retrouver l’url)
sshl : le même recodé en C pour raisons d’optimisations

5. Remerciements

• Toinator pour la relecture et quelques précisions, l’initiation à ce genre d’outils et le chapitre à venir sur le VPN over SSH, si on peut dire.
• Mandraxe

Lorsque vous avez des problèmes de mode passif, actif etc en FTP, pensez à ceci.
Si quelqu’un veut poster en commentaire la théorie expliquant le problème, n’hésitez pas. Il me semble me rappeler des histoires de trames FTP contenant les IP émettrices et donc nécessité d’avoir des modules de masquerading particulier pour bien gérer le FTP… un vague résidu de cours de réseau

La configuration

J’ai un serveur avec :

Bref que du bonheur en apparence.

Le problème

Malgré ça, je galère toujours d’un client FTP à l’autre. Le dernier en date : ncftp pour des échanges depuis un LAN vers ce serveur public. Ca se traduit par un cafouilli général dans les modes passifs etc.
Et un message d’erreur que pour une fois, j’ai relu lentement et me suis rappelé le coup du NAT spécifique FTP :

Falling back to PORT instead of PASV mode

En soit, je me foutais de savoir comment le client FTP établissait sa connexion, car dans tous les cas ça marchait, ça restait sécurisé dans la limite de ce que je demandais, mais c’était surtout que la complétion de nom, style cd rep TAB-TAB-TAB mettait 20 secondes à répondre le temps de passer en mode « PORT » justement. Soit environ 19,8 secondes de trop.

Comment on le règle ?

On pense à activer le NAT spécifique au protocole FTP, dans netfilter. Pour ce faire, par exemple via l’outil modconf (ou sudo modconf chez Ubuntu) afin d’activer ces 2 modules :
./kernel/net/netfilter/nf_conntrack_ftp.ko
./kernel/net/ipv4/netfilter/nf_nat_ftp.ko

Point besoin de rebooter, rien.
Voilà, un protocole FTP mieux géré par firewall netfilter sur votre serveur.

Excusez-moi pour l »à peu près technique concernant cet article. FTP ça me gave, c’est un sac d’ennuis ce truc. Mais c’est pratique.

Deux/trois tests plus tard, je vois le plan : ok pour les ports standards de bureautik-man à la plage (lire ses mails, naviguer sur Internet) mais le reste….. zob.
En gros, j’ai pu voir vite fait que ça passait pour les ports 80, 443, 465, 993 et 1194. Le reste j’ai pas cherché. A tous les coups, le 25, 143, 110 doivent passer aussi. Sans compter la miriade de saloperies de ports réseaux d’un Exchange / Active Dir. Ca doit marcher aussi, sinon comment faire pour vite vite reprendre sa propale depuis son transat ?

Alors bon, le VPN passe, donc c’est bon me direz-vous. Justement pas. S’il s’agit de dépanner le VPN ou si vous avez mis des restrictions sur le VPN (histoire que le VPN ne soit pas nécessairement une énorme porte ouverte dans l’entreprise), ça vous fait une belle jambe que le VPN fonctionne.

Conclusions :
1) Obligé de se taper des SSH sur port 443, des tunnels à gogo lorsque le VPN est trop restrictif…
2) Tu parles d’un accès web, tu peux même pas faire ce que tu veux. Pourtant, dès lors que le port 25 est ouvert, si la motivation principale est comme d’hab d’endiguer le spam des zombies etc, franchement, le mal est fait. Ca sert à rien de bloquer le reste.
3) Ou alors j’ai raté une conf quelque part pour ouvrir le port 22 ? je doute

C’est mes yeux ou c’est vraiment de l’accès restreint ce genre de connexion ?

Enfin, bientôt en vacances, c’est déjà ça…

Dans cet article, je vais montrer comment installer le serveur sous Debian, le paramétrer un minimum et enfin comment déployer l’agent (il existe plusieurs méthodes et la doc n’est pas forcément limpide – pardon aux auteurs, j’ai dû relire plusieurs fois et m’y reprendre à plusieurs fois).
Mon contexte d’utilisation de l’agent est essentiellement du poste Windows où tout le monde n’a pas nécessairement le droit d’admin. Enfin, j’ai un domaine Samba, pratique pour exécuter des choses au login. Si c’est votre cas ou si vous avez un domaine AD de Bigrosoft, ça facilitera le déploiement.

Je ne vous expliquerai pas tout non plus, pour ne pas plagier la doc officielle. Je vous donne des pistes pour aller le plus vite possible en comprenant au mieux les grands principes.

Installation sous Debian

En considérant que vous avez déjà une base MySQL en état de marche et que vous souhaitez installer OCSInventory-NG sur la même machine, ça se résume à un classique :

aptitude install ocsinventory-reports ocsinventory-server

Un 3è paquet appelé ocsinventory-agent est l’agent pour Linux. Probablement inutile sur votre serveur. Le paquet ocsinventory-reports est l’outil de reporting web. A priori pas à dissocier de l’installation sauf si la base de données est sur un autre serveur.
Pensez à survoler les pré-requis d’installation tout de même. Il fallait à priori que j’installe le paquet libphp-pclzip, ce que j’ai fait sans trop y croire (il ne figurait pas dans les dépendances Debian il me semble).

La configuration du paquet vous demande si vous voulez gérer à la main le côté base de données ou laisser l’outil Debian de conf automatique de base de données :

Si vous le faites à la main, la documentation (fichier /usr/share/doc/ocsinventory-server/README.Debian
) explique qu’il faut forcer le nom de votre schéma de base de données à ocsweb car le nom est actuellement hardcodé un peu partout.

J’ai opté pour le mode automatique. Ca vous demande le compte root pour créer le schéma ocsweb et un utilisateur admin associé (appelé « ocs »). A la fin ça donne ça :

Setting up ocsinventory-server (1.01-4) ...
dbconfig-common: writing config to /etc/dbconfig-common/ocsinventory-server.conf

Creating config file /etc/dbconfig-common/ocsinventory-server.conf with new version

Creating config file /etc/ocsinventory/ocsinventory.conf with new version
granting access to database ocsweb for ocs@localhost: success.
verifying access for ocs@localhost: success.
creating database ocsweb: success.
verifying database ocsweb exists: success.
dbconfig-common: flushing administrative password
Reloading web server config...6692

Configuration par le web

Comme toute application LAMP qui se respecte, la suite se passe par une interface web de configuration. Celle-ci est de base inaccessible dans le packaging Debian. Il faut donc aller créer un mot de passe dans un fichier htpasswd. Le fichier est là : /etc/ocsinventory/htpasswd.setup et pour créer un contenu intéressant, il convient de l’effacer et de le créer comme vous voulez :

cd /etc/ocsinventory
rm htpasswd.setup
htpasswd -c htpasswd.setup admin
chown root:www-data htpasswd.setup
chmod 640 htpasswd.setup

Attention aux permissions :

-rw-r----- 1 root www-data   20 2008-05-21 11:14 htpasswd.setup

Enfin on lance l’installation via l’adresse http://votre_serveur/ocsreports/install.php
Vous vous identifierez donc 2 fois : une fois pour passer le stade du HTAccess d’Apache (le compte admin avec password qui va bien dans /etc/ocsinventory/htpasswd.setup) puis le compte admin de la base de données (login ocs et password choisi à l’installation).
Faites défiler les écrans, il n’y en a pas beaucoup et ce n’est pas bien méchant. Lisez tout. Il peut y avoir quelques « warnings » :

WARNING: You will not be able to build any auto deployment package with size greater than 8m.
You must raise both post_max_size and upload_max_filesize in your php.ini to correct this.

WARNING: The user you typed does not seem to be root
If you encounter any problem with files insertion, try setting the global max_allowed_packet mysql value to at least 2M in your server config file.

WARNING: files/ocsagent.exe missing, if you do not reinstall the DEPLOY feature won't be available

Rien d’inquiétant. A garder à l’esprit tout de même pour plus tard.

L’interface de reporting

Enfin, vous vous connectez à l’interface de reporting avec le login/pass standard et vous changez le mot de passe tout de suite !!! http://votre_serveur_de_reporting/ocsreports/, login admin, password admin.

Deux paramètres cruciaux

Il y a un détail de configuration qui est un peu long à comprendre (ou alors je suis lent), c’est le rythme auquel les PC vont faire des remontées. Que vous installiez l’agent en mode « service Windows » ou non, la problématique est la même : ne pas forcer un inventaire toutes les 5 minutes ni nécessairement à chaque login sur un poste. Il s’agit des paramètres PROLOG_FREQ et FREQUENCY que vous trouverez sans mal dans le menu de paramétrage qui va bien de l’interface ocsreports.
- FREQUENCY définit en nombre d’heure la période max entre 2 inventaires pour un agent donné. « période max » car pour éviter les surcharges si tout le monde remontait son inventaire en même temps ; l’agent choisit donc un timing aléatoirement entre « tout de suite » et cette période max.
Cette période précise donc à l’agent l’intervalle de temps avant d’aller demander au serveur quoi faire – pas nécessairement remonter l’inventaire.
- PROLOG_FREQ définit la fréquence de remontée d’inventaire cette fois-ci. C’est différent du paramètre précédent qui indiquait tous les combiens de temps on se pose la question. En bon français de base.
Exemples :
PROLOG_FREQ = always & FREQUENCY = 6 => toutes les 6 heures au max, je force une rémontée (qui sera faite à chaque fois)
PROLOG_FREQ = 2 & FREQUENCY = 6 => toutes les 6 heures au max, je pose la question au serveur, celui-ci demandera un inventaire si l’inventaire actuel a plus de 2 jours pour ce PC. Ca peut être utile pour des postes qui se déconnectent souvent du réseau : ainsi, toutes les 6 heures, on vérifiera si ce n’est pas le moment de se secouer.
Pigé ? non, ben testez alors. Notez qu’en mode « service Windows », l’agent stocke son compteur de temps dans un fichier de conf du répertoire à il est installé. Ca peut aider pour comprendre vos tests.

Déploiement

Le but est de savoir comment vous allez faire pour faire exécuter à distance, sur les PC de votre parc, l’outil de reporting (ocsagent.exe) sans avoir à lever les fesses de votre chaise et passer sur tous les PC un par un et sans craindre qu’un gros malin court-circuite le processus à son lancement (histoire que vous ne voyiez pas ses jeux de poker, logiciels de peer-to-peer et EXE de lancement de groslolo.xxx – c’est du vécu sauf groslolo).
Il existe plusieurs méthodes, toutes décrites sur le wiki officiel
Mon retour d’expérience est le suivant : la fabrication d’un package installable à distance, sans droit d’admin, installant un service Windows, n’a pas fonctionné. Malgré plusieurs tentatives et de l’aide demandée sur le forum. La doc du packager est là.

J’ai donc opté pour une méthode ne nécessitant pas la présence d’un service Windows. Pour la simple raison qu’un gros malin ayant les droits nécessaires pourra aller désactiver l’agent. La méthode par service Windows est pourtant celle recommandée par les auteurs. Mouais.
C’est donc la méthode où l’utilisateur téléchargera malgré lui l’agent à chaque logon au domaine et ira remonter un inventaire (PROLOG_FREQ = ALWAYS, voir plus haut). Attention l’agent fait 1,5 Mo en gros. Pas négligeable si le parc est énorme.
Pour ce faire, vous forcez un appel au script ocslogon.exe depuis votre script de connexion Samba situé dans /etc/samba/scripts.
Quelques remarques :
- Le plus simple est de renommer votre script en adresse_ip_du_serveur.exe (exemple 10.0.0.1.exe), ainsi, l’agent saura à aller chercher le serveur pour remonter ses données. Il passe par un répertoire particulier du serveur web (/ocsinventory). J’oubliais : il faut du HTTPS sur le serveur, me semble-t-il.
- Votre .BAT de logon au domaine ira chercher l’agent sur un répertoire partagé public déjà « monté » et vous l’appellerez avec les paramètres suivants : X:\blabla\10.0.0.1.exe /NP où NP signifie « No Proxy », ça évite qu’il aille voir la conf proxy de IE et fasse potentiellement n’importe quoi pour taper en interne. Pigé ?

N’hésitez pas à lire dans la doc officielle tout ce qui concerne le renommage de ocslogon.exe en adresse_ip.exe ou nom_serveur.exe.

Voilà, vous devriez très vite voir se peupler la base de données et avec lui l’outil de reporting.

Détail : j’ai pété le nombre de connx à Mysql

Mine de rien, le nombre de connexion simultanées à votre MySQL va en prendre pour son grade. Si vous avez une limitation assez basse, vous allez bientôt avoir des soucis de connexion à la base. Un petit

SHOW PROCESSLIST

dans MySQL vous montrera le nombre de connx actives.
Et le paramètre set-variable=max_connections=255 (ou plus) dans la section [mysqld] de votre fichier /etc/mysql/my.cnf + redémarrage de la base vous fera le plus grand bien.

Voilà, fliquez bien – en 2/3 minutes, vous devriez pouvoir faire des requêtes assez sympa dans la base, en tapant sur les tables SOFTWARES et HARDWARE : compter le nombre d’occurrence de tel logiciel, remonter tous les logiciels de l’éditeur trucmuche etc.

Il y a un truc bien merdique (sous IE :O) avec les fichiers PAC. Je vous en fais part car pour le coup, j’ai trouvé beaucoup de monde sur google se posant une question et personne n’y répondant correctement.

Une fois votre « proxy.pac » créé, il s’agit de le mettre à dispo des utilisateurs. Deux solutions :
- le publier sur un serveur web (interne)
- le copier d’une manière ou d’une autre sur le PC des utilisateurs, localement

La première méthode est bien pour une utilisation interne (serveur web interne toujours accessible), mais pour les personnes mobiles, c’est naze : quel que soit le serveur web utilisé, il faudra pouvoir l’atteindre, ce qui n’est pas nécessairement possible depuis un site quelconque de connexion à Internet.

La deuxième méthode est bonne pour tout le monde, du moment que vous avez moyen d’injecter le fichier sur le PC des utilisateurs.
Ensuite, dans ce cas, vous indiquez dans votre navigateur un chemin du genre c:\mon repertoire\monproxy.pac
Et c’est là le début des ennuis.
- Firefox va convertir l’adresse en file:///c:/mon%20repertoire/monproxy.pac
- IE ne convertit rien et ne trouve pas le fichier. Bref, ça-marche-pas (c) MS

Comment faire ? j’ai vu plein de fois la question sur le web, jamais la réponse.
Pour que ça marche sous IE, il faudra donc :
- commencer par file://c:/
- ne pas mettre d’espace ni de %20. Comment faire ? nommer les répertoires à l’ancienne, façon Windows 95. C’est pas beau ça ? c’est pas un navigateur génial IE ? Exemple : file://c:/docume~1/mon_id/mon_proxy.pac

Et voilà. La clef, c’est le « ~1″ des familles.

J’entends dans le fond de la salle une question : « pourquoi ne pas mettre le fichier sur C:\ ou C:\Windows directement ? ». Parce-que j’ai des utilisateurs non admin de leur poste et le script de logon au domaine n’a pas les droits d’écrire là-dedans. Par contre dans %USERPROFILE% (ie, C:\Documents and settings/mon_id/) c’est bon.

Simple, mais de quoi perdre des heures.
Merci Microsoft.

Bon, je poste un peu après tout le monde sur le sujet. Mais c’est histoire de faire part de 2/3 remarques. A voir les news postées un peu partout, j’ai l’impression de revivre la naissance de « Blaster » sous Windows : grande ampleur alors que la correction existait et beaucoup découvrent/découvraient ça tardivement sans trop savoir quoi faire.
Bon ici, il ne s’agit que de rectifier avant qu’une faille soit exploitable. Mais c’est extrêmement préoccupant.
Et le pire, c’est que contrairement à beaucoup de failles, le problème réside dans les « clefs de cryptage » que vous utilisez (qui vous sont propres), pas dans l’outil en lui-même. Donc appliquer les patchs constitue seulement 1% de la solution. (dans le cas où vos clefs ont été générées, disons, entre hier et y’a 2 ans… c’est large)

Point de départ de l’information

Si vous découvrez seulement maintenant le sujet et que vous gérez des Debian ou Ubuntu ou dérivés, c’est grave, lisez vite les « security advisory » de openssl et de openssh publié le lendemain. Ce sont les seules sources fiables, comme point de départ.
Si ça vous gonfle car c’est en anglais, parce-que personne n’en voudrait à votre pseudo-serveur etc, alors arrêtez tout de suite de « gérer » un serveur…
Le wiki de Debian résume bien tous les services qui peuvent être impactés et donnent les opérations à faire. A commencer par OpenSSH (tout le monde l’a celui-là)

Donc, pour cette fois, et pour les suivantes, faites ceci :

Pour bien réagir la prochaine fois :

Inscrivez-vous sur la mailing-list de securité Debian

Inscrivez-vous soit par l’interface web, soit en envoyant un mail à debian-security-announce-REQUEST@lists.debian.org avec sujet subscribe et en confirmant une fois le 1er de retour reçu).
Optez pour celle appelée « debian-security-announce », pas nécessairement « debian-security » qui est plutôt une chat-room non modérée
=> Ainsi, vous serez au courant au bon moment avec les bonnes infos, plutôt que des « on dit » incomplets sur des forums.
Si vous n’êtes pas en Debian, ça vaut quand même. Il doit y avoir l’équivalent sur Ubuntu et autres dérivés.

Lisez les alertes à tête reposée et faites ce qui est demandé

Par exemple, dans celle d’OpenSSL dit notamment une toute petite phrase : « We recommend that you upgrade your openssl package and subsequently regenerate any cryptographic material, as outlined above. »
=> Cette toute petite phrase veut simplement dire qu’il faut regénérer TOUT ce qui a trait à la crypto. Donc tous vos certificats pour vos protocoles sécurisés, notamment SSH, HTTPS, POP3S, IMAPS, SSMTP etc. Sans parler des known_hosts et authorized_keys. En gros, si vous gérez un paquet de serveurs, ça va juste vous pourrir un bon paquet d’heures. Mais c’est obligatoire.

Le mot de la fin

Voilou, c’était histoire de clarifier la situation vu ce qu’on peut lire comme info incomplète sur cette faille. Le classique "apt-get update ; apt-get upgrade" du matin ne suffit pas !
J’ai eu envie de faire cet article quand je pense aux hébergeurs qui proposent des serveurs à pas cher, avec environ 97% d’admin archi-débutant-pas-sérieux. Je me ferais du souci à leur place. Surtout si un exploit est révélé !
Faites que le mien ne bloque pas le trafic SSH en cas d’exploit révélé (si si, mon hébergeur l’a proposé, arg !)…. ce serait un bordel sans nom.

Accéder à l’interface réseau virtuelle

OpenVPN 2.0 ne permet pas d’exploiter la carte virtuelle si vous n’êtes pas admin, d’après ce que j’en comprends vu la remarque sur la version 2.1 sur le site :

TAP-Win32 adapter can now be opened from non-administrator mode

En fait sur ce sujet, avec OpenVPN 2.0, je ne sais plus si j’avais simplement un problème pour accéder à l’interface virtuelle ou pour créer des « routes » ou les 2. J’ai opté pour la 2.1 RC7 (et tant pis si ce n’est pas la finale).

Pour résoudre à coup sûr ce problème, utilisez la version 2.1.

Ajouter des « routes »

Une fois que l’utilisateur sans droit est capable de lancer l’openvpn, vous vous chopez des erreurs sur vos routes ajoutées dans la conf de votre VPN histoire que tout ce petit monde communique avec le reste de votre infra. En effet, sous Windows, le « add route » est réservé à l’admin… ou plus simplement aux personnes du groupe « Opérateurs de configuration réseau ».
Donc ajoutez vos utilisateurs sans droits là-dedans. Ils ne seront pas admin complet mais pourront déjà abîmer leur configuration réseau…

Impossible d’écrire des logs par le GUI

Si vous avez cette erreur, pensez à donner les droits d’écriture sur tout le répertoire C:\Program Files\OpenVPN\log, pour tout le monde, ou, moins bourrin, pour votre utilisateur.
Notez : le GUI OpenVPN est intégré à OpenVPN 2.1 maintenant. Ce n’est pas le cas avec le package 2.0

Cette fois, c’est bon, votre utilisateur presque-sans-droit peut faire du VPN et massacrer involontairement votre LAN depuis chez lui… :/

Pourquoi donc ? par exemple pour ne rendre visible dans une DMZ que les relais et non pas les serveurs POP/IMAP directement. Ca peut permettre aussi (dans le cas du logiciel PERDITION que je vais montrer ci-dessous) de faire une répartition par utilisateur (donc par exemple par origine) entre différents serveurs POP ou IMAP de votre infrastructure, pour de la répartition de charge ou toute autre raison qui vous semble intéressante.

Bon là, si ça ne vous parle pas, l’article ne vous servira à rien, revenez plus tard. Sinon, let’s go pour une introduction par un exemple de mise en place du logiciel PERDITION.

En deux mots, le principe d’un relai comme ça est de prendre les demandes d’authentification, de les relayer au vrai serveur de mail et suivant le résultat, de faire ou non un « pipe » vers le vrai serveur de mail (selon le protocole voulu).

Commencez donc par installer l’application. Sous Debian : apt-get install perdition par exemple.

Ensuite, allez dans /etc/perdition/ et dupliquez votre fichier perdition.conf en perdition.imap.conf suivant vos besoins. Le manuel préconise en fait de créer un fichier par protocole utilisé. A la limite, le fichier d’origine perdition.conf ne sert plus à rien à la fin. Vous pouvez le conserver néanmoins si vous n’utiliserez dans votre proxy qu’un seul des 4 protocoles.

Il faut maintenant éditer ce(s) fichier(s) pour chaque protocole. Tous les paramètres sont par défaut en commentaire. A vous de choisir ce qu’il faut. Le minimum vital pour de l’IMAP4s par exemple est, (dans le fichier /etc/perdition/perdition.imap4s.conf du coup :

protocol IMAP4S
outgoing_port 993
outgoing_server imap.mondomaine.com # votre vrai serveur IMAP
ssl_mode ssl_listen # ou ssl_all, voyez la doc
ssl_ca_file /etc/ssl/certs/masociete.crt
ssl_cert_file /etc/ssl/certs/mon_imap.cert
ssl_key_file /etc/ssl/certs/mon_imap.key

Quelques remarques :
1) Vous n’êtes pas obligé d’utiliser une « Certification Authority », donc dans ce cas, pas besoin de "ssl_ca_file".
2) Les chemins et noms de fichiers des certificats/clefs sont arbitraires.
3) Pour de l’IMAP non sécurisé, vous n’auriez qu’à modifier les 3 premières lignes et laisser en commentaire celles commençant par "ssl".
4) Pour du POP ou POP3s, c’est le même principe.
5) Enfin, le fichier de config /etc/perdition/perdition*conf contient pas mal d’aide sur chaque paramètre, et le man perdition aussi.

Enfin, dernière brique, préciser quels protocoles on prend en charge et vérifier que perdition est bien lancé par le système. Ca se passe dans le fichier /etc/default/perdition où vous irez contrôler ça :

RUN_PERDITION=yes
POP3=no #ou yes
POP3S=no #ou yes
IMAP4=no #ou yes
IMAP4S=yes #ou no

Pour chaque protocole que vous utilisez, vous aurez donc créé le /etc/perdition/perdition.protocole.conf qui va bien. Relancez le service via "/etc/init.d/perdition restart" et vérifiez que les processus "perdition.protocole" qui vous intéressent tournent.

Evidemment, vous vérifierez enfin que toute votre configuration firewall ressemble à quelque chose et permet notamment l’accès aux ports qui vont bien de votre proxy POP/IMAP.

J’oubliais, pour faire de la répartition par utilisateur (tel utilisateur sur tel serveur), il faut éditer le fichier "/etc/perdition/popmap". Quelques exemples sont donnés, genre :

horms:mailserver1
tymm:mailserver2

Puis créer une « base de données » (un fichier .db) via un "make" basé sur le Makefile disponible dans /etc/perdition/Makefile.
(C’est un peu le même principe, en plus glauque, que le fichier /etc/aliases et sa version base de données générée par la commande postalias).
Personnellement, je n’ai pas mis en place ce système de répartition, mais ça ne doit pas être bien plus compliqué que ça.

Voilou.

Au fait à quoi ça sert ? En gros un VPN à la maison, ça sert en général à des groupes d’amis un peu geeks voulant vraiment avoir leur VPN flottant au-dessus d’Internet pour s’échanger des fichiers facilement, avoir leurs réseaux fermés de je ne sais quoi.

Si maintenant on imagine que ce réseau fermé est – exemple tout à fait au hasard – un serveur de jeu que vous voulez rendre accessible comme si vous étiez en LAN, alors que vous êtes sur Internet, certains trouveront cet outil complètement génialissime. Va savoir pourquoi…
Enfin, si j’ai choisi Hamachi, c’est parce-que VOUS êtes quelqu’un aimant un peu l’informatique (sinon vous ne liriez pas cet article) et que vos amis joueurs sont des buses en informatique (cas classique). Ainsi, si vous leur demander d’installer un client VPN hyper compliqué, vous n’êtes pas près de jouer…

En relisant, je vois que l’article est long. Comme quoi, « zero-conf » <=> beaucoup d’explications. Allez, visite guidée.

Je vais décrire ce cas : un serveur de jeu (quel qu’il soit) sur un Linux, configuré pour un LAN, que je souhaite rendre accessible sur Internet à mes amis via ce VPN (donc comme si j’étais en LAN). Je vais donc vous expliquer trois choses. Premièrement : comment installer le client sur Linux et créer votre réseau d’amis. Deuxièmement : comment installer le client sur Windows et rejoindre votre réseau. Enfin, tout au long de la doc, quelques considérations de sécurité, des concepts derrière Hamachi etc.
Notamment, si je ne parle pas de serveur Hamachi, c’est parce-qu’il n’y en a pas. Si j’ai bien tout compris, la mise en relation des utilisateurs (vous et vos amis) entre eux passe à un moment donné par un point central (chez l’éditeur d’Hamachi je suppose). Mais ce n’est pas pour autant ques tous les utilisateurs du VPN Hamachi peuvent se voir (il faut se donner l’accord mutuel). C’est un peu la seule solution pour rendre le tout « zero-conf ». Ensuite, les transferts passent en direct évidemment.

La plupart des trucs que je raconte sort des README et de la doc d’Hamachi, mais comme vous ne le lisez pas (ou que vous ne comprenez rien à l’anglais) et que, même en ayant lu tout ça, ça reste un peu opaque sans pratiquer, je vous commente la chose avec un exemple de bout en bout.

J’oubliais : ce n’est pas opensource mais c’est gratuit dans la limite de création de réseaux de 16 personnes (je crois).

Enfin, si vous voulez comprendre le principe avant de mettre en place, survolez tout l’article avant d’envoyer la purée

Les différences entre Hamachi Linux et Windows sont :

- Sous Linux, il n’y pas d’interface graphique pour Hamachi

- Sous Linux, il faudra créer votre brin VPN à la main (3/4 commandes à recracher telles quelles)

- Sous Linux, il faudra balancer 3/4 commandes (simples) pour créer votre « compte » et votre réseau

- Sous Windows, tout cela sera graphique et automagique

- Sous Windows, vous faites tourner des serveurs de jeux vous ? Je serais surpris. Ben zappez la partie Linux dans ce cas.

Le principe d’Hamachi (valable pour Linux et Windows) :

Vous allez vous créer un compte, identifié par une couple de clef de cryptage (pensez à les sauvegarder si vous réinstaller votre PC ou votre serveur Linux). Vous vous donnerez un surnom et le système Hamachi vous donnera une IP privée (de la plage 5.x.y.z) qui vous caractérise sur le VPN. En fait, tous les utilisateurs Hamachi sont plus ou moins tous le même VPN (puisqu’on a tous une IP 5.x.y.z qu’on ne contrôle pas et puisqu’on passe à un moment par un serveur Hamachi pour se connecter etc).
Sauf que, histoire que ce ne soit pas une poubelle géante (un réseau interconnectant des gens entre eux qui ne le souhaitent pas), vous ne pouvez pas communiquer avec une IP 5.x.y.z (qu’elle corresponde ou non à un compte Hamachi) si vous ne faites pas partie d’un « réseau » (sorte de channel sur IRC si on voulait comparer – ou une chatroom à la limite), réseau protégé par un mot de passe et pour lequel n’existe aucune liste mentionnant son existence.
En gros, si votre réseau s’appelle chezmoionsamuse, que le pass n’est pas trop bidon, il n’y a aucune chance qu’un intrus vienne vous perturber par hasard (je suppose). Si vous voulez vous en convaincre, finissez de mettre en place le bazar et essayez des ping sur des IP au hasard, ou mieux, sur l’IP 5.x.y.z d’un ami nouvellement inscrit (avant qu’il ait rejoint votre réseau et après qu’il l’ai fait).
De plus, sous Linux, votre firewall refusera toute communication par défaut, je décrirai comment autoriser ce qu’il faut plus bas (notamment pour atteindre le serveur de jeu, c’est le but de mon exemple).
Sous Windows, ça semble grand ouvert par défaut (encore une fois, aux personnes figurant sur un réseau où vous êtes vous-mêmes).
Pas la peine de flipper, ça semble bien pensé à ce niveau-là.

Sous Linux : installation de l’application
Téléchargez l’outil, décompressez l’archive quelque part, passez root et faites ceci :

root$ make install

Copying hamachi into /usr/bin ..
Creating hamachi-init symlink ..
Compiling tuncfg ..
Copying tuncfg into /sbin ..

Hamachi is installed. See README for what to do next.

En gros, vous venez de vous rajouter un binaire /sbin/tuncfg qui va servir à exploiter une carte réseau virtuelle, votre brin VPN.

Sous Linux : installation de ce qu’il faut pour exploiter les tunnels virtuels
Votre noyau Linux doit avoir chargé le module « tun » (plus d’infos là). Le plus simple est de charger le module grâce à l’outil modconf (apt-get install modconf). Ca donne ça :

Si vous ne trouvez pas ce module, c’est que votre noyau est compilé main (et vous avez fait l’impasse sur plein de choses) ou que votre distribution Linux est naze Dans ce cas, recompilez-en un avec ce module (démerdez-vous un peu).
Pour vérifier qu’il est chargé :

$ lsmod | grep tun
tun                    11776  0

Avec modconf, ce module sera chargé à chaque boot.

Il faut ensuite créer à la main (une seule fois) un périphérique réseau qui sera exploité pour ces tunnels. Si vous tapez actuellement tuncfg (en tant que root), vous obtenez :

root$ tuncfg
tuncfg: cannot stat() /dev/net/tun -- No such file or directory
tuncfg: visit http://www.hamachi.cc/tuntap for more information

Donc, en root, tapez ceci :

root$ mkdir /dev/net
root$ mknod /dev/net/tun c 10 200

Alors le lancement de tuncfg ne dit plus rien (preuve qu’il s’est bien lancé, faites un ps pour contrôler)

Optionnel sous Linux : comment faire en sorte que tuncfg soit chargé au reboot ?
Si vous n’avez pas envie de devoir relancer à chaque reboot la commande tuncfg, vous pouvez par exemple créer un script qui sera appelé au boot. Je ne détaille pas le principe sous Linux, juste la procédure. Faites des man sur les commandes utilisées si vous êtes curieux.
Créez un fichier /etc/init.d/hamachi_tuncfg avec les permissions d’exécution, contenant :

#!/bin/sh
#script simple pour /etc/init.d de demarrage de tuncfg pour HAMACHI
#auteur : michauko

test -x /sbin/tuncfg || exit 0
. /lib/lsb/init-functions

export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"

case "$1" in
  start)
        log_daemon_msg "Demarrage TUNCFG pour HAMACHI" "tuncfg"
        if start-stop-daemon --start --quiet --oknodo --exec /sbin/tuncfg ; then
            log_end_msg 0
        else
            log_end_msg 1
        fi
        ;;
  stop)
        log_daemon_msg "Arret TUNCFG pour HAMACHI" "tuncfg"
        if start-stop-daemon --stop --quiet --oknodo --name tuncfg ; then
            log_end_msg 0
        else
            log_end_msg 1
        fi
        ;;

  restart)
        log_daemon_msg "Redemarrage TUNCFG pour HAMACHI" "tuncfg"
        start-stop-daemon --stop --quiet --oknodo --retry 30 --name tuncfg
        if start-stop-daemon --start --quiet --oknodo --exec /sbin/tuncfg ; then
            log_end_msg 0
        else
            log_end_msg 1
        fi
        ;;

  *)
        log_action_msg "Usage: /etc/init.d/hamachi_tuncfg {start|stop|restart}"
        exit 1
esac

exit 0

Ensuite, on crée les raccourcis qui vont bien dans les runlevels :

# update-rc.d  hamachi_tuncfg defaults
 Adding system startup for /etc/init.d/hamachi_tuncfg ...
   /etc/rc0.d/K20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc1.d/K20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc6.d/K20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc2.d/S20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc3.d/S20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc4.d/S20hamachi_tuncfg -> ../init.d/hamachi_tuncfg
   /etc/rc5.d/S20hamachi_tuncfg -> ../init.d/hamachi_tuncfg

Pour simuler le reboot, appelez la commande /etc/init.d/hamachi_tuncfg start (ou stop ou restart). Contrôlez la (non-)présence du processus avec ps.

Voilààààà, tout est prêt au niveau de l’OS Linux pour lancer Hamachi.

Lancement et utilisation de Hamachi sous Linux :

Maintenant que la partie technique est faite (cf. les paragraphes ci-dessus), il faut vous créer un compte. Cette fois, vous allez utilisez un compte utilisateur « normal » (ie, pas root). Par exemple, pour en revenir au serveur de jeu, le compte de l’utilisateur qui héberge ledit serveur. La commande – à faire une seule fois – est la suivante :

toto$ hamachi-init
Initializing Hamachi configuration (/home/toto/.hamachi). Please wait ..

  generating 2048-bit RSA keypair .. ok
  making /home/toto/.hamachi directory .. ok
  saving /home/toto/.hamachi/client.pub .. ok
  saving /home/toto/.hamachi/client.pri .. ok
  saving /home/toto/.hamachi/state .. ok

Authentication information has been created. Hamachi can now be started with
'hamachi start' command and then brought online with 'hamachi login'.

Ensuite, les commandes suivantes servent à chaque fois que vous voulez vous connecter au « système Hamachi » (avant de lancer votre serveur de jeu par exemple).

D’abord lancer hamachi :

toto$ hamachi start
Starting Hamachi hamachi-lnx-0.9.9.9-20 .. ok

Puis vous connecter (passer « online ») :

toto$ hamachi login
Logging in ....>....... ok

Si vous voulez connaitre votre IP sur le VPN (c’est-à-dire à quelle adresse sera hébergée votre serveur de jeu), faites un :

toto$ cat ~/.hamachi/state
Identity   5.168.x.y <---- c'est elle l'IP, c'est là que vos amis iront pour atteindre serveur "LAN sur Internet"
Nickname   votre_nick_quand_vous_l_aurez_choisi
AutoLogin  yes
OnlineNet  vos_reseaux_lorsque_vous_en_aurez_crees_ou_rejoints

Ensuite, choisissez-vous un beau nickname (à faire une seule fois, sauf pour en changer) :

toto$ hamachi set-nick toto_qui_hoste_le_serveur_de_jeu
Setting nickname .. ok

Ensuite, il faut créer un réseau. A noter que celui qui crée le réseau sera le seul à avoir le droit de le détruire ou de kicker des gens. Donc je suggère que le compte qui héberge le serveur de jeu soit celui qui crée ce réseau (rappel : ce réseau = ce point de ralliement, ce channel). Ca se fait comme ça :

toto$ hamachi create mon_reseau mon_mot_de_passe
Creating mon_reseau .. ok

Vous pouvez lister les personnes présentes (d’une part inscrites, d’autre part connectées ou non). Pour l’instant ce sera vide :

toto$ hamachi list
   [mon_reseau]

Vous-même n’êtes pas encore connecté à ce réseau (sinon il y aurait une « * » devant [mon_reseau]). Pour ce faire :

toto$ hamachi go-online mon_reseau
Going online in mon_reseau .. ok

(Ca vous demandera le mot de passe, évidemment).

Lorsque tous vos amis joueurs, sous Windows, auront rejoint votre réseau, ça ressemblera plutôt à :

toto$ hamachi list
 * [mon_reseau]
       * 5.90.x.y       fredo                     83.a.b.c:1043
          5.168.d.e     warlord
        * 5.63.e.f       autrepote               82.g.h.i:1077

Les « * » signifient que les gens sont connectés, vous avez leur IP VPN et leur IP Internet en fin de ligne. Si vous ne voyez pas les surnoms, il faut lancer la commande hamachi get-nicks.

Voilà vous savez tout.

Quelques autre commandes avant que je n’oublie, voyez :

toto$ hamachi --help
Hamachi, a zero-config virtual private networking utility, ver 0.9.9.9-20

  usage: hamachi [-c ] [command]

  -c         overrides default configuration directory (~/.hamachi)
  command    specifies an action. Can be one of the following -

             #  start [debug]
                stop
             #  set-nick 
                login
                logout
             #  list
                get-nicks
             #  create  [
]
                delete 
                evict   <5.x.x.x>
             #  join    [
]
                leave  
             #  go-online 
                go-offline 

  If no command is specified, hamachi displays its status including version,
  pid, online status and the nickname

et aussi, pour quitter Hamachi, le plus brutal est :

toto$ hamachi stop
Shutting down .. ok

Ca sauvegarde votre état, à savoir : online/offline, les réseaux auxquels vous étiez connectés etc. Vous pouvez quitter d’abord proprement tout ça (c’est pas utile) avec des commandes style hamachi logoff et hamachi go-offline mon_reseau (pour rejoindre un réseau : hamachi go-online mon_reseau).

Bon voilà, vous savez tout sous Linux pour :

- mettre en place hamachi

- créer votre compte, vous connecter

- créer votre réseau et vous y (dé)connecter

- voir qui est dessus

- et surtout : connaitre votre IP sur le VPN, IP qui sera à donner à tout le monde pour joindre votre serveur.

Sous Linux : quoi faire sur le firewall ?

Si vous avez déjà des amis sous Hamachi sous Windows, vous verrez que ces amis n’arrivent pas à « ping-er » l’IP du VPN de l’utilisateur Hamachi sous Linux (donc potentiellement ils ne pourront pas joindre votre serveur de jeu).
Il faut ouvrir le firewall proprement.
En effet, sans ça, si vous tentez des ping dans un sens ou dans l’autre (depuis votre compte Hamachi Linux et depuis un compte que vous aurez sur une autre machine Windows par exemple), vos logs risquent de vous dire quelque chose comme ça :

Listed by source hosts:
 Rejected 5 packets on interface ham0
    From 5.x.y.z - 4 packets
       To 5.a.b.c - 4 packets
          Service: 8 (icmp/8) (Shorewall:INPUT:REJECT:) - 1 packet
          Service: www (tcp/80) (Shorewall:INPUT:REJECT:) - 3 packets
    From 5.x.y.z - 1 packet
       To 5.a.b.c - 1 packet
          Service: 3 (icmp/3) (Shorewall:OUTPUT:REJECT:) - 1 packet

Les curieux auront vu avec ifconfig qu’une nouvelle interface réseau est née : ham0.
J’utilise shorewall (cf. ma doc Debian pour plus d’infos). Si vous n’ utilisez « que » iptables, vous êtes autiste et vous pourrez transposer ce qui suit.

Dans le fichier /etc/shorewall/interfaces, vous déclarez une zone correspondant à l’interface réseau virtuelle de Hamachi, ça donne quelque chose comme ça :

net     eth0            detect          dhcp,tcpflags,norfc1918,routefilter,nosmurfs,logmartians,blacklist
#pour hamachi :
ham     ham0            detect          tcpflags,detectnets,nosmurfs

Ensuite, dans /etc/shorewall/zones, vous expliquez que cette « zone » est de type ipv4 classique :

fw      firewall
net     ipv4
ham     ipv4
loc    ipv4

Enfin, comme vous souhaitez sûrment être restrictif pour l’accès à ce réseau, il n’est sûrement pas la peine de préciser quelque chose dans le fichier /etc/shorewall/policy : tout est droppé par défaut. Le retour d’information du firewall (le serveur de jeu) vers les clients sera autorisé même sans règle type ACCEPT fw ham puisque la communication aura été initié dans l’autre sens (client joueur qui s’adresse au serveur). N’oublions pas que le firewall Linux est « stateful ».
Donc on n’a plus qu’à ouvrir ce qui nous intéresse. Ci-dessous le port du jeu « Call Of Duty UO » et l’autorisation de ping (ça aide toujours un peu à débugger) dans le fichier /etc/shorewall/rules :

# HAMACHI
Ping/ACCEPT     ham             fw
ACCEPT          ham             fw      udp 28960 # CALL OF DUTY

Vous relancez shorewall (/etc/init.d/shorewall restart), contrôlez son bon lancement (tail /var/log/shorewall-init.log). Et ô magie, le ping Windows/ip_hamachi -> Linux/ip_hamachi passe.

Pour ce qui est de la connexion au serveur de jeu dont il est question dans cet article, il faut encore que vous le lanciez en lui expliquant d’une manière ou d’une autre qu’il est configuré en LAN et que son adresse d’attachement est 5.x.y.z et non pas votre IP publique. Pigé ? Certains pourraient même avoir besoin de désactiver des contrôles de clefs…

Maintenant pour vos amis qui ne demandent qu’à jouer, pas à geeker, voici le chapitre qu’il leur faut :

Installation & utilisation sous Windows

Ca, c’est le chapitre où vous expliquez au reste de votre équipe de bras cassés de l’informatique comment faire pour se connecter à votre VPN-machin sous Windows pour (enfin) pouvoir jouer. ‘y comprennent rien c’est grave
Il faut installer le client Windows, le lancer et suivre ce que ça raconte. Il y a même un tuto obligatoire qui explique le B-A.BA pour prendre en main Hamachi. Ensuite, vos amis rejoindront votre réseau (qu’on a nommé ici « mon_reseau ») et c’est terminé.
En image, ça donne ça :

Et je vous le donne en mille, dans le cas ci-dessus, l’utilisateur Linux (vous) qui a créé le réseau est la personne dont le nick est « ze_serveur ». Plus haut, j’ai du le nommer « toto_qui_hoste_le_serveur ». Pigé ?

Voilà. C’est fini. Fraggez bien.