Regras de Estilo Cisco ACL para Tabelas IP em um Roteador Linux

Question

Eu tenho mais experiência em Cisco que Linux quando se trata de roteadores. Ao criar minhas regras de firewall, estou acostumado a pensar em in our out ACLs anexadas a interfaces específicas.

Estou pensando que posso imitar esse comportamento com as tabelas IP fazendo com que a cadeia FORWARD pule para uma cadeia personalizada para cada interface.

Por exemplo (as políticas padrão serão DROP):

iptables -N INET_IN
iptables -A FORWARD -i eth0 -j INET_IN
iptables -A INET_IN -m tcp -p tcp --dport 80 -d 12.12.12.12 -j ACCEPT

Provavelmente vou usar a inspeção com informações de estado, mas a ideia acima é geral.

1. Existe algum motivo para isso me causar problemas ou simplesmente não funcionar?
2. Se funcionar, isso não é apenas o caminho para isso e eu preciso de alguma Reeducação?

Answer 1

Em última análise, o design da cadeia de iptables é uma mistura de preferência pessoal e utilização de funcionalidade. Eu venho da mesma maneira que você, por exemplo. Eu amo a "metáfora" do iptables e abomino a metáfora do Cisco ACL. Eu gosto de pensar em conversas stateful ao invés de fluxos de pacotes. (Se eu tiver que escolher entre um Cisco PIX ou roteador com o conjunto de recursos do firewall versus iptables, em termos de prazer de administrar, eu levaria o iptables em qualquer dia ...)

A frase "Provavelmente vou acabar usando inspeção stateful ..." é um pouco confusa. O Netfilter é um filtro de pacotes com estado. Você poderia escrever um conjunto de regras que funcionasse em torno de seu "estado", mas isso seria contraproducente. Escrever regras baseadas no estabelecimento de conexões também é muito mais prazeroso, eu descobri, do que tentar escrever as regras necessárias e "espelhar" as regras para gerenciar o tráfego sem estado.

Você deseja que um pacote atravesse o menor número possível de cadeias e o menor número de regras possível. Iniciar suas cadeias de tabela de "filtros" com -m state --state RELATED,ESTABLISHED -j ACCEPT permitirá que o mecanismo de inspeção com informações de estado insira pacotes para conexões já estabelecidas através do conjunto de regras sem percorrer toda a cadeia.

O que você está propondo com as cadeias relacionadas à interface funcionará muito bem e é uma prática bastante comum. Se você tem um conjunto comum de regras que precisam ser aplicadas a todas as interfaces, eu as colocaria primeiro na cadeia comum, depois ramificaria para outras cadeias específicas da interface ou do tipo de tráfego a partir dali.