Primera observación de una red doméstica

¿Cuánto podemos saber sobre los dispositivos de una red doméstica utilizando únicamente información básica del sistema y comprobaciones ligeras?

STATUS       COMPLETED
AREA         REDES / LAN
PLATFORM     LINUX
SCOPE        OBSERVACIÓN INICIAL
RESULT       BASELINE

Esta primera práctica no intenta identificar con certeza todos los dispositivos de una red.

El objetivo es más pequeño: obtener una primera fotografía y aprender a distinguir entre presencia, inferencia e identidad.

Los ejemplos utilizados son genéricos. No se publican direcciones IP, MAC, nombres de host, topología ni resultados procedentes de ninguna red privada real.

La pregunta

Queremos comprobar qué información podemos obtener desde un equipo Linux utilizando únicamente herramientas habituales y sin instalar software adicional.

La primera distinción será:

presencia
≠
identidad

y trabajaremos además con cuatro niveles:

observado
inferido
probable
confirmado

Escenario

Podemos imaginar una vivienda con una mezcla habitual de dispositivos:

router
ordenadores
móviles
televisor
varios dispositivos Alexa
bombillas Wi-Fi
cámara
impresora
repetidor

No conocemos de antemano qué dirección utiliza cada uno.

El objetivo es construir una tabla de evidencias, no adivinar todos los nombres.

Requisitos

Esta práctica está pensada para Linux.

Utilizaremos:

ip
ping
getent

No instalaremos software adicional.

Ejecuta estas pruebas únicamente sobre una red propia o sobre una red en la que tengas autorización.

1. Identificar la interfaz

Primero comprobamos las interfaces disponibles:

ip -br addr

Una salida simplificada podría parecerse a:

lo       UNKNOWN  127.0.0.1/8
eth0     UP       192.168.1.25/24

En este ejemplo:

interfaz → eth0
IP       → 192.168.1.25
red      → /24

Todavía no hemos descubierto ningún dispositivo.

Solo sabemos desde dónde estamos observando.

2. Comprobar las rutas

Consultamos la tabla de rutas:

ip route

Ejemplo:

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.25

Podemos extraer:

red local → 192.168.1.0/24
gateway   → 192.168.1.1

El gateway suele corresponder al router principal, aunque seguiremos considerando esa identidad como una inferencia mientras no exista una comprobación independiente.

3. Consultar los vecinos conocidos

Linux mantiene una tabla de vecinos aprendidos mediante ARP en IPv4 y NDP en IPv6.

ip neigh

Ejemplo:

192.168.1.1 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE
192.168.1.34 dev eth0 lladdr aa:bb:cc:dd:ee:ff STALE

Ya tenemos una relación entre:

IP
+
MAC

pero todavía no:

IP
→ dispositivo concreto

Estados como:

REACHABLE
STALE
DELAY
PROBE
FAILED

describen el estado de la entrada de vecino. No constituyen un inventario completo de la red.

4. Realizar una comprobación ICMP ligera

La tabla de vecinos solo contiene equipos con los que nuestro sistema ha interactuado.

Si nuestra red de ejemplo fuese:

192.168.1.0/24

podemos enviar un único ICMP a cada dirección:

for i in $(seq 1 254); do
  ping -c 1 -W 1 "192.168.1.$i" >/dev/null 2>&1 &&
    echo "responde: 192.168.1.$i"
done

Hay que sustituir 192.168.1 por el prefijo correspondiente a nuestra propia red.

El comando:

envía un único ping
→ espera como máximo un segundo
→ muestra las direcciones que responden

No realiza un escaneo de puertos.

Una respuesta demuestra únicamente que ese host respondió a ICMP en ese momento.

Una ausencia de respuesta no demuestra necesariamente que no exista.

Puede estar:

dormido
temporalmente desconectado
ignorando ICMP
utilizando otra dirección

5. Volver a consultar vecinos

Después repetimos:

ip neigh

o, para una interfaz concreta:

ip neigh show dev eth0

Sustituimos eth0 por nuestra interfaz real.

Es posible que ahora existan más entradas que al principio.

6. Intentar resolver nombres

Para una dirección concreta podemos probar:

getent hosts 192.168.1.34

Si existe información disponible podría aparecer:

192.168.1.34 dispositivo.local

También puede no devolver nada.

Eso no representa un fallo: simplemente esa fuente no dispone de un nombre.

Incluso cuando aparece un nombre, debe registrarse como evidencia y no automáticamente como identidad definitiva.

7. Construir la tabla

Ahora podemos empezar a registrar lo observado.

Por ejemplo:

No es obligatorio rellenar la identidad.

desconocida

es un resultado perfectamente válido.

8. Utilizar la MAC como una pista más

Los primeros bytes de una dirección MAC pueden asociarse normalmente con una organización o fabricante mediante una base OUI.

En esta primera práctica no añadiremos otra dependencia para resolverlo automáticamente.

Podemos realizar una consulta manual en una base OUI fiable y registrar el resultado como:

fabricante sugerido

no como:

dispositivo identificado

Porque:

fabricante
≠
modelo

fabricante
≠
función

fabricante
≠
equipo concreto

Si encontramos varias direcciones asociadas a Amazon, por ejemplo, todavía no sabemos automáticamente si corresponden a un Echo, un Fire TV, un Kindle u otro producto.

9. Clasificar la evidencia

Usaremos cuatro estados.

Observado

Existe evidencia directa de presencia.

Por ejemplo:

entrada ARP
respuesta ICMP

Inferido

Una evidencia permite formular una hipótesis.

Por ejemplo:

gateway
→ posible router

Probable

Varias evidencias independientes apuntan a la misma explicación.

Por ejemplo:

fabricante
+
nombre
+
comportamiento
→ posible tipo de dispositivo

Confirmado

Existe una comprobación suficientemente independiente para asociar el dispositivo con su identidad real.

La regla será:

si seguimos teniendo dudas
→ no ascendemos el estado

Qué no hacemos en esta práctica

Quedan deliberadamente fuera:

escaneo de puertos
nmap
captura de tráfico
autenticación contra dispositivos
fingerprinting de servicios
SNMP
mDNS específico
UPnP
consultas al router
automatización de vigilancia

No porque sean técnicas incorrectas.

Simplemente responden a preguntas posteriores y queremos saber primero cuánto podemos aprender con la capa más básica.

Resultado

El resultado final no tiene que ser una lista perfecta.

Algo como esto sería completamente válido:

router                    → probable
dispositivo Amazon        → fabricante observado
posible dispositivo IoT   → inferido
dispositivo desconocido   → observado

Un inventario que conserva incertidumbre es más útil que uno que inventa precisión.

Límites

Esta primera fotografía todavía deja sin resolver cuestiones importantes:

DHCP
MAC privadas
dispositivos dormidos
IPv6
nombres ambiguos
fabricantes compartidos
equipos que no responden a ICMP
cambios de dirección

Por tanto, el resultado debe considerarse una baseline.

No un inventario definitivo.

Conclusión

Esta práctica demuestra algo sencillo pero importante:

observar un dispositivo
≠
identificarlo

Con herramientas básicas podemos obtener una primera imagen útil de la red y empezar a registrar evidencia.

Lo importante es no convertir cada pista en una certeza.

Las siguientes prácticas podrán añadir nuevas capas y comprobar cuánto mejora realmente cada una la calidad del inventario.