[GTER] bgp ttl security -

Fri Dec 5 19:26:19 -02 2014

Entao no caso de juniper, onde seto apenas se d multihop ou nao( sem descrever quantos saltos sao), o ttl seria um complemto do multihop?!
Disable connect check seriam para rotas "conectadas" so que atraves das loopbacks...?!
Resumindo e isto?!

Enviado via iPhone 
Grupo Connectoway

> Em 05/12/2014, às 12:36, Vitor Mazali <vitor_mazali at hotmail.com> escreveu:
> 
> Rodrigo,
> Alterando o ttl-security check o roteador entende que seu neighbor estará além de 1 salto (alterando o comportamento padrão para sessões eBGP), assim como com o ebgp-multihop. Em outras palavras, você usaria ou o ebgp-multihop <hops> ou o ttl-security hops <hops> para permitir que seu roteador se conecte a destinos não diretamente conectados. Vale lembrar que, para o caso de uma sessão eBGP entre loopbacks de roteadores adjacentes, o disable-connected-check também funciona, afinal, os roteadores estão diretamente conectados, não haverá decremento de ttl antes do TCP SYN chegar ao IP de destino.
> Atenciosamente,Vitor Mazali.
>> Date: Thu, 4 Dec 2014 13:23:06 -0300
>> From: rodrigo at 1telecom.com.br
>> To: gter at eng.registro.br
>> Subject: [GTER] bgp ttl security -
>> 
>> Estava lendo um material sobre outra coisa e me apareceu este aqui sobre BGP
>> ttl security em um site da cisco:
>> 
>> BGP Time To Live Security Check
>> Overview
>> Another BGP attack scenario that is listed at the beginning of this document
>> is a Denial of Service (DoS) attack against the BGP process. The BGP Time To
>> Live (TTL) security check is designed to protect the BGP process from these
>> kinds of CPU-utilization-based attacks and route manipulation attempts. The
>> BGP protocol must be examined in greater detail to understand how this
>> protection technique works.
>> 
>> The BGP protocol defines two types of sessions: internal BGP sessions
>> (iBGP), which are established between peers within the same Autonomous
>> System (AS), and external BGP sessions (eBGP), which are established between
>> peers in two different ASs. eBGP sessions are the BGP sessions that are
>> established between an Enterprise and its upstream SP.
>> 
>> By default and per the RFC, when eBGP is configured, the IP header TTL for
>> all neighbor session packets is set to 1. This setting was originally
>> assumed to be useful because it prevents the establishment of an eBGP
>> session beyond a single hop. However, an attacker could be located up to 255
>> hops away and still send spoofed packets to the BGP-speaking router
>> successfully. For example, an attacker could send large amounts of TCP SYN
>> packets to the BGP peer in hopes of overwhelming the BGP process. The BGP
>> MD5 neighbor authentication technique described earlier in this document
>> does not protect against this kind of attack and can actually exacerbate its
>> effects by causing the router CPU to expend resources while it attempts to
>> compute MD5 hashes on large numbers of attack packets. Therefore, another
>> mechanism was required to defend against BGP DoS attacks. The BGP TTL check
>> uses a clever modification to the original BGP RFC to accomplish this goal.
>> 
>> The BGP TTL security check leverages the fact that the vast majority of
>> Internet SP eBGP peering sessions are established between routers that are
>> adjacent to each other (for example, either between directly connected
>> interfaces or possibly between loopbacks). Because successful TTL spoofing
>> is considered nearly impossible, a mechanism that is based on an expected
>> TTL value was developed to provide a simple, robust defense from
>> infrastructure attacks that are based on forged BGP packets. The concept was
>> originally defined and subsequently modified in the following documents: BGP
>> TTL Security Hack (BTSH)
>> <http://smakd.potaroo.net/ietf/idref/draft-gill-btsh/index.html>  and BGP in
>> The Generalized TTL Security Mechanism (GTSM)
>> <http://www.ietf.org/rfc/rfc3682> .
>> 
>> When the BGP TTL security check is enabled, the initial TTL value for an
>> eBGP packet is set to 255 rather than 1, and a "minimum TTL-value" is
>> enforced on all BGP packets that are associated with that eBGP session.
>> Because the IP header TTL value is decremented by each router hop along its
>> path to its final destination, the diameter from which an attacker could
>> possibly source packets is restricted to those routers that are directly
>> connected.
>> 
>> The BGP TTL security check is not required nor is it considered useful for
>> iBGP sessions. The BGP TTL security check was first introduced in Cisco IOS
>> Software Releases 12.0(27)S, 12.3(7)T, and 12.2(25)S.
>> Refer to BGP Support for TTL Security Check
>> <http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_btsh.html
>>> for more information.
>> 
>> Minha dúvida é: se multihop nao está ativo significa que posso estabelecer
>> BGP atraves de rota conectada apenasŠaté entao ok, entao como a definicao de
>> ttl descrita me protegeria de spoofing por exemplo?
>> Ou somente habilitar ttl em conexoes multihop ? Ele ainda fala que
>> autenticacoes md5 nao protegem neste caso, e sim elevam o uso de cpu em caso
>> de ataques. É fato, uma vez que vai ficar verificando a hora toda a
>> autenticacao md5Š.
>> Em minhas regras e firewall existe tambem que aceito conexoes bgp nos ip¹s
>> apenas dos BGP PEERS e tem um prefix-list criando um apply-path onde listo
>> estes ip¹s de forma automática.
>> Se correr o bicho pega e se ficar o bicho come?
>> 
>> 
>> PS> aqui nao uso ciscoŠjuniperŠ
>> Alguém poderia dar um briefing sobre o assunto por favor?
>> ref:. 
>> http://www.cisco.com/web/about/security/intelligence/protecting_bgp.html
>> 
>> 
>> 
>> Rodrigo Augusto
>> Gestor de T.I. Grupo Connectoway
>> http://www.connectoway.com.br <http://www.connectoway.com.br/>
>> http://www.1telecom.com.br <http://www.1telecom.com.br/>
>> * rodrigo at connectoway.com.br <mailto:rodrigo at connectoway.com.br>
>> ( (81) 3497-6060
>> ( (81) 8184-3646
>> ( INOC-DBA 52965*100
>> 
>> 
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>                         
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter