dd-wrt: impede que o VAP acesse a internet

1

Estou tentando configurar uma rede secundária para meu material IOT. Quero permitir apenas alguns acessos à Internet e o restante deve ser "preso" a essa rede. Além disso, todos os dispositivos na rede IOT devem poder acessar meu servidor MQTT que está na minha rede principal.

Minha configuração é a seguinte:

  • Firmware: DD-WRT v3.0-r34015M kongac (12/09/17) - Versões mais recentes me causam muitos problemas com a conectividade sem fio. O Wi-Fi continua a cair após 10 minutos e a única forma de o resolver é reiniciar o router.
  • Hardware: Netgear R7000

Minha rede está configurada de forma que:

  • Em Sem fio - > Configurações básicas:

    • adicionei um VAP
    • Configuração de rede: ponte
    • Isolamento de AP: Desativar
  • Em Configuração - > VLANs

    • Porta 2 = VLAN15 (sem atribuição de ponte)
  • Em Configuração - > Networking

    • Adicionada nova ponte (br2)
    • Atribuído wl02 e vlan15 a br2
    • Atribuído 192.168.7.0/24 a br2
    • Adicionado servidor DHCP para br2
  • Em Configuração - > Roteamento Avançado

    • Adicionada uma rota de 192.168.1.0/24 a 192.168.7.0/24 via br2

Se eu não adicionar regras de firewall, poderei acessar os dispositivos da minha rede principal na minha rede IOT e, se eu me conectar à minha rede IOT, posso navegar na web.

Depois de fazer algumas pesquisas, eu adicionei essas regras de firewall (parece que o dd-wrt está sempre prefixando as regras, então DROP precisa ser inserido primeiro):

iptables -I FORWARD -i br2 -j DROP
iptables -I FORWARD -i br2 -o br0 -d 192.168.1.38 -p tcp --dport 1883 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i br0 -o br2 -m state --state NEW -j ACCEPT

Como resultado,

  • IOT - > Internet = NEGADO
  • Principal - > IOT = NEGADO
  • IOT - > 192.168.1.38:1883 = NEGADO

Tenho certeza de que estou perdendo algo com o iptables, mas não tenho certeza sobre o quê.

Além disso, é seguro assumir que adicionar:

iptables -I FORWARD -i br2 -o br0 -s 192.168.7.5 -m state --state NEW -j ACCEPT

permitirá 192.168.7.5 acessar a internet?

Qualquer orientação é muito apreciada.

Atualização: Saída de comandos solicitados (com IP da WAN redigido):

root@DD-WRT:~# ip -br link
root@DD-WRT:~# ip -4 -br address
root@DD-WRT:~# ip route
default via 73.70.220.1 dev vlan2
X.X.X.X/23 dev vlan2  proto kernel  scope link  src X.X.X.X
127.0.0.0/8 dev lo  scope link
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
172.16.0.0/24 via 172.16.0.1 dev vlan3
172.16.0.0/24 dev vlan3  proto kernel  scope link  src 172.16.0.3
192.168.1.0/24 via 192.168.1.1 dev br0  scope link
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.7.0/24 via 192.168.7.1 dev br2  scope link
192.168.7.0/24 dev br2  proto kernel  scope link  src 192.168.7.1
192.168.15.0/24 dev br1  proto kernel  scope link  src 192.168.15.1
root@DD-WRT:~# ip rule
0:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default
    
por dimaj 11.08.2018 / 22:57

1 resposta

0

Primeira coisa: -I significa inserir na cabeça, ou seja, prefixar . Use -A para acrescentar no final. -A pode não funcionar como esperado se você não também examinar outras regras do iptables que já tenham sido colocadas antes. Então, vamos continuar usando -I , mas com um número de linha incrementado depois de escolher onde inserir e ter as regras na ordem usual.

Seu problema é lidar com as regras stateful . Um fluxo de conntrack é NEW com o primeiro pacote. Qualquer pacote de resposta não será novo, mas iniciará o estado ESTABLISHED . Suas regras só permitem NEW states para que nada funcione corretamente.

Não conhecer todas as outras regras ou configurações de rede resultará em regras prováveis de sub-ótimos / duplicados nesta resposta, mas deve funcionar de qualquer maneira.

Primeiro, adicione regras genéricas que permitirão resposta, assim como pacotes relacionados (por exemplo: para udp com icmp ou para módulos auxiliares como ftp data), uma regra por direção. Essas regras não permitirão tráfego somente porque um novo fluxo é sempre NEW (portanto, não ESTABLISHED ou RELATED ) por definição. Portanto, você só precisa se preocupar com NEW states ( -m conntrack --ctstate substituído -m state --state , então você deve usá-lo se disponível, senão substitua todas as strings por -m state --state ):

iptables -I FORWARD 1 -i br2 -o br0  -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 2 -i br0 -o br2  -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Agora você pode lidar com (apenas) os novos fluxos:
Observe que a regra anterior e a próxima regra podem ser combinadas em apenas uma regra com todos os 3 estados ou nenhuma verificação de estado em tudo desde que sempre será um desses 3 estados (ok, ao lado de INVALID)

iptables -I FORWARD 3 -i br0 -o br2 -m conntrack --ctstate NEW -j ACCEPT
iptables -I FORWARD 4 -i br2 -o br0 -d 192.168.1.38 -p tcp --dport 1883 -m conntrack --ctstate NEW -j ACCEPT
iptables -I FORWARD 5 -i br2 -j DROP

Para sua última pergunta, duvido que o que você escreveu permita o acesso à Internet, porque provavelmente a Internet não estará disponível na interface do br0 . Estaria disponível na interface que possui o IP público. Isso deve funcionar sem saber qual interface é, simplesmente por não declará-la (executar após os comandos anteriores ou reordenar números de acordo. iptables-save e iptables-restore são seus amigos):

iptables -I FORWARD 5 -o br2 -d 192.168.7.5 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 6 -i br2 -s 192.168.7.5 -m conntrack --ctstate NEW -j ACCEPT

Mas as informações perdidas adicionadas na pergunta ajudariam com certeza: ip -br link ; %código%; %código%; ip -4 -br address (e possivelmente ip route ). Então as regras provavelmente poderiam ser mais genéricas ainda sem reduzir a segurança.

UPDATE: ip rule correspondência para corresponder a um endereço MAC .

É possível combinar um endereço mac em vez de um IP. Esta informação só pode ser usada como fonte e só faz sentido na rede correta. Portanto, iptables-save não pode ser usado para corresponder ao MAC. Vamos apenas substituir a regra 5 acima por uma mais genérica (o que ainda é bom para a segurança). Usando mac para substituir as regras 5 e 6 acima, ajuste (novamente: -o br2 é útil):

iptables -R FORWARD 5 -o br2 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -R FORWARD 6 -i br2 -m mac --mac-source 02:03:04:05:06:07 -m conntrack --ctstate NEW -j ACCEPT

E no final você recebe:

iptables -I FORWARD 1 -i br2 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 2 -i br0 -o br2 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 3 -i br0 -o br2 -m conntrack --ctstate NEW -j ACCEPT
iptables -I FORWARD 4 -d 192.168.1.38/32 -i br2 -o br0 -p tcp -m tcp --dport 1883 -m conntrack --ctstate NEW -j ACCEPT
iptables -I FORWARD 5 -o br2 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 6 -i br2 -m mac --mac-source 02:03:04:05:06:07 -m conntrack --ctstate NEW -j ACCEPT
iptables -I FORWARD 7 -i br2 -j DROP

O quinto é um superconjunto do segundo, porque provavelmente deve haver a interface WAN adicionada na regra, mas eu não sei.

    
por 12.08.2018 / 17:20