Evita o tráfego de saída, a menos que a conexão OpenVPN esteja ativa usando o pf.conf no Mac OS X

Question

Eu consegui negar todas as conexões com redes externas, a menos que minha conexão com o OpenVPN esteja ativa usando o pf.conf. No entanto, perco a conectividade Wi-Fi se a conexão for interrompida fechando e abrindo a tampa do laptop ou desligando e ligando novamente o Wi-Fi.

• Estou no Mac OS 10.8.1.
• Eu me conecto à Web via Wi-Fi (de vários locais, incluindo Wi-Fi público).
• A conexão do OpenVPN é configurada com Viscosity.

Eu tenho as seguintes regras de filtragem de pacotes configuradas em /etc/pf.conf

# Deny all packets unless they pass through the OpenVPN connection
wifi=en1
vpn=tun0

block all

set skip on lo
pass on $wifi proto udp to [OpenVPN server IP address] port 443
pass on $vpn

Eu inicio o serviço de filtro de pacotes com sudo pfctl -e e carrego as novas regras com sudo pfctl -f /etc/pf.conf .

Eu também editei /System/Library/LaunchDaemons/com.apple.pfctl.plist e mudei a linha <string>-f</string> para ler <string>-ef</string> para que o filtro de pacotes fosse lançado na inicialização do sistema.

Tudo isso parece funcionar muito bem no início: os aplicativos só podem se conectar à web se a conexão OpenVPN estiver ativa, então eu nunca estou vazando dados por uma conexão insegura.

Mas, se eu fechar e reabrir a tampa do laptop ou desligar e ligar o Wi-Fi novamente, a conexão Wi-Fi será perdida e vejo um ponto de exclamação no ícone de Wi-Fi na barra de status. Clicar no ícone Wi-Fi exibe uma mensagem "Alerta: sem conexão com a Internet":

Pararecuperaraconexão,precisodesconectarereconectaroWi-Fi,àsvezescincoouseisvezes,antesqueamensagem"Alerta: sem conexão com a Internet" desapareça e eu possa abrir a conexão VPN novamente. Outras vezes, o alerta de Wi-Fi desaparece por conta própria, o ponto de exclamação é apagado e eu posso me conectar novamente. De qualquer maneira, pode levar cinco minutos ou mais para obter uma conexão novamente, o que pode ser frustrante.

Remover a linha block all resolve o problema (mas permite conexões inseguras), portanto, parece que há um serviço que estou bloqueando que a Apple exige para recuperar e confirmar uma conexão Wi-Fi. Eu tentei:

• Ativando icmp adicionando pass on $wifi proto icmp all ao pf.conf
• Ativando a resolução de DNS adicionando pass on $wifi proto udp from $wifi to any port 53
• Tentando saber mais registrando pacotes bloqueados (alterando block all para block log all ), mas o registro parece estar desativado no OS X, porque fazendo sudo tcpdump -n -e -ttt -i pflog0 para ver os resultados do registro em "tcpdump: pflog0: No esse dispositivo existe ".

Nada disso ajuda a restabelecer uma conexão Wi-Fi mais rapidamente.

O que mais posso fazer para determinar qual serviço precisa estar disponível para recuperar a conectividade Wi-Fi ou qual regra devo adicionar ao pf.conf para tornar as reconexões de Wi-Fi mais confiáveis?

    

Answer 1

Ao monitorar conexões de rede usando o Little Snitch, descobri que a Apple usa o aplicativo mDNSResponder em segundo plano para verificar se a conexão Wi-Fi está disponível. O mDNSResponder envia pacotes UDP para servidores de nomes para verificar a conectividade e resolver nomes de host para IPs.

Alterar a regra UDP que eu tinha anteriormente para permitir todos pacotes UDP via Wi-Fi permite que o mDNSResponder se conecte, o que significa que o Wi-Fi agora se reconecta pela primeira vez após uma desconexão. No caso de ajudar os outros no futuro, o meu pf.conf final, incluindo as regras padrão da Apple para o Mountain Lion, é assim:

#
# com.apple anchor point
#
scrub-anchor "com.apple/*"
nat-anchor "com.apple/*"
rdr-anchor "com.apple/*"as
dummynet-anchor "com.apple/*"
anchor "com.apple/*"
load anchor "com.apple" from "/etc/pf.anchors/com.apple"

#
# Allow connection via Viscosity only
#
wifi=en1 #change this to en0 on MacBook Airs and other Macs without ethernet ports
vpn=tun0
vpn2=tap0

block all

set skip on lo          # allow local traffic

pass on p2p0            #allow AirDrop
pass on p2p1            #allow AirDrop
pass on p2p2            #allow AirDrop
pass quick proto tcp to any port 631    #allow AirPrint

pass on $wifi proto udp # allow only UDP packets over unprotected Wi-Fi
pass on $vpn            # allow everything else through the VPN (tun interface)
pass on $vpn2           # allow everything else through the VPN (tap interface)

Isso significa que agora os dados podem ser vazados pelo Wi-Fi pelo pequeno número de aplicativos que usam o protocolo UDP, infelizmente, como ntpd (para sincronização de horário) e mDNSResponder. Mas isso ainda parece melhor do que permitir que os dados passem desprotegidos pelo TCP, que é o que a maioria dos aplicativos usa. Se alguém tiver alguma sugestão para melhorar esta configuração, comentários ou outras respostas serão bem-vindos.

    

Answer 2

Você não precisa permitir todos UDP. O 'm' no mDNS significa 'multicast', e usa um endereço IP de destino multicast específico chamado "link multicast address local" e UDP port number 5353 .

Isso significa que na sua solução acima, você está desnecessariamente permitindo o tráfego para todas as 65535 portas UDP para todos os 3,7 bilhões de endereços IP roteáveis no mundo para ignorar sua VPN. Você ficaria surpreso com a quantidade de aplicativos que usam o UDP, o que significa que você está derrotando significativamente a finalidade da sua ideia original de impedir o tráfego de saída quando a VPN está inativa.

Por que não usar esta regra:

pass on $wifi proto udp to 224.0.0.251 port 5353

Uma regra prática muito importante com a configuração do firewall - ao fazer exceções por meio do firewall, sempre tente usar a regra mais específica possível. A especificidade às vezes vem à custa da conveniência & facilidade de uso, ou seja, você pode descobrir que há algum outro protocolo de link local que precisa ser liberado e adicionar outra regra específica.

Se você trocar a regra acima e achar que o problema wifi original retorna, então seu PF pode estar bloqueando o DHCP, o protocolo usado para autoconfigurar os endereços IP de seus dispositivos de rede. (em uma rede doméstica, normalmente seu roteador de banda larga seria seu servidor DHCP). A regra que você precisaria para permitir o DHCP seria:

pass on $wifi proto udp from 0.0.0.0 port 68 to 255.255.255.255 port 67

* Observação: talvez seja necessário substituir 0.0.0.0 por any . O pacote DHCPREQUEST que seu computador envia primeiro tem um endereço de origem 0.0.0.0 porque, nesse estágio, seu computador ainda não tem um endereço IP.
Para ser sincero, eu gostaria de usar mais any . Outra opção é extrair qualquer especificação de origem, ou seja, pass on $wifi proto udp to 255.255.255.255 port 67 , mas isso significa que perdemos a parte da porta de origem da regra, e ser o mais específico possível é sempre a opção mais segura.

Espero que ajude. Aqui estão alguns links úteis:

mDNS: link

DHSP: link

    

Answer 3

Isso me deu informações suficientes para dar um grande salto e usar o pf.conf. Aqui está o que eu uso no meu 10.8 para torná-lo reconectar após a conexão VPN cai:

(Eu só uso ethernet mas você pode trocar $ lan por $ wifi e deve funcionar)

lan=en0
wifi=en1
vpn=tun0
block all
set skip on lo
pass on $lan proto { udp,tcp } to 8.8.8.8
pass on $lan proto tcp to vpn.btguard.com port 1194
pass on $vpn

    

Answer 4

Com o objetivo de criar as regras de PF de maneira "fácil", identificando as interfaces ativas existentes, incluindo as atuais (vpn) interfaces este pequeno programa killswitch pode ser usado,

Ainda em andamento, mas pode ser um bom começo para identificar IP externo e interfaces ativas para criar adequadamente as regras de firewall.

exemplo ou saída usando a opção -i (info):

$ killswitch -i
Interface  MAC address         IP
en1        bc:57:36:d1:82:ba   192.168.1.7
ppp0                           10.10.1.3

public IP address: 93.117.82.123

Passando o servidor ip -ip :

# --------------------------------------------------------------
# Sat, 19 Nov 2016 12:37:24 +0100
# sudo pfctl -Fa -f ~/.killswitch.pf.conf -e
# --------------------------------------------------------------
int_en1 = "en1"
vpn_ppp0 = "ppp0"
vpn_ip = "93.117.82.123"
set block-policy drop
set ruleset-optimization basic
set skip on lo0
block all
pass on $int_en1 proto udp to 224.0.0.251 port 5353
pass on $int_en1 proto udp from any port 67 to any port 68
pass on $int_en1 inet proto icmp all icmp-type 8 code 0
pass on $int_en1 proto {tcp, udp} from any to $vpn_ip
pass on $vpn_ppp0 all

Está longe de ser perfeito, mas o trabalho está em andamento. Mais informações / códigos podem ser encontrados aqui: link

    

Answer 5

- Como adição -

Você pode querer adicionar esta linha:

pass on $wifi inet6 proto udp from any to FF02:0000:0000:0000:0000:0000:0000:00FB port 5353

para permitir que o mDNS opere no ipv6