Filtragem de NAT e IP de origem no PF, usando o OpenBSD> = 4.7

Acabei de ler um livro sobre PF (The Book Of PF, No Starch), mas há uma pergunta não respondida por ele.

Se eu tiver uma máquina de gateway usando duas interfaces, $ int_if e $ ext_if, e eu NAT os pacotes provenientes de $ int_if: net (que é, digamos, 10.0.0.0/24) para $ ext_if usando match, quando o NAT for aplicado ? Antes ou depois das regras de filtragem?

Exemplo:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
pass out on $ext_if from 10.0.0.0/24
block drop out on $ext_if from 10.0.0.23

Isso funciona? Ou obtém o IP de origem de um pacote vindo de 10.0.0.23 NATed para o endereço $ ext_if antes da verificação se é de 10.0.0.23 avaliada?

Acho que esse diagrama não é útil para responder a essa pergunta, mas é interessante: [ http://www.benzedrine.cx/pf_flow.png ]

Se você ler as Perguntas frequentes sobre o PF NAT [ http://www.openbsd.org/faq/pf/nat.html ], especialmente a seção "Configurando o NAT", você encontrará estas frases:

Quando um pacote é selecionado por uma regra de correspondência, os parâmetros (por exemplo, nat-to) nessa regra são lembrados e aplicados ao pacote quando uma regra de aprovação correspondente ao pacote é atingida. Isso permite que toda uma classe de pacotes seja manipulada por uma única regra de correspondência e, em seguida, decisões específicas sobre a possibilidade de permitir o tráfego com regras de bloqueio e aprovação.

Eu acho que soa como se não fosse o que afirmei no parágrafo acima; portanto, o IP de origem é "lembrado" até que haja uma decisão sobre a ação a ser feita com o pacote. Se a decisão for tomada, o NATting será aplicado.

O que você acha?

PS: Esta é uma questão bastante teórica. Se você for um pouco pragmático, faça o seguinte:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
block drop from 10.0.0.23
# or, explicitly,
# block drop in on $int_if from 10.0.0.23

Portanto, a blockregra já é aplicada quando o pacote chega em $ int_if.

EDIT: Outra possibilidade é, obviamente, decidir antes do NAT:

pass from 10.0.0.0/24
block drop from 10.0.0.23
match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)

Se um pacote de 0,23 chegar, ele primeiro corresponderá à primeira regra, depois corresponderá à segunda regra e à terceira "regra". Mas como a segunda regra é a última decisão sobre aprovação / bloqueio, o pacote é bloqueado. Direita?

Sim, é bastante teórico o que você pediu, mas é uma pergunta muito interessante.

A matchregra será aplicada quando estiver atuando na última regra correspondente. matchregras são "pegajosas", como você mencionou. O principal objetivo deles é poder definir coisas como uma regra NAT uma vez e não precisar colocar nat-to no final de várias regras que você tem sobre o tráfego de saída.

No seu exemplo, o pacote será descartado. Eu precisaria olhar o código ou pedir a Henning Brauer para ter certeza se eles ignorariam completamente a verificação de NAT no caso de devolução, mas ele não sairia de NAT.

Acho que sua regra é coberta pelo Livro da PF (obteve a 2ª edição?), Mas não acho que eles sejam explícitos com a regra da correspondência.

Corrija-me se eu estiver errado, você deseja passar todos os pacotes de saída de 10.0.0.0/24, mas deseja bloquear 10.0.0.23? Em caso afirmativo, altere sua regra para:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
block drop out quick on $ext_if from 10.0.0.23
pass out on $ext_if from 10.0.0.0/24

Basta usar quickpara impedir que o firewall continue filtrando (semelhante a breakalgumas linguagens de programação).

http://www.openbsd.org/faq/pf/filter.html#quick

A palavra-chave rápida

Conforme indicado anteriormente, cada pacote é avaliado em relação ao conjunto de regras de filtro de cima para baixo. Por padrão, o pacote está marcado para passagem, que pode ser alterado por qualquer regra e pode ser alterado várias vezes antes do final das regras de filtro. A última regra correspondente "vence". Há uma exceção a isso: A opção rápida em uma regra de filtragem tem o efeito de cancelar qualquer processamento adicional de regras e faz com que a ação especificada seja executada. Vejamos alguns exemplos:

Errado:

block in on fxp0 proto tcp to port ssh
pass  in all 

Nesse caso, a linha de bloqueio pode ser avaliada, mas nunca terá efeito, pois é seguida por uma linha que passa tudo.

Melhor:

block in quick on fxp0 proto tcp to port ssh
pass  in all 

Essas regras são avaliadas um pouco diferente. Se a linha de bloqueio for correspondida, devido à opção rápida, o pacote será bloqueado e o restante do conjunto de regras será ignorado.