[GTER] Co-operative DDoS Mitigation

[Patrick Tracanelli]

> On Oct 23, 2015, at 15:28, Fabiano Ribeiro <fabiano.ribeiro at gerenciatec.com.br> wrote:
> 
>     Não tinha pensado nisso, é algo que poderia ser programado em um
> sistema operacional.
>    A maior dificuldade seria manter sincronizado as alterações das rotas
> do peer com as regras do ipfw. Um código que rode de tempo em tempo seria
> uma puta de uma gambiarra. O certo era uma interação do daemon que a cada
> update uma trigger pudesse ser chamada. Alguém já viu algo assim ?

O ipfw ja faz verify source reach, verify reverse path e anti spoof olhando a tabela de roteamento local, sem trigger e sem gambiarra. Tem um overhead que não inexpressivo, mas menor que o custo do encaminhamento certamente. Eu tenho usado bastante em ambientes com alta taxa de pps a ser filtrado, em caixa separada e com netmap-ipfw. Resumindamente fecha um BGP Full com a caixa que vai filtrar e set nexthop pra loopback (voce não pretende/precisa usar a rota), o netmap-ipfw vai ver a rota la e olhar por onde chega e decidir se da match ou não. 

Muitas vezes no entanto o simples funciona melhor que a outra opção, e dependendo do ataque apenas marcar RTF_BLACKHOLE pra tudo que cai na rota default na entrada da interface também tem mostrado bons resultados. Vou dar uma palestra sobre isso dia 3 aqui em Lake Mary, FL na sede do Team Cymru. Depois compartilho os slides.

De qualquer forma apesar de ter coisa melhor, o “trigger” que você quer ja existe, o “set pftable” do OpenBGP permite que qualquer filtro BGP com seus critérios popule uma table do firewall com o conteúdo da tabela RIB, a tabela esta sempre la e é uma RADIX como vc teria na FIB então você pode fazer o que quiser com ela incluindo filtrar como quiser. Eu pessoalmente não gosto de nada que envolva pf hehe, não escala, então não uso. Mas o recurso está la.

--
Patrick Tracanelli