Trust no one !
La plupart des protocoles réseaux utilisés de nos jours n’étant pas cryptés, il est souvent nécessaire de mettre en place un VPN afin de sécuriser certains flux. Pour cet article, nous utiliserons le daemon VPN ‘mpd‘.
Installation du serveur
Il faut tout d’abord installer le port mpd
# cd /usr/ports/net/mpd/ && make install clean
Puis éditer le fichier ‘/etc/rc.conf‘ pour que le daemon soit lancé au démarrage en background (option -b) sans que la console d’administration soit accessible de l’extérieur (option -a)
mpd_flags="-b -a 127.0.0.1" mpd_enable="YES"
Configuration du serveur
La configuration se situe dans trois fichiers, voici un exemple de configuration pour chacun des fichiers :
# Fichier /usr/local/etc/mpd/mpd.conf default: load vpn1 vpn1: new -i ng0 vpn vpn # the session value does matter, but I'm not sure why set iface session 28800 # "username" here should match "username" in mpd.secret set bundle authname "majinbox" set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e56 set ccp yes mpp-e128 # set this to your correct routing information set iface route 10.253.6.0/24 set link yes acfcomp protocomp set ipcp yes vjcomp set iface disable on-demand set iface idle 0 set link keep-alive 61 753 set link mtu 1460 set ccp yes mpp-stateless set link no pap set link accept chap set link enable no-orig-auth open
Cette configuration permet d’avoir un lien appellé ‘vpn1‘ pour l’utilisateur ‘majinbox‘. Dans le cas ou le VPN serait utilisé par des clients sous Windows, il est important de commenter la ligne qui active la compression. Il est possible de créer plusieurs connexions, en ajoutant ‘load vpn2‘ dans la section ‘default‘ et en créant une section contenant les directives propres à la sections.
# fichier /usr/local/etc/mpd/mpd.conf majinbox MonMotDePasseEnClair
Ce fichier contient les identifiant et mot de passes des différents utilisateurs. Les mots de passes étant stockés en clair, il faut limiter au maximum les droits en lecture sur ce fichier.
#fichier /usr/local/etc/mpd/mpd.links vpn: set link type pptp set pptp peer 217.174.206.169 set pptp enable incoming set pptp disable originate
Ce fichier permet de définir le sens des connexions VPN, dans notre cas, la connexion est entrante car nous sommes sur le serveur.
Installation et configuration du client
L’installation est la configuration du client est identique à l’exception du fichier ‘mpd.links‘. Il faut être vigilant et lancer le serveur avant le client.
Jusqu’il y a peu de temps, il fallait bidouiller le /etc/make.conf pour utiliser l’option -j de make permettant de paralléliser la compilation d’un port. En plus d’être un hack relativement laids, ce type de bidouille était incompatible avec certains ports. Ce temps là est révolu, il y maintenant une whitelist de ports qui sont d’office compilé avec autant de job en parallèle qu’il y a de cores présents sur la machine. Les ports qui ne sont pas marqué comme compatibles restent compilés sans parallélisation.
Cette fonctionnalité est activée par défaut, pour la désactiver (ce qui n’a d’intérêt que dans des cas très particuliers), il suffit d’ajouter à /etc/make.conf la directive suivante :
DISABLE_MAKE_JOBS=yes
Afin de forcer le nombre de jobs à exécuter en parallèle (option -j de make), il faut utiliser la directive suivante (toujours dans /etc/make.conf) :
MAKE_JOBS_NUMBER=6
Il existe un option pour les kamikazes téméraires qui permet de forcer l’utilisation de cette nouvelle fonctionnalité pour l’ensemble des ports (même pour ceux qui ne sont pas marqués comme compatibles) :
FORCE_MAKE_JOBS=yes
Je vous déconseille néanmoins cette solution. Si le but est de compiler quelques ports qui ne sont pour l’instant pas marqués comme validés, il suffit d’ajouter le fichier Makefile du ou des ports en question et d’y ajouter la directive suivante en dessous des déclarations de dépendances :
MAKE_JOBS_SAFE=yes
Les mainteneurs de ports peuvent aussi marquer leur port comme incompatible avec la directive :
MAKE_JOBS_UNSAFE=yes
Jails faciles et légères avec ezjails
Update : Ajout de l’option « -p » à l’installation qui permet d’avoir les ports dans les jails
Principes de fonctionnement
Petit rappel : les jails permettent d’exécuter un système FreeBSD à l’intérieur d’un autre système FreeBSD. Cela permet entre autre d’installer des ports incompatibles sur une seule machine et de protéger le système des éventuelles failles de sécurité d’un démon lancé dans une jail.
‘ezjail‘ est un petit script sh qui permet en plus d’automatiser la création de jails de limiter l’espace disque utilisé par chaque jail en permettant de n’utiliser qu’un seul système de base monté en read-only sur chacun des jails.
Installation d’ezjail
cd /usr/ports/sysutils/ezjail make install clean
Il peut être utile d’ajouter la directive suivante au fichier ‘/etc/rc.conf‘ afin d’automatiser le démarrage des jails lors d’un reboot :
ezjail_enable="YES"
Création d’un premier jail
Il faut tout d’abord configurer ezjail. Suivant l’espace disque disponible, il peut être utile de modifier le répertoire dans lequel sont stockées les jails : ‘/usr/jails/‘ par défaut.
# cp /usr/local/etc/ezjail.conf.sample /usr/local/etc/ezjail.conf # vi /usr/local/etc/ezjail.conf
Afin de créer le jail de base, il suffit de lancer la commande :
# ezjail-admin install -p
Pour créer un jail, il suffira ensuite d’ajouter un alias IP dans le système hôte et de lancer la commande ‘ezjail-admin create‘. Uns fois, le jail créé, on pourra lancer ‘ezjail‘
# ifconfig fxp0 192.168.22.101 alias # ezjail-admin create <jailname> <jailIP> # /usr/local/etc/rc.d/ezjail start
FreeBSD propose deux solutions de RAID software : gmirror et ZFS (uniquement depuis la version 7.0 pour ce dernier). La solution ZFS n’étant pas suffisamment mature selon moi, je ne parlerai dans cet article que de la mise en place de gmirror.
Situation de départ
- Un serveur ou un poste de travail sous FreeBSD 6.X ou 7.0 avec un disque dur qui contient les partitions sur lesquelles sont les données à passer en RAID et un deuxième disque dur au moins aussi spacieux
- Un accès à distance au serveur : cette solution fonctionne uniquement par SSH (testé avec succès par votre serviteur). Il faut cependant faire attention car en cas d’erreur, il faudra un accès physique pour redemarrer serveur.
La stratégie
- Passage du disque actuellement utilisé en mirroring
- Reboot sur une grappe RAID à un seul disque
- Ajout du deuxième disque à la grappe RAID
Les détails de la mise en place
- Pour être en mesure de modifier des disques qui sont en cours d’utilisation, il faut utiliser la commande suivante :
sysctl kern.geom.debugflags=16
- Il faut ensuite créer une grappe RAID an l’initialisant avec le disque en cours d’utilisation (dans le cas présent : ad0) :
gmirror label -v -b round-robin gm0 /dev/ad0
- Il faut maintenant modifier le fichier /boot/loader.conf (en le créant si nécessaire). Afin que gmirror soit chargé au démarrage, il faut ajouter la directive suivante :
geom_mirror_load="YES"
- Il faut ensuite modifier le fichier /etc/fstab, les modifications dépondrons de votre installation. Il faut remplacer les références à votre disque physique (eg /dev/ad0) et les remplacer par la grappe RAID (eg /dev/mirror/gm0)
- L’étape suivante est critique, il faut redémarrer. S’il y a une erreur dans le fichier /boot/loader.conf ou dans le fichier /etc/fstab, le serveur risque fort de ne pas redémarrer correctement. Les erreurs les plus fréquentes sont l’oubli des ‘_’ dans geom_mirror_load ou l’utilisation de /dev/gm0 à la place de /dev/mirror/gm0. Il faut donc être le plus vigilant possible avant de redémarrer le serveur.
- Une fois le serveur redemarré et le bon fonctionnement de la grappe RAID validé, nous pouvons ajouter le deuxième disque à la grappe avec la commande suivante (dans notre cas, le deuxième disque est ad1) :
gmirror insert gm0 /dev/ad1
- Il est possible de connaitre l’état de la grappe à tout moment avec la commande :
gmirror status
. Dans notre cas, la grappe sera en état dégradée tant que les données du premier disques n’auront pas été copiées sur le deuxième disque.