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

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

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.

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.

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

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.

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

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.

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:

• arping (versión de Thomas Habets) .
• arping (versión iputils)

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.

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

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.