Configuré pf usando IceFloor en mi sistema OSX 10.9 con Server 3.0.2. Todo parece estar bien excepto que no puedo conectarme al sistema usando el nombre DNS o la IP pública de localhost. Por ejemplo, puedo conectarme a http/puerto 80 desde Internet, pero no desde la máquina usando la IP pública. La conexión de la máquina a localhost/127.0.0.1 funciona. Aquí está el registro que obtengo (xxxx es la IP pública del host):
rule 7/0(match): block in on en0: x.x.x.x.80 > x.x.x.x.64460: Flags [R.], seq 1, ack 1, win 65535, length 0
Y aquí está la lista de reglas.
$ sudo pfctl -s rules
[sudo] password for paul:
No ALTQ support in kernel
ALTQ related functions disabled
scrub-anchor "icefloor.nat" all fragment reassemble
anchor "icefloor.nat" all
block drop in quick from <emergingthreats> to any
block drop out quick from any to <emergingthreats>
block drop in log quick from <_blacklist> to any
block drop out log quick from any to <_blacklist>
block drop in quick from no-route to any
block drop in quick from urpf-failed to any label "uRPF"
block drop log inet all label "Generic_blocks_(IPv4)"
block drop log inet6 all label "Generic_blocks_(IPv6)"
anchor "icefloor.groupblocks" all label "Blocks"
anchor "inspector.blocks" all label "Temp_blocks"
anchor "icefloor.exceptions" all label "Logs_exceptions"
anchor "icefloor.portknocking" all label "Hidden_services"
anchor "icefloor.genericipv6" all
anchor "icefloor.inbound" all label "Local_services"
anchor "icefloor.outbound" all label "All_traffic"
anchor "icefloor.outbound_nat" all label "NAT_clients_traffic"
anchor "icefloor.custom_rules" all
¿Puedes decirme cuál rule 7/0(match)es? ¿Y por qué no está permitido conectarse desde localhost a la clave pública (en ningún puerto abierto)? ¿Tiene algo que ver con la no-routeregla f? ¿O las dos Generic_blocks_reglas?
Gracias de antemano,
Pablo
Respuesta1
Yo también estaba enfrentando este problema y fue necesario realizar algunas pruebas tcpdumppara resolverlo todo.
Para responder a su primera pregunta, cuál es rule 7/0(match): es la regla "Generic_blocks_(IPv4)" que IceFloor agrega automáticamente para bloquear y registrar todo el tráfico no autorizado explícitamente. Puede confirmar el número de esa regla ejecutándola pfctl -gsrcomo root.
A la razón por la que está bloqueado. La conexión entrante es lo que está bloqueado. No tiene nada que ver con la no ruta ni nada en elvisibleconjunto de reglas. Tiene que ver con cómo se maneja localmente su nombre DNS. La tabla de enrutamiento de su máquina ( netstat -r) tiene una entrada para su nombre DNS que apunta localhosta la lo0interfaz.
La entrada del registro contiene información desconcertante, específicamente el block in on en0, que le lleva a creer que algo está sucediendo en la interfaz en0. Sin embargo, al hacer un análisis tcpdump -nvvvi en0 tcp and port 80se demostró que en realidad no viajaba ningún paquete en0. Sin embargo, se encontraron paquetes con tcpdump -nvvvi lo0 tcp and port 80, lo que confirma que el tráfico (como se esperaba) se estaba produciendo en lo0.
La configuración predeterminada de IceFloor ( /Library/IceFloor/icefloor.conf) se genera con una línea que tiene set skip on lo0. Al principio, esto parece una frase muy estándar y bienvenida (verhttp://www.openbsd.org/faq/pf/options.html). Todas las demás piezas lo0parecían libres de las reglas del pf. Por una corazonada, decidí comentar esa línea y agregar una nueva regla (justo después de que la tabla incluya): pass quick on lo0. Después de recargar con esta configuración modificada, pude acceder exitosamente a mi servidor web a través de mi nombre DNS (problema resuelto). Entonces parece que la set skip on lo0línea tiene algunos problemas.
El inconveniente de modificar manualmente el icefloor.confarchivo es que le impide utilizar la pestaña Firewall en la interfaz de IceFloor. Ya que guardar una nueva configuración anularía cualquier edición manual.