¿Cómo uso Linux para encontrar direcciones IP no utilizadas en mi red?

28

Tengo acceso a dos computadoras (A y B) en una red. Ambos tienen una dirección IP estática con una máscara de subred de 255.255.255.128 ( verifiqué que no se estaba utilizando un servidor DHCP). Quiero configurar varias direcciones IP en la misma máquina y, por lo tanto, quiero saber qué todas las direcciones IP ya se están utilizando en la subred.

De una pregunta anterior , probé el nmap -sP -PR 172.16.128.*comando, pero soy escéptico sobre su resultado ya que el mismo comando da resultados diferentes en mis dos computadoras (A y B). En A, los espectáculos de resultados, una lista de direcciones IP que son 8 (supuestamente) ya que se utiliza, incluida la de A y B .

Nmap done: 256 IP addresses (8 hosts up) scanned in 1.23 seconds

Pero en B, el resultado es diferente, es decir,

Nmap done: 256 IP addresses (0 hosts up) scanned in 0.00 seconds

¡El resultado en B ni siquiera muestra su propia dirección IP, así como la dirección IP de A!

¿Qué estoy haciendo exactamente mal aquí? ¿Hay alguna forma infalible en Red Hat Linux (RHEL) de descubrir todas las direcciones IP que se utilizan en la subred de la que forma parte mi computadora?

RHEL: 6.5
Nmap version: 5.51
Vishal Sharma
fuente
9
¿Quién gestiona la red? ¿Tiene su permiso para asignar direcciones IP arbitrarias a sus hosts?
Roger Lipscombe
44
Si tengo el permiso. Buena pregunta.
Vishal Sharma
11
La única forma de obtener una respuesta adecuada es preguntar a su administrador de red. Cualquier cosa que haga corre el riesgo de ser inexacta porque los dispositivos pueden estar apagados, reiniciarse, no responder, etc.
Jon Bentley
77
Para completar los comentarios de Roger y Jon, si las direcciones IP en su red se asignan manualmente y sin un DHCP, debe haber un registro en algún lugar (sea una base de datos, una hoja de Excel o un directorio en papel antiguo) donde se registran todas las asignaciones de IP y las personas administrar la red debe tener y usar esta información. Ninguna solución técnica asegurará que no esté robando involuntariamente la IP de otra máquina (deje que sea un servidor inactivo o una computadora portátil de usuario remoto). Si este registro se pierde o no existe, es necesario un inventario completo.
zakinster
Debe citar las direcciones IP comodín para asegurarse de que su shell no intente expandirlo como un posible nombre de archivo. Por ejemplo,nmap -sP -PR '172.16.128.*'
roaima

Respuestas:

39

Cualquier dispositivo con buen comportamiento en una LAN Ethernet es libre de ignorar casi cualquier tráfico, por lo que los PING, escaneos de puertos y similares no son confiables. Sin embargo, los dispositivos no son libres de ignorar las solicitudes ARP , afaik. Dado que especifica que está escaneando una red local, creo que el método menos frágil para hacer lo que desea es intentar conectarse a una dirección remota y luego buscar en mi caché ARP.

Aquí hay un dispositivo simple sin filtro (es decir, uno que no está configurado para ignorar algunas clases de tráfico 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

Aquí hay un dispositivo de filtrado (uno configurado con una sola línea iptablespara ignorar todo el tráfico):

[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

Aquí hay un dispositivo que está inactivo; Tenga en cuenta la falta de una dirección 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

Este método no es infalible, por un lado, se pierden los dispositivos que están apagados, pero es el método menos terrible que he probado.

Editar : Eric Duminil, sí, solo funciona en una red local; ver párrafo uno.

Vishal, los métodos son funcionalmente idénticos. Tenga en cuenta el texto citado en la respuesta de Leo sobre nmap:

Cuando un usuario privilegiado intenta escanear destinos en una red ethernet local, se utilizan solicitudes ARP a menos que --send-ipse especifique lo contrario .

Su método implica menos mecanografía. La mía se puede hacer sin privilegios y puede darle una mejor comprensión de lo que realmente está sucediendo. Pero lo mismo se hace en el cable en ambos casos.

MadHatter apoya a Monica
fuente
2
Esto solo funciona con dispositivos en la misma red local, ¿verdad? Lo probé en un servidor mío, las solicitudes de ping se eliminan en algún punto intermedio y no puedo encontrar ninguna línea relevante con arp.
Eric Duminil
Gracias por la respuesta. Solo quería saber cómo se compara su método con el de @Leo. ¿Es mejor que eso de alguna manera (porque de lo contrario es más fácil usar un solo comando).
Vishal Sharma
2
@VishalSharma, EricDuminil: ver edición arriba.
MadHatter apoya a Monica
Para ser claros, ¿significa que el método de @ Leo será similar al suyo solo cuando lo use un usuario privilegiado y, por lo tanto, cuando lo use un usuario desfavorecido, su resultado no será completo / incorrecto? Además, por usuario privilegiado, ¿quiere decir que un usuario tiene acceso a sudo?
Vishal Sharma
1
@VishalSharma la primera parte de tu comentario es correcta. El usuario privilegiado incluye hacer algo bajo sudo -u root(a menudo acortado sudo), pero también simplemente iniciar sesión como root, o haberlo hecho /bin/su, de ahí el término general.
MadHatter apoya a Monica
20

Como un dispositivo no puede ignorar las solicitudes ARP, me gusta usar una herramienta llamada arp-scan. Está disponible en la mayoría de los repositorios.

Cuando ejecuta el comando con el --localnetinterruptor, le dará una visión general de toda su red interna.

sudo arp-scan --localnet

Me da una lista de todas las direcciones IP y MAC en mi red. También es posible especificar un rango de red para escanear.

sudo arp-scan 172.16.128.0/25

Si tiene varias interfaces de red configuradas, puede especificar la que desea usar con el conmutador -I.

sudo arp-scan -I eth0 172.16.128.0/25

Puede encontrar más información sobre posibles conmutadores en https://linux.die.net/man/1/arp-scan o ejecutando man arp-scan.

Thorchy
fuente
Parece una herramienta prometedora, pero no viene con RHEL 6.5 (en mi caso al menos está ausente).
Vishal Sharma
@VishalSharma Eso es lamentable. Está disponible para CentOS, por lo que habría pensado que también debería estar disponible en RHEL.
Thorchy
44
Está en EPEL, los paquetes adicionales de Fedora para Enterprise Linux.
mattdm
No funciona si LaBrea se está ejecutando.
joshudson
@joshudson Estoy bastante seguro de que es imposible que cualquier herramienta / software escanee la red en busca de direcciones IP no utilizadas cuando se está ejecutando LaBrea.
Thorchy
11

No sé qué versión de nmap está ejecutando en su Red Hat 6.5, pero para versiones recientes, la forma correcta (y más rápida) creo que sería:

nmap -sn -n 172.16.128.0/25

Esto mostrará una lista de todos los hosts en su red (por lo tanto, podría usar cualquier otra IP de esa subred, ya que debería estar disponible).

Edite y tenga en cuenta: la subred que menciona es 255.255.255.128, pero luego muestra la salida como exploración de 254 hosts. A menos que me falte algo, debería ser una máscara / 25 y 126 hosts disponibles. Si desea escanear un / 24, cambie el comando anterior para consultar los 254 hosts.

Del libro nmap, -sPse suspende y se reemplaza por -sn:

-sn (Sin escaneo de puertos)

Esta opción le dice a Nmap que no realice un escaneo de puertos después del descubrimiento de host, y solo imprima los hosts disponibles que respondieron a las sondas de descubrimiento de host. Esto a menudo se conoce como un "escaneo de ping", pero también puede solicitar que se ejecuten los scripts de traceroute y del host NSE. Este es, por defecto, un paso más intrusivo que el escaneo de la lista, y a menudo se puede usar para los mismos fines. Permite el reconocimiento ligero de una red objetivo sin atraer mucha atención. Saber cuántos hosts están activos es más valioso para los atacantes que la lista proporcionada por el análisis de la lista de cada IP y nombre de host.

Los administradores de sistemas a menudo también encuentran valiosa esta opción. Se puede usar fácilmente para contar máquinas disponibles en una red o monitorear la disponibilidad del servidor. Esto a menudo se llama un barrido de ping y es más confiable que hacer ping a la dirección de difusión porque muchos hosts no responden a las consultas de difusión.

El descubrimiento de host predeterminado realizado con -sn consiste en una solicitud de eco ICMP, TCP SYN al puerto 443, TCP ACK al puerto 80 y una solicitud de marca de tiempo ICMP de forma predeterminada. Cuando lo ejecuta un usuario sin privilegios, solo se envían paquetes SYN (mediante una llamada de conexión) a los puertos 80 y 443 en el destino. Cuando un usuario privilegiado intenta escanear destinos en una red ethernet local, se utilizan solicitudes ARP a menos que se especifique --send-ip. La opción -sn se puede combinar con cualquiera de los tipos de sonda de descubrimiento (las opciones -P *, excluyendo -Pn) para una mayor flexibilidad. Si se utiliza cualquiera de esas opciones de tipo de sonda y número de puerto, las sondas predeterminadas se anulan. Cuando existen firewalls estrictos entre el host de origen que ejecuta Nmap y la red de destino, se recomienda utilizar esas técnicas avanzadas.

En versiones anteriores de Nmap, -sn se conocía como -sP.

El -nobjetivo es evitar la resolución DNS de los clientes (hace que el escaneo sea más rápido):

-n (Sin resolución DNS)

Le dice a Nmap que nunca invierta la resolución DNS en las direcciones IP activas que encuentre. Dado que el DNS puede ser lento incluso con el solucionador de código auxiliar paralelo incorporado de Nmap, esta opción puede reducir los tiempos de escaneo.

Puede usar otras combinaciones para profundizar el escaneo o los servicios, pero eso debería ser suficiente para lo que está buscando, a menos que los hosts se enmascaren o dejen todo.

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

León
fuente
La salida que mencioné es del comando nmap -sP -PR 172.16.128. * Por eso escanea 254 hosts.
Vishal Sharma
En mi caso, la ID de red es 172.16.128.128, por lo tanto, tuve que modificar el comando que me sugirió. Usé nmap -sn -n 172.16.128.128/25.
Vishal Sharma
No estoy seguro de lo que quería decir con ID de red, pero si su dispositivo tiene esa dirección y desea que todos los 254 hosts escaneados en su subred, debe ejecutar en su nmap -sn -n 172.16.128.1/24lugar (como dije en la respuesta anterior, escaneará un 255.255. 255.0 máscara)
Leo
Por ID de red, quise decir, la cadena obtenida al realizar 'Y lógico' de IP_Address y la máscara de subred.
Vishal Sharma
Veo. Entonces, ¿el comando nmap que publiqué responde a su pregunta? ¿Ambos dispositivos enumeran las mismas direcciones que se utilizan?
Leo
8

Parte 1 - fping

Esta herramienta hace ping a todo en el rango de red especificado y muestra los que responden a través de 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.....

Parte 2 - arp

Dado que fping habló con todo en la LAN, eso habrá provocado que se agregue una entrada a la tabla ARP del sistema. Léalo en un par de minutos, porque la tabla arp elimina las entradas antiguas.

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

También tenga en cuenta que la tabla ARP tiene un tamaño máximo y el núcleo desalojará las entradas antiguas y de bajo uso.

Ponlo todo junto con

 fping -a -g 10.28.1.0/24 && arp -a | grep -v incomplete > arp.txt

luego navegue por arp.txt a su gusto.

Criggie
fuente
5

IPv6

No asuma que IPv4 es su única opción. Muchos sistemas operativos modernos manejan IPv6 perfectamente, incluso si su ISP no proporciona conectividad V6.

Incluso puede haber dispositivos a los que solo se puede acceder mediante IPv6, o incluso otros protocolos.

Hay un montón de prácticas direcciones de multidifusión documentadas en https://en.wikipedia.org/wiki/Multicast_address#IPv6 Pero la más interesante para usted es 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
Criggie
fuente
3

Una mala respuesta es hacer ping a la dirección de transmisión con

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!)

Hay ~ 50 direcciones IP en esa red con una máscara de red / 16 y solo siete respondieron. Entonces esta no es una buena solución.

Criggie
fuente
1
¿Por qué una respuesta diferente? Puedes editar post
daisy
3
@daisy porque son respuestas diferentes. Una respuesta monolítica podría ser buena, pero una parte la mantiene presionada. Las respuestas separadas permiten que el mecanismo de votación arriba / abajo funcione correctamente. Esta respuesta fue realmente solo para completar, no es muy útil en la práctica.
Criggie
1
Lo único que prueba ping es si un dispositivo está configurado o no para responder a los pings.
Rob Moir
@RobMoir verdadero: el punto principal de esto es que la dirección de transmisión existe y que fue diseñada en IPv4.
Criggie
3

Además de la respuesta de MadHatter, hay una herramienta que realiza la búsqueda de arp sin intentar enviar primero un paquete de red: arping .

Parece que hay dos implementaciones:

Para su propósito, simplemente tomaría el paquete de su distribución de Linux ya que las diferencias probablemente solo estén en los detalles.

allo
fuente
1

Cuando los dinosaurios deambulaban por la tierra, los proto-nerds usaban arpwatch

arpwatch es una herramienta de software para monitorear el tráfico del Protocolo de resolución de direcciones en una red informática. [1] Genera un registro de emparejamiento observado de direcciones IP con direcciones MAC junto con una marca de tiempo cuando el emparejamiento apareció en la red. También tiene la opción de enviar un correo electrónico a un administrador cuando un emparejamiento cambia o se agrega.

página de manual de arpwatch

RedGrittyBrick
fuente
0

Inicie sesión en sus conmutadores y emita show mac-address o comandos similares (según la marca y el modelo). Esto le dará todas las direcciones MAC de dispositivos activos (excepto el conmutador). Si alguno de estos MAC no ocurre entre los MAC encontrados con cualquiera de los ping u otros métodos en las otras respuestas, es posible que desee investigar más a fondo qué dispositivo es. Tal vez no importe porque ni siquiera habla IP o pertenece a una VLAN diferente, pero al menos puede obtener una descripción general de si sus otras sondas son precisas.

Hagen von Eitzen
fuente