[GTER] ServerU L-800+FreeBSD 10.1+OpenBGPD+Netmap

[Patrick Tracanelli]

Fabiano,

Sendo bem pragmático, minhas sugestões:

1 - na borda, *se* tiver real necessidade de filtragem use ipfw
2 - apenas regras stateless
3 - seus interrupt requests na placa de rede aumentam na proporção IRQ-RATE=(pps*nro_regras) então tenha a menor quantidade possível de regras de firewall, meia dúzia na borda é suficiente
4 - use e abuse de tables e especialmente tablearg pra fazer com 1 só regra o que você precisaria de várias (sumarizar regras, isso não é iptables… quanto menos melhor)

Essas recomendações não tem nada a ver com FreeBSD+OpenBGPD, tem a ver com a borda. Você não vai fazer PBR nateado na borda, não vai usar route-to, se for usar algo será um ipfw fwd ou setfib com múltiplas tabelas FIB do kernel do FreeBSD, ou seja PBR sem tradução, então pare de pensar em PF. A integração do PF com OpenBGP permite coisas legais como

match from any source-as 15169 set pftable google

E pronto na table google voce terá todos os CIDR anunciados pelo AS do Google. Legal, talvez útil, mas não use PF pra isso, mantenha o filtro desligado se precisar dessa “facilidade” use um trigger qualquer pra jogar o que tem na table do PF pra uma table do ipfw e use-a com ipfw pro bem da sua caixa e sua performance. Apesar da integração ser legal é também pouco provável que voce va precisar e de fato usar.

Ja o uso de netmap-ipfw não tem a ver com seu cenário, você teria que mudar a topologia e colocar outra caixa com netmap-ipfw protegendo a caixa com BGP :)

Enfim, resumindo, o custo de ter firewall, mesmo meia dúzia de regras, será de 40% da performance. Quanto mais regras, pior esse custo. Com 400 regras de firewall por exemplo, sua caixa que roteia 5Gbit/s não passará de 2Gbit/s.

De volta ao PBR, fwd e setfib são muito mais leves que pf route-to e não onerará sua caixa mais do que uma regra de filtro convencional oneraria. Diferente da maior parte das outras implementações de PBR, normalmente divididas em etapas (route-mark, route-map, match de ACL no route-mark, tradução e tracking). Então um motivo a mais pra ipfw e não pf.

Mas claro, estou assumindo que voce esteja na borda com perfil de uso de borda e venha a precisar de algo proximo de toda a capacidade da caixa pra funções… de borda ;) Mas se voce tem uma L-800 e não precisará tirar o máximo da caixa, talvez estejamos com preciosismo. Temos clientes, cidades, estados, que tem L800 com BGP e seus 300Mbit/s, 400Mbit/s de upstream e a mesma caixa faz firewall stateful, NAT, controle de banda, etc, cenários onde perder 40% ou 80% da capacidade de troughput da caixa não faz diferença pois ainda assim teria sobras pra necessidade do cliente nesse cenário.

Bom ainda que seja um caso desses, continue preferindo ipfw.

IPFW tem melhor performance em todos aspectos, e tem melhores capacidades de filtragem também, ipoptions, icmp administrative responses, IPv6, ou até mesmo um simples “iplen 0-19” é algo que você sequer, consegue fazer com PF. Veja bem não é que ipfw faz melhor, pf sequer faz… e na borda isso e recursos como antispoof, verify return path, verify source path reachability, são recursos que na hora que você precisar, é bom ter.

Particularmente olho pro PF não como um firewall mas como um mecanismo poderoso pra fazer NAT ;) e todos os xunxos e gambiarras intrínsecas ao NAT como PBR traduzido, tracking de sessões traduzidas, gerenciamento de pools etc. Ou seja o melhor que o PF tem a oferecer, deve ficar longe de uma caixa de borda. Se precisa de NAT avançado e PBR traduzido provavelmente essa função deve estar em uma caixa mais pra dentro da sua infra, mais perto dos clientes, POPs, bem mais longe da borda. Ou seja voltando ao início, tudo se resume ao ponto 1 no começo do e-mail.


> On 16/05/2015, at 18:36, Fabiano Ribeiro <fabiano.ribeiro at gerenciatec.com.br> wrote:
> 
> Rubens,
> 
>   Então, como disse hoje não preciso de PBR, mas quero já testar o recurso
> caso seja preciso direcionar um tráfego para algum link. Como ela está aqui
> em laboratório dando sopa já quero deixar testado a capacidade para saber
> se posso contar com o recurso em alguma situação. Não preciso chegar ao
> máximo da capacidade da ServerU agora.
> 
>   Estamos fugindo da discussão inicial, que é saber qual o melhor firewall
> para trabalhar no freebsd+openbgpd. Algum colega da lista trabalha com PBR
> e qual firewall usa ?
> 
> Em 16 de maio de 2015 18:21, Rubens Kuhl <rubensk at gmail.com> escreveu:
> 
>> 2015-05-16 18:03 GMT-03:00 Fabiano Ribeiro <
>> fabiano.ribeiro at gerenciatec.com.br>:
>> 
>>>    Agora eu entendi porque que é difícil encontrar relatos de uso do
>>> openbgpd+pf, pois no core não se utiliza firewall para filtragem de DDoS
>>> (no meu caso está na camada de distribuição), mas para utilizar PBR
>> baseado
>>> em routing mark é necessário o mesmo, ou estou enganado ?
>>>    Além disso, os colegas deixam desativado os recursos de firewall
>> (seja
>>> ipfw ou PF) no sistema ? Há realmente essa necessidade ? Sei que será
>>> necessário threads a mais para processar o firewall, mas não vejo motivo
>> de
>>> deixá-lo desativado se eu quiser dropar um input na minha porta SSH. A
>>> menos que se queira chegar ao máximo de Mpps da caixa.
>>> 
>> 
>> Firewall de proteção do plano de controle é algo a deixar ligado, inclusive
>> com stateful. Tráfego só de passagem pela caixa que é melhor deixar
>> normalmente intocado, só filtrando quando for ataque à sua infra-estrutura
>> (não a clientes, que você deve filtrar nos dispositivos que atendem os
>> clientes).
>> 
>> 
>> Rubens
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>> 
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 at sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"