Comment utiliser Linux pour trouver des adresses IP inutilisées sur mon réseau?
J'ai accès à deux ordinateurs (A et B) sur un réseau. Les deux ont une adresse IP statique avec un masque de sous-réseau de 255.255.255.128 (I vérifié qu'un serveur DHCP n'était pas utilisé). Je veux configurer plusieurs adresses IP sur la même machine et donc je veux savoir quelles sont toutes les adresses IP déjà utilisées dans le sous-réseau.
À partir d'un question précédente , j'ai essayé nmap -sP -PR 172.16.128.*, mais je suis sceptique quant à son résultat car la même commande donne des résultats différents sur mes deux ordinateurs (A et B). Sur A, le résultat montre une liste de 8 adresses IP qui sont (supposément) déjà utilisées, y compris celle de A et B .
Nmap done: 256 IP addresses (8 hosts up) scanned in 1.23 seconds
Mais sur B, le résultat est différent c'est-à-dire,
Nmap done: 256 IP addresses (0 hosts up) scanned in 0.00 seconds
Le résultat sur B n'affiche même pas sa propre adresse IP ainsi que l'adresse IP de A!
Qu'est-ce que je fais exactement de mal ici? Existe-t-il un moyen infaillible dans Red Hat Linux (RHEL) de découvrir toutes les adresses IP utilisées dans le sous-réseau dont mon ordinateur fait partie?
RHEL: 6.5
Nmap version: 5.51
Tout périphérique qui se comporte bien sur un réseau local Ethernet est libre d'ignorer presque tout le trafic, de sorte que les PING, les analyses de port, etc. ne sont pas tous fiables. Les appareils ne sont cependant pas libres d'ignorer requêtes ARP , afaik. Étant donné que vous spécifiez que vous analysez un réseau local, je trouve que la méthode la moins fragile pour faire ce que vous voulez est d'essayer de vous connecter à une adresse distante, puis de regarder dans mon cache ARP.
Voici un périphérique simple et non filtrant (c'est-à-dire qui n'est pas configuré pour ignorer certaines classes de trafic IP):
[me@risby tmp]$ ping -c 1 -W 1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=0.351 ms
[...]
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.1
? (192.168.3.1) at b8:27:eb:05:f5:71 [ether] on p1p1
Voici un périphérique de filtrage (un configuré avec une seule ligne de iptables pour ignorer tout le trafic):
[me@risby tmp]$ ping -c 1 -W 1 192.168.3.31
[...]
1 packets transmitted, 0 received, 100% packet loss, time 0ms
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.31
? (192.168.3.31) at b8:27:eb:02:e4:46 [ether] on p1p1
Voici un appareil qui vient de tomber; notez l'absence d'une adresse MAC:
[me@risby tmp]$ ping -c 1 -W 1 192.168.3.241
[...]
1 packets transmitted, 0 received, 100% packet loss, time 0ms
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.241
? (192.168.3.241) at <incomplete> on p1p1
Cette méthode n'est pas infaillible - il manque des appareils qui sont éteints, pour une chose - mais c'est la méthode la moins terrible que j'aie encore essayée.
Edit : Eric Duminil, oui, cela ne fonctionne que sur un réseau local; voir paragraphe un.
Vishal, les méthodes sont fonctionnellement identiques. Notez le texte cité dans la réponse de Leo à propos de nmap:
Lorsqu'un utilisateur privilégié essaie d'analyser des cibles sur un réseau Ethernet local, les requêtes ARP sont utilisées à moins que
--send-ipa été spécifié.
Sa méthode implique moins de frappe. Le mien peut être fait sans privilège, et mai vous donne une meilleure compréhension de ce qui se passe réellement. Mais la même chose se fait sur le fil dans les deux cas.
Puisqu'un appareil ne peut pas ignorer les requêtes ARP, j'aime utiliser un outil nommé arp-scan. Il est disponible dans la plupart des référentiels.
Lorsque vous exécutez la commande avec le --localnet switch it vous donnera un aperçu de l'ensemble de votre réseau interne.
Sudo arp-scan --localnet
Me donne une liste de toutes les adresses IP et MAC sur mon réseau. Il est également possible de spécifier une plage réseau à analyser.
Sudo arp-scan 172.16.128.0/25
Si plusieurs interfaces réseau sont configurées, vous pouvez spécifier celle que vous souhaitez utiliser avec le commutateur -I.
Sudo arp-scan -I eth0 172.16.128.0/25
Plus d'informations sur les commutateurs possibles peuvent être trouvées sur https://linux.die.net/man/1/arp-scan ou en exécutant man arp-scan.
Je ne sais pas quelle version de nmap vous utilisez dans votre Red Hat 6.5, mais pour les versions récentes, la manière correcte (et plus rapide) je pense que ce serait:
nmap -sn -n 172.16.128.0/25
Cela répertorie tous les hôtes de votre réseau (vous pouvez donc utiliser n'importe quelle autre IP de ce sous-réseau, car elle devrait être disponible).
Modifiez et notez: Le sous-réseau que vous mentionnez est 255.255.255.128, mais vous affichez ensuite la sortie comme analysant 254 hôtes. À moins que je manque quelque chose, cela devrait être un masque/25 et 126 hôtes disponibles. Si vous souhaitez analyser un/24, modifiez la commande ci-dessus pour interroger les 254 hôtes.
Du livre nmap, -sP est interrompu et remplacé par -sn:
-sn (pas d'analyse de port)
Cette option indique à Nmap de ne pas effectuer d’analyse de port après la découverte de l’hôte et d’imprimer uniquement les hôtes disponibles qui ont répondu aux sondes de découverte de l’hôte. Ceci est souvent appelé "analyse ping", mais vous pouvez également demander que les scripts traceroute et NSE Host soient exécutés. Ceci est par défaut une étape plus intrusive que l'analyse de liste, et peut souvent être utilisé aux mêmes fins. Il permet une reconnaissance légère d'un réseau cible sans attirer beaucoup l'attention. le nombre d'hôtes actifs est plus précieux pour les attaquants que la liste fournie par l'analyse de la liste de chaque IP et nom d'hôte.
Les administrateurs système trouvent souvent cette option également intéressante. Il peut facilement être utilisé pour compter les machines disponibles sur un réseau ou surveiller la disponibilité du serveur. Ceci est souvent appelé un balayage ping et est plus fiable que le ping de l'adresse de diffusion car de nombreux hôtes ne répondent pas aux requêtes de diffusion.
La découverte d'hôte par défaut effectuée avec -sn consiste en une demande d'écho ICMP, TCP SYN vers le port 443, TCP ACK vers le port 80 et une demande d'horodatage ICMP) par défaut. Lorsqu'il est exécuté par un utilisateur non privilégié, seuls les paquets SYN sont envoyés (à l'aide d'un appel de connexion) aux ports 80 et 443 sur la cible. Lorsqu'un utilisateur privilégié essaie d'analyser des cibles sur un réseau Ethernet local, les requêtes ARP sont utilisées sauf si - -send-ip a été spécifié. L'option -sn peut être combinée avec n'importe quel type de sonde de découverte (les options -P *, à l'exclusion de -Pn) pour plus de flexibilité. Si l'une de ces options de type de sonde et de numéro de port est utilisée, le les sondes par défaut sont remplacées. Lorsque des pare-feu stricts sont en place entre l'hôte source exécutant Nmap et le réseau cible, l'utilisation de ces techniques avancées est recommandée. Sinon, les hôtes pourraient être manqués lorsque le pare-feu abandonne les sondes ou leurs réponses.
Dans les versions précédentes de Nmap, -sn était appelé -sP.
Le -n est d'éviter la résolution DNS des clients (accélère le scan):
-n (pas de résolution DNS)
Indique Nmap de ne jamais inverser la résolution DNS sur les adresses IP actives qu'il trouve. Comme le DNS peut être lent même avec le résolveur de talon parallèle intégré de Nmap, cette option peut réduire les temps de scan.
Vous pouvez utiliser d'autres combinaisons pour approfondir l'analyse ou les services, mais cela devrait suffire pour ce que vous recherchez, sauf si les hôtes se masquent ou abandonnent tout.
Partie 1 - fping
Cet outil envoie un ping à tout ce qui se trouve dans la plage réseau spécifiée et affiche ceux qui répondent via ICMP.
root@thionite:~# fping -a -g 10.28.1.0/24
10.28.1.1
10.28.1.2
10.28.1.3
10.28.1.4
10.28.1.5
10.28.1.12.....
Partie 2 - arp
Depuis que fping a parlé de tout sur le LAN, cela aura entraîné l'ajout d'une entrée à la table ARP du système. Lisez-le en quelques minutes, car la table arp vide les anciennes entrées.
root@thionite:~# arp -a | grep -v incomplete
? (10.28.1.1) at 00:0d:b9:35:29:c4 [ether] on eth0
? (10.28.1.2) at 68:05:ca:10:53:5f [ether] on eth0
? (10.28.1.3) at d2:f1:6e:54:05:22 [ether] on eth0
? (10.28.1.4) at 00:1a:4d:26:85:ee [ether] on eth0
? (10.28.1.5) at 6e:a6:e5:78:da:ca [ether] on eth0
? (10.28.1.12) at 3c:4a:92:76:85:d8 [ether] on eth0
Notez également que la table ARP a une taille maximale et que le noyau expulsera les entrées anciennes et à faible utilisation.
Mettez le tout ensemble avec
fping -a -g 10.28.1.0/24 && arp -a | grep -v incomplete > arp.txt
puis parcourez arp.txt à votre guise.
IPv6
Ne présumez pas que IPv4 est votre seule option. De nombreux systèmes d'exploitation modernes gèrent très bien IPv6, même si votre FAI ne fournit pas de connectivité V6.
Il peut même y avoir des périphériques qui ne sont accessibles que par IPv6, ou même d'autres protocoles.
Il y a un tas d'adresses de multidiffusion pratiques documentées dans https://en.wikipedia.org/wiki/Multicast_address#IPv6 Mais la plus intéressante pour vous est ff02 :: 1
root@thionite:~# ping6 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80::4261:86ff:fec4:cbaa%eth0 eth0: 56 data bytes
64 bytes from fe80::4261:86ff:fec4:cbaa%eth0: icmp_seq=1 ttl=64 time=0.047 ms
64 bytes from fe80::21a:4dff:fe26:85ee%eth0: icmp_seq=1 ttl=64 time=0.215 ms (DUP!)
64 bytes from fe80::6a05:caff:fe10:535f%eth0: icmp_seq=1 ttl=64 time=0.233 ms (DUP!)
64 bytes from fe80::226:55ff:feda:299c%eth0: icmp_seq=1 ttl=64 time=0.334 ms (DUP!)
64 bytes from fe80::20d:b9ff:fe35:29c4%eth0: icmp_seq=1 ttl=64 time=0.501 ms (DUP!)
64 bytes from fe80::21e:c2ff:fe13:36bf%eth0: icmp_seq=1 ttl=64 time=0.512 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:85d8%eth0: icmp_seq=1 ttl=1 time=0.518 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:8506%eth0: icmp_seq=1 ttl=1 time=0.757 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:e550%eth0: icmp_seq=1 ttl=1 time=0.772 ms (DUP!)
64 bytes from fe80::60cc:69ff:fe4f:7db0%eth0: icmp_seq=1 ttl=64 time=0.992 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe32:3232%eth0: icmp_seq=1 ttl=64 time=1.00 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe30:3030%eth0: icmp_seq=1 ttl=64 time=1.24 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe31:3131%eth0: icmp_seq=1 ttl=64 time=1.34 ms (DUP!)
64 bytes from fe80::6ca6:e5ff:fe78:daca%eth0: icmp_seq=1 ttl=64 time=2.35 ms (DUP!)
64 bytes from fe80::b639:d6ff:feab:1000%eth0: icmp_seq=1 ttl=64 time=7.04 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:85d8%eth0: icmp_seq=1 ttl=1 time=8.02 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:8506%eth0: icmp_seq=1 ttl=1 time=8.03 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:e550%eth0: icmp_seq=1 ttl=1 time=8.06 ms (DUP!)
64 bytes from fe80::212:12ff:fef7:8044%eth0: icmp_seq=1 ttl=64 time=8.24 ms (DUP!)
64 bytes from fe80::8edc:d4ff:fef2:67e0%eth0: icmp_seq=1 ttl=64 time=18.3 ms (DUP!)
64 bytes from fe80::21e:c2ff:fea9:6d71%eth0: icmp_seq=1 ttl=64 time=295 ms (DUP!)
...repeats
Une mauvaise réponse consiste à cingler l'adresse de diffusion avec
root@thionite:~# ping -b 10.28.255.255
WARNING: pinging broadcast address
PING 10.28.255.255 (10.28.255.255) 56(84) bytes of data.
64 bytes from 10.28.2.7: icmp_seq=1 ttl=64 time=0.220 ms
64 bytes from 10.28.3.12: icmp_seq=1 ttl=255 time=0.594 ms (DUP!)
64 bytes from 10.28.9.4: icmp_seq=1 ttl=64 time=1.03 ms (DUP!)
64 bytes from 10.28.1.151: icmp_seq=1 ttl=255 time=1.04 ms (DUP!)
64 bytes from 10.28.3.13: icmp_seq=1 ttl=255 time=2.22 ms (DUP!)
64 bytes from 10.28.3.11: icmp_seq=1 ttl=255 time=2.43 ms (DUP!)
Il y a environ 50 adresses IP sur ce réseau avec un masque de réseau/16 et seulement sept ont répondu. Ce n'est donc pas une bonne solution.
En plus de la réponse de MadHatter, il existe un outil qui effectue la recherche arp sans essayer d'envoyer un paquet réseau en premier: arping .
Il semble y avoir deux implémentations:
Pour votre objectif, je prendrais simplement le paquet de votre distribution Linux car les différences ne sont probablement que dans les détails.
À l'époque où les dinosaures parcouraient la terre, les proto-nerds utilisaient arpwatch
arpwatch est un outil logiciel pour surveiller le trafic du protocole de résolution d'adresse sur un réseau informatique. [1] Il génère un journal d'appariement observé des adresses IP avec les adresses MAC ainsi qu'un horodatage lorsque l'appariement est apparu sur le réseau. Il a également la possibilité d'envoyer un e-mail à un administrateur lorsqu'un couplage change ou est ajouté.
Connectez-vous à vos commutateurs et lancez show mac-address ou commandes similaires (selon la marque et le modèle). Cela vous donnera toutes les adresses MAC des appareils actifs (sauf le commutateur lui-même). Si l'un de ces MAC ne se produit pas parmi les MAC trouvés avec l'une des commandes ping ou d'autres méthodes dans les autres réponses, vous souhaiterez peut-être étudier plus en détail le périphérique concerné. Peut-être que cela n'a pas d'importance car il ne parle même pas IP ou appartient à un autre VLAN, mais au moins vous pouvez obtenir un aperçu de la précision de vos autres sondes.