Comment utiliser Linux pour trouver des adresses IP inutilisées sur mon réseau?


28

J'ai accès à deux ordinateurs (A et B) sur un réseau. Les deux ont obtenu une adresse IP statique avec un masque de sous-réseau de 255.255.255.128 (j'ai 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'une question précédente , j'ai essayé la nmap -sP -PR 172.16.128.*commande, 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, les spectacles de résultats, une liste de 8 adresses IP qui sont (soi - disant) déjà utilisé, 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

9
Qui gère le réseau? Avez-vous la permission d'attribuer des adresses IP arbitraires à vos hôtes?
Roger Lipscombe

4
Oui j'ai la permission. C'est une bonne question.
Vishal Sharma

11
La seule façon d'obtenir une réponse correcte est de demander à votre administrateur réseau. Tout ce que vous faites risque d'être inexact, car les appareils peuvent être éteints, redémarrer, ne pas répondre, etc.
Jon Bentley

7
Pour compléter les commentaires de Roger et Jon, si les IP de votre réseau sont attribuées manuellement et sans DHCP, il devrait y avoir un registre quelque part (que ce soit une base de données, une feuille Excel ou un ancien répertoire papier) où chaque allocation IP est enregistrée et les personnes la gestion du réseau doit disposer et utiliser ces informations. Aucune solution technique ne garantira que vous ne volerez pas involontairement l'IP d'une autre machine (que ce soit un serveur en panne ou un ordinateur portable utilisateur distant). Si ce registre est perdu ou inexistant, un inventaire complet est nécessaire.
zakinster

Vous devez citer les adresses IP génériques pour vous assurer que votre shell n'essaye pas de le développer en tant que nom de fichier possible. Par exemple,nmap -sP -PR '172.16.128.*'
roaima

Réponses:


39

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 les 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 iptablespour 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 é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 sur nmap:

Lorsqu'un utilisateur privilégié tente d'analyser des cibles sur un réseau Ethernet local, les requêtes ARP sont utilisées, sauf indication --send-ipcontraire.

Sa méthode implique moins de frappe. Le mien peut être fait sans privilège et peut vous donner 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.


2
Cela ne fonctionne qu'avec les appareils du même réseau local, non? Je l'ai essayé sur un de mes serveurs, les requêtes ping sont abandonnées quelque part entre les deux et je ne trouve aucune ligne pertinente avec arp.
Eric Duminil

Merci pour la réponse. Je voulais juste savoir comment votre méthode se compare à celle de @Leo? Est-ce mieux que cela d'une certaine manière (car sinon, il est plus facile d'utiliser une seule commande).
Vishal Sharma

2
@VishalSharma, EricDuminil: voir la modification ci-dessus.
MadHatter prend en charge Monica

Juste pour être clair, cela signifie-t-il que la méthode de @ Leo ne sera similaire à la vôtre que lorsqu'elle est utilisée par un utilisateur privilégié et donc lorsqu'elle est utilisée par un utilisateur défavorisé, son résultat ne sera pas complet / incorrect? De plus, par utilisateur privilégié, voulez-vous dire, un utilisateur ayant un accès sudo?
Vishal Sharma

1
@VishalSharma la première partie de votre commentaire est correcte. L'utilisateur privilégié comprend faire quelque chose sous sudo -u root(souvent abrégé sudo), mais aussi simplement être connecté en tant que root, ou l'avoir fait /bin/su, d'où le terme générique.
MadHatter prend en charge Monica

20

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 --localnetcommutateur, elle 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.


On dirait un outil prometteur, mais il n'est pas livré avec RHEL 6.5 (dans mon cas au moins il est absent).
Vishal Sharma

@VishalSharma C'est malheureux. Il est disponible pour CentOS, j'aurais donc pensé qu'il devrait également être disponible sur RHEL.
Thorchy

4
Il se trouve dans EPEL, les packages supplémentaires de Fedora pour Enterprise Linux.
mattdm

Ne fonctionne pas si LaBrea est en cours d'exécution.
joshudson

@joshudson Je suis presque sûr qu'il est impossible pour un outil / logiciel de scanner le réseau à la recherche d'adresses IP inutilisées lorsque LaBrea est en cours d'exécution.
Thorchy

11

Je ne sais pas quelle version de nmap vous exécutez 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épertoriera chaque hôte de votre réseau (vous pouvez donc utiliser n'importe quelle autre IP de ce sous-réseau, car elle devrait être disponible).

Modifier et noter: 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, -sPest 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 d'hôte et d'imprimer uniquement les hôtes disponibles qui ont répondu aux sondes de découverte d'hôte. Ceci est souvent appelé «analyse ping», mais vous pouvez également demander l'exécution de scripts hôte traceroute et NSE. Par défaut, cette étape est plus intrusive que l'analyse de liste et peut souvent être utilisée aux mêmes fins. Il permet une reconnaissance légère d'un réseau cible sans attirer beaucoup d'attention. Savoir combien d'hôtes sont 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 comprend une demande d'écho ICMP, TCP SYN au port 443, TCP ACK au 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 une plus grande flexibilité. Si l'une de ces options de type de sonde et de numéro de port est utilisée, 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.

Dans les versions précédentes de Nmap, -sn était connu sous le nom de -sP.

Il -ns'agit d'éviter la résolution DNS des clients (rend l'analyse plus rapide):

-n (pas de résolution DNS)

Indique à Nmap de ne jamais inverser la résolution DNS sur les adresses IP actives qu'il trouve. Étant donné que le DNS peut être lent même avec le résolveur de stub 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.

Source: https://nmap.org/book/man-host-discovery.html


La sortie que j'ai mentionnée est de la commande nmap -sP -PR 172.16.128. * C'est pourquoi il scanne 254 hôtes.
Vishal Sharma

Dans mon cas, l'ID réseau est 172.16.128.128, j'ai donc dû modifier la commande que vous avez suggérée. J'ai utilisé nmap -sn -n 172.16.128.128/25.
Vishal Sharma

Je ne sais pas ce que vous vouliez dire par ID réseau, mais si votre appareil a cette adresse et que vous voulez que tous les 254 hôtes soient analysés dans votre sous-réseau, vous devriez exécuter à la nmap -sn -n 172.16.128.1/24place (comme je l'ai dit dans la réponse ci-dessus, cela analysera un 255.255. 255,0 masque)
Leo

Par ID réseau, je voulais dire, la chaîne obtenue en effectuant «Et logique» de IP_Address et masque de sous-réseau.
Vishal Sharma

Je vois. Alors, la commande nmap que j'ai publiée répond-elle à votre question? Les deux appareils répertoriant les mêmes adresses sont-ils utilisés?
Leo

8

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.


5

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

3

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.


1
Pourquoi une réponse différente? Vous pouvez modifier le post
marguerite

3
@daisy parce que ce sont des réponses différentes. Une réponse monolithique pourrait être bonne, mais elle est retenue par une partie. Des réponses séparées permettent au mécanisme de vote haut / bas de fonctionner correctement. Cette réponse n'était vraiment que pour être complète, ce n'est pas très utile dans la pratique.
Criggie

1
La seule chose que ping teste est de savoir si un périphérique est configuré ou non pour répondre aux pings.
Rob Moir

@RobMoir true - le point principal est que l'adresse de diffusion existe et qu'elle a été conçue dans IPv4.
Criggie

3

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.


1

À 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 avec 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é.

page de manuel arpwatch


0

Connectez-vous à vos commutateurs et lancez show mac-address des commandes ou des commandes similaires (selon la marque et le modèle). Cela vous donnera toutes les adresses MAC des appareils actifs (à l'exception de vous-même). Si aucun de ces MAC ne se produit 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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.