Eu configurei o pf usando IceFloor em meu sistema OSX 10.9 executando o Server 3.0.2. Tudo parece estar bem, exceto que não consigo me conectar ao sistema usando o nome DNS ou o IP público do host local. Por exemplo, posso me conectar ao http/porta 80 pela internet, mas não pela própria máquina usando o IP público. A conexão da máquina com localhost/127.0.0.1 funciona. Aqui está o log que recebo (xxxx é o IP público do 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
E aqui está a lista de regras
$ 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
Você pode me dizer qual rule 7/0(match)é? E por que não é permitido conectar-se do localhost à chave pública (em qualquer porta aberta)? Tem algo a ver com a no-routeregra f? Ou as duas Generic_blocks_regras?
Desde já, obrigado,
Paulo
Responder1
Eu também estava enfrentando esse problema e precisei de alguns testes tcpdumppara descobrir tudo.
Para responder à sua primeira pergunta, qual é rule 7/0(match): É a regra "Generic_blocks_(IPv4)" adicionada automaticamente pelo IceFloor para bloquear e registrar todo o tráfego autorizado não explicitamente. Você pode confirmar o número dessa regra executando pfctl -gsrcomo root.
Vamos ao motivo pelo qual ele está bloqueado. A conexão de entrada é o que está bloqueado. Não tem nada a ver com a não-rota ou qualquer coisa novisívelconjunto de regras. Tem a ver com a forma como o seu nome DNS é tratado localmente. A tabela de roteamento da sua máquina ( netstat -r) possui uma entrada para o seu nome DNS que aponta para localhosta lo0interface.
A entrada de log contém algumas informações intrigantes, especificamente o block in on en0, que leva você a acreditar que algo está acontecendo na interface en0. No entanto, fazer um tcpdump -nvvvi en0 tcp and port 80mostrou que nenhum pacote estava realmente viajando en0. Os pacotes foram, no entanto, encontrados com tcpdump -nvvvi lo0 tcp and port 80, confirmando assim que o tráfego estava (conforme esperado) acontecendo em lo0.
A configuração padrão do IceFloor ( /Library/IceFloor/icefloor.conf) é gerada com uma linha que possui set skip on lo0. À primeira vista, esta parece ser uma linha muito padrão e bem-vinda (verhttp://www.openbsd.org/faq/pf/options.html). Todas as outras partes lo0pareciam desimpedidas pelas regras da PF. Por palpite, decidi comentar essa linha e adicionar uma nova regra (logo após a inclusão da tabela): pass quick on lo0. Depois de recarregar com esta configuração modificada, consegui acessar meu servidor web através do meu nome DNS (problema resolvido). Portanto, parece que a set skip on lo0linha tem alguns problemas.
O revés da modificação manual do icefloor.confarquivo é que isso impede que você use a guia Firewall na interface do IceFloor. Como salvar uma nova configuração substituiria quaisquer edições manuais.