[GTER] Ataques em Servidores

[Julio Arruda]

Diogo Montagner wrote:
> 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.
> 

RTBH puro (filtrar destino), sim, e' normal o 'inter-dominios', RTBH 
para source based filtering, nao conheco ninguem nem que tentou implementar.
> 
> ----> 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 ?