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

[Douglas Fischer]

Fiquei interessado.
Vou olhar com mais carinho...

Mas confesso que fiquei com medo já na parte:
"Isso implicou em alterar um pouco do código do PF em si"

Não me lembro de uma estória assim que tenha terminado bem depois de
qualquer update.

Em 19 de maio de 2016 14:06, Raimundo Santos <raitech at gmail.com> escreveu:

> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter




-- 
Douglas Fernando Fischer
Engº de Controle e Automação