[GTER] Campanha Técnica IP-Spoofing
Douglas Fischer
fischerdouglas at gmail.com
Thu Feb 1 20:13:51 -02 2018
Danton, essa descrição que você deu é do modo Strict do RP-Filter, onde ele
olha para a FIB "E" para a interface de onde vem o pacote.
No modo loose ele só olha se a rota para a FIB, desconsiderando a interface
para aonde aponta a rota. Nesse modo esse problema que descreveu não ocorre.
Tens razão de ser reticente com o RP-Filter, mas ele funciona sim.
Em 1 de fev de 2018 1:33 PM, "Danton Nunes" <danton.nunes at inexo.com.br>
escreveu:
> On Thu, 1 Feb 2018, Douglas Fischer wrote:
>
> Opa, acho que está havendo uma confusão de conceitos...
>>
>> RP-Filter não é statefull firewall.
>> Não necessariamente a conexão precisa ter saído por aquela interface.
>> É só um lookup na tabela para ver se existe rota para aquela interface
>> apontando para alguma coisa que bata com a origem do pacote.
>>
>> A rota default pode ou não cobrir o RP-Filter lookup, depende da
>> implementação.
>>
>
> pense no caso em que você tem mais de um upstream, tem zilhões de rotas
> para cada um deles, e não tem rota default. o pacote sai por A porque é por
> lá que há uma rota na FIB (tabela do kernel), mas volta por B, e isso é
> normal. No entanto não há na FIB uma rota do destino por B e o RP-filter
> rejeita o pacote. Não haveria esse problema se o RP-filter se baseasse na
> tabela RIB, mas essa está no nível de aplicação, com o programa que
> processa o protocolo BGP, e não no kernel e o filtro está no kernel, usando
> somente informações do próprio kernel (a FIB).
>
> Resultado: um pacote que não era falsificado foi rejeitado.
>
> Conselho de amigo: NUNCA use RP-filter em multihoming!
>
> Numa situação bastante comum, a interface para a rede interna é
> single-homed, e nela é possível aplicar o RPF sem problemas.
>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list