Corrigé du DS du 13 novembre 2002

4 Corrigé du DS du 13 novembre 2002

Examen d'une durée de deux heures avec tous les documents autorisés (y compris ordinateurs).

Le barême approximatif est de 3 points pour chaque exercice et de 8 points pour la question de réflexion (dont 2 sur la dernière série de questions).

4.0.8 Configuration de commutateur

Vous devez configurer un commutateur Cisco de 12 ports (du type Catalyst 2912) dans le contexte suivant : il doit avoir comme adresse IP de service 192.168.0.1, sur les ports Ethernet 1 et 4 sont connectées des machines du vlan 2, sur les ports 2 et 3 des machines du vlan 3, le commutateur est relié à un commutateur haut débit par l'intermédiaire du port 12, une machine Linux qui souhaite avoir une adresse IP dans le vlan 2 et une adresse IP dans le vlan 3 se trouve sur le port 10 et enfin un routeur inter-vlan est sur le port 11. Donnez la configuration des interfaces FastEthernet0/x et vlan1 pour que les différents éléments puissent communiquer correctement. Le routeur et le commutateur haut débit utilisent l'encapsulation isl et la machine Linux le module 802.1q du noyau 2.4.

Voici une configuration minimale :

interface VLAN1
  ip address 192.168.0.1 255.255.255.0
!
interface FastEthernet0/1
  switchport access vlan 2
!
interface FastEthernet0/2
  switchport access vlan 3
!
interface FastEthernet0/3
  switchport access vlan 3
!
interface FastEthernet0/4
  switchport access vlan 2
!
interface FastEthernet0/10
  switchport mode trunk
  switchport trunk encapsulation dot1q
!
interface FastEthernet0/11
  switchport mode trunk
!
interface FastEthernet0/12
  switchport mode trunk
!

4.0.9 Configuration IP

Donnez les commandes vconfig, ifconfig et route à passer pour configurer la machine Linux évoquée dans l'exercice précédent avec comme adresse IP 172.16.138.2 dans le vlan 2 (il s'agit d'un réseau IP de préfixe de taille 17 et de passerelle 172.16.140.1) et comme adresse IP 193.51.20.69 dans le vlan 3 (il s'agit d'un réseau IP de préfixe de taille 26 et de passerelle 193.51.20.65). Cette machine doit pouvoir sortir sur Internet.

Comme passerelle on préférera bien entendu la passerelle du réseau routé, c'est à dire 193.51.20.65. Les commandes sont :
vconfig add eth0 2
ifconfig eth0.2 172.16.138.2 netmask 255.255.128.0 \
                             broadcast 172.16.255.255
vconfig add eth0 3
ifconfig eth0.3 193.51.20.69 netmask 255.255.255.192 \
                             broadcast 193.51.20.127
route add default gw 193.51.20.65

4.0.10 Serveur et requêtes LDAP

Le serveur LDAP de l'école permet d'accèder à des informations sur les éléments actifs du réseau. Les éléments sont rangés par locaux techniques au dessous de l'objet de nom

dc=ports,dc=network,ou=Register,o=eudil,c=fr

Voici un exemple d'objet "local technique" :

$ PORTS="dc=ports,dc=network,ou=Register,o=eudil,c=fr"
$ ldapsearch -x -b "dc=RG20,$PORTS" -s base
dn: dc=RG20,dc=ports,dc=network,ou=Register,o=eudil,c=fr
objectClass: top

Voici un exemple d'objet "commutateur" :

$ PORTS="dc=ports,dc=network,ou=Register,o=eudil,c=fr"
$ ldapsearch -x -b "dc=2924M-1,dc=RG20,$PORTS" -s base
dn: dc=2924M-1,dc=RG20,dc=ports,dc=network,ou=Register,o=eudil,c=fr
nbports: 24
vlans:: MTpBTEw6CjI6QUxMOgozOkFMTDoKNDpTVEFGRjpBVVRPCjU6U1RBRkY
type: cisco2924M-giga
ipAddress: 172.26.224.16
objectClass: top

Donnez l'extrait du fichier de configuration de slapd permettant de :

donner l'accès en écriture aux attributs d'un commutateur uniquement à l'objet administrateur cn=admin,ou=People,o=eudil,c=fr,
donner l'accès en lecture aux attributs d'un commutateur à l'exception de l'attribut vlans à tous les utilisateurs standards.

Donnez la commande pour afficher la liste des objets "locaux techniques" de l'école sans afficher les objets concernant les éléments actifs (est-il possible de n'avoir que des objets "locaux techniques" ?). Affichez tous les objets des commutateurs de type cisco2950G.

Voici l'extrait des contrôles d'accès dans slapd.conf :
access to attrs=vlans
  by dn="cn=admin,ou=People,o=eudil,c=fr" write
  by * none

access to attrs=nbports,type,ipAddress
  by dn="cn=admin,ou=People,o=eudil,c=fr" write
  by * read
Recherche des locaux techniques (avec en plus l'objet représentant la racine des objets "locaux techniques") :
$ PORTS="dc=ports,dc=network,ou=Register,o=eudil,c=fr"
$ ldapsearch -x -b "$PORTS" -s one
La liste des commutateurs les plus récents :
$ PORTS="dc=ports,dc=network,ou=Register,o=eudil,c=fr"
$ ldapsearch -x -b "$PORTS" type=cisco2950G

4.0.11 Configuration d'un DNS

Extrapolez vos connaissances sur la configuration d'un serveur DNS de type bind en IPv4 pour donner les fichiers de configuration nécessaires pour servir une zone IPv6. La zone à servir est ipv6.eudil.fr et contient des machines dans le préfixe IPv6 3ffe:0304:0110:0001:0:0:0:0/64. Il n'y a que deux machines dans cette zone :

pevele d'adresse IPv6 3ffe:0304:0110:0001:0260:08ff:fe71:b982 et
hainaut d'adresse IPv6 3ffe:0304:0110:0001:0260:08ff:fe71:b9be.

Pour ces zones IPv6 il n'existe qu'un seul serveur primaire pevele.eudil.fr et un seul serveur secondaire albanie.ilot.org. Donnez l'extrait du fichier named.conf déclarant la zone IPv6 et la zone inverse (rappelons que la racine pour les zones inverses IPv6 est ip6.int). Donnez le fichier déclarant les deux machines dans la zone ipv6.eudil.fr. Enfin, donnez le fichier déclarant les deux noms dans la zone inverse.

Le deux zones sont déclarées comme suit dans named.conf :

zone "ipv6.eudil.fr" {
        type master;
        file "eudil/eudilv6";
};
zone "1.0.0.0.0.1.1.0.4.0.3.0.e.f.f.3.ip6.int" {
        type master;
        file "eudil/eudilv6.rev";
};

Le fichier eudil/eudilv6 de la zone directe est :

@ IN  SOA pevele.eudil.fr.  hostmaster.pevele.eudil.fr. (
          3236765269 21600 3600 2592000 3600 )
  IN  NS  pevele.eudil.fr.
  IN  NS  albanie.ilot.org.

pevele  IN  AAAA 3ffe:0304:0110:0001:0260:08ff:fe71:b982
hainaut IN  AAAA 3ffe:0304:0110:0001:0260:08ff:fe71:b9be

Le fichier eudil/eudilv6.rev de la zone inverse est :

@ IN  SOA pevele.eudil.fr.  hostmaster.pevele.eudil.fr. (
          3236765269 21600 3600 2592000 3600 )
  IN  NS  pevele.eudil.fr.
  IN  NS  albanie.ilot.org.

2.8.9.b.1.7.e.f.f.f.8.0.0.6.2.0 IN  PTR  pevele.ipv6.eudil.fr.
e.b.9.b.1.7.e.f.f.f.8.0.0.6.2.0 IN  PTR  hainaut.ipv6.eudil.fr.

4.0.12 Exercice de réflexion

Pour assurer la sécurité des machines de l'Université, le CRI de l'USTL a décidé d'interdire tout flux TCP/IP entrant. Par défaut aucun paquet IP provenant d'Internet à destination des machines de l'USTL ne peut passer. L'application stricte de la règle ci-dessus interdirait tout usage d'Internet aux utilisateurs de l'Université donc deux exceptions ont été introduites.

La première concerne les réponses TCP : les paquets TCP autres que le premier paquet d'une connexion TCP (le fameux SYN) peuvent atteindre les machines de l'USTL. Ainsi lorsqu'une connexion TCP est initiée par une machine de l'Université, les paquets de retour de cette connexion peuvent passer le parefeu du CRI.

La seconde exception concerne la possibilité pour les machines de l'USTL de faire des requêtes FTP en mode actif. C'est cette exception qui sera le principal objet de l'exercice.

Enfin il existe des exceptions particulières (les deux précédentes sont générales et s'appliquent à toutes les machines de l'USTL) qui permettent à des machines précises, connues par leur numéros IP, de rendre des services vis à vis de l'extérieur (serveurs de messagerie, de pages web, etc.).

Première série de questions

Ces questions ne concernent que la première exception et les exceptions particulères. Que se passe-t-il si une machine d'Internet tente d'envoyer à une machine du campus un paquet TCP autre qu'un paquet SYN et autre qu'un paquet de réponse pour une connexion TCP établie ? (dites si le paquet passe le parefeu et l'éventuel type de réponse de la machine ciblée). Que pensez-vous du degré de sécurité des exceptions particulières ? (une machine du campus peut-elle usurper des droits donnés à une autre machine ? si oui comment ?).

Si une machine extérieure tente d'envoyer à une machine de l'USTL un paquet IP ne faisant pas partie d'une connexion déjà établie, le paquet est soit rejeté par le parefeu (cas d'un paquet SYN, ce qui interdit une ouverture de connexion provenant de l'Internet) soit passe jusqu'à la machine de l'USTL (paquet TCP autre que le paquet SYN). Dans le dernier cas, le paquet ne peut pas être rattaché à une connexion établie (mauvaise adresse IP source, mauvais port source ou destination ou mauvais numéro de séquence). La machine de l'USTL retourne donc un paquet TCP RST (reset) pour signaler une erreur de connexion TCP.

Les exceptions particulières ne reposent que sur les adresses IP des machines destination (machines de l'USTL). Il est donc possible qu'une autre machine de l'USTL usurpe les droits d'une machine privilégiée en utilisant son adresse IP (par exemple en la mettant hors service avec une attaque réseau puis en reconfigurant son interface réseau avec l'adresse IP de la machine privilégiée).

Seconde série de questions

Quel mécanisme utilisé par un client FTP en mode actif oblige le CRI à créer une seconde exception générale ? Donnez en français la règle statique la moins permissive possible permettant aux clients FTP de l'USTL de fonctionner en mode actif. Donnez cette même règle en terme d'ACL Cisco puis en terme de commande iptables pour une machine Linux (on suppose que la machine Linux a sa carte eth0 pour sortir sur Internet et sa carte eth1 pour accéder au réseau local). Par statique on entend que la règle ne prend pas en compte le contenu des paquets précédents pour autoriser le passage d'un paquet.

Pour récupérer des données (fichier ou liste de répertoire) un client FTP en mode actif lance un serveur TCP sur la machine locale et demande au serveur FTP (via la connexion de commande) de contacter ce serveur TCP pour transférer ces données. Le serveur FTP contacte le client FTP à partir de son port TCP ftp-data (port numéro 20).

Le parfeu du CRI doit donc laisser passer toute connexion TCP initiée de l'Internet d'un port 20 vers l'USTL sur un port supérieur ou égal à 1024 (port utilisateur).

La règle cisco se définie par les commandes IOS suivantes :
access-list 100 allow tcp any eq 20 any gt 1023
...
interface fastEthernet0
  ip access-group 100 in
!
Les commandes pour Linux sont :
iptables -P FORWARD 
iptables -A FORWARD -j ACCEPT -p tcp -i eth0 -o eth1 \
                              --sport ftp-data --dport 1024:

Troisième série de questions

Comment exploiter cette exception à l'interdiction des paquets entrants pour réussir à établir une connexion ssh entre une machine de l'USTL que vous administrez et une machine de l'extérieur que vous administrez également ? Plus précisément quel paramètre du serveur sshd devez-vous modifier par rapport à une installation classique sur la machine à l'USTL ? Quel micro-bout de code devez-vous ajouter au source du client ssh sur la machine extérieure ? Dans quelles conditions et avec quels arguments doit être exécuté le client ssh sur la machine externe ?

L'exploitation de la faille consiste à établir une connexion ssh du port 20 de la machine extérieure vers un port utilisateur de la machine USTL.

Le serveur sshd sur la machine USTL doit aussi écouter sur un port utilisateur. Pour un serveur sshd sous Linux il faut ajouter la ligne Port 2222 (par exemple) dans le fichier /etc/ssh/sshd_config.

Il n'est pas possible de forcer la commande ssh actuelle de Linux à se lier au port 20 de la machine locale. Aussi il faut ajouter un bout de code dans le fichier sshconnect.c des sources du logiciel openssh-3.4p1. Le bout de code est à ajouter dans la fonction ssh_create_socket juste après l'appel à socket :
{ struct sockaddr_in address;
  address.sin_family=family;
  address.sin_addr.s_addr=INADDR_ANY;
  address.sin_port=htons(20);
  bind(sock,(struct sockaddr *)&address,sizeof(address));
  }
Comme seul le super administrateur a le droit de lier une socket TCP à un port système (port entre 0 et 1023), la commande ssh modifiée doit être lancée par root ou porter le bit u+s avec root comme propriétaire. La commande à utiliser est simplement ssh -p 2222 mysshd.univ-lille1.fr.

Quatrième série de questions

Une fois la connexion par ssh possible, quelle ligne de commande basée sur ssh doit-on utiliser pour pouvoir atteindre le serveur web de la machine USTL à partir de la machine externe ? Quelle URL doit-on utiliser ? Enfin quel mécanisme complexe faudrait-il utiliser pour éviter ce "trou de sécurité" ? Ce mécanisme pourrait-il être contourné et si oui comment ?

On peut utiliser ssh comme tunnel pour atteindre un serveur web à l'USTL (on prend l'exemple du serveur web de weppes) :
ssh -p 2222 -L 8080:weppes.priv.eudil.fr:80 mysshd.univ-lille1.fr
L'URL à utiliser est alors http://localhost:8080/.

Pour éviter le trou de sécurité du à la règle de filtrage statique, il suffit d'utiliser une règle dynamique qui n'autorise que les connexions entrantes correspondant à des directives PORT envoyées par des clients FTP de l'USTL. Ce mécanisme peut encore être contourné par le lancement périodique d'un pseudo-client FTP qui ne fait rien que d'envoyer la directive PORT pour le port 2222 sur le serveur FTP de la machine extérieure.

Dernière série de questions

Supposez désormais que l'on souhaite plutôt accèder à la machine USTL via FTP. On suppose que l'on procède comme pour ssh en ce qui concerne le serveur à l'USTL et le client à l'extérieur. Le client FTP peut-il fonctionner en mode actif ? pourquoi ? peut-il fonctionner en mode passif ? pourquoi ?

Le client peut fonctionner en mode actif car c'est le serveur FTP qui va tenter d'ouvrir une connexion (de son port 20 vers un port utilisateur du client FTP). Le parefeu laisse passer les connexions initiées de l'USTL. Par contre le mode passif ne marche pas car le serveur FTP va lancer un serveur TCP sur un port utilisateur que le client FTP de l'extérieur doit contacter. C'est interdit par le parefeu (sauf autorisation particulière).