Nmap-fr:Evasion pare feu IDS et usurpation identite
Évasion pare feu/IDS et usurpation d'identité
Cette section ne présente pas de recette miracle pour contourner des systèmes de détection d'intrusion (IDS) lors de scans Nmap, mais les options mises à disposition afin d'y parvenir.
-f
L'option -f spécifie à Nmap de forcer la fragmentation des paquets de test en tailles de 8 bytes (-f) ou 16 bytes (-f -f), ce qui a pour but de rendre moins facilement évidente (plus furtive) l'activité auprès de l'hôte scanné. Notez que chaque paquet fragmenté aura un en-tête IP, permettant de rattacher les fragments entre eux lors de la recomposition.
--mtu <val>
L'option –mtu permet de spécifier la taille du fragment offset. FAIRE UNE CAPTURE TCPDUMP
-f; --mtu <val>
Paquets fragmentés
-D <decoy1, [,decoy2][,ME] ...>
Cette option permet de leurrer l'hôte scanné, en dissimulant notre scan parmi des scans fictifs d'hôtes dans la liste decoy1, decoy2, etc. Effectivement, des paquets simulant un scan de 5 à 10 ports sont envoyés vers l'hôte scanné afin de noyer notre IP dans la multitude.
Par ailleurs, l'option ME permet de positionner sa véritable adresse dans la liste des decoys. Si ME est positionné en sixième position ou au delà, la probabilité pour qu'un IDS ne repère pas notre IP est plus élevée.
Remarques :
- L'extrait de capture suivante montre qu'il est facile de déterminer un scan Decoy, dans la mesure où les numéros de séquence sont tous identiques :
20:12:17.378853 IP 212.27.54.252.40258 > 172.16.196.128.80: S 4052032885:4052032885(0) win 3072 <mss 1460> 20:12:17.379058 IP 212.27.53.252.40258 > 172.16.196.128.80: S 4052032885:4052032885(0) win 4096 <mss 1460> 20:12:17.379248 IP 172.16.196.1.40258 > 172.16.196.128.80: S 4052032885:4052032885(0) win 2048 <mss 1460>
- Par ailleurs, dans les logs unifiés de Snort, le type de scan Decoy n'est détecté qu'à partir d'un certain nombre d'hôtes inclus dans la liste des decoys :
Type de scan mal détecté (3 hôtes decoys)
[**] [122:1:0] (portscan) TCP Portscan [**] [Priority: 3] 11/06-20:12:17.380959 212.27.54.252 -> 172.16.196.128 PROTO:255 TTL:0 TOS:0x0 ID:0 IpLen:20 DgmLen:164 DF
Exemple de scan decoy détecté (7 hôtes decoys)
[**] [122:2:0] (portscan) TCP Decoy Portscan [**] [Priority: 3] 11/06-20:28:21.125365 212.27.54.252 -> 172.16.196.128 PROTO:255 TTL:0 TOS:0x0 ID:4586 IpLen:20 DgmLen:168
Exemple 1 : hôtes decoys fictifs (inactifs)
A partir de l'hôte 172.16.196.128, nmap est lancé avec les options suivantes :
# nmap -n -e vmnet8 172.16.196.128 -D 172.16.196.127,172.16.196.129 -p 80
Sur l'hôte scanné, un extrait de capture tcpdump est présenté ci-dessous. On y retrouve notre IP en première position, parmi d'autres
21:29:46.240833 IP (tos 0x0, ttl 46, id 36962, offset 0, flags [none], proto TCP (6), length 44) 172.16.196.1.41938 > 172.16.196.128.80: S, cksum 0xdd3f (correct), 3447741600:3447741600 (0) win 3072 <mss 1460> 21:29:46.240841 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 1 72.16.196.128.80 > 172.16.196.1.41938: R, cksum 0x00e9 (correct), 0:0(0) ack 3447741601 win 0 21:29:46.240903 IP (tos 0x0, ttl 45, id 36962, offset 0, flags [none], proto TCP (6), length 44) 172.16.196.127.41938 > 172.16.196.128.80: S, cksum 0xe0c1 (correct), 3447741600:34477416 00(0) win 2048 <mss 1460> 21:29:46.240999 IP (tos 0x0, ttl 40, id 36962, offset 0, flags [none], proto TCP (6), length 44) 172.16.196.129.41938 > 172.16.196.128.80: S, cksum 0xe4bf (correct), 3447741600:34477416 00(0) win 1024 <mss 1460>
Exemple 2 : hôtes decoys actifs
Dans l'exemple qui suit, les hôtes decoys sont tous actifs. Les extraits de la sonde tcdump sont très différents :
Thank you for your comprehension.
-S <spoofed_IP_addr>
La commande qui suit est exécutée à partir d'un poste dont l'adresse IP est 172.16.196.1. Par ailleurs, l'hôte scanné a pour adresse IP 172.16.196.128.
# nmap -e vmnet8 -S 172.16.196.129 172.16.196.128 -p 80
Les traces enregistrées sur l'hôte scanné ne dévoilent pas la véritable identité de la source, mais font apparaître l'adresse usurpée ;
10:43:20.151304 IP (tos 0x0, ttl 42, id 9247, offset 0, flags [none], proto TCP ( 6), length 44) 172.16.196.129.39995 > 172.16.196.128.80: S, cksum 0xc56d (correct ), 402731273:402731273(0) win 3072 <mss 1460> 10:43:20.151570 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), l ength 40) 172.16.196.128.80 > 172.16.196.129.39995: R, cksum 0xe916 (correct), 0: 0(0) ack 402731274 win 0
-e <interface>
Nmap détermine normalement automatiquement l'interface à utiliser. Néanmoins, pour forcer l'interface (utile par exemple pour l'utilisation de VMWARE), utiliser le paramètre -e. La commande ifconfig permet de lister les interfaces.
# nmap -e vmnet1 -sS 172.16.196.128
-g/--source-port <srcport>
Les options -g et --source-port sont équivalentes. Elles permettent de faire apparaître un numéro de port source défini dans les paquets de test. Certains par-feu mal paramétrés peuvent baser leur confiance sur le port source des paquets. Ainsi par exemple, si un par feu ne laisse écouter le port 21 qu'en provenance du port 20, il est possible de modifier le scan en utilisant le port source 20 comme suit
# nmap -sS -g 20 -p 21 172.16.196.128
Les captures produites par tcpdump :
19:20:54.766123 IP 172.16.196.1.20 > 172.16.196.128.21: S 3976655148:3976655148(0) win 3072 <mss 1460> 19:20:54.766235 IP 172.16.196.128.21 > 172.16.196.1.20: R 0:0(0) ack 3976655149 win 0
Si nous précisons maintenant le port source, les résultats sont différents (le firewall laisse passer le flux)
# nmap -sS -g 20 -p 21 172.16.196.128
Les captures produites par tcpdump :
19:20:54.766123 IP 172.16.196.1.20 > 172.16.196.128.21: S 3976655148:3976655148(0) win 3072 <mss 1460> 19:20:54.766235 IP 172.16.196.128.21 > 172.16.196.1.20: R 0:0(0) ack 3976655149 win 0
--data-length <number_of_bytes>
Par défaut, Nmap n'envoie que les en-têtes des paquets (40 bytes pour TCP et 28 bytes pour ICMP). Afin de faire passer un scan pour moins suspect qu'il n'y paraît, il est possible d'ajouter des données. La taille de ces données est fournie après l'instruction –data-length et est exprimée en bytes.
L'extrait qui suit correspond à un échange FTP standard.
08:52:36.928387 IP (tos 0x10, ttl 64, id 62215, offset 0, flags [DF], proto TCP (6), length 52) 172.16.196.1.47270 > 172.16.196.129.21: ., cksum 0x8e24 (correct), 897556646:897556646(0) ack 3 835495017 win 92 <nop,nop,timestamp 757095 1086> 0x0000: 4510 0034 f307 4000 4006 6708 ac10 c401 E..4..@[email protected]..... 0x0010: ac10 c481 b8a6 0015 357f a0a6 e49d 0269 ........5......i 0x0020: 8010 005c 8e24 0000 0101 080a 000b 8d67 ...\.$.........g 0x0030: 0000 043e ...>
L'exemple qui suit est un extrait de capture d'un paquet de test sur le port 21, envoyé avec des données. Cet extrait ressemble à un échange FTP standard.
10:24:49.112042 IP (tos 0x0, ttl 46, id 15740, offset 0, flags [none], proto TCP (6), length 106 8) 172.16.196.1.52503 > 172.16.196.128.21: S, cksum 0x63fd (correct), 4102358251:4102359275(1024 ) win 3072 <mss 1460> 0x0000: 4500 042c 3d7c 0000 2e06 6aad ac10 c401 E..,=|....j..... 0x0010: ac10 c480 cd17 0015 f485 04eb 0000 0000 ................ 0x0020: 6002 0c00 63fd 0000 0204 05b4 e2e3 88dd `...c........... 0x0030: 235f dda4 1d82 314a f07f af5d f5b4 3c85 #_....1J...]..<.
Snort identifie l'événement comme un échange FTP crypté :
[**] [125:7:1] (ftp_telnet) FTP traffic encrypted [**] [Priority: 3] 11/07-10:24:49.112042 172.16.196.1:52503 -> 172.16.196.128:21 TCP TTL:46 TOS:0x0 ID:15740 IpLen:20 DgmLen:1068 ******S* Seq: 0xF48504EB Ack: 0x0 Win: 0xC00 TcpLen: 24 TCP Options (1) => MSS: 1460
--ip-options <options>
VOIR http://seclists.org/nmap-dev/2006/q3/0052.html
Thank you for your comprehension.
--ip-options <options>
Envoie des paquets avec les options IP spécifiées.
--ttl <val>
Ce paramètre permet de modifier la valeur TTL (Time To Live, en français durée de vie) des paquets des test envoyés par Nmap.
--spoof-mac <mac_addr/prefix/nom_vendeur>
L'argument --spoof-mac permet d'usurper une adresse mac dans les paquets raw de test. Cela peut être intéressant si l'hôte scanné se situe derrière un pare-feu filtrant par adresses mac.
La valeur de l'argument peu correspondre à :
- la chaîne « 0 » : dans ce cas, une adresse mac est générée aléatoirement;
- une chaîne hexadécimale composée de 6 paires de nombres, éventuellement séparées par « : » (par exemple 00:50:56:c0:00:08 ou 005056c00008) correspondant à une adresse mac;
- le début d'une chaîne hexadécimale (par exemple 00:50:56) : dans ce cas, Nmap complètera aléatoirement la chaîne pour obtenir les 6 paires de nombres;
- un nom de fournisseur dont Nmap cherchera une correspondance dans le fichier nmap-mac-prefixes. Un extrait de ce fichier est fourni ci-dessous. Dans ce cas, le préfixe constructeur est retenu, auquel sont ajoutés des nombres aléatoires, pour compléter l'adresse mac.
0020FC Matrox 0020FD ITV Technologies 0020FE Topware / Grand Computer 0020FF Symmetrical Technologies 002100 GemTek Technology Co. 002101 Aplicaciones Electronicas Quasar (AEQ) 002102 UpdateLogic 002103 GHI Electronics 002104 Siemens Home and Office Communication Devices GmbH&Co. KG
Dans tous les cas, l'option --send-eth est nécessaire (décrite plus loin dans le paragraphe divers), afin de s'assurer que Nmap envoie les données au niveau de la couche Ethernet.
--badsum; --mtu <val>
Thank you for your comprehension.
--badsum
Envoie des paquets dont la somme de contrôle (checksum) est erronée.