Outils pour utilisateurs
informatique:linux:nmap
Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
|
informatique:linux:nmap [2010/01/07 13:26] benoit |
informatique:linux:nmap [2018/09/06 19:10] (Version actuelle) |
||
|---|---|---|---|
| Ligne 1: | Ligne 1: | ||
| ====== NMAP ====== | ====== NMAP ====== | ||
| + | Utilisation classique : | ||
| + | nmap -A -T4 machine.distante.com | ||
| + | ===== Scan TCP ===== | ||
| ==== Scan TCP SYN ==== | ==== Scan TCP SYN ==== | ||
| Ligne 18: | Ligne 21: | ||
| nmap -sT server.distant.com | nmap -sT server.distant.com | ||
| + | |||
| + | |||
| + | ==== Scan TCP ACK ==== | ||
| + | |||
| + | Ce type de scan est différent des autres abordés jusqu'ici, dans le sens où ils ne peuvent pas déterminer si un port est ouvert(ni même ouvert|filtré). Il est utilisé pour établir les règles des pare-feux, déterminant s'ils sont avec ou sans états (statefull/stateless) et quels ports sont filtrés. | ||
| + | |||
| + | Le scan ACK n'active que le drapeau ACK des paquets (à moins que vous n'utilisiez l'option --scanflags). Les systèmes non-filtrés réagissent en retournant un paquet RST. Nmap considère alors le port comme non-filtré, signifiant qu'il est accessible avec un paquet ACK, mais sans savoir s'il est réellement ouvert ou fermé. Les ports qui ne répondent pas ou renvoient certains messages d'erreur ICMP (type 3, code 1, 2, 3, 9, 10, ou 13), sont considérés comme filtrés. | ||
| + | |||
| + | nmap -sA server.distant.com | ||
| + | |||
| + | ===== Scan UDP ===== | ||
| ==== Scan UDP ==== | ==== Scan UDP ==== | ||
| + | Même si les services les plus connus d'Internet son basés sur le protocole TCP, les services UDP sont aussi largement utilisés. DNS, SNMP ou DHCP (ports 53, 161/162 et 67/68) sont les trois exemples les plus courants. Comme le scan UDP est généralement plus lent et plus difficile que TCP, certains auditeurs de sécurité les ignorent. C'est une erreur, car les services UDP exploitables sont courants et les attaquants eux ne les ignoreront pas. Par chance, Nmap peut aider à répertorier les ports UDP. | ||
| + | |||
| + | Le scan UDP est activé avec l'option-sU. Il peut être combiné avec un scan TCP, comme le scan SYN ( -sS), pour vérifier les deux protocoles lors de la même exécution de Nmap. | ||
| + | |||
| + | Le scan UDP envoie un en-tête UDP (sans données) à chaque port visé. Si un message ICMP « port unreachable (type 3, code 3) » est renvoyé, le port est alors fermé. Les autres messages d'erreur « unreachable ICMP (type 3, codes 1, 2, 9, 10, or 13) » rendront le port filtré. À l'occasion, il arrive qu'un service répond par un paquet UDP, prouvant que le port est dans l'état ouvert. Si aucune réponse n'est renvoyée après plusieurs essais, le port est considéré comme étant ouvert|filtré. Cela signifie que le port peut être soit ouvert, soit qu'un dispositif de filtrage bloque les communications. Le scan de versions ( -sV) peut être utilisé pour différencier les ports ouverts de ceux filtrés. | ||
| + | |||
| + | Une des grandes difficultés avec le scan UDP est de l'exécuter rapidement. Les ports ouverts et filtrés ne renvoient que rarement des réponses, laissant Nmap expirer son délai de retransmission au cas où les paquets se soient perdus. Les ports fermés posent encore un plus grand problème: ils renvoient normalement une erreur ICMP « port unreachable ». Mais à la différence des paquets RST renvoyés par les ports TCP fermés en réponse à un scan SYN ou à un connect(), de nombreux hôtes limitent par défaut la cadence d'émission de ces messages. Linux et Solaris étant particulièrement stricts à ce sujet. Par exemple, le kernel 2.4.20 limite cette cadence des destinations inaccessibles (« destination unreachable ») à un par seconde (cf.net/ipv4/icmp.c). | ||
| + | |||
| + | Nmap détecte cette limitation de fréquence et s'y ralenti conformément afin d'éviter de saturer le réseau avec des paquets inutiles que la machine cible rejettera. Malheureusement, une limitation à la Linux d'un paquet par seconde fera qu'un scan des 65 536 ports prendra plus de 18 heures. Les idées pour accélérer les scans UDP incluent le scan des cibles en parallèle, ne scanner que les ports les plus courants en premier, scanner derrière le pare-feu et utiliser l'option --host-timeoutpour éviter les hôtes les plus lents. | ||
| + | |||
| + | nmap -sU server.distant.com | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | ===== Détection d'OS et version des applications ===== | ||
| + | Pour vérifier la version des applications qui écoutent : | ||
| + | nmap -sV server.distant.com | ||
| - | Pour faire un scan des ports et vérifier la version des applications qui écoutent : | + | Pour activer la détection du système d'exploitation : |
| - | nmap -sS -sV server.distant.com | + | nmap -O server.distant.com |
| - | ou | + | |
| - | nmap -sS -sV server.distant.com | + | |
informatique/linux/nmap.1262867184.txt.gz · Dernière modification: 2018/09/06 18:59 (modification externe)
Outils de la page
Sauf mention contraire, le contenu de ce wiki est placé sous les termes de la licence suivante : CC Attribution-Noncommercial-Share Alike 4.0 International
