Attacks on BGP Routing Ranges

William Herrin bill at herrin.us
Wed Apr 18 15:35:35 UTC 2018


On Wed, Apr 18, 2018 at 7:03 AM, Ryan Hamel <Ryan.Hamel at quadranet.com> wrote:
> The attacks are definitely inbound on the border router interface. I have tracked outbound attacks before and wish it was this simple, but its not.
>
>> a) edge filter, on all edge interfaces ensure that only udp traceroute, icmp are sent (policed) to infrastructure addresses
>
> While I can implement an edge filter to drop such traffic, it's impacting our clients traffic as well.

Access list accept from bgp peer to local bgp address
Access list reject all to local bgp subnet
Access list accept everything else

Attack packets still cross the link, but then they die without any
further effect.

If the problem is that the attacker is forging the source address of
your ISP's BGP peering address then your ISP has a problem with their
filters that they must fix on pain of losing you as a customer.

If the problem is they're flooding your link with trash packets Job's
unreachable linknets will help but ultimately the attacker can just
switch to some other IP address you can't afford to change. If your
ISP can't help, this is where a DDOS mitigation service comes in to
play.



>> c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255
>
>  Could you explain how this can resolve my issue? I am not sure how this would work.

With GTSM, your router will reject any BGP packet which does not still
have an layer-3 TTL of 255. Since 255 is the highest the TTL can be
set and the TTL is decremented every hop, only an adjacent router can
send a packet that you will receive with a TTL of 255.

Personally, I wouldn't do this. Normal BGP operation is that the BGP
packet starts with a TTL of 1. If the neighbor is not adjacent, the
packet expires before it reaches your router. If it reaches your
router with a TTL larger than 1 and you haven't enabled bgp multihop
then the packet is discarded. Changing BGP's semantics like this
requires cooperation and expertise from your ISP and is likely to be
brittle.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Dirtside Systems ......... Web: <http://www.dirtside.com/>


More information about the NANOG mailing list