Archive for the ‘informations techniques’ Category

Surveillance des services sur les serveurs VPN

mardi, mai 20th, 2008

Pour effectuer la surveillance des serveurs VPN (une fois opérationnel, ces serveurs seront des points d’entrée critique), nous avons décider d’utiliser NAGIOS et l’addon NRPE.
Sur les serveurs VPN, lancer apt-get update && apt-get install nagios-plugins nagios-nrpe-server
et apt-get install nagios-plugins-lifc.
Modifier le fichier /etc/nagios/nrpe.cfg
allowed_hosts=127.0.0.1,<adresse_serveur_nagios>

#command[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/hda1
#command[check_disk2]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/hdb1
command[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /
command[check_ppp_connect]=/usr/lib/nagios/plugins/check_ppp_connect -w 20 -c 30
command[check_xl2tpd]=/usr/lib/nagios/plugins/check_xl2tpd

relancer le serveur NRPE : /etc/init.d/nagios-nrpe-server restart

modification non obligatoire dans le fichier /etc/services
nrpe 5666/tcp # Nagios NRPE

On vérifie que le service nrpe tourne correctement :
netstat -at | grep nrpe

Tester la connexion depuis le serveur Nagios : /usr/local/nagios/libexec/check_nrpe -H <adresse_client_nagios> -c check_users
sur le serveur nagios
définition d’un template service :
define service{
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 2
notification_interval 120
contact_groups admins-serveurs-vpn
notification_options w,u,c,r
notification_interval 120
notification_period 24x7
name services-vpn
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
parallelize_check 1 ; Active service checks should be parallelized (disabling this can lead to major performance problems)
obsess_over_service 1 ; We should obsess over this service (if necessary)
check_freshness 0 ; Default is to NOT check service 'freshness'
notifications_enabled 1 ; Service notifications are enabled
event_handler_enabled 1 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
}

définition d’un template host :
define host{
name linux-box ; The name of this host template
use generic-host ; This template inherits other values from the generic-host template
check_period 24x7 ; By default, Linux hosts are checked round the clock
check_interval 5
# retry_interval 1
max_check_attempts 10
check_command check-host-alive
notification_period 24x7
notification_interval 120
notification_options d,r
contact_groups admins-serveurs-vpn
register 0
}

création des hotes :

define host{
host_name Besancon_Bouloie_metro-C_test-vpn ; The name we're giving to this server
alias test-vpn ; A longer name for the server
address 194.57.91.251 ; IP address of the server
use linux-box ; Inherit default values from a template
}
...

création des services :

define service{
use services-vpn
host_name Besancon_Bouloie_metro-C_test-vpn
service_description CPU Load
check_command check_nrpe!check_load
}
...

création du hostgroup :

define hostgroup{
hostgroup_name TEST_Equipements
alias TEST
members Besancon_Bouloie_metro-C_test-vpn, Besancon_Bouloie_metro-C_vpn1, Besancon_Bouloie_metro-C_vpn2
}

Configuration serveur : connexion client XP/VISTA

jeudi, mai 15th, 2008

Depuis la sortie de VISTA SP1, la connexion IPSEC ne s’effectue plus correctement car il manque une commande (forceencaps=yes) dans la configuration des connexions pour les clients XP/VISTA.

Si, dans la configuration du serveur nous modifions légèrement la connexion pour les clients XP/VISTA en ajoutant :
conn vpn-l2tp-XP
# force l'encapsulation en UDP
forceencaps=yes

alors la connexion d’un VISTA SP1 fonctionne.
De fait, il faudra faire attention en cas de problème de connexion à bien ajouter dans REGEDIT la valeur (pour VISTA) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
(pour XP) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec valeur DWORD AssumeUDPEncapsulationContextOnSendRule à 2 comme cela est spécifié dans l’article Problème VISTA/XP SP2 : modification de la base de registre

Pour le moment nous avons deux choix au niveau du serveur :
– imposer la manipulation de regedit pour les clients XP et garder un type de connexion commune pour XP et VISTA
– régénérer des certificats pour les clients VISTA et créer une connexion spécifique pour VISTA et conserver la connexion XP actuelle.
Le choix sera déterminé semaine 21 suivant les essais faits avec XP SP2 et SP3 et VISTA sans SP1 et avec SP1. Pour le moment seuls les clients XP SP2 et VISTA sans SP1 peuvent utiliser les serveurs IPSEC.

Les résultats des tests démontrent que pour Windows XP SP1/SP2 et SP3 nous pouvons conserver la même configuration client et serveur => aucun changement à effectuer sur les postes clients XP ni de changement de certificat.

Pour Windows VISTA sans SP1 ou avec SP1, il faut mettre à jour la base de registre.

IPSEC et taille du certificat serveur

mercredi, mai 7th, 2008

Le protocole IKE d’échange des certificats entre le serveur et le client ne supporte pas, de la part du serveur, une fragmentation des paquets contenant le certificat. Ainsi, avec une clef de certificat de taille 1024 bits, tout se passe bien, mais si l’on en crée une de 4096 bits, le serveur est incapable de négocier avec le client une connexion IPSEC.
Les serveurs VPN sont donc équipés de certificats avec des clefs de 1024 bits.

LINUX serveur : script

vendredi, mai 2nd, 2008

Un script spécifique lors de la création d’un lien PPPXX à été écrit pour éliminer dans IPTABLES (mangle) les restes des connexions mal fermé. Le problème est l’accumulation dans la tabe mangle de connexion lié au même PPP alors que la connexion en cours à besoin d’un ajout en cours pour sa propre connexion PPP.

Le script effectue donc une élimination de toutes les lignes dans mangle traitant du PPP en cours ; ensuite il y a ajout de la bonne ligne PPP dans la table mangle.

Le fichier se trouve dans : ip-pre-up.d/vpn-pre-connect

LINUX : L2TP contre XL2TP

vendredi, mai 2nd, 2008

Ces deux programmes permettent d’identifier par une surcouche à PPP un utilisateur à travers un lien IPSEC actif.

Au cours des travaux de mise en oeuvre du projet VPN, nous avons souvent oscillé entre les deux, pour plusieurs raisons :

– L2TP n’est plus maintenur officielement

– XL2TP est maintenu

– pour un client L2TP permet une authentification sans passer par un fichier pap-secret avec un mot de passe en clair

– L2TP est en standard dans les distributions LINUX

– L2TP à été modifié est un repository au LIFC le maintient à jour

Lors des tests beta, nous avons remarquer que L2TP du côté serveur tombait régulièrement sans raison et sans information dans les fichiers de logs.

Le serveur est donc recofiguré avec XL2TP.

Côté client L2TP peu être maintenu.

Configuration serveurs : RADIUS et iptables

lundi, avril 14th, 2008

Le serveur RADIUS assure le AAA (Authorization, Authentication et Accounting). Pour ce faire, le service RADIUS recoit des informations du serveur IPSEC à travers la couche L2TP/PPP. C’est effectivement par ce biais que le client peut émettre une demande d’authentification supplémentaire au seul certificat.

sur le serveur IPSEC, nous avons dans /etc/options.l2tpd.lns qui est appelé par xl2tpd (pppoptfile = /etc/ppp/options.l2tpd.lns) les instructions suivantes :
plugin radius.so
plugin radattr.so

qui suffisent à utiliser un serveur RADIUS depuis L2TP.
Le fichier /etc/radiusclient.conf donne :
authserver "serveur radius"
acctserver "serveur radius"

Le reste des options étant des définitions standards, tels les dictionnaires
dictionary /etc/radiusclient/dictionary
dans lequel on retrouve :
INCLUDE /etc/radiusclient/dictionary.rfc2868
INCLUDE /etc/radiusclient/dictionary.microsoft
INCLUDE /etc/radiusclient/dict.perso

Le dictionnaire de la RFC 2868 est récupéré sur une machine sur laquelle se trouve un serveur RADIUS, mais il faut modifier certains type : “integer has_tag” devient “integer” et “string has_tag” devient “string”. Sans ces modifications, une erreur apparait dans les logs au lancement de l2tp. Il faut aussi enlever de ces fichiers dictionnaire les lignes de début et de fin de dictionnaire comme BEGIN-VENDOR et END-VENDOR .
Le dictionnaire de la RFC 2668 nous permet de manipuler les VLANs (Tunnel-Type 13 et Tunnel-Medium-Type IEEE-802 et la valeur du VLAN par le champ Tunnel-Private-Group-Id). Sans ces champs, il est impossible de définir les VLANs.

Cette approche à toute son utilité si nous voulions récupérer un numéro de VLAN depuis le serveur LDAP de l’UFC ou dans un fichier local (ou base de données). Or, notre approche du problème est légerement différente puisque nous n’utilisons pas de prédéfinition de VLAN pour un utilisateur, mais plutôt une définition de REALM permettant pour un même utilisateur d’accéder à différents VLANs.

Le serveur IPSEC est prêt à se servir du serveur RADIUS et les informations que nous récupérons sont :
nom de l’utilisateur, le realm, une date d’expiration, le réseau, la marque iptables, les indications de validité du compte et du realm.
Si le RADIUS du projet VPN est chainé à un RADIUS local de laboratoire, celui-ci peut renvoyer une valeur pour l’adresse IP du client, le RADIUS de laboratoire effectuant l’aspect DHCP. La valeur de l’IP ainsi retournée doit correspondre au réseau.
La marque iptables possède toute une histoire. Sur le serveur IPSEC, nous avons deux cartes réseaux. La première définie le réseau de connexion du serveur au monde extérieur et un route -n nous donne :
0.0.0.0 194.57.91.254 0.0.0.0 UG 0 0 0 eth1
La seconde est configuré en mode trunk et possède tous les VLANs rattachés au VPN. De fait, cette interface possède des sous-interfaces sur des VLANs (ex :
eth0.410 Lien encap:Ethernet HWaddr 00:B0:D0:68:72:BD
inet adr:172.20.252.253 Bcast:172.20.252.255 Masque:255.255.255.0
)
Mais il s’est posé un problème important ; dès la fin de la première connexion, les connexions suivantes n’étaient plus routées correctement. Pour corriger ce problème, nous avons défini un routage sélectif par marquage des paquets suivant leur origine.
auto eth0.410
iface eth0.410 inet static
address 172.20.252.253
netmask 255.255.255.0
network 172.20.252.0
broadcast 172.20.252.255
up ip route add default via 172.20.254 dev eth0.410 table ufc.generic
up ip rule add fwmark 13 table ufc.generic
down ip rule del fwmark 13
down ip route del table ufc.generic

Et on marque les paquets à l’initialisation de la session PPP faite par le client suivant le REALM demandé et accepté.
Avec l’exécutable perl /etc/ppp/ip-up.d/vpn-connect, nous créons un fichier /var/run/radattr.pppXX qui contient les informations retournées par RADIUS (ex :
Framed-IP-Address 172.20.128.37
Framed-IP-Netmask 255.255.255.0
Ufc-Iptables-Mark 12
)
Lors de la deconnexion, c’est le fichier /etc/ppp/ip-down.d/vpn-disconnect qui est exécuté.
Nous avons ainsi les logs de l’exécution des scripts :
Apr 10 16:37:35 test-vpn vpn-connect: /sbin/iptables -t mangle -A PREROUTING -s 172.20.128.37 -i ppp0 -j MARK --set-mark 12
Apr 10 16:37:40 test-vpn vpn-disconnect: iptables -D PREROUTING -s 172.20.128.37 -i ppp0 -j MARK --set-mark 0xc
Sur le serveur, il ne faut pas oublier de définir les valeurs données dans le fichier /etc/network/interfaces ; cela s’effectue en ajoutant les valeurs dans /etc/iproute2/rt_tables :
10 femto.ext
11 lifc.lab
12 lifc.edu
13 ufc.generic

Ainsi le traffic PPP du client est marqué correctement et est routé en utilisant le routeur du VLANs sur lequel il est raccordé.

Configuration serveurs : architecture

lundi, avril 14th, 2008

Le projet VPN repose non pas sur un seul serveur, mais sur des serveurs hébergants des services.
Chacun de ces services peut être colocalisé avec d’autres, mais pour des raisons d’administration et de risques (panne, piratgae) ceux-ci sont répartis.
Le serveur IPSEC a une adresse IP publique atteignable depuis l’extérieur de l’UFC sur le protocole ESP (50) ;
Le serveur d’authentification n’est atteignable que par le serveur IPSEC (classe privée). Il héberge un serveur RADIUS ;
La base de données POSTGRESQL qui contient les droits des utilisateurs est atteignable par le serveur RADIUS.

schéma de principe lors de la connexion d\'un client

Client Linux et Serveur : options dans sysctl.conf

jeudi, avril 10th, 2008

Pour le bon fonctionnement du proxy-arp du serveur VPN,

le fichier /etc/sysctl.conf du serveur VPN doit être configuré comme suit en ajoutant ces options :
net.ipv4.ip_forward=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.conf.all.log_martians=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2


Sans ces options, le proxy-arp du serveur VPN ne fonctionne pas correctement et empêche le client d’accéder à quoi que ce soit hors le serveur VPN lui même.

Gantry : bug dans les modules MP10.pm et MP20.pm

jeudi, avril 10th, 2008

Un patch a été envoyé (29/02/2008) pour corriger des erreurs sur le mod_perl (1 et 2) dans Gantry.

Certificat serveur et MacOS

jeudi, avril 10th, 2008

Le certificat du serveur doit absolument contenir une information subjectAltName. Dans le fichier openssl.cnf il faut donc (si on utilise tinyCA) configurer la section suivante ainsi :
[ server_cert ]
...
#subjectAltName = email:copy
subjectAltName = IP:"adresse du serveur VPN"

Sans cette option, les clients MacOS ne peuvent pas établir la connexion IPSEC.