Firewall en Debian/Linux. Guardog vs Firestarter
Hace tiempo leía yo en algún lugar…
On Tue, 30 Mar 2004, XXX YY wrote:
> Listeros, unas preguntas. Estoy recibiendo 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
>
> ¿Qué son?
…
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 obvio 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.
> ¿Cómo puedo correjir el problema?
Revisa las tres posibilidades anteriores: 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 muy obvio 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.
*** Fin correo electrónico de la persona XXX YY
De Cortafuegos y Firewalls
Aunque GNU/Linux goza de buena salud en seguridad y velocidad de respuesta para cerrar fallos nunca está demás configurar un Cortafuegos (firewall).
Los eruditos dicen que *BSD son más seguros. Más rápidos es corregir fallos. Presumen de ello. Yo no digo que si, ¿ni que no?, porque aun no he probado a usar un sistema *BSD.
Yo conozco dos grandes soluciones para el diseño de los mismos. Guardog y Firestarter. Porque aquí tu puedes diseñar tu cortafuegos, quieres saber lo que hace.
Uno me permite diseños complejos de enrutado, etc. Es Guardog que se usa junto con Guidedog para permitir NAT o redireccionamiento de puertos, creo, yo lo uso únicamente para NAT.
La pareja Guardog-Guidedog es mágica. Te permite diseñar redes pensando en zonas. Tal y como se diseñan las redes. El día que se configure mediante dibujos (tal y como lo explican en la Universidad) será la bomba.
Pantallazos de Guardog y Guidedog:
guidedog enroutado screenshot
guidedog redireccionamioento screenshot
guarddog2 zone screenshot
guarddog2 logging screenshot
guarddog2 protocol screenshot
guarddog2 propiedades avanzadas screenshot
Otro me permite blindar una sola máquina. Firestarter. También tiene interfaz de monitorización.
Pantallazos de Firestarter:
firestarter asistente screenshot
firestarter políticas screenshot
firestarter tray screenshot
firestarter eventos screenshot
firestarter conexiones activas screenshot
Existe otro programa que permite control remoto e interactividad en tiempo real. No recuerdo el nombre pero si que estaba en Debian. Si alguien se interesa lo puedo buscar o lo puede buscar (ya sabiendo que existe).
Permite interactividad con las reglas según llegan los paquetes a las colas de recepción y envio. Pero no es tan bonito y “usable” como los de “esto que pase, esto que no” destinados a window$. Además que lo de tu si vale, se termina haciendo pesado y muchas veces ni prestas atención con tal de que desaparezca el mensajito.
A los especialistas y los puristas estos artilugios les incomodan. A mi me mola, porque lo de las reglas de los cortafuegos me parece un coñazo sobervio. Quisiera saber mucho más del tema, pero quiesiera ser especialista en tantas cosas que no me cunde el tiempo.
Estas herramientas son muy cómodas por tanto.
Últimos comentarios