[GTER] bgp ttl security -

[Vitor Mazali]

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