> 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: ([EMAIL PROTECTED])~# ipfw enable altq ([EMAIL PROTECTED])~# ipfw add 1 count altq fila1 all from any to any 110,143,993 keep-state ([EMAIL PROTECTED])~# ipfw show 1 00001 90 4578 count altq fila1 ip from any to any dst-port 110,143,993 ([EMAIL PROTECTED])~# 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 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" _______________________________________________ freebsd mailing list freebsd@fug.com.br http://lists.fug.com.br/listinfo.cgi/freebsd-fug.com.br