[FUG-BR] PF ou IPF

Patrick Tracanelli eksffa em freebsdbrasil.com.br
Ter Abr 25 13:42:01 BRT 2006


> O problema é que minha opinião ainda é subjetiva pois usei muito pouco o
> PF, mas este me parece mais completo e bem estruturado. O "bem
> estruturado" pode ter um "q" de opinião pessoal ou romantismo, mas vamos
> lá...

Pois e eu andei usando bastante PF tambem, tentando reescrever minhas 
regras e tive problemas. Por exemplo PF nao trata ipoptions tao bem 
quanto IPFW. Nao consegui tratar windows size. Nao consegui tratar range 
de tamanho de pacote (como iplen no ipfw). Nao pude filtrar lsrr, rr, 
etc de IP. Tem varias outras coisas, algumas pode ate ser culpa minha - 
por exemplo nao consegui limitar sessoes simultaneas de um mesmo IP pra 
um servidor SMTP, como limit src-addr ou combinacao de src-addr e dst-port.

Nao consegui tambem identificar pacotes passando numa sessao IPSec. Nao 
consegui filtrar rarp :(

> Tem coisas como o uso de tabelas dinâmicas, listas e macros, que
> facilitam a criação de regras mais abrangentes e a manutenção "on-line"
> de regras.

Bem apontando, sao recursos interessantes, em especial as listas. Mas as 
macros do PF sao meio pasmaceira, um script shell substitui `a altura 
hehe, e as tables do PF mais "burras" que as do IPFW. table no ipfw usa 
duas tabelas em arvore radix (mesma do PATRICIA Trie, roteamento) uma 
radix pra hosts e uma pra redes; logo a performance e bem maior quando 
comparada com uma radix tree que nao distingue hosts de redes (como 
redes sao mais abrangentes devem ser "evaluated" primeiro, ja que tem 
mais chance de dar o match).

> Já tem nat incorporado (mais simples de configurar), no ipfw precisamos
> do natd.

Tai um ponto muito forte do PF. Ja tem in-kernel NAT (ipfw tem mas e 
experimental), apesar do menor controle (o natd por ser um processo da 
userland vc impoe limites a ele, podendo ate associa-lo a uma login 
class dependendo de como execute-o, no kernel nao). Acho que a maior 
vantagem disso e poder usar balanceamento de saida e nat pools, o que o 
natd nao faz. Por outro lado natd tem suporte melhor a sockets do que o 
Pf nat. Dai existe a necessidade de "chunchos" do tipo usar proxy na 
user-land. Infelizmente nao tem proxy de userland pra toda aplicacao. Na 
verdade nem sei se tem pra outras alem de ftp.

Mas pra opcao de NAT o IPNAT do IPF tambem e excelente. Nao deixa a 
desejar pro PF nao. Entao o amigo com duvidas talvez queira testar IPF 
pra esse caso pra concluir hehe.

> Tem AltQ (controle de banda) e failover integrado com CARP e pfsync
> também já bem funcionais e testados.

ALTQ tem seus problemas insuportaveis, como nao fazer queue no 
ip_output(). Nao tem flexibilidade pra criar WF2Q+, e quando faz algo 
similar o calculo e baseado no tamanho da RAIZ da queue. Entao nao ha 
divisao por demanda precisa como no caso do dummynet. Isso pode ser 
pessimo pra quem usa em provedores. Por nao fazer output nao da pra por 
exemplo assumir politicas distintas por interface com base no fluxo. Por 
exemplo:

ambiente dual homed simples, interface interna e externa.

Criar uma limitacao na interface interna por fluxo de entrada e saida, e 
tornar essa limitacao independente de atividade de qualquer outro host. 
Assim da pra "limitar" o trafego de saida total de forma independendente 
ou colocar os caras pra dividir o trafego de saida total entre 
agrupamentos de hosts; paralemanente na interface externa colocar uma 
politica que divida dinamicamente (por demanda e nao baseado em calculo 
da largura de banda) o trafego sainte e entrante. Assim da pra dividir 
no mesmo firewall o perimetro de controle de fluxo (um seja um shaper 
"multi-screened control na literatura da SANS). Entao voce impoe limites 
na interface interna e faz todomundo "dividir o prejuizo" na interface 
externa, caso o link esteja congestionado. O bom e que esse "dividir o 
prejuizo" e de forma que faz distincao entre os hosts, com weight. Assim 
quem tem por exemplo limites de 512Kb na interna pode ter o dobro do 
consumo de quem tem limites de 256Kb, fazendo o primrimeiro concorrer 
apenas com outros com seu mesmo peso.

Com ALTQ seria necessario 2 maquinas pra fazer isso.

Por outro lado, ALTQ tem borrow e upperlimit. Se funcionasse em todos os 
fluxos seria uma grande vantagem, pq sao opcoes funcionais bem legais. 
Mas tambem, estamos falando do ALTQ, e isso nao e necessariamente 
vantagem do PF. Eu uso ALTQ com IPFW, e funciona muito bem. E em caso de 
fluxo entrante se o destino nao for *me* como o ip_fw2.c tem a chamada 
ip_output() quando a maquina atual com gateway, que e a mesma que o ALTQ 
usa, quando o pacote passa de uma interface pra outra o fluxo se aplica. 
Entao temos um efeito do feitico virando contra o feiticeiro ja que com 
IPFW o ALTQ consegue a tao querida funcionalidade que nao consegue no 
PF. Eu uso aqui ALTQ com ipfw, da pra se divertir um bocado:

(eksffa em claire)~# ipfw enable altq
(eksffa em claire)~# ipfw add 1 count altq fila1 all from any to any 
110,143,993 keep-state

(eksffa em claire)~# ipfw show 1
00001     90     4578 count altq fila1 ip from any to any dst-port 
110,143,993

(eksffa em claire)~# pfctl -v -s queue
queue root_rl0 bandwidth 18Kb priority 0 cbq( wrr root ) {def, fila1, fila2}
   [ pkts:        939  bytes:     134099  dropped pkts:      0 bytes:    0 ]
   [ qlength:   0/ 50  borrows:      0  suspends:      0 ]
queue  def bandwidth 6.12Kb cbq( default )
   [ pkts:        923  bytes:     132815  dropped pkts:      0 bytes:    0 ]
   [ qlength:   2/ 50  borrows:      0  suspends:     29 ]
queue  fila1 bandwidth 5.94Kb
   [ pkts:         16  bytes:       1284  dropped pkts:      0 bytes:    0 ]
   [ qlength:   0/ 50  borrows:      0  suspends:      0 ]
queue  fila2 bandwidth 5.94Kb
   [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:    0 ]
   [ qlength:   0/ 50  borrows:      0  suspends:      0 ]

Sobre pfsync, pra mim e sinonimo de facilidade apenas. O ipfw consegue 
fazer melhor e mais flexivel. Por exemplo voce pega um pacote e antes de 
aprova-lo faz

"ipfw tee 40789 all from X to Y"

uma copia do pacote vai pra aplicacao nessa porta, a outra continua no 
firewall ate encontrar a acao. A copia que vai pra aplicacao, a 
aplicacao se for o fwloadd do mesmo autor do balance e free vrrpd envia 
pro outro daemon, e esse pode gerar o estado da conexao de forma 
dinamica no outro firewall; fino, simples e genial. E *funciona* hehe. 
So nao e documentado (como tudo do mesmo autor).

Por outro lado ao fazer isso com o tee a maquina na outra ponta pode 
fazer um divert desse mesmo pacote, digamos um divert pro conhecido 
snort_inline. Ou pro snortsam. Com isso antes de decidir se gera 
redundancia do estado da conexao a outra maquina pode atuar de forma 
pro-ativa e resolver o que realmente fazer com o pacote. Pode bloquear 
ou deixar passar... entao um pacote aprovado num perimetro pode ter a 
aprovacao revogada no outro, no caso com base ate no conteudo do pacote 
(layer7) se envolver snortsam ou snort_inline. Impossivel fazer isso com 
pfsync.

Ja o CARP e outros 10 :) Nao depende de PF.

> Tem "synproxy", que não tem no

Tai um recurso muito fera do PF. Esse devia ser copiado na cara dura por 
outros firewall hehe.

> Além disso a documentação bem completa e oficial (bem escrita, clara e
> correta) em português me parece também uma boa vantagem.

kudos Douglas Santos hehehe :D Excelente traducao mesmo! :-)

Recursos feras do PF que eu acho que podem fazer a diferenca sao tambem 
route-to. Com IPFW da pra fazer a mesma coisa mas menos facil 
(policy-routing). Por outro lado o route-to tem opcao de round-robin. No 
IPFW teria que usar "prob X" nos "divert" se for fazer pra IPs nateados, 
ja que infelizmente "prob X" no "fwd" quebra as pernas por nao ter um 
estado FWD que o "keep-state" conheca.

Outra vantagem e nao mtar as regras de state quando mata as regras pai. 
Mas ai e mais uma consideracao do que realmente algo que faca a diferenca.

Ipfw tem "set" e com "set disable/enable" e "set swap" da pra fazer 
miserias em relacao a politicas periodicas de firewall (rotinas via cron 
por exemplo). Com pf teria que usar anchors mas ainda assim as regras 
manter-se-iam em memoria e sendo processadas. No caso do set apenas o em 
memoria e' verdade.

Bom essas sao as minhas comparacoes como usuario dos 2 firewall. Nao uso 
IPF entao nao posso opinar com detalhes sobre ele. Acho que PF e IPFW 
tem vantagens e desvantagens, e as vantagens de um nao se sobreoe `as 
vantagens do outro.

Por isso sou adepto do "use e se aprofunde nos dois". Parece exagero mas 
se nao for assim, nao vai ser possivel ter seguranca em qual usar.

Mas resumindo minha opiniao (hehe finalmente)

1) Pra NAT avancado, especialmente balanceamento: PF

2) Pra firewall em si (filtro, firewall eh filtro, nao podemos esquecer 
hehehe, firewall nao e controle de banda, nem nat, sem 
classificacao...): IPFW controla melhor, tem mais controle sobre 
ipoptions, tos, ipflags, etc, etc.

3) Pra controle de banda: com PF voce soh tem ALTQ. Com ipfw tem ALTQ e 
Dummynet. Dummynet e mais simples e limitado em recursos (o que e 
dummynet? resumindo simulacao de link muito funcional com pipes e uma 
implementacao parcial - mas essencial, nao precisamos de mais - do 
WF2Q+, com pipe, queue e weight). Por outro lado dummynet e mais 
flexivel que ALTQ em inumeras maneiras. Mas ALTQ tem mais recursos. 
Menos aplicaveis e verdade, mas sao mais recursos. Ja que com IPFW temos 
os 2, usar IPFW entao, obvio!

Tai, agora 'e "pesar" as necessidades e chegar as conclusoes hehe.

-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
(31) 3281-9633 / 3281-3547
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

_______________________________________________
freebsd mailing list
freebsd em fug.com.br
http://lists.fug.com.br/listinfo.cgi/freebsd-fug.com.br



Mais detalhes sobre a lista de discussão freebsd