A correspondência negativa versus positiva afeta o desempenho do firewall?

Question

Estou curioso para saber se a correspondência negativa versus positiva afeta o desempenho da pilha netfilter . por exemplo. é iptables -I INPUT -p tcp -s 192.168.0.0/16 -j DROP equivalente a iptables -I INPUT -p tcp !-s 192.168.0.0/16 -j ACCEPT em termos de desempenho?

Foi-me dito que a correspondência negativa poderia ter um desempenho muito pior, mas não creio que isso seja apoiado por nenhum fato; pelo que sei, é o número de iterações correspondentes (ou seja, regras) que mais afeta o desempenho. Infelizmente eu não tenho uma configuração de teste em mãos com a qual eu poderia testar essa hipótese.

A razão pela qual estou perguntando isso é que a empresa em que trabalho usa muitos roteadores MikroTik pequenos (tanto em tamanho quanto em recursos de computação) e estou tentando criar uma política de firewall de práticas recomendadas razoável. Aparentemente RouterOS, o sistema operacional proprietário MikroTik vem com esses roteadores, é baseado no kernel Linux 2.6.16, então eu acredito que as limitações de um kernel 2.6.16 vanilla também se aplicam lá. Como a pessoa que afirma que há uma diferença no desempenho é meu chefe, quero ter certeza de que posso ignorar com segurança a reivindicação.

    

Answer 1

Meu primeiro instinto é que, em seu exemplo, o custo e a complexidade de suas regras são idênticos e o que é melhor é tanta preferência pessoal quanto qualquer outra coisa. A inversão geralmente é não mais complexa como uma regra de correspondência no netfilter.

O consenso geral parece ser que o número e o ordenamento de regras é muito mais importante para o desempenho ideal do que como você cria regras individuais, embora você também possa obter ganhos.

O firewall do netfilter Linux normalmente opera sob uma primeira base de correspondência e as regras em cada cadeia são processadas sequencialmente, então quanto menos regras precisarem ser processadas antes de acertar uma partida, maior será o seu desempenho.

Essa é a razão pela qual a maioria das configurações de firewall tem algo como: -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT como a primeira regra. Normalmente, essa regra única corresponde à maioria de todo o tráfego em sites razoavelmente ocupados. (Como em mais de 99% de todo o tráfego ...)

Agora, as regras de firewall restantes só devem ser acionadas e processadas para novas conexões, reduzindo significativamente a quantidade de processamento necessária.

Como as regras são processadas em ordem, do ponto de vista do desempenho, faz sentido ordenar as regras pela probabilidade de elas serem acionadas.

por exemplo. em um servidor da Web, a grande maioria do tráfego estará nas portas HTTP padrão. Portanto, uma regra como -A INPUT -p tcp -m state --state NEW -m multiport --dports 80,443 -j ACCEPT efetuando a maioria de seus usuários deve ser sua segunda regra e não como o número de regra 199 depois de toda uma série de regras que provavelmente não corresponderão a ninguém, exceto a um pequeno número de usuários específicos e / ou protocolos incomuns.

No que diz respeito à criação de regras, usando os módulos corretos, como por exemplo o multiport e o iprange, você pode criar regras inteligentes, em vez de várias regras individuais.