¿Qué es un paquete marciano?
La IANA define un paquete marciano como uno que llega a una interfaz donde la interfaz no utiliza esa red. Para Linux, es cualquier paquete que llega a una interfaz que no está configurada para esa subred de ninguna manera.
Cualquier aviso de paquete marciano debe ser investigado. Paquetes marcianos:
- Se utilizan con frecuencia en la piratería de intrusiones.
- Puede ser un síntoma de un servidor mal configurado en otra parte de la red.
- Puede indicar un problema de infraestructura de red.
Si los elementos de configuración en su /etc/sysctl.conf deshabilite esta detección, deben habilitarse y volver a ejecutar el programa sysctl. Algunas entradas de muestra para verificar son:
net.ipv4.conf.all.log_martians=1 net.ipv4.conf.default.log_martians=1 net.ipv4.conf.bondib0.log_martians=1
En esta publicación, ilustraremos cómo interpretar los mensajes de fuentes marcianas con algunos ejemplos del mundo real.
Ejemplo 1:cómo interpretar el mensaje fuente marciano
Usemos el ejemplo que se muestra a continuación:
Aug 22 11:08:21 server kernel: martian source 192.168.12.197 from 192.168.12.198, on dev bondib0 Aug 22 11:08:21 server kernel: ll header: 08:00:00:00:45:00:01:00:00:00:40:00:40:11:9f:11:c0:a8:0c:c6:c0:a8:0c:c5
Significa que el servidor recibe un paquete en la interfaz bondib0, el origen del paquete (remitente) fue 192.168.12.198 y el destino del paquete (destinatario) fue 192.168.12.197. Sin embargo, sin información adicional, no sabemos por qué el paquete se informó como paquete marciano.
Ejemplo 2:transmisión no válida
May 22 03:40:37 example2 kernel: IPv4: martian source 255.255.255.255 from 10.140.249.4, on dev eth1 May 22 03:40:37 example2 kernel: ll header: 00000000: ff ff ff ff ff ff 00 50 56 ad 59 09 08 00 .......PV.Y...
Aquí eth1 recibió un paquete de transmisión del remitente 10.140.249.4, y el destinatario 255.255.255.255 es una transmisión limitada, la audiencia objetivo son todos los hosts en la 'red local' (aquí está el segmento 10.140.249.4 con máscara de red desconocida), y el el tráfico nunca debe ser reenviado por un enrutador.
Sin embargo, en este caso, eth1 tiene la dirección IP 10.168.252.8/16, no era la misma red que el remitente 10.140.249.4. Por lo tanto, no se espera recibir dicho paquete de transmisión de este remitente, y el paquete fue rechazado como una fuente marciana. Tal problema puede ser causado por un enrutador mal configurado.
Ejemplo 3:filtrado de ruta inversa
May 25 16:46:04 example3 kernel: martian source 10.255.16.101 from 10.255.1.140, on dev eth0 May 25 16:46:04 example3 kernel: ll header: 00:10:e0:3b:1b:8a:00:1f:27:3f:34:00:08:00
Aquí, en el ejemplo 3, eth0 recibió un paquete de 10.255.1.140 y el destinatario es 10.255.16.101. Para entender por qué fue rechazado, debemos inspeccionar la configuración de red de los 2 hosts, como se ilustra a continuación:
El servidor example3 tiene 2 interfaces eth0 (10.255.16.101) y bond0 (10.255.1.101), se conectaron a L3 Switch y L2 Switch, por separado. El conmutador L3 se conectó a 2 segmentos de red:10.255.16.0/24 y 10.255.1.0/24. El remitente se conectó directamente al conmutador L2 y el conmutador L2 se conectó al conmutador L3.
Aquí, el remitente intentó comunicarse con eth0 en el ejemplo 3, el paquete pasará por el conmutador L2 y el conmutador L3 y llegará al destino 10.255.16.101. Esto estaría permitido normalmente. Sin embargo, el Linux moderno suele tener habilitado el filtrado de ruta inversa:
# sysctl -a | grep eth0.rp_filter net.ipv4.conf.eth0.rp_filter = 1
En modo restringido, el kernel prueba los paquetes entrantes con RFC3704, si la interfaz no es la mejor ruta inversa, la verificación del paquete fallará. En este caso, el remitente debería haber podido comunicarse con el servidor ejemplo3 a través de bond0 ya que estaban en el mismo segmento. La verificación falló y el paquete fue rechazado.
La solución más sencilla es conectar bond0 (10.255.1.101) en su lugar. Si eso no es factible debido a alguna razón especial, deshabilite el filtrado Reserve Path o use el modo suelto en eth0.