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

8

Acabei de ler um livro sobre PF (O Livro do PF, Sem Amido), mas há uma pergunta que não foi 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 (ou seja, 10.0.0.0/24) para $ ext_if usando match , quando recebe o NAT 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 NAT para o endereço de $ ext_if antes do check se ele é de 10.0.0.23 é avaliado?

Esse diagrama não é útil para responder a essa pergunta, mas é interessante, no entanto: [ link ]

Se você ler a FAQ do PF NAT [ link ], especialmente a seção "Configurando o NAT", você vai encontrar essas 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 é alcançada. Isso permite que uma classe inteira de pacotes seja manipulada por uma única regra de correspondência e, em seguida, decisões específicas sobre permitir ou não o tráfego podem ser feitas com as regras block e pass.

Eu acho que parece que não é como eu disse no parágrafo acima, então 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?

P.S .: Esta é uma questão bastante teórica. Se você é um pouco pragmático, você vai fazer assim:

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 regra block 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 .23 chegar, ele corresponderá primeiro à primeira regra, depois corresponderá à segunda e à terceira "regra". Mas como a segunda regra é a última decisão sobre a passagem / bloqueio, o pacote é bloqueado. Certo?

    
por dermesser 11.08.2012 / 16:31

2 respostas

1

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

A regra match será aplicada quando estiver agindo na última regra de correspondência. As regras match são "fixas", como você mencionou. O objetivo principal deles é poder definir coisas como uma regra NAT uma vez, e não ter que colocar nat-to no final de um monte de regras que você tem sobre o tráfego de saída.

No seu exemplo, o pacote será descartado. Eu teria que olhar para o código ou pedir a Henning Brauer para ter certeza se eles ignorariam completamente a checagem de NAT no caso de queda, mas não não seria cancelado.

Eu acho que sua regra é coberta pelo Book of PF (pegou a 2ª edição?), mas eu não acho que eles sejam explícitos sobre isso com a regra de correspondência.

    
por 10.10.2013 / 01:35
0

Por favor, corrija-me se eu estava errado, você quer passar todos os pacotes de saída de 10.0.0.0/24, mas você quer bloquear 10.0.0.23? Se sim, mude 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 quick para impedir que o firewall continue filtrando (semelhante a break em algumas linguagens de programação).

link

The quick Keyword

As indicated earlier, each packet is evaluated against the filter ruleset from top to bottom. By default, the packet is marked for passage, which can be changed by any rule, and could be changed back and forth several times before the end of the filter rules. The last matching rule "wins". There is an exception to this: The quick option on a filtering rule has the effect of canceling any further rule processing and causes the specified action to be taken. Let's look at a couple examples:

Wrong:

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

In this case, the block line may be evaluated, but will never have any effect, as it is then followed by a line which will pass everything.

Better:

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

These rules are evaluated a little differently. If the block line is matched, due to the quick option, the packet will be blocked, and the rest of the ruleset will be ignored.

    
por 27.12.2012 / 03:08