[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