Filtros para dropar tudo que não seja PPPOE (queria entender melhor essas configs que andei vendo)

Achei 2 pacotes de regras que de acordo com os seus postadores, dropam tudo que que não tiver dentro de quadros pppoe:

Código PHP:

---

ebtables.6.cmd=-P FORWARD DROP
ebtables.6.status=enabled
ebtables.5.cmd=-A FORWARD -p 0x8864 -j ACCEPT
ebtables.5.status=enabled
ebtables.4.cmd=-A FORWARD -p 0x8863 -j ACCEPT
ebtables.4.status=enabled 


---

Código PHP:

---

ebtables.4.cmd=-A FORWARD -d broadcast -o eth0 -j DROP
ebtables.4.status=enabled
ebtables.5.cmd=-A FORWARD -p 0x8863 -j ACCEPT
ebtables.5.status=enabled
ebtables.6.cmd=-A FORWARD -p 0x8864 -j ACCEPT
ebtables.6.status=enabled
ebtables.7.cmd=-A FORWARD -j DROP
ebtables.7.status=enabled 


---

vocês saberiam me dizer a diferença de um para o outro? Eu tenho meus palpites, mas não entendo nada disso aí, parece grego pra mim. Só faço algumas deduções devido aos códigos usados.

Também é estranho pra mim a ordem das regras, no mkt em geral as regras são aplicadas de cima pra baixo, mas parece que no airos isso é diferente ou essa primeira regra aí ia parar o ap completamente...

Outra curiosidade minha, esse número depois do "ebtables" se refere a que? É um tipo de hierarquia, tipo as regras 4 são aplicadas antes das regras 6? Ou esses números se referem à camada na qual essas regras serão aplicadas??

E principalmente, se eu copiar e colar um desses 2 conjuntos de regras no meu ap com airos, vai resolver meu problema? Vai deixar apenas os quadros PPPOE passando e dropar todo o resto?

Valeu, abraços!

fazem a mesma coisa, eu prefiro o segundo, por forçar um DROP nofinal, assim se vc der um iptables -F .. nao perde conexao de gerenciamento.. (ja que o primeiro coloca a politica de DROP como padrao)

o segundo ainda tem um bloqueio de broadcast ai...

mas fazem o mesmo efeito...

A primeira é mais elegante, coloca a politica como DROP e só vai liberar o que você fizer de forma explicita no caso pppoe-session e pppoe-discovery, a segunda opção chove no molhado, quando coloca ebtables.4.cmd=-A FORWARD -d broadcast -o eth0 -j DROP, isso é desnecessário já que existe um DROP no final, tudo que não for liberado vai ser dropado, inclusive o broadcast,multicast. No final as duas fazem a mesma coisa, mas se for pensar em performance a primeira ganha por 1 regra a menos. Em relação ao comentário do colega de perder a sessão de gerenciamento, isso não procede, pois a conexão ao equipamento só pode ser bloqueada na chain INPUT ou OUTPUT o qual não é esse caso.

Att,

Anderson Araújo

eh.. nao perde mesmo nao.. :P

nao prestei atenção qual chain era :P

Obrigado pelas respostas pessoal, vou tacar as regras em alguns aps ubnt que tenho aqui pra ver o que acontece, e depois se tiver tudo nos conformer boto em todos os outros.

Vocês sabem se tem algum lugar no airos que eu posso ver se as regras estão funcionando, se tão dropando pacotes, como a gente pode ver no mkt?

no console do ubnt, via ssh !!

iptables -t filter -L -nv

Pessoal, recentemente eu usei aqui o discovery tool da ubnt aqui na minha rede e achei alguns nanostations instalados em alguns clientes. A questão é, esses clientes tão conectados em painéis com rádios Ubiquiti, com essas regras de dropagem de tudo que não for pacote ppp. Creio que esses clientes não deveriam estar aparecendo no discovery, não entendo pq aparecem... Pensei que eles podiam estar enviando dados dentro dos pacotes ppp, mas eu rodei o discovery sem estar conectado no ppp, e acha esses clientes do mesmo jeito. Aparentemente apenas um dos meus aps está deixando vazar esses negócios, mas ele tá com as mesmas regras que os outros:

Citação:

---

aaa.1.status=disabled
aaa.status=disabled
bridge.1.devname=br0
bridge.1.fd=1
bridge.1.port.1.devname=eth0
bridge.1.port.1.status=enabled
bridge.1.port.2.devname=ath0
bridge.1.port.2.status=enabled
bridge.1.stp.status=disabled
bridge.status=enabled
dhcpc.1.devname=br0
dhcpc.1.status=disabled
dhcpc.status=disabled
dhcpd.1.status=disabled
dhcpd.status=disabled
dnsmasq.1.devname=eth0
dnsmasq.1.status=enabled
dnsmasq.status=disabled
ebtables.1.cmd=-t nat -A PREROUTING --in-interface ath0 -j arpnat --arpnat-target ACCEPT
ebtables.1.status=disabled
ebtables.2.cmd=-t nat -A POSTROUTING --out-interface ath0 -j arpnat --arpnat-target ACCEPT
ebtables.2.status=disabled
ebtables.3.cmd=-t broute -A BROUTING --protocol 0x888e --in-interface ath0 -j DROP
ebtables.3.status=disabled
ebtables.4.cmd=-A FORWARD -p 0x8863 -j ACCEPT
ebtables.4.status=enabled
ebtables.5.cmd=-A FORWARD -p 0x8864 -j ACCEPT
ebtables.5.status=enabled
ebtables.50.status=disabled
ebtables.51.status=disabled
ebtables.52.status=disabled
ebtables.6.cmd=-P FORWARD DROP
ebtables.6.status=enabled
ebtables.status=enabled
httpd.port=80
httpd.status=enabled
igmpproxy.status=disabled
iptables.3.status=disabled
iptables.status=disabled

---

tem alguma merda aí?

Isso aqui eu uso nos APS, a regra liberando sua rede é para ter acesso aos rádios via IP e com as regras abaixo eu não consigo descobrir os rádios pelo discovery:

echo "ebtables -A FORWARD -p 0x8863 -j ACCEPT" > /etc/persistent/rc.poststart
echo "ebtables -A FORWARD -p 0x8864 -j ACCEPT" >> /etc/persistent/rc.poststart
echo "ebtables -A FORWARD -p IPv4 --ip-src sua_rede_gerencia --ip-dst sua_rede_gerencia -j ACCEPT" >> /etc/persistent/rc.poststart
echo "ebtables -A FORWARD -p ARP -j ACCEPT" >> /etc/persistent/rc.poststart
echo "ebtables -P FORWARD DROP" >> /etc/persistent/rc.poststart
cfgmtd -w -p /etc/
reboot

Agora o radio cliente vai conseguir com o discovery ver só o seu AP, senão quiser nem isso é só desabilitar o discovery nele, ou ver qual a porta/protocolo ele usa e dar um drop na chain input.

Att,

Anderson Araújo

valeu, vou tentar.

Na

Citação:

---

echo "ebtables -A FORWARD -p IPv4 --ip-src sua_rede_gerencia --ip-dst sua_rede_gerencia -j ACCEPT" >> /etc/persistent/rc.poststart

---

o que tá em negrito é o que eu substituo pelo ip ou tem mais alguma coisa; esses -- antes de ip, são isso mesmo? E o ip, padrão xxx.xxx.xxx.xxx/xx ?

Mais uma: tem alguma razão especial pra se ter que colocar o ip de origem e o de destino? Nesse caso, é uma regra dessas pra cada station que tiver conectada no ap? Pq se for uma regra só pra uma rede inteira, acho que nao precisava ter src e dst, seria só o endereço da rede em que o ap e os stations estariam. Né não?

Acho que vou acabar não usando essa regra, não tenho conhecimento suficiente pra entender, e consigo acessar os stations pelos ips que eles pegam do servidor pppoe quando discam.