Utilisation de NAP + DHCP

Introduction au NAP

NAP ou « Network Access Protection » est une technologie Microsoft introduite dans Windows Server 2008 autrefois appelé « Network Access Quarantine Control » dans Windows Server 2003. NAP permet de contrôler l’accès réseau d’un hôte à partir de la conformité du système hôte en question. On détermine si un hôte est sain ou pas en fonction d’options configurées sur le serveur.

Cette fonctionnalité améliore donc la sécurité réseau des entreprises qui elles-mêmes définissent des stratégies pour les clients de leur réseau. Les machines sont définies comme étant saines et peuvent donc accéder au réseau si et seulement si, elles répondent aux exigences définies par l’administrateur (Firewall actif / mises à jours activées / antivirus activé / …). Dans le cas contraire, elles seront isolées et n’auront pas d’accès au réseau tant qu’elles ne seront pas en conformité avec les stratégies.

Une remarque importante est à souligner : bien que le NAP permet de protéger l’accès au réseau, un client dont le pc passe correctement les vérifications du service NAP et accède au réseau, peut tout à fait pirater ce dernier.

FTPS, Active Directory et …

Partie 0 : Brève explication

Avant d’entrer dans le vif du sujet, nous devrons tout d’abord intégrer notre machine (ici Debian 6.0.3) dans l’Active Directory afin que les utilisateurs de celui-ci puissent également accéder au FTPS qui sera mis en place.

Le domaine sera : test.local

Le contrôleur de domaine : ldap.test.local

Le contrôleur intègre un serveur DNS.

Partie 1 : Intégration AD

Nous partirons du principe que notre Active directory est déjà présent et qu’il tourne parfaitement sur notre machine Windows 2008 R2.

Les paquets à installer sont les suivants : libkrb53 krb5-config krb5-user samba winbind ntpdate ntp

Etant donné que nous utiliserons le protocole Kerberos, nous devons nous assurer d’avoir une parfaite synchronisation des horloges systèmes.

# ntpdate ldap.test.local

Passons maintenant au fichier /etc/krb5.conf (il ne faut rien mettre d’autre dans ce fichier):

[logging]
default = FILE:/var/log/krb5.log

[libdefaults]
ticket_lifetime = 24000
clock_skew = 300
dns_lookup_realm = false
dns_lookup_kdc = true

[realms]
TEST.LOCAL = {
kdc = ldap.test.local:88
admin_server = ldap.test.local
default_domain = TEST.LOCAL
}

[domain_realm]
.test.local = TEST.LOCAL
test.local = TEST.LOCAL

Nous allons ouvrir un ticket kerberos avec ce compte en tapant la commande :

# kinit Administrator@TEST.LOCAL

La console affiche ce message : Password for Administrator@TEST.LOCAL:
On entre alors le password et si la console nous rend la main sans message d’erreur on peut s’assurer du succès de l’ouverture du ticket en tapant:

 # klist

La console nous renvoie alors : Ticket cache: FILE:/tmp/krb5cc_0Default principal: Administrator@TEST.LOCAL avec la date de création et d’expiration.

Il faut maintenant se rendre dans le fichier de configuration de Samba.

Samba va permettre de faire communiquer une machine Windows et avec une machine Unix, Winbind permet de récupérer les utilisateurs et les groupes du  domaine Windows.

# nano /etc/samba/smb.conf

On y copie EXACTEMENT les lignes suivantes :

  [global]
  security = ads
  realm = TEST.LOCAL
  password server = 172.16.10.1
  # note that workgroup is the \'short\' domain name
  workgroup = test
  winbind separator = /
  idmap uid = 10000-20000
  idmap gid = 10000-20000
  winbind enum users = yes
  winbind enum groups = yes
  template homedir = /home/%D/%U
  template shell = /bin/bash
  client use spnego = yes
  client ntlmv2 auth = yes
  encrypt passwords = yes
  winbind use default domain = yes
  restrict anonymous = 2
  # to avoid the workstation from
  # trying to become a master browser
  # on your windows network add the
  # following lines
  domain master = no
  local master = no
  preferred master = no
  os level = 0

Maintenant que nous avons modifié le fichier, un redémarrage des différents services est nécessaire :

  # /etc/init.d/samba stop
  # /etc/init.d/winbind stop
  # /etc/init.d/samba start
  # /etc/init.d/winbind start

Il faut maintenant que nous configurions le système d’authentification.

    • Rendons nous dans le fichier /etc/nsswitch.conf et ajoutons les lignes suivantes :
  # nano /etc/nsswitch.conf
  # Example configuration of GNU Name Service Switch functionality.
  # If you have the `glibc-doc-reference' and `info' packages installed, try:
  # `info libc "Name Service Switch"' for information about this file.
  passwd:         compat winbind
  group:          compat winbind
  shadow:         compat
  hosts:          files dns
  networks:       files
  protocols:      db files
  services:       db files
  ethers:         db files
  rpc:            db files
  netgroup:       nis
  bootparams:     files
  automount:      files
  aliases:        mount
    • Dans le fichier /etc/pam.d/common-account, nous devons rajouter la ligne suivante :
account sufficient      pam_winbind.so

C’est-à-dire qu’au final, le fichier doit contenir ces 2 lignes :

account sufficient      pam_winbind.so
account sufficient      pam_unix.so
    • Modifions maintenant le fichier /etc/pam.d/common-auth :
auth sufficient pam_winbind.so krb5_auth krb5_ccache_type=FILE
auth sufficient pam_unix.so nullok_secure use_first_pass
auth required pam_deny.so
    • Dernier fichier à modifier, /etc/pam.d/common-session :
session required pam_unix.so
session required pam_mkhomedir.so umask=0022 skel=/etc/skel

Nous allons à présent modifier les fichiers /etc/hostname, /etc/hosts et /etc/resolv.conf. Commençons par le premier :

     # nano /etc/hostname

On ajoute dans ce fichier le nom de la machine suivi du suffixe :

ftps.test.local

Dans le fichier /etc/hosts, on rassemble l’ensemble des noms pouvant être utilisés pour identifier la machine :

127.0.0.1 localhost
127.0.0.1 ftps.test.local ftps
172.16.10.1 ldap.test.local ldap
172.16.10.42 ftps.test.local ftps

Dans /etc/resolv.conf :

nameserver 172.16.10.1

Nous allons à présent intégrer notre Debian au domaine, pour cela on utilise la commande suivante :

# net ads join -S LDAP.TEST.LOCAL -U Administrator

Le mot de passe nous est demandé, on le rentre. On obtient ceci en réponse : 

Using short domain name – TEST
Joined 'ftps to realm 'TEST.LOCAL’

On peut tester que nous avons bien rejoint le domaine :

# wbinfo –u (liste des utilisateurs du domaine)
# wbinfo –g (liste des groupes du domaine)
# getent passwd (renvoi l’ensemble des utilisateurs utilisables)
# getent group (renvoi l’ensemble des groupes utilisables)

Partie 2 : FTPS

Pour une question d’affinité, j’ai décidé de travailer avec vsftpd.

vsFTPd, forme raccourcie de Very Secure FTP Daemon, est un serveur FTP libre simple et sécurisé.

Il a été développé dans l’optique de la meilleure sécurité possible afin de combler les failles des serveurs FTP classiques. Il bénéficie de toutes les options habituelles des serveurs FTP classiques (proFTPd, Pure-FTPd,…) et prend en charge l’IPv6 ainsi que SSL.

Afin d’installer vsftpd, nous allons utiliser le célèbre apt-get install :

# apt-get install vsftpd

On se rend maintenant dans le fichier de configuration :

# nano /etc/vsftpd.conf

On supprime l’entièreté du fichier et on copie :

#### GENERAL CONFIGURATION ####
listen=YES
connect_from_port_20=YES
pam_service_name=vsftpd
#ftpd_banner=Bienvenue sur le serveur ftp.
dirmessage_enable=YES
xferlog_enable=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
#deny_email_enable=YES
#banned_email_file=/etc/vsftpd.banned_emails
use_localtime=YES
#dirlist_enable=NO
idle_session_timeout=600
data_connection_timeout=12

#### RIGHTS CONFIGURATION #####
local_enable=YES
write_enable=YES
anonymous_enable=NO
#anon_upload_enable=YES
#anon_mkdir_write_enable=YES
chroot_local_user=YES
chroot_list_file=/etc/vsftpd/user_list
local_umask=077
#chown_uploads=YES
#chown_username=whoever
secure_chroot_dir=/var/run/vsftpd/empty
#async_abor_enable=YES
#ascii_upload_enable=YES
#ascii_download_enable=YES
#ls_recurse_enable=YES
setproctitle_enable=YES

#### VIRTUAL USER CONFIGURATION #####
virtual_use_local_privs=YES
user_sub_token=$USER
local_root=/home/TEST/$USER
hide_ids=YES # SUPER IMPORTANT
#########

##### SECURE CONFIGURATION #####
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=YES
# require_ssl_reuse=NO # Certains clients FTP necessitent cette ligne
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES
rsa_cert_file=/etc/ssl/private/vsftpd.cert.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.key.pem
pasv_enable=YES
pasv_promiscuous=NO
pasv_min_port=40000
pasv_max_port=40100pasv_address=127.0.0.1
#ou domaine.com avec pasv_addr_resolve=YES
port_promiscuous=NO
#rsa_cert_file=/etc/ssl/private/vsftpd.pem
###########

Il faut maintenant sécuriser le protocole (car de base, il ne l’est pas). On va alors créer un certificat :

# apt-get install openssl
# openssl req -x509 -nodes -days 730 -newkey rsa:1024 -keyout vsftpd.pem -out vsftpd.pem

Il nous est alors demandé de renseigner plusieurs champs, le plus important : Common Name (eg, YOUR name) []

On copie le fichier généré dans le répertoire /etc/ssl/certs/ :

# cp vsftpd.pem /etc/ssl/certs

On sécurise le certificat :

# chown root:root /etc/ssl/certs/vsftpd.pem
# chmod 600 /etc/ssl/certs/vsftpd.pem

Nous ajoutons les lignes suivantes dans notre fichier de configuration (déjà présente dans le fichier du dessus) :

ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=YES
 
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES

On redémarre le service :

# /etc/init.d/vsftpd restart

Partie 3 : Répertoire personnel

Un problème se pose, pour que l’utilisateur de l’Active Directory ait un répertoire personnel créé automatique, il faut normalement se connecter avec celui-ci sur la Debian, nous ne pouvons procéder ainsi.

La solution trouvée est de créer un script qui va vérifier l’existence ou nom pour chaque utilisateur du domaine d’un répertoire personnel, si le répertoire n’existe pas il sera créé.

# nano script.sh

On rajoute :

#!/bin/sh
 for user in $( wbinfo -u );
 do
         if [ ! -d /home/TEST/$user ]
         then
                 /bin/mkdir /home/TEST/$user
                 /bin/chown -R $user:"domain users" /home/TEST/$user
         fi
 done
 /etc/init.d/winbind restart

On sauvegarde et on rend exécutable le script :

# chmod +x (777) script.sh

Maintenant, nous devons faire en sorte que ce script soit automatisé toutes les minutes :

# nano /etc/crontab

On y ajoute :

*/1 * * * * root   /root/script.sh

On redémarre le service avec un petit /etc/init.d/cron restart

Partie 4 : Bloquer SSH

Pour une question de sécurité, seul root sera autorisé à utiliser ssh. Nous allons rajouter une ligne dans le fichier /etc/ssh/sshd_config :

AllowUsers root

Partie 5 : Clé publique / Clé privée

Dans PuTTYGen, nous cliquons sur « Generate » puis on remue la souris dans l’encadré rouge afin de générer la clé.

On copie alors la clé publique et on la colle dans le fichier .ssh/authorized_key

# mkdir –p .ssh
# nano .ssh/authorized_keys

On clique ensuite sur “save private key”, nous répondons “oui” à la question « Are you sure you want to save this key without a passphrase to protect it ». On choisit alors un emplacement ou sauver la clé.

Dans PuTTY, on va dans “Connection” puis “Data”, on renseigne le champ « Auto-login username »

Dans « Connection » à « SSH » à « Auth », on clique sur « browse » et on va rechercher la clé privée.

Et pour une question de meilleure lisibilité, on peut se rendre dans « Window » puis « Translation » et choisir «UTF-8»

Pour terminer, on retourne dans « Session », on ajoute l’adresse IP (ou l’Host Name). On donne un nom à la session dans « Saved Sessions », on sauvegarde et on clique sur « Open ».

Partie 6: Client FTP

Le client FTP utilisé ici sera FileZilla. Quelques petites modifications sont à faire afin qu’il fonctionne correctement.

On clique sur « Ouvrir le gestionnaire des sites »

On crée un nouveau site et on y ajoute les champs suivants :

ftp 2ftp

L’identifiant et le mot de passe correspondent à un utilisateur de l’Active Directory.

 

Le DHCP sous Windows Server 2008

 

Dans le cadre des cours que j’ai donné à l’Henallux, il était demandé de faire un serveur DHCP sous Windows Server 2008 (R2). Chose qui a donné parfois pas mal de fil à retordre pour pas mal de mes étudiants.

C’est donc en pensant à eux et à la façon dont j’alimenterais encore une fois YanX.eu d’un tuto utile que je me suis décidé à faire un petit « Howto » pour la création d’un serveur DHCP. L’équivalent sous Linux arrivera incessamment sous peu.

En deux mots, le serveur DHCP sert à attribuer dynamiquement des adresses IP aux clients qui seront à même d’envoyer une requête à un serveur DHCP traînant dans le réseau mais aussi de recevoir la réponse en retour.

On ne va donc pas entrer dans les détails niveau réseau mais il faut savoir que de base, une requête DHCP venant du client est faite en broadcast. Cela signifie donc que la requête n’est pas censée aller au-delà d’un routeur. Toutefois, des fonctionnalités sympathiques se trouvant des appareils faisant office de routeur permettent de relayer ces requêtes et de les envoyer en dehors du réseau (ip helper-address chez Cisco)

Attaquons la configuration du serveur DHCP. Supposons que le serveur Windows 2008 est fraîchement installé, démarré, pré-configuré (IP statique, Hostname configuré, …). Nous allons commencer par installer le rôle Serveur DHCP

Il nous faut ensuite choisir la carte sur laquelle on veut voir le DHCP actif. Dans mon cas, je n’ai qu’une carte réseau mais en admettant que nous en avons deux (une côté LAN client et l’autre côté Internet dans le cas où le serveur ferait office de routeur), il faudra choisir la carte où notre serveur va répondre aux requêtes DHCP.

Ensuite, il faudra choisir un nom de domaine (dans le cas d’un Active Directory cela est assez important mais dans le cas d’un petit DHCP dans un réseau local, nous pouvons y mettre ce que nous voulons. Par exemple test.local . Pour en savoir un peu plus, ce « suffixe » qu’on envoie en DHCP sert essentiellement à résoudre des noms d’hôtes. Dans le cas d’un AD par exemple, si notre domaine est mydomain.com et qu’un client clientA fait partie de ce domaine, en faisant un ping clientA , on va en fait résoudre clientA.mydomain.com ).

Il faut également définir une ou deux IP de serveur DNS qui seront envoyés au client dans le paquet DHCP.

Le WINS (ancêtre du serveur DNS moderne) est de moins en moins utilisé. Je le désactive donc dans le cadre de ce tuto ;-) .

Après quoi, nous allons rajouter une (ou plusieurs) étendue(s) DHCP. On entend par étendue le sous-réseaux qui va bénéficier du DHCP avec tous ses paramètres (Passerelles, Bail, …).

Dans le Wizard de Windows Server 2008, on nous propose d’ajouter un nom d’étendue (permettant de repérer plus facilement une étendue dans l’arborescence quand on en dispose de plusieurs), une adresse de début et de fin (qui seront les IP distribuées aux clients), le masque de sous-réseau qui sera envoyé aux clients et la passerelle par défaut qui sera également envoyée.

Ensuite, on vient désactiver le mode DHCPv6. Dans le cas d’un petit réseau local, à part pour s’amuser, on n’implémente généralement pas l’IPv6.

Enfin, après un bref aperçu de ce que nous avons paramétré, nous pouvons installer le serveur DHCP. Ceci doit se terminer avec un « Installation réussie« . Le cas échéant, lisez attentivement le message d’erreur que vous seriez susceptible d’avoir.

Un coup d’oeil dans l’arborescence du Gestionnaire de serveur nous permet de visualiser l’étendue que nous avons configuré. C’est ici qu’on pourrait rajouter également des options que nous avons oublié dans l’assistant de configuration (par exemple une passerelle oubliée). Mais c’est ici aussi qu’on peut rajouter des options avancées non-proposées dans l’assistant (l’adresse d’un serveur de temps (NTP), …)

Il reste plus qu’à configurer nos clients en DHCP pour recevoir les adresses émanant du serveur. Le DHCP est très utile lorsqu’il s’agit d’une grande entreprise qui doit gérer de nombreux sous-réseaux. Une seule machine pouvant ainsi distribuer des adresses à une quantité de machine permet de gagner énormément de temps (à ne pas devoir configurer toutes les machines en IP statique au risque d’avoir des conflits IP notamment) mais aussi d’éviter les erreurs de configuration des postes clients.

Dans un petit réseau local, le DHCP permet à Monsieur Tout-le-monde de déballer son routeur et son PC puis d’utiliser directement sa machine pour surfer sur Internet sans devoir se tracasser de savoir ce qu’est une adresse IP.

En résumé, le DHCP c’est très bien et, en plus, le serveur DHCP n’est pas bien difficile à mettre en place :-).