[GTER] Patch para guardar dados de NAT no PF do FreeBSD 10.2-RELEASE

[Raimundo Santos]

Olá, pessoas!

Eis o patch que comentei estar no forno. Saiu! Pra pequenos - talvez
pequenos-médios - isso pode ajudar. No mais, valeu cada segundo de
aprendizado.

https://gist.github.com/raitech/4150c8767d8f1f8642ccd9d44c4c57c6

Já está em operação no provedor para o qual prestava serviços há algumas
semanas.

O PF exporta informações no formato PCAP, aquele que o tcpdump é capaz de
ler via BPF. Pra que tudo dê certo, ele usa o Link Type do PCAP pra dizer
que é um quadro do PF e não um quadro Ethernet comum, então o que sobra é o
datagrama IP, que é exatamente o alvo do trabalho do PF.

Alterei os headers dentro do kernel para guardar as informações que antes
não o eram, a saber, os dados de origem não traduzidos. Isso implicou em
alterar um pouco do código do PF em si também pra guardar nas estruturas
esses dados. Ainda em código do kernel, alterei a interface pflog para
exportar corretamente os novos dados.

Depois o trabalho foi fazer o pflogd saber da alteração, assim como o
tcpdump. Dessa forma, ninguém precisa desenvolver um leitor do novo formato
que a pflog vai retornar, um

tcpdump -ner /var/log/pflog

já deve ser suficiente.

Mas há de se ter um cuidado extra: como o snaplen (tamanho da captura que
um aplicatico que escreve PCAP vai guardar) padrão do pflogd (160 bytes), o
que teremos é: headers do "frame" pflog, o header IP inteiro e parte do
TCP/UDP; ou seja: todo o trabalho de não guardar as informações de destino,
em conformidade com o Marco Civil da Internet, é perdido.

Então, na hora de configurar o novo pflogd no rc.conf:

pflogd_flags="-s 104"

Assim ele só guarda o "frame" do pflog, contendo as informações de origem
antes e depois da tradução. Porém, se for para debug, é interessante poder
colocar qualquer snaplen e ter um snaplen padrão que abarque não só o caso
de log previsto (ou sugerido) no MCI.


---Para aplicar o patch:

. Prepare um ambiente de testes! NÃO EXECUTE ABSOLUTAMENTE NADA, EM
PRODUÇÃO, QUE VOCÊ NÃO TENHA TESTADO ANTES!

. Obtenha o código fonte do FreeBSD 10.2-RELEASE da maneira que preferir.
. Obtenha o patch do Gist no link do Github que está no começo dessa
mensagem.
. Vá ao diretório onde foi parar o código fonte (usualmente: /usr/src) e
execute

patch -Nup 1 < /caminho/pro/arquivo_do_patch.patch

. Depois (observe qualquer especificidade do seu kernel! Essa é uma forma
bem genérica de fazer)

make buildworld && make installworld && buildkernel && installkernel

Feito isso, reinicie e configure seu PF como lhe aprouver. Não esqueça que:

. a primeira regra com log que pegar um pacote é a que vale, mesmo que não
seja a que gerou a decisão/ação do PF.

. regras de NAT só valem no direção de entrada de pacotes, são checadas
depois de BINAT e levam um pacote já traduzido para a parte de filtro de
fato do PF.

Se alguém puder testar, mesmo que pra escrutínio do meu trabalho, ficarei
imensamente grato!

Notas:

. Por não ter banda suficiente disponível durante meu processo de análise e
codificação, usei o src.txz disponível na mídia pela qual instalei o
sistema. Isso é perigoso, pois posso ter regredido em alguns patches
importantes desde a última atualização do sistema. Procure atualiazar o
sistema já tendo um /usr/src preenchido ou obter a versão mais nova do
código fonte, assim, de quebra, terá patches pro sistema compilados e
instalados. (Não sei dizer se esse código mais novo vem do 10.2-STABLE.)

. Apesar de estar em produção em um ambiente, não tenho como garantir
absolutamente nada da operação no seu ambiente.

. "Por quê não usar método XYZ ao invés de ter esse trabalhão?" - a
liberdade a mim conferida não permitiu :P

. Tive o cuidado de invadir o código do PF o mínimo que consegui, pensando
um pouco em performance.

. Esse é meu primeiro grande patch, portanto reitero: ficarei imensamente
grato com feedbacks!

[]s
Raimundo Santos