[l-linux] Mensajes en consola mail kernel: martian source ????

Ernesto Hernandez-Novich l-linux@linux.org.ve
Tue, 30 Mar 2004 16:42:44 -0400 (VET)


On Tue, 30 Mar 2004, Mauricio Rojas wrote:
> Listeros, unas preguntas
>
> Estoy resibiendo estos mensajes en consola :
>
> Mar 30 11:20:22 mail kernel: martian source 192.168.x.x from
> 192.168.x.x, on dev eth1
> Mar 30 11:20:22 mail kernel: ll header:
> ff:ff:ff:ff:ff:ff:00:0b:db:18:fe:3d:08:00
>
> Que son?

'mail' es el nombre de la máquina (mal escogido, por cierto [1]), y lo
que indica es que el kernel de la máquina mail está emitiendo ese
mensaje [2]. NO quiere decir que el mail sea la causa del problema (otra
razón más para [1]: ayuda a no confundirse ante mensajes "novedosos").

Las "x" que pusiste omitieron algo que _si_ era importante,
contrariamente a tu suposición de que eran irrelevantes, y de no haberlo
hecho hubiera permitido dar una respuesta _exacta_. Lo bueno es que ahora
tendrás que deducirla tu mismo para afianzar conocimientos :-)

En todo caso, lo que está diciendo es que por la interfaz eth1 se
recibió un paquete cuya dirección de origen es _imposible_ a la luz de
la actual configuración de interfaces/tabla de rutas; en otras palabras,
por esa interfaz nunca podría venir un paquete con la dirección que
vino, por tanto es un paquete "marciano" que, de paso, es obvísimo con
sólo mirar el encabezado "extraño" [3].

Quizás alguien está haciendo spoofing, o bien alguna máquina tiene una
muy mala configuración IP.

> Son un problema?

Si, paquetes inesperados que llegan por un camino por el cual no pueden
llegar indica algún problema de audacia (cracker), indolencia
(administrador que no configuró correctamente los segmentos IP) o
incoherencia (interfaces/tablas de rutas no cónsonas con la necesidad).

Usando paquetes como éstos se pueden atacar vulnerabilidades remotas en
stacks TCP/IP (¿cuáles?, ahora no se me ocurre ninguna particular, pero
las hay). Usando las IP que ocultaste, la MAC que aparece presentada
en el encabezado, un sniffer, arping y otras herramientas similares
puedes determinar cuál es la máquina que está generando esos paquetes y
golpear al dueño con algún objeto contundente.

Por eso es un paquete marciano. Quizás encontraste el Rover que estaba
perdido.

> Como puedo correjir el problema?

Revisa las tres posibilidades anteriroes: spoofing, mala configuración
IP en los clientes, mala configuración IP en el servidor.

[1] Las máquinas en una red IP _nunca_ deben llamarse como "lo que
    hacen" sino con un nombre único, preferiblemente siguiendo un tema.
    Lo que haces no es más que un "rol", y como los roles cambian pero
    los nombres no, se utiliza un alias (CNAME en DNS) para asociar
    roles a nombres. Eso permite comenzar con una sola máquina que tenga
    todos los roles, y luego agregar máquinas y cambiar roles... pero el
    resto de la configuración puede quedar exactamente igual, en
    particular para los clientes y sus aplicaciones que suelen ser los
    más afectados cuando hay cambios de máquinas servidoras.
[2] El syslog acompaña cada mensaje con el nombre de la máquina origen,
    porque puede configurarse para que reciba todos los mensajes de
    todas las máquinas, cosa que es más práctica porque así hay un
    sólo sitio donde estudiar logs.
[3] La primera parte del encabezado (ff:ff:ff:ff:ff:ff) corresponde a
    la dirección MAC origen, que corresponde al broadcast local. Digo que
    es obvísimo porque _nunca_ se usa ese tipo de direcciones en un
    intercambio Ethernet:
    a. Cuando el origen conoce al destino, ambos serán MACs específicas.
    b. Cuando el origen no conoce al destino, el origen será una MAC
       específica y el destino será ff:ff:ff:ff:ff:ff (esto es un caso
       de ARP).
    c. Cuando el origen no conoce su dirección IP y quiere averiguarla,
       el origen será 00:00:00:00:00:00 y el destino será
       ff:ff:ff:ff:ff:ff (esto es RARP, BOOTP y/o DHCP).
    d. No hay otro caso.
    El kernel sabe tanto IP e Ethernet como el Comer, así que puede
    sacar la misma conclusión que yo y decir que hay algo anormal en el
    paquete, en consecuencia la notificación.
-- 
Ernesto Hernández-Novich - On Linux 2.6.4 i686 - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't apt-get it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3