[GTER] Ataques em Servidores
Diogo Montagner
diogo.montagner at gmail.com
Thu Apr 16 00:01:23 -03 2009
Mesmo implementado intra-carrier, existe ainda um risco muito grande
de hijack se o controle for deixado por conta do peer remoto.
Tu conhece algum caso de implementação aonde o controle do bloqueio
baseado na origem é autorizado para o peer remoto ?
O draft do rtbh recomenda que o controle seja interno. Com o controle
interno do RTBH, o problema do cliente terá que seguir o fluxo normal
de solução de problemas: abertura de ticket, etc.
----> extraído de
http://tools.ietf.org/html/draft-kumari-blackhole-urpf-02#page-4
The BGP policy will need to be relaxed to accept announcements tagged
with this community to be accepted even though they contain addresses
not controlled by the network announcing them. These announcements
must NOT be propagated outside the current AS and should carry the
no-export community.
As a matter of policy, operators SHOULD NOT accept source-based RTBH
announcements from their peers or customers, they should only be
installed by local or attack management systems within their
administrative domain.
Abs
./diogo -montagner
2009/4/14 Julio Arruda <jarruda-gter at jarruda.com>:
> Julio Arruda wrote:
>>
>> Diogo Montagner wrote:
>>>
>>> Solicite a operadora qual é a comunidade de black-hole e use ela. Mas
>>> lembre neste caso tu estará realizando um bloqueio de black-hole na
>>> operadora para um endereço IP seu (alvo do ataque), logo o tráfego
>>> limpo também será enviado para o /dev/null.
>>>
>>> Pra fazer uso da comunidade de black-hole tu terá que fazer o anuncio
>>> do /32 (alvo do ataque) com a comunidade de BH setada. Isto é feito
>>> através da aplicação de uma export policy no BGP com a operadora.
>>>
>>> Obs.: não esqueça de ativar o envio de comunidades se o seu roteador
>>> não faz isto por default.
>>
>> Ele quer fazer blackhole de origem, nao de destino :-)
>> Existe uma variante do RTBH que faz isto, 'junto' com uRPF, so que nao
>> creio seja implementado inter carriers, sem contar que deve depender do
>> universo de atacantes..
>>
>
> Um documento leve sobre isto..
>
> http://www.arbornetworks.com/index.php?option=com_docman&task=doc_download&gid=112
>
> E tambem comenta de outra feature, chamada flowspec no Junos, que creio a
> RNP usa, e sei de ao menos uma carrier fora do Brasil usando.
>
> disclaimer -> minha outra personalidade bipolar e' jarruda at arbor.net
>
>>>
>>> []s
>>> ./diogo -montagner
>>>
>>>
>>>
>>> 2009/4/13 GIULIANO (UOL) <giulianocm at uol.com.br>:
>>>>
>>>> Pessoal,
>>>>
>>>> Suponto um link de 1 Gbps recebendo um trafego alto de mais de 400 Mbps
>>>> ...
>>>> na forma de um ataque de DoS. O trafego sobe de uma so vez ... para 900
>>>> Mbps
>>>> ... e na media trabalha com 500 Mbps.
>>>>
>>>> Como eu poderia fazer, pra injetar um bloqueio de rota ... dos prefixos
>>>> de
>>>> onde se originam o ataque ... via BGP ? Estamos monitorando o trafego e
>>>> o
>>>> roteador de borda ja esta trabalhando com 89% de CPU.
>>>>
>>>> O roteador e CISCO e o cliente roda BGP com AS publico com 1 unica
>>>> operadora. Alguam poderia me ajudar ? Existem formas de fazer isso ?
>>>> Existe
>>>> algum modelo de configuracao ?
>>>>
>>>> Obrigado,
>>>>
>>>> Giuliano
>>>> --
>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>>>>
>>> --
>>> gter list https://eng.registro.br/mailman/listinfo/gter
>>
>> --
>> gter list https://eng.registro.br/mailman/listinfo/gter
>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list