Un petit guide pour la sécurité

C'est très simple : lorsqu'un serveur offre un service particulier (Web, messagerie, mail), il exécute un programme assurant ce service. Ce programme est en attente de connexions. Les clients devant accéder à ce service doivent connaitre l'adresse IP du serveur et le numéro de port associé au service. Ce numéro de port a été attribué suivant le document standard RFC1010 au programme exécutant ce service. Sur les systèmes Linux et *BSD la liste de ces numéros est disponible dans le fichier /etc/services. La plupart des services ont un numéro de port bien défini. Par exemple, un serveur de messagerie utilise le port 25, un serveur Web le port 80… Lorsqu'un service est en écoute sur un port, on dit que le numéro de port associé à ce service est ouvert. L'intérêt du scanner est très simple : il permet de trouver dans un délai très court, tous les ports ouverts sur une machine distante. Il existe différents types de scanner, certains se contentent juste de donner : la liste des ports ouverts, le type et la version de l'OS tournant sur le serveur (ces fonctionnalités seront décrites dans ce chapitre avec Nmap). D'autres scanners comme Nessus permettent de tester différentes failles connues sur ces services. Voir Section 4.5, « Nessus ».

3-2-1-1. Exemple avec Nmap▲

[root@nowhere.net /root]# nmap 192.168.1.1

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Interesting ports on (192.168.1.1) :
(The 1544 ports scanned but not shown below are in state : closed)
Port State Service
21/tcp open ftp
53/tcp open domain
80/tcp open http
110/tcp open pop-3
111/tcp open sunrpc
113/tcp open auth
631/tcp open cups
845/tcp open unknown
901/tcp open samba-swat
10000/tcp open snet-sensor-mgmt

Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds.

Je présenterai de manière très succincte Nmap et me focaliserai principalement sur les fonctions les plus utilisées.

Pour connaitre les ports ouverts sur une machine, Nmap procède à l'envoi de paquets sur tous les ports de cette machine et analyse les réponses. Bien sûr, il y a différents types de scans, donc différents types d'envois et donc, différents types de réponses.

Nous nous intéresserons aux scans utilisant le protocole TCP (les scans UDP et ICMP étant possibles eux aussi).

3-2-2-1. Le scan vanilla TCP connect▲

[root@nowhere.net /root]# nmap [ip de la machine cible]

  ou

[root@nowhere.net /root]# nmap -sT [ip de la machine cible]

3-2-2-2. Les scans furtifs▲

Nous rentrons maintenant dans une classe de scans plus difficiles à détecter :

Le scan en connexion demi-ouverte ou « Syn-scan »

Nmap envoie sur chaque port un paquet TCP avec le flag SYN armé ; si un port est ouvert, il renverra un paquet avec les flags SYN et ACK armés. Illustration :

La commande se fait par l'appel de nmap avec l'option -sS :

 

Sélectionnez

[root@nowhere.net /root]# nmap -sS [adresse IP de la machine cible]

Les scans Xmas, FIN et NULL

Le scan FIN consiste en l'envoi de paquets TCP avec seulement le flag FIN armé. La commande se fait par l'appel de nmap avec l'option -sF :

 

Sélectionnez

[root@nowhere.net /root]# nmap -sF [adresse IP de la machine cible]

Le scan NULL consiste en l'envoi de paquets TCP avec seulement le flag NULL armé. La commande se fait par l'appel de nmap avec l'option -sN :

 

Sélectionnez

[root@nowhere.net /root]# nmap -sN [adresse IP de la machine cible]

Le Xmas scan (traduisez le scan de Noël) consiste en l'envoi de paquets TCP avec les flags FIN/URG/PUSH armés. La commande se fait par l'appel de nmap avec l'option -sX :

 

Sélectionnez

[root@nowhere.net /root]# nmap -sX [adresse IP de la machine cible]

Pour ces trois types de scans, les systèmes répondent avec un paquet RST si le port est fermé et ne répondent pas si le port est ouvert. Le NULL scan ne fonctionne pas contre des plateformes Microsoft. Illustration :

Si on lance Nmap avec l'option -O :

[root@nowhere.net /root]# nmap -O 192.168.0.1

Starting nmap 3.48 ( http://www.insecure.org/nmap/ )
Interesting ports on (192.168.0.1):
(The 1647 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
22/tcp  open  ssh
25/tcp  open  smtp
53/tcp  open  domain
80/tcp  open  http
113/tcp open  auth
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds
515/tcp open  printer
587/tcp open  submission
901/tcp open  samba-swat
Device type: general purpose
Running: Linux 2.4.X (1)
OS details: Linux 2.4.20 - 2.4.21 w/grsecurity.org patch
Uptime 76.872 days (since Tue Sep  2 15:20:23 2003)

Nmap run completed -- 1 IP address (1 host up) scanned in 7.030 seconds

• Notez bien cette ligne : Linux 2.4.X.

Nmap parvient à déterminer le système d'exploitation tournant sur la machine cible. La machine cible utilise un noyau Linux 2.4.21-grsec. Nmap ne s'est pas trompé.

Il faut savoir que chaque système d'exploitation construit ses paquets d'une manière bien particulière. Certains champs au niveau de la couche IP ou TCP sont propres à chaque système d'exploitation. Nmap contient une base de données d'un grand nombre de systèmes. Nmap envoie donc des paquets tests à la machine cible et compare les paquets reçus en réponse à ceux de sa base de données et en déduit le type de système.

Cette base de données est mise à jour en fonction des différentes version de Nmap.

Nmap offre la possibilité de prévoir les futures attaques, et aussi de connaitre quels services tournent sur une machine. Une installation faite un peu trop vite peut laisser des services en écoute (donc des ports ouverts sans que cela ne soit nécessaire) et donc vulnérables à une attaque. N'hésitez pas à utiliser Nmap contre vos serveurs pour savoir quels ports sont en écoute.

Nmap est un logiciel très complet et très évolutif, et il est une référence dans le domaine du scanning.

Configurer votre pare-feu pour empêcher les scans :

[root@nowhere /root]# iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Cette commande permet de détecter l'envoi un grand nombre de paquets TCP avec les flags FIN et/ou SYN et/ou ACK et/ou RST armé(s). Vérifiez que votre pare-feu (si ce n'est pas iptables) supporte la détection de scans.

• Je vous conseille de lire Utiliser iptables :Spécifications de filtrage.
• Divers articles écris par le développeur de Nmap sur le scanning (en anglais) : The Art of Port Scanning, Remote OS detection via TCP/IP Stack FingerPrinting et ICMP based remote OS TCP/IP stack fingerprinting techniques.

Netcat permet d'établir une connexion (TCP ou UDP) sur un port souhaité et d'y envoyer ou d'y recevoir des données. Voici un exemple :

[root@nowhere.net /root]# nc 192.168.1.1 21

220 ProFTPD 1.2.5rc1 Server (ProFTPD Default Installation) [neuromancer]

On obtient directement la version du logiciel utilisé.

Netcat comporte plein d'autres fonctionnalités (comme l'envoi de scripts…). Le pirate n'a plus qu'à trouver une faille applicative (voir chapitre suivant) sur le logiciel correspondant.

3-3-1-1. Comment s'en protéger ?▲

Ce type de faille empêche le logiciel de fonctionner et ainsi de répondre aux requêtes demandées (d'où l'appellation déni de service). La technique est simple, il suffit d'utiliser un bogue connu qui va faire planter le logiciel assurant un service.

Les bogues de type dépassement de buffer ou d'exploitation de bogues de format posent de gros problèmes de sécurité. Ils visent majoritairement des applications fonctionnant avec les accès administrateur (setuid root) pour permettre à un attaquant d'obtenir un interpréteur de commande au niveau administrateur (uid root) sans aucune authentification.

Malheureusement, une mauvaise programmation de scripts ou l'utilisation de fonctions boguées peut être source de failles de sécurité. Il convient d'être très attentif au niveau du développement d'un script.

Pour bien configurer son pare-feu, il suffit de bien respecter les conseils suivants :

• Essayez de limiter l'accès à votre réseau par des utilisateurs connus utilisant une adresse IP statique. Vous pourrez ainsi rejeter toutes les autres requêtes venant d'utilisateurs utilisant une adresse IP non autorisée. Vous effectuez de la sorte un filtrage au niveau IP.
• Fermez tous les ports en écoute sur les différents serveurs et ouvrez seulement ceux dont vous avez besoin.
• Filtrez ces ports, c'est-à-dire rejetez toutes les autres requêtes sur les autres ports que ceux en écoute.
• Empêchez toutes les connexions sortantes sur des services non autorisés. Pour cela, il suffit de définir un nombre limité de services auxquels les serveurs et les clients peuvent accéder (mail, ftp, web…). Ensuite, il faut configurer le firewall pour rejeter les connexions depuis l'intérieur vers l'extérieur sur des services différant de ceux définis.

La première étape lors d'une attaque est de déterminer les règles actives sur le pare-feu. Le but est simple : savoir quels ports ne sont pas filtrés.

5-2-2-1. Avec le scanner▲

[root@nowhere.net /root]# nmap 192.168.1.2

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Interesting ports on (192.168.1.2) :
(The 1549 ports scanned but not shown below are in state : closed)
Port State Service
21/tcp filtered ftp
22/tcp filtered ssh
111/tcp open sunrpc
515/tcp open printer
1024/tcp open kdm

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second

5-2-2-2. Comment s'en protéger ?▲

5-2-2-3. Le firewalking▲

Prelude Hybrid IDS est un des détecteurs d'intrusions les plus connus. Prelude est disponible et libre sur les plateformes Linux, FreeBSD et Windows.

Prelude possède une architecture modulaire et distribuée. Modulaire, car ses composants sont indépendants, et peuvent être facilement mis à jour. Distribuée, car ces composants indépendants interagissent les uns avec les autres. Cela permet d'avoir divers composants installés sur différentes machines et de réduire ainsi la surcharge d'applications.

Ces différents composants sont les sondes et les managers. Les sondes peuvent être de deux types : réseau ou locale. Une sonde réseau analyse tout le trafic, pour y détecter d'éventuelles signatures d'attaques. La sonde locale assure la surveillance d'une seule machine, elle analyse le comportement du système pour y détecter des tentatives d'exploitation de vulnérabilités internes. Les sondes signalent les tentatives d'attaques par des alertes. Ces alertes sont reçues par le manager qui les interprète et les stocke.

Pour une description complète de Prelude (installation, configuration et utilisation) consultez ce document : http://lehmann.free.fr/PreludeInstall/InstallPrelude.html

Snort, téléchargeable librement sur www.snort.org, est un NIDS lui aussi. Il n'est pas structuré comme Prelude. Snort est un programme « monolithique », il ne comporte pas de module comme Prelude, ce qui peut rendre son implémentation dans un réseau un peu moins souple que Prelude. Snort fonctionne en trois modes (Sniffer, PacketLogger et NIDS). Les deux premiers modes ne sont pas intéressants pour la détection d'intrusion. Le troisième mode permet, lui, d'analyser le trafic réseau pour y détecter d'éventuelles attaques.

Pour une description complète de Snort (installation, configuration et utilisation) consultez ce site : http://www.snort.org/docs/ (en anglais).

Le protocole AH (Authentification Header) permet de garantir l'authenticité des paquets échangés en leur inscrivant une somme de contrôle (de l'en-tête IP jusqu'à la fin du paquet) chiffrée.

Le protocole ESP (Encapsulating Security Payload) encrypte toutes les données du paquet, garantissant leur confidentialité.

Le protocole IPcomp (IP payload compression) permet de compresser un paquet avant de le chiffrer avec ESP.

Le protocole IKE (Internet Key Exchange) est utilisé pour l'échange des clés utilisées pour l'encryptage.

AH, ESP et IPcomp fonctionnent dans le mode transport ou le mode tunnel. Le mode « transport » encrypte directement les échanges entre deux machines. Le mode « tunnel » encapsule les paquets encryptés dans de nouveaux en-tête IPv4/IPv6. Il est conçu pour les passerelles VPN.

IPsec pose quelques problèmes dus à son implémentation. Certains problèmes apparaissent au niveau des messages de broadcast et multicast. IPsec est difficile à filtrer sur les firewalls existants. Il est aussi impossible à gérer pour les traductions d'adresse (NAT).

Description générale des tunnels et implémentation sous Linux : MISC Magazine n°15 - IPsec et Linux 2.6 http://www.securiteinfo.com/cryptographie/IPSec.shtml Description générale des tunnels et implémentation sous Windows : http://www.laboratoire-microsoft.org/articles/network/ipsec/

Pour télécharger les sources, binaires, ou différents documents concernant Nessus, consultez le site : http ://www.nessus.org

La page web de User Mode Linux : http://user-mode-linux.sourceforge.net

La plupart des antivirus peuvent détecter les chevaux de Troie. Néanmoins, comparer la signature numérique accompagnant les fichiers (cela se fait par un calcul reposant sur un algorithme de chiffrement appliqué à l'ensemble du fichier) avec la sienne permet de savoir directement si l'on est infecté.

Il est aussi conseillé de consulter les sites suivants pour vérifier que vos programmes ne contiennent pas de chevaux de Troie :

• Le CERT (Computer Emergency Response Team) est un organisme s'occupant des problèmes de sécurité sur Internet. Il recense les différents problèmes de sécurité et publie des articles (advisories) pour les décrire.
• Bugtraq : http://seclists.org/bugtraq/

Parfois, certains logiciels (messagerie, utilitaires système) peuvent contenir des backdoors, c'est-à-dire que, pour certaines commandes suivies d'arguments particuliers ou avec un mot de passe bien défini, le logiciel peut avoir un comportement différent (permettre à l'utilisateur de devenir root, renvoyer un shell système à l'utilisateur, etc.).

Ces « trappes » sont incluses directement dans le code du logiciel. Certains développeurs sont soucieux de posséder un accès sur tous les systèmes utilisant leurs logiciels. Par exemple, Ken Thompson, l'un des pères d'UNIX, avoue avoir modifié l'application /bin/login en permettant l'accès direct au système par la saisie d'un mot de passe précompilé en dur. Thompson pouvait ainsi visiter tous les systèmes utilisant son application modifiée. Parfois, certains pirates diffusent des applications infestées de backdoors.

6-3-1-1. Comment s'en protéger ?▲

Ces backdoors peuvent très bien faire partie de la première catégorie. Comme il a été montré, certains logiciels peuvent autoriser un accès pour un mot de passe particulier. Toutefois, ce paragraphe va se focaliser sur des applications en écoute sur un port bien défini utilisées par les pirates pour obtenir un shell. Un logiciel préalablement installé par le pirate est en attente de connexion sur un port discret. La plupart de ces programmes sont en écoute sur des numéros de ports ayant une valeur assez élevée (supérieure à 5000). Le pirate n'a plus qu'à se connecter sur ce programme pour récupérer son accès sur la machine.

6-3-2-1. Comment s'en protéger ?▲

• Les checksums. Une base de données de checksums sur les différents fichiers système peut déjà constituer une bonne parade. Je vous conseille d'effectuer des checksums à la fin d'une installation sur les différents fichiers comme ls, ps, stat ifconfig, etc. et sur les différentes bibliothèques partagées.
  Cette base de données devrait être stockée sur un CDROM ou tout autre support non réinscriptible.
• Compiler les programmes vitaux en statique. Comme je l'ai dit précédemment, certaines commandes font appel à des bibliothèques partagées et des utilitaires comme « md5sum » (qui sert à faire des checksums) sous Linux. D'où son comportement pourrait être modifié indirectement par un rootkit attaquant les bibliothèques partagées. Pour éviter ce genre de désagrément, compilez une partie des programmes vitaux en statique, ainsi vous disposerez d'une trousse de secours en cas d'infection par rootkits. Bien sûr, pour compiler les programmes vitaux en statique, faut-il encore disposer d'un OS qui permette d'accéder aux sources de ces programmes vitaux…
• Chkrootkit. Chkrootkit (pour CHecK ROOTKIT) vous permet de détecter la présence d'un rootkit, il fonctionne sous Linux (FreeBsd…) et est téléchargeable librement sur www.chkrootkit.org.
• Compilez votre noyau en statique. Vous éviterez ainsi le chargement de modules externes.

Là, c'est très difficile. Un sniffer est passif, il n'envoie aucun paquet, il ne fait qu'intercepter. Mais la carte réseau étant en mode transparent, son comportement s'en trouve changé, son temps et sa façon de répondre à certains paquets sont modifiés. On peut détecter la présence d'un sniffer grâce à ce changement de comportement. Le programme AntiSniff, disponible sur Windows NT et Linux à l'adresse http://packetstormsecurity.org/sniffers/antisniff/ de Lopht Heavy Industries peut envoyer des paquets « tests » et en déduire si la carte est en mode transparent, donc susceptible de sniffer.

Une deuxième parade pour déjouer le sniffing est de « tunneler » toutes les transactions. Cela veut dire encrypter toutes les transactions réseau. Utiliser IpvSec ou des VPN, ssh sur votre réseau s'avère être une défense efficace contre le sniffing.

L'utilisation de tunnels est traitée dans la Section 4.4, « Le tunneling ».

Les antivirus commerciaux comme Norton Antivirus ou McAfee VirusScan sont de bons outils pour traquer les virus. Toutefois, il convient de les mettre régulièrement à jour pour profiter pleinement de leurs capacités.

Il est aussi important de suivre l'évolution et l'apparition de nouveaux virus ; pour cela, consulter les sites (ainsi que pour tous les autres dispositifs destructeurs décrits dans ce chapitre) :

• Le CERT en anglais.
• Les sites du CNRS : Liste de diffusion du CNRS sur les virus

Comme pour les virus, l'antivirus se révèle être une parade efficace. Consultez les listes citées dans la Section 6.2, « Le virus ».

Utilisez un antivirus performant (McAfee, Norton …) régulièrement mis à jour.

Consultez les sites décrits dans la Section 6.2, « Le virus ».

Cette technique consiste à saturer un serveur en envoyant une multitude de paquets TCP avec le flag SYN armé, cela aura pour but de créer une multitude de connexions demandant un grand nombre de ressources système.

La plupart des attaques par SYN-flood sont bien détectées par différents firewalls.

7-5-1-1. Comment s'en protéger ?▲

[root@nowhere /root]# iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT

De la même manière que pour le SYN flooding, l'attaquant envoie un grand nombre de requêtes UDP sur une machine. Le trafic UDP étant prioritaire sur le trafic TCP, ce type d'attaque peut vite troubler et saturer le trafic transitant sur le réseau.

La plus célèbre attaque utilisant l'UDP-flooding est le Chargen Denial of Service Attack. Un pirate envoie une requête sur le port echo d'une machine A indiquant comme port source celui du port chargen d'une machine B. Le service chargen de la machine B renvoie un caractère sur le port echo de la machine A.

Ensuite le service echo de A renvoie ce caractère sur chargen. chargen le reçoit, en ajoute un autre et les renvoie sur le port echo de A qui les renvoie à son tour sur chargen … et cela continue jusqu'à la saturation de la bande passante.

7-5-2-1. Comment s'en protéger ?▲

[root@nowhere /root]# iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT

Plus connu sous le nom de Teardrop Attack, Bonk ou encore Boink, cette attaque utilise une faille propre à certaines piles TCP/IP. Cette vulnérabilité concerne la gestion de la fragmentation IP.

Ce problème apparaît lorsque la pile reçoit le deuxième fragment d'un paquet TCP contenant comme donnée le premier fragment. La pile TCP/IP peut s'avérer incapable de gérer cette exception et le reste du trafic.

Cette faille est très connue sur les piles de Windows 95 et 98.

Le principe est d'envoyer un paquet ICMP avec une quantité de données supérieure à la taille maximale d'un paquet IP . Encore une fois, la pile peut s'avérer incapable de gérer cette exception et le reste du trafic.

Cette attaque est basée sur le protocole ICMP. Lorsqu'on envoie un ping à un réseau en broadcast (par exemple 255.255.255.0), le paquet est envoyé à chacune des machines du réseau.

Un pirate envoie un ping en broadcast sur un réseau (A) avec une adresse IP source correspondant à celle de la machine cible (B). Le flux entre le port ping de la cible (B) et du réseau (A) sera multiplié par le nombre de machines sur le réseau (A).

Cela conduit à une saturation de la bande passante du réseau (A) et du système de traitement de paquets de (B).

7-5-5-1. Comment s'en protéger ?▲

# iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT

Plusieurs types d'attaques sont lancés en parallèle à partir de plusieurs sources.

Le mail bombing consiste à envoyer de gros ou de nombreux fichiers à un utilisateur pour saturer sa boîte de réception de courrier électronique.

7-5-7-1. Comment s'en protéger ?▲

Toute carte réseau possède une adresse physique. C'est cette adresse qui lui permet de recevoir les paquets qui lui sont destinés sur le réseau local. Cette adresse physique est associée à l'adresse IP grâce au protocole ARP. La table de correspondance entre les adresses IP et les adresses physiques est contenue dans le cache ARP. Lorsqu'un échange doit s'établir entre 2 machines du réseau local, ces deux machines envoient des requêtes ARP avec l'adresse IP du récepteur, associée à un champ vide pour son adresse physique. Ce récepteur va renvoyer son adresse physique dans une réponse ARP.

Si un attaquant envoie un message de réponse ARP avec son adresse physique correspondant à l'adresse IP du récepteur, tout le flux IP dirigé vers le récepteur sera redirigé vers l'attaquant. On dit qu'il a empoisonné le cache ARP du récepteur.

Illustration :

9-2-1-1. Comment s'en protéger ?▲

9-2-1-2. Documents▲

L'ARP-Poisining permet de rediriger tout le trafic IP mais, si l'attaquant n'a besoin que du trafic TCP, il peut interférer dans une connexion client-serveur pour rediriger le flux du client vers lui. La synchronisation TCP est assurée par les numéros de séquences TCP. Si, pendant un échange, l'attaquant envoie des paquets mal formés au client avec une adresse IP correspondant à celle du serveur en y plaçant des mauvais numéros de séquences, le client va croire qu'il a perdu la connexion et stoppera ses échanges avec le serveur. Mais si l'attaquant envoie les bons numéros de séquences au serveur, il récupérera la connexion pour lui.

Illustration :

Le document Man-In-the-Middle Attack est très complet sur cette question.

Comme il a été décrit, un serveur DHCP possède un stock d'adresses IP qu'il distribue aux différents clients. Ce stock est bien sûr limité. Il y aura seulement un nombre défini de clients pouvant disposer des différentes adresses IP en même temps. Si le serveur est bien administré avec une liste «fermée» de correspondances entre adresses MAC et IP aucune attaque par épuisement n'est possible.

Si le service est mal administré ; c'est-à-dire que les correspondances entre adresses MAC et IP se font dynamiquement à partir d'une plage d'adresses IP vacantes, le scénario suivant est possible.

Si un pirate génère un grand nombre de requêtes DHCP semblant venir d'un grand nombre de clients différents, le serveur épuisera vite son stock d'adresses. Les «vrais» clients ne pourront donc plus obtenir d'adresse IP : le trafic réseau sera paralysé.

Cette attaque vient en complément de la première. Si un pirate a réussi à saturer un serveur DHCP par épuisement de ressources, il peut très bien en activer un autre à la place. Ainsi, il pourra contrôler tout le trafic réseau.

Chaque fois que c'est possible, il faut limiter le service DHCP à une liste «fermée» de correspondances d'adresses MAC et IP. De cette façon toute requête « étrangère » à cette liste est systématiquement rejetée.

• Sous Windows, remplissez les champs de l'option Réservations dans le programme de configuration du serveur DHCP
• Sous Linux, éditez le fichier /etc/dhcpd.conf sur le serveur DHCP. Par exemple, pour un client toto avec l'adresse MAC 00:C0:34:45:56:67 à laquelle on fait correspondre : l'adresse 192.168.1.2, le routeur 192.168.1.1 et le serveur de noms 192.168.1.3.

host toto {
  hardware ethernet 00:C0:34:45:56:67;
  fixed-address 192.168.1.2;
  option routers 192.168.1.1;
  option domain-name-server 192.168.1.3;
  }

S'il est impossible d'établir une liste « fermée », segmentez votre réseau en sous-réseaux et attribuez-leur à chacun un serveur DHCP. Ces serveurs seront indépendants les uns des autres.

Enfin, les nouvelles versions du protocole DHCP permettent l'utilisation de mécanismes d'authentification plus stricts. Assurez-vous que vos serveurs utilisent ces versions de protocoles (Voir RFC3118).

• Sécurisation sous Windows : [FIXIT]
• Sous Linux : Installation d'un serveur DHCP et How to make Network Configuration as easy as DHCP

C'est la première attaque que nous allons décrire. Elle aboutit à un détournement de flux entre deux machines à l'avantage du pirate.

Imaginons qu'un client A veuille établir une connexion avec une machine B. La machine A connaît le nom de la machine B mais pas son adresse IP, ce qui l'empêche de pouvoir communiquer avec. La machine A va donc envoyer une requête au serveur DNS du réseau de B pour connaître l'adresse IP de B, cette requête sera identifiée par un numéro d' identification (ID). Le serveur répond à cette requête en fournissant l'adresse IP de B et en utilisant le même numéro d'ID.

Ce numéro a une valeur comprise entre 0 et 65535.

Le DNS ID spoofing a pour but de d'envoyer une fausse réponse à une requête DNS avant le serveur DNS. De cette façon, le pirate peut rediriger vers lui le trafic à destination d'une machine qui l'intéresse.

Dans notre exemple, un pirate C doit répondre à A avant le serveur DNS (D) du réseau de B. Ainsi, il envoie à A son adresse IP associée au nom de la machine B. A communiquera alors avec le pirate C au lieu de la machine B.

Illustration :

Néanmoins, pour implémenter cette attaque, le pirate doit connaître l'ID de requête DNS. Pour cela, il peut soit utiliser un sniffer s'il est sur le même réseau, soit prédire les numéros d'ID par l'envoi de plusieurs requêtes et l'analyse des réponses.

Le principe de cette attaque est très similaire à celui de l'ARP-Poisoning. Pour gagner du temps dans la gestion des requêtes, le serveur DNS possède un cache temporaire contenant les correspondances adresses IP - noms de machine. En effet, un serveur DNS n'a que la table de correspondance des machines du réseau sur lequel il a autorité. Pour des machines distantes, il doit interroger d'autres serveurs DNS. Pour éviter de les interroger à chaque requête, il garde en mémoire (dans un cache), le résultat des précédentes requêtes.

L'objectif du pirate est d'empoisonner ce cache avec de fausses informations. Pour cela, il doit avoir un nom de domaine sous contrôle et son serveur DNS.

Imaginons qu'un pirate (A) possède le nom de domaine attaquant.com, et son serveur DNS (C) et qu'il veuille empoisonner le cache du serveur DNS (B) du réseau cible.net.

Le pirate envoie une requête au serveur DNS (B) du réseau cible.net demandant la résolution du nom de domaine attaquant.com.

Le serveur DNS (B) de cible.net va donc envoyer une requête sur le serveur DNS (C) de l'attaquant (c'est lui qui a autorité sur le domaine attaquant.com). Celui-ci répondra et joindra des informations additionnelles falsifiées par le pirate (un nom de machine (D) associé à l'adresse IP (A) du pirate). Ces informations seront mises en cache sur le serveur DNS (B) de cible.net. Si un client quelconque (E) demande l'adresse IP pour le nom de la machine (D), il recevra l'adresse du pirate (A) en retour.

Illustration :

Configurez votre serveur DNS pour qu'il ne résolve directement que les noms de machine du réseau sur lequel il a autorité.

Autorisez seulement des machines internes à demander la résolution de noms de domaines distants.

Mettez à jour ou changez les logiciels assurant le service DNS pour qu'ils vous protègent des attaques décrites précédemment.

Il existe de nombreux documents décrivant la configuration du service DNS. Dans le monde GNU/Linux, la référence de base est le DNS HOWTO. On peut aussi citer DNS et sécurité.

En ce qui concerne le volet sécurité, deux références sortent du lot :

• Le guide publié par le CERT : Securing an Internet Name Server est une excellente référence sur la syntaxe des fichiers de déclaration de zones.
• La page Web Secure BIND Template est dédiée à la publication de patrons de fichiers de configuration. Elle est très régulièrement mise à jour depuis plusieurs années.

• Sous UNIX, il est conseillé de désactiver le service finger dans le fichier /etc/inetd.conf. Pour cela, ajoutez un dièse (#) devant la ligne relative au service finger.
   

  Sélectionnez

  # finger stream tcp nowait root /usr/sbin/tcpd in.fingerd

• Sous Windows, désactivez le programme associé au service finger.

Si vous ne souhaitez pas désactiver le service finger, configurez votre firewall pour limiter les accès vers ce service.

Le serveur FTP anonyme pose de plus gros problèmes. Le premier est qu'une mauvaise gestion des droits d'accès peut s'avérer une erreur fatale. Laisser trop de répertoires en droit d'écriture et/ou d'exécution est plus que dangereux pour la sûreté du système. Le pirate pourrait y installer ou y exécuter des codes malveillants lui permettant d'accroître son pouvoir sur la machine.

10-5-1-1. Bouncing attack - Attaque par rebonds▲

Installez un serveur FTP anonyme seulement en cas d'absolue nécessité. Si vous devez le faire, limitez au maximum les droits sur les différents répertoires et fichiers laissés au public.

Pour vous protéger des attaques par sniffer, je vous recommande d'utiliser SFTP (Secure FTP) pour vos transactions FTP. SFTP encryptera les échanges et les protégera ainsi des écoutes indiscrètes. Vous pouvez aussi utiliser des tunnels comme IPSec pour protéger vos connexions (voir Section 4.4, « Le tunneling »).

Filtrez les accès (via un firewall) en allouant seulement l'accès à un certain groupe d'adresses IP (en évitant d'inclure des serveurs anonymes permettant de servir de relais).

Parfois, les bannières des serveurs web sont trop explicites. Exemple sur un serveur Apache :

[root@nowhere /root]# telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 04 Jan 2004 15:07:06 GMT
Server: Apache/1.3.29 (Debian GNU/Linux)
Last-Modified: Sat, 24 Nov 2001 16:48:12 GMT
ETag: "17082-100e-3bffcf4c"
Accept-Ranges: bytes
Content-Length: 4110
Connection: close
Content-Type: text/html; charset=iso-8859-1

Connection closed by foreign host.

Lors de l'envoi de la commande HEAD / HTTP/1.0, trop d'informations sont données.

Les pages d'erreurs (404 : page non trouvée) peuvent aussi contenir des informations sur le système.

La complexité des serveurs ou des navigateurs (clients) Web pose de gros problèmes de sécurité. Ces applications sont vulnérables à de nombreux bogues. Chaque application a son type de faille. Netscape, par exemple, devient vulnérable lors du traitement de certaines chaînes de caractères. Cela peut permettre de remonter toute l'arborescence des fichiers du serveur. Les serveurs IIS peuvent renvoyer un shell système pour un envoi de commandes particulières.

Les langages comme Javascript, Perl, PHP, ASP pour la réalisation de scripts peuvent se révéler dangereux. L'origine d'une faille dans une application Web peut apparaitre à cause de deux problèmes. Le premier est la fiabilité de la conception du script, le second est la fiabilité des fonctions utilisées. Si un script est mal conçu, il peut être la source de nombreuses failles. De même, si sa conception est bonne mais qu'il utilise des fonctions boguées, il peut se révéler encore plus dangereux.

Vérifiez que votre serveur web n'est pas trop bavard. Si c'est le cas, modifiez sa configuration pour qu'il se taise. Pour cela, consultez la documentation pour modifier le contenu des messages d'erreur ou de bienvenue.

Un serveur web ne devrait jamais être exécuté avec les droits administrateur.

Mettez à jour les navigateurs et les serveurs pour prévoir d'éventuelles failles.

Lors du développement de scripts, prenez garde lors de la conception à la gestion des droits des utilisateurs pour son exécution. Informez-vous aussi sur les fonctions connues pour être «sensibles».

Les NIDS peuvent être une bonne parade contre les attaques reposant sur des failles logicielles. Ils permettent de détecter l'exécution de telles attaques (Voir Section 4.3, « Les systèmes de détection d'intrusion (HIDS/NIDS) »).

L'utilisation de SHTTP (Secure HTTP) est aussi une bonne parade contre les attaques HTTP.

Une bonne définition de SHTTP est donné par E.Rescorla et A. Schiffman :

SSL (« Secure Socket Layer » pour Netscape) permet de protéger les transactions Web, il peut être judicieux de l'utiliser.

Sous UNIX, pour désactiver le service ident, ajoutez un dièse (#) pour commenter la ligne concernant ce service dans le fichier /etc/inetd.conf.

# :INFO : Info services
#ident stream tcp wait identd /usr/sbin/identd identd

Le protocole IP est non-orienté connexion, il n'assure aucune vérification de la réception des paquets et ne se soucie guère de la façon de les traiter. IP n'assure qu'un routage d'une adresse vers une autre. Il est donc facile de duper le routage IP en injectant des paquets falsifiés ayant des adresses IP valides sur le réseau.

Le protocole TCP, quant à lui, assure une fiabilité de la remise des paquets grâce à des numéros de séquences qui les distingue un à un. Chaque paquet TCP possède deux numéros, le numéro de séquence et le numéro d'acquittement. Ces deux nombres sont codés sur 32 bits. Ils sont uniques, afin de ne pas confondre les paquets lors de leurs traitements.

C'est sur ces bases que nous allons décrire l'attaque.

Imaginons que le client A est connecté en rsh sur le serveur B. Le pirate C va tenter de voler la connexion au client.

Il va en premier lieu réduire au silence le client en le saturant avec des attaques telles que le syn-flooding, le déni de service (voir Section 6.5, « Les attaques par déni de services »).

La seconde partie de l'attaque est assez simple. Le pirate envoie une série de demandes de connexion au serveur (paquets TCP avec le flag SYN armé) en utilisant l'adresse de A. Le serveur répond avec une série de paquets d'acquittement (flags SYN et ACK armés). C'est là que réside toute la finesse de l'IP spoofing.

Mais d'abord, quelques rappels sur le protocole TCP. Pour l'établissement d'une connexion TCP, le client envoie un paquet avec un numéro de séquence initial (NS1). Le serveur va répondre avec un paquet d'acquittement ayant son propre numéro de séquence (NS2), mais ayant un numéro d'acquittement (NA1) égal au numéro de séquence initial incrémenté d'une unité (NA1=NS1+1). Ensuite le client renvoie un paquet avec un numéro d'acquittement (NA2=NS2+1). Une connexion TCP s'établit donc en trois parties.

Ce principe de numéros de séquences et d'acquittements est utilisé tout au long de la transaction pour en assurer la fiabilité. La subtilité de l'attaque réside dans le fait que le serveur génère la valeur NS2 suivant un cycle particulier. Il peut utiliser, par exemple, soit une fonction générant un nombre aléatoire, soit incrémenter une valeur initiale de 128 toutes les secondes et de 64 après chaque connexion. Tout dépend de l'implémentation de la pile TCP/IP du système.

Et c'est là que réside tout le problème. Le pirate envoie un grand nombre de demandes de connexion dans un laps de temps déterminé et analyse les acquittements du serveur pour déterminer l'algorithme d'incrémentation. Si cet algorithme est basé sur la génération de nombres aléatoires, l'attaque a peu de chances d'aboutir. Mais si l'algorithme est facilement compréhensible, le pirate va alors envoyer une requête de connexion au serveur en utilisant l'adresse IP du client. Le serveur va répondre avec un paquet d'acquittement de numéro de séquence (NS). Le client mis hors service ne pourra répondre, le pirate le fera à sa place.

Pour cela, il doit injecter un paquet ayant un numéro d'acquittement de valeur NA=NS +1. Mais, ayant usurpé l'adresse du client, il ne peut intercepter les paquets lui étant destinés. Il ne peut donc pas connaître cette valeur NS. Il va donc la générer lui-même à partir de son analyse de l'algorithme d'incrémentation. C'est pourquoi cette attaque est aussi qualifiée « d'attaque aveugle ». Si le numéro est valide, le pirate a établi la connexion au serveur en se faisant passer pour le client.

Le fait que l'attaque ne se restreigne qu'à une petite partie de systèmes vient du fait que la plupart des piles TCP/IP utilisent des numéros de séquences basés sur des nombres aléatoires. Certains systèmes comme BSD ou HP-UX connaissent de gros problèmes à cause de l'IP-Spoofing.

Illustration

Nmap invoqué avec les options -O et -v vous fournit une indication sur la difficulté qu'aura le pirate à procéder à une attaque par IP spoofing contre votre serveur.

Exemple :

[root@nowhere /root]# nmap -O -v 192.168.1.4

Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Host (192.168.1.4) appears to be up ... good.
Initiating Connect() Scan against (192.168.1.4)
Adding open port 111/tcp
Adding open port 21/tcp
Adding open port 515/tcp
Adding open port 1024/tcp
Adding open port 22/tcp
Adding open port 139/tcp
The Connect() Scan took 1 second to scan 1554 ports.
For OSScan assuming that port 21 is open and port 1 is closed and neither are firewalled
Interesting ports on (192.168.1.4) :
(The 1548 ports scanned but not shown below are in state : closed)
Port State Service
21/tcp open ftp
22/tcp open ssh
111/tcp open sunrpc
139/tcp open netbios-ssn
515/tcp open printer
1024/tcp open kdm

Remote operating system guess : Linux 2.1.19 - 2.2.19
Uptime 0.122 days (since Thu Mar 27 16 :02 :38 2003)
TCP Sequence Prediction : Class=random positive increments
Difficulty=4687481 (Good luck !)
IPID Sequence Generation : Incremental

Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds

Les lignes intéressantes :

TCP Sequence Prediction : Class=random positive increments
Difficulty=4687481 (Good luck !)

Celles-ci nous renseignent sur la difficulté d'une attaque par IP-Spoofing. Plus le nombre associé à la valeur Difficulty est élevé, plus il est difficile d'entreprendre une attaque. Le message Good Luck ! entre parenthèses est plutôt ironique vis-à-vis de la réussite de l'attaque.

Si, par malchance, lors d'un scan, vous obtenez un nombre très bas avec un message du type « Trivial Joke », cela signifie que votre système est très vulnérable à une attaque par IP-Spoofing.

Sur la plupart des systèmes, les numéros de séquence sont incrémentés de façon aléatoire, ce qui limite déjà une grande partie des attaques par IP spoofing.

Pour se protéger, il faut commencer par supprimer tous les services se basant sur l'authentification IP (rlogin, rsh).

Certains modules comme rp_filter sous Linux permettent une défense contre ces attaques.

L'utilisation de tunnels permet également de parer cette attaque.

Description de l'IP-Spoofing : IP-spoofing Demystified.

Protégez toutes vos ressources NETBIOS par mot de passe. Ne laissez jamais un service NETBIOS de votre réseau en écoute sur Internet.

Autorisez seulement l'accès aux ressources NETBIOS au client de votre réseau.

Un bon guide pour la sécurisation NETBIOS (en anglais) : A STUDY IN REMOTE NT PENETRATION

Le gros problème avec NFS, c'est que le client fait toujours confiance au serveur et vice-versa. Un compte « root » sur une machine cliente peut très bien compromettre le serveur et vice-versa.

Utilisez la commande mount avec l'option -nosuid sur les clients, ce qui empêche la modification ou l'utilisation des programmes setuid sur un système de fichier NFS.

Utilisez l'option root-squash dans le fichier /etc/exports. Cela aura pour but d'empêcher un client root de devenir root sur le système de fichiers NFS stockés sur le serveur.

Protéger l'accès à votre serveur NFS en filtrant à partir de l'adresse IP, les différents clients.

Il est possible d'obtenir des nombreuses informations (notamment les fichiers de mots de passe) à partir du nom de domaine NIS.

Il est aussi possible pour un utilisateur non autorisé d'obtenir les fichiers de mots de passe à partir d'un poste local client NIS.

Les mots de passe sont transmis avec un niveau de chiffrement faible sur le réseau, donc facilement interceptables par un sniffer.

Évitez de donner le même nom de domaine DNS au domaine NIS.

Vérifiez si votre version de NIS vous assure une vérification de l'adresse du domaine depuis lequel sont lancées les requêtes.

Supprimez la commande ypcat sur les ordinateurs clients.

Protégez l'accès à votre serveur NIS en filtrant à partir de l'adresse IP, les différents clients.

Il est conseillé de filtrer l'accès sur ce port grâce à un firewall bien configuré ou de désactiver totalement ce service.

Si vous avez des ressources partagées en accès libre à tout le monde (everyone shares), un pirate utilisera un scanner de share pour les détecter et s'y connecter.

Même si vous protégez ces shares par mot de passe, certains logiciels peuvent tester différents mots de passe en se loguant à la ressource et ainsi tenter différentes combinaisons de mots de passe (voir Chapitre 7, Sécurisation des mots de passe).

Pour être sûr que les mots de passe SMB soient envoyés encryptés sur le réseau (même en cas de requêtes « frauduleuses »), vérifiez que la valeur des clés suivantes de la base de registre est bien égale à 0 :

• Sous Windows NT4 : HKEY\LOCAL\MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters « EnablePlainTextPasswordi »=dword :00000000";
• Sous Windows XP : HKEY\_LOCAL\_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters « enableplaintextpassword »=dword :00000000"

Protégez toutes vos ressources par mots de passe, évitez les shares en accès libre à tout le monde et n'oubliez jamais de choisir des mots de passe associés de la bonne façon (voir Chapitre 7, Sécurisation des mots de passe).

Ne laissez jamais un serveur SMB en écoute sur Internet, cela est plus que suicidaire. Si vous êtes obligés d'utiliser SMB à travers Internet, utilisez les tunnels (voir Section 4.4, « Le tunneling »).

Sur votre réseau interne, filtrez l'accès sur votre serveur SMB grâce à un firewall.

La description des problèmes de sécurité sur SMB (en anglais) : SMB/CIFS BY THE ROOT

Appliquez des règles de firewalling assez strictes concernant le serveur SMTP (usage réservé exclusivement aux machines du réseau interne).

Certains serveurs SMTP empêchent le relayage, vérifiez si votre serveur de messagerie supporte cette option.

Une requête SQL passe par plusieurs étapes avant d'aboutir.

Les données sont envoyées par le client par l'intermédiaire d'un script sur le serveur Web. Il s'ensuit une connexion au serveur SQL, puis l'envoi des données de la requête du client. La requête est exécutée par le serveur SQL. La réponse est reçue par le client et est affichée sous la forme d'une page Web.

L'attaque par SQL-Injection consiste à injecter des caractères spéciaux ou des chaînes de caractères particulières dans les requêtes SQL du client. Ces caractères peuvent être interprétés par le serveur SQL comme des commandes permettant d'obtenir un accès sans mot de passe, de récupérer des fichiers, etc.

Pour bien sécuriser votre serveur SQL, vérifiez que tous les comptes possèdent un mot de passe. Sur certaines versions de serveur, les comptes administrateur ou de certains utilisateurs peuvent être accessibles sans mot de passe après une installation.

Se protéger du SQL-Injection n'est pas toujours aisé, il faut surtout être attentif à la programmation des scripts et aux fonctions utilisées.

La technique du « SQL Injection » décrite par son inventeur : How I hacked PacketStorm [ftp://ftp.pastoutafait.org/txt/rfp.txt]

Utilisez plutôt SSH, qui présente les mêmes fonctionnalités que telnet mais permettant en plus de « tunneler » la connexion en encryptant toutes les transactions.

Utilisez IPsec ou des utilitaires de « tunneling » (voir Section 4.4, « Le tunneling ») pour protéger toutes vos connexions.

Je vous conseille aussi de restreindre l'accès à votre serveur telnet via un firewall.

Il faut savoir que XWINDOW fonctionne sur une architecture client-serveur. Il est donc possible à un client connecté sur un serveur X d'interagir avec celui-ci. Il peut agir sur les fenêtres, capturer des événements X ou en créer. Si un serveur X WINDOW est mal configuré, n'importe quel client pourra s'y connecter et modifier son fonctionnement.

Utilisez la commande xhost pour fermer les accès au serveur XWINDOW.

[root@nowhere /root]# xhost -

Les utilisateurs des applications Peer to Peer constituent des cibles idéales pour la propagation des virus. Les développements de ces applications sont récents ; ils n'ont pas subi d'audit sérieux. Le «pouvoir d'attraction» de l'échange de fichier est si grand que cet usage s'est répandu très rapidement. On obtient donc un cocktail dangereux : des applications faibles déployées à très grande échelle sur l'Internet.

Les virus récents (postérieur à la série Gibe-? de septembre 2003) ont commencé à utiliser systématiquement les outils Peer to Peer. Une fois de plus les utilisateurs ne sont absolument pas conscients de leur «participation» à la propagation de ces virus. Pourtant, si on s'intéresse un peu à la journalisation, les traces de propagation sont immédiatement observables. Voici un relevé sur une heure d'exploitation d'un routeur :

Security Violations
=-=-=-=-=-=-=-=-=-=
Feb 17 19:28:14 routeur 14623: Feb 17 20:28:13.155 GMT: %SEC-6-IPACCESSLOGP: list inbound denied tcp 68.170.38.226(1214) -> aaa.bbb.ccc.23(3127), 1 packet
Feb 17 19:33:18 routeur 14625: Feb 17 20:33:17.880 GMT: %SEC-6-IPACCESSLOGP: list inbound denied tcp 68.170.38.226(1214) -> aaa.bbb.ccc.23(3127), 1 packet
Feb 17 19:37:19 routeur 14627: Feb 17 20:37:18.056 GMT: %SEC-6-IPACCESSLOGP: list inbound denied tcp 210.1.13.35(1214) -> aaa.bbb.ddd.204(4899), 1 packet
Feb 17 19:54:20 routeur 14628: Feb 17 20:54:19.200 GMT: %SEC-6-IPACCESSLOGP: list inbound denied tcp 200.89.144.81(4663) -> aaa.bbb.eee.65(3127), 1 packet
Feb 17 19:57:25 routeur 14629: Feb 17 20:57:24.892 GMT: %SEC-6-IPACCESSLOGP: list inbound denied tcp 68.144.158.56(4662) -> aaa.bbb.ddd.201(3127), 1 packet
Feb 17 20:00:19 routeur 14630: Feb 17 21:00:18.544 GMT: %SEC-6-IPACCESSLOGP: list inbound denied tcp 200.89.144.81(4663) -> aaa.bbb.eee.65(3127), 2 packets

La distinction entre la journalisation d'une utilisation «usuelle» d'un outil Peer to Peer et la journalisation de la propagation de virus est immédiate. Pour un échange de fichiers on aurait observé plusieurs dizaines (voire centaines) d'entrées dans le journal sur une heure. Dans le cas présenté, on observe que les adresses IP sources changent pour chaque entrée et que deux applications Peer to Peer ont été utilisées : eDonkey2000 avec les numéros de ports 4662-4663 et Kazaa avec le numéro de port 1214. Enfin, le «clou du spectacle», le numéro de port destination 3127 correspond à la porte cachée du virus W32/MyDoom/W32.Novarg.A.

On retrouve une des caractéristiques des flux réseaux Peer to Peer : il est techniquement difficile de limiter ces flux mais ils sont très faciles à observer et à repérer. Si vous aviez encore quelques illusions sur l'utilisation «anonyme» des outils Peer to Peer, il est grand temps de les perdre. Il est même probablement trop tard, vous êtes déjà repérés !

Sous Linux, le projet P2PWall - IPTables blocking of P2P traffic donne des utilitaires et des documents permettant d'utiliser le firewall iptables pour filtrer le trafic d'application Peer to Peer.

Très simple, une PME ou une université possède un administrateur qui doit gérer l'ensemble du parc informatique et sa conception réseau. Il a pour cahier des charges d'assurer une connexion Internet avec le réseau local, un serveur de messagerie et un site Web.

Avec peu de moyens, l'administrateur crée son réseau de la sorte :

Les serveurs Web, de messagerie et de partage de connexion Internet seront assurés par une seule machine. Cette machine est connectée directement à Internet.

Dans ce type de réseau, il n'y aucune forme de sécurité : la connexion avec Internet n'est absolument pas sécurisée.

Après un premier piratage, notre administrateur reçoit de nouveaux crédits. Il repense l'architecture :

Il dédiera une machine au serveur web, une machine au serveur de messagerie, deux machines au firewalling et un routeur pour assurer la connexion Internet.

Les serveurs de messagerie et Web sont dans une zone extérieure à celle du réseau local. Ils constituent une zone démilitarisée (DMZ). Démilitarisée car on peut s'y connecter depuis l'extérieur, contrairement au réseau local.

Le firewall situé entre le réseau local et le routeur empêchera toute connexion de l'extérieur vers le réseau local, et autorisera seulement les connexions depuis le réseau local sur un nombre limité de services.

Le firewall situé entre le routeur et la DMZ autorisera tous les accès sur les serveurs Web et de messagerie (depuis le réseau local comme depuis l'extérieur), mais en empêchera les tentatives de connexion sur les autres services.

Malheureusement, notre administrateur subit un autre piratage. Il suppose que le pirate a pu passer le routeur et les firewalls en soumettant des requêtes sur des ports autorisés. Il a très bien pu envoyer un exploit sur un serveur Web ou de messagerie vulnérable.

Alors, pour se protéger, il intercale une sonde NDIS (voir Section 4.3, « Les systèmes de détection d'intrusion (HIDS/NIDS) ») entre le firewall et le réseau local et dans la DMZ. Si un pirate venait à envoyer des requêtes suspectes ou des exploits connus, les NIDS préviendraient du risque d'intrusion (de l'intérieur ou de l'extérieur). Le manager NDIS se situera dans le réseau local.

Il dédie toujours une seule machine à un seul service. Il met régulièrement à jour les logiciels, et s'informe sur les nouvelles failles de sécurité.

Ceci constitue un niveau acceptable permettant de résister à des nombreuses attaques.

Nous allons nous appuyer dans cette section sur l'architecture précédente. Nous allons modifier certaines parties du réseau.

Nous allons d'abord insérer une zone de décontamination entre Internet et le réseau interne. Cette zone est constituée d'analyseurs de contrôle de contenu, des antivirus et d'autres utilitaires surveillant le trafic réseau (comme des NIDS). Tous les flux entrants et sortants passeront par cette zone de décontamination. Ces proxies applicatifs peuvent prendre la décision de couper la connexion en cas d'attaques ou de simplement rejeter la demande.

Cette zone est appelée zone de décontamination car elle permet de détecter des signatures d'attaques dans les flux de données provenant d'Internet et d'éviter la propagation dans le reste du réseau.

Pour le réseau local, nous le subdiviserons en sous-réseaux, chaque sous-réseau possédera un NDIS (sonde + manager). Ces sous-réseaux seront reliés entre eux par des switches.

Ce type d'architecture est très efficace pour la sécurité, mais reste néanmoins assez coûteuse et difficile à gérer. L'utilisation de tunnels (voir Section 4.4, « Le tunneling ») permet en plus d'accroître la sûreté des transactions.

Le programme « scanner » sera appelé en mode console et recevra deux arguments : l'interface réseau d'utilisation et l'adresse IP de la machine à scanner. Il affichera la liste des ports ouverts et se terminera.

Exemple d'utilisation :

[root@nowhere.net /root]#./scanner -i eth0 -c 192.168.1.2

Le port 21 est ouvert
Le port 22 est ouvert
Le port 1111 est ouvert
Le port 1024 est ouvert

Mais intéressons-nous à son développement.

Le scan en port demi-ouvert consiste à envoyer un paquet TCP avec le flag SYN armé sur un port précis. Si ce port est ouvert, on recevra en réponse un paquet TCP avec le couple SYN/ACK armé.

Le programme recevra en argument, l'adresse IP de la machine à scanner et le nom de l'interface réseau (par exemple « eth0 »).

ATTENTION ! Le but de ce chapitre est de présenter les bibliothèques libnet et libpcap et certaines de leurs fonctions les plus utiles d'une manière succincte. Ce chapitre n'est en aucun cas un cours de programmation réseau.

Le principe de fonctionnement du programme est simple ; il sera constitué de deux fonctions : la première permettra d'envoyer les paquets (sur les 16000 premiers ports) et la deuxième de les recevoir. Ces deux fonctions seront activées en parallèle dans deux processus distincts (grâce à l'appel de la fonction fork()).

Je présenterai les deux fonctions utilisées pour intercepter et envoyer :

Pour recevoir (void ReceptionPaquet(unsigned int, u_char device) :

La fonction ReceptionPaquet permet de recevoir les paquets circulant sur le réseau. Pour cela, elle utilise la bibliothèque libpcap. Nous utiliserons deux fonctions de cette bibliothèque pour notre programme :

La première est la fonction pcap_t *pcap_t pcap_open_live(char *device, int snaplen, int promisc,int to_ms,char *errbuf).

Cette fonction initialise la carte réseau et renvoie un descripteur de type pcap_t sur cette interface réseau en écoute.

Le paramètre *device est un pointeur sur une chaîne de caractères contenant le nom de l'interface réseau utilisée (par exemple « eth0 »).

Le paramètre snaplen représente la taille maximale (en octet) d'un paquet intercepté (max=65535).

Le paramètre promisc contrôle le fonctionnement de la carte réseau. S'il est égal à 1, la carte est en mode transparent, c'est-à-dire qu'elle intercepte tous les paquets (même ceux qui ne lui sont pas destinés). Si cette valeur est différente de 1, la carte n'acceptera que les paquets lui étant destinés. Pour notre programme, la carte sera en mode transparent donc promisc sera égal à 1.

Le paramètre to_ms spécifie le délai (en millisecondes) d'interception de paquets. Lorsque ce délai est écoulé, la fonction se termine.

Le paramètre *errbuf est un pointeur sur une chaîne de caractères pouvant contenir une message d'erreur en cas de mauvaise ou non exécution du programme.

La deuxième fonction est la fonction u_char *pcap_next(pcap_t *p, struct pcap_pkthdr *h). Cette fonction utilise comme argument le descripteur « p » pour accéder à la carte réseau. Elle renvoie chaque paquet intercepté. C'est une fonction bloquante.

Ces deux fonctions sont toujours utilisées en série, la pcap_open_live initialise la carte réseau et renvoie un descripteur de fichier, ensuite ce descripteur de fichier est utilisé par la fonction *pcap_next qui intercepte les paquets.

Voici la fonction ReceptionPaquet :

void ReceptionPaquet(unsigned int IP_Cible, u_char *Device)

/*Variable utilisée par les fonctions de libpcap (elle contiendra notre
paquet*/
struct pcap_pkthdr Header ;

/*Descripteur représentant l'interface réseau (retourné par
la fonction pcap_open_live()*/
pcap_t *Descr ;

/*Structure pour l'en tête ETHERNET*/
struct ethhdr *EtherHdr ;

/*Structure pour l'en tête IP*/
struct ip *IpHdr ;

/*Structure pour l'en tête TCP*/
struct tcphdr *TcpHdr ;

/*Tampon pour retour d'erreur*/
char ErrBuf[LIBNET_ERRBUF_SIZE] ;

/*Pointeur vers le paquet*/
u_char *Packet ;

/*Descripteur pour libnet*/
libnet_t *l ;

/* Initialisation pour les fonctions de
libnet (obtention d'un descripteur)*/

l=libnet_init(LIBNET_RAW4,NULL,ErrBuf) ;

/*Descripteur "Descr" sur l'interface réseau en écoute*/

Descr = pcap_open_live(Device,65535,1,0,ErrBuf) ;

while(1)  /*On recupére le paquet (il est pointé par la variable
"Packet")*/

  Packet = (u_char *) pcap_next(Descr,&Header) ;

/*On convertit le paquet pour analyser l'en tête ETHERNET*/

  EtherHdr = (struct ethhdr * ) (Packet) ;

/*On verifie si le protocole est bien IP*/

  if(ntohs(EtherHdr-¿h_proto)==ETH_P_IP)

/*On convertit le paquet pour analyser l'en tête IP*/

   IpHdr = (struct ip * ) (Packet +ETH_HLEN) ;

/*On verifie si le protocole est bien TCP*/

  if(IpHdr-¿ip_p==IPPROTO_TCP)

 TcpHdr = (struct tcphdr * ) ( Packet + ETH_HLEN +
4 * (IpHdr-¿ip_hl)) ;

  /* Cela sert à verifier que nous avons bien envoyé le paquet et qu'il
provient bien de la machine "scannée". Ceci se base sur l'analyse des
adresses IP */

  if(

  (IpHdr-¿ip_src.s_addr==IP_Cible) &&
(IpHdr-¿ip_dst.s_addr== libnet_get_ipaddr4(l)))

/*Pour verifier que le port d'envoi correspond au même que le notre*/
if(ntohs(TcpHdr-¿dest)==PORT_SOURCE)

  /*Si les flags SYN et ACK sont armés, le port est ouvert*/
if((TcpHdr-¿ack==1) && (TcpHdr-¿syn==1))

printf("Le port %d est ouvert
n",ntohs(TcpHdr-¿source)) ;
    /*Destruction du descripteur*/
libnet_destroy(l) ;

Pour envoyer (void EnvoiPaquet(unsigned int,int)) :

La fonction EnvoiPaquet permet d'injecter les paquets sur le réseau. Pour cela, elle utilise la bibliothèque Libnet.

Nous allons utiliser différentes fonctions de la bibliothèque Libnet.

La première est la fonction libnet_t *libnet_init(int injection_type, char *device, char *err_buf).

Cette fonction permet d'initialiser une interface d'injection des paquets. Elle traite trois arguments :

• Le premier injection_type définit le type d'interface (niveau ethernet, IP ou TCP). Pour notre programme, une injection au niveau IP suffira (valeur LIBNET_RAW4).
• Le deuxième argument *device est un pointeur sur la chaîne de caractères contenant le nom de l'interface réseau qui sera sollicitée (ex : eth0), la valeur NULL conviendra car libnet choisira automatiquement une carte réseau.
• Le dernier argument *err_buf est utilisé pour les messages d'erreur (comme libpcap). Elle renvoie un pointeur sur l'interface d'injection de type libnet_t.

Les fonctions libnet_ptag_t libnet_build_tcp(…) et libnet_autobuild_ipv4(…) sont utilisées pour construire les en-têtes TCP et IP. Elles prennent comme arguments les différentes valeurs constituant les en-têtes TCP et IP (numéro de port, de séquences … pour TCP, adresses IP, type de protocole pour IP). Elle renvoient toutes les deux un descripteur de type libnet_ptag_t, ces fonctions doivent toujours respecter l'ordre TCP puis IP (sens couche application vers couche réseau ou physique). Ces fonctions prennent en argument le pointeur sur l'interface d'injection (pointeur renvoyé par la fonction libnet_init).

La fonction int libnet_write(libnet_t) injecte le paquet. La fonction void libnet_destroy(libnet_t) détruit l'interface crée par libnet.

Voici la fonction EnvoiPaquet :

void EnvoiPaquet(
/*IP Machine Cible*/
unsigned int IP_cible,
/*Port Destination*/
int port_dest)

   /*Variables pour les fonction de libnet*/
char ErrBuf[LIBNET_ERRBUF_SIZE] ;
libnet_t *l ;

libnet_ptag_t Tag ;

  /*Pour initialiser et obtenir un descripteur*/
l=libnet_init(LIBNET_RAW4,NULL,ErrBuf) ;

  /*Pour construire l'en tête TCP*/

  Tag=libnet_build_tcp(
PORT_SOURCE, /*Port Source*/
port_dest, /*Port destination*/
0, /*N° Séquence*/
0, /*N° Acquitement*/
TH_SYN, /*Demande de connexions*/
4096, /*Taille de fenêtre*/
0, /*Somme de contrôle*/
0, /*Pointeur d'urgence*/
LIBNET_TCP_H, /*Taille en tête*/
(u_char *) (NULL),/*Pointeur vers les données*/
0, /*Taille des données*/
l,
0) ;

  /*Pour construire l'en tête IP*/

  Tag=libnet_autobuild_ipv4(
LIBNET_IPV4_H+LIBNET_TCP_H, /*Taille du paquet*/
IPPROTO_TCP, /*Protocole*/
IP_cible, /*Adresse IP de la machine Cible*/
l) ;

  /*Pour envoyer le paquet*/
libnet_write(l) ;

  /*Pour détruire le descripteur*/
                                                                          
libnet_destroy(l) ;

La fonction main() :

La fonction main() traite les arguments de la ligne de commande, lance un processus enfant, dans lequel elle utilisera la fonction ReceptionPaquet et attendra une seconde pour le lancement du processus et de la fonction ReceptionPaquet, puis exécutera 16000 fois la boucle d'envoi de paquets (16000 ports). Elle attendra encore 5 secondes pour le traitement des réponses et terminera le programme.

Voici la fonction main :

extern char *optarg ;
extern int optind ;
extern int opterr ;

  int main(int argc,char *argv[])

  /*Pour avoir les paramètres de la ligne de commande*/
static char optstring[]="i :c :" ;
int optch ;
char *Device ;

  /*Variable d'itération*/
int i ;

  /*Pour stocker l'adresse IP*/
u_int32_t IP_Cible ;

  /*Variable qui va reçevoir le PID du processus enfant*/
int Pid ;

  /*Pour traiter les paramètres de la ligne de commande*/

  if(argc ¡ 5)

printf("
nscanner -i interface -c IP Cible
n") ;
return 0 ;

  while((optch= getopt(argc,argv,optstring)) !=EOF)

switch(optch)

/*Pour le nom de l'interface*/
case 'i' :
Device = (char *) (malloc(strlen(optarg)*sizeof(char))) ;
strncpy(Device,optarg,strlen(optarg)) ;
break ;

  /*Pour l'adresse IP de la machine cible*/
case 'c' :
IP_Cible = inet_addr(optarg) ;
break ;

  default :
printf("
nscanner -i interface -c IP Cible
n") ;
return 0 ;

  /*On lançe le processus enfant (récuperation et analyse des paquets*/
Pxml:id=fork() ;

  if(Pxml:id==0)

ReceptionPaquet(IP_Cible,Device) ;

  /*On attend une seconde*/

  sleep(1) ;

  /* On envoie les paquets sur les 16000 premiers ports*/

  for(i=0 ;i¡16000 ;i++)

EnvoiPaquet(IP_Cible,i) ;

  /*On détruit le processus enfant*/

  sleep(5) ;

  kill(Pid,SIGINT) ;

  return 0 ;

}

Pour libnet : http://libnet.sourceforge.net/

Pour libpcap : http://www.tcpdump.org