Tengo una máquina en particular que mantengo abrochada con mucha fuerza. Sólo se permiten algunos puertos/protocolos específicos. Tengo un conjunto bastante básico de reglas que funcionan muy bien.
Mientras trabajaba en otro problema, me di cuenta de que podía añadir unas cuantas reglas más y ajustar aún más las cosas especificando puertos concretos en interfaces de red específicas. Así, por ejemplo, en una interfaz de red, sólo se permite el acceso a 80 y 443, sin acceso de correo o vpn a esa interfaz.
Así que aquí está el aspecto de una de las antiguas normas:
pass in quick proto tcp from any to any port { 80 443 } keep stateY este es el aspecto de una de las nuevas normas:
pass in quick proto tcp from any to en1 port { 80 443 } keep stateLa diferencia es sutil, pero estoy especificando una interfaz de red específica, no sólo en a 'cualquiera'. Este servidor en particular tiene tres conexiones a Internet.
El problema es... pf ya no se iniciará justo en el arranque con estas nuevas reglas. Cuando especifico la interfaz, mi pf startup script no se inicia pf . Y tengo que hacerlo manualmente a través del terminal.
A primera vista, el problema parece que mi script probablemente está intentando utilizar interfaces de red que aún no están en funcionamiento. Pero ya estoy esperando a que aparezcan. Aquí está mi pf startup script, ha funcionado perfectamente durante años, hasta este cambio de norma.
#!/bin/bash
ipconfig waitall
/sbin/pfctl -e -f /etc/pf.confCon las nuevas reglas, no se carga nada en el inicio del sistema cuando esto se ejecuta. Pero si ejecuto la misma pfctl una vez que el sistema está en marcha, carga las reglas e inicia el cortafuegos sin problemas.
He modificado mi script para guardar varias copias de ifconfig para poder ver cómo progresa el estado de las dos interfaces en0 y en1. Antes de la ipconfig waitall comando, están allí sin IPs. Después del comando, siguen sin ips y aparecen como "inactivos". Durante los siguientes segundos, las diferentes IPs comienzan a cargarse. Pero las dos interfaces aparecen todo el tiempo.
Así que la solución fácil del parche sería simplemente ejecutar ipconfig waitall seguido de sleep 6 y dar por terminado el día. Pero prefiero saber exactamente lo que está causando el cuelgue para poder esperar a que esa "cosa" exacta esté lista, en lugar de dejar el firewall completamente abierto durante 6 segundos. Es un servidor de alto tráfico y recibe muchos intentos de hackeo/datos, así que cada segundo puede contar.
0 votos
¿Has comprobado que el script se ejecuta realmente? ¿Puedes extender el script para detectar cualquier error que se produzca en sus comandos y registrarlo?
0 votos
@nohillside Lo hice, y lo es. Y no emite nada, ni errores, ni comentarios, nada.
1 votos
¿Ha encontrado alguna solución?
0 votos
@sunknudsen Una especie de solución. Especifico la dirección IP en lugar de la interfaz de red. No es la forma que prefería pero funciona. Mi servidor tiene IPs estáticas por lo que es efectivamente el mismo.