Hello,
I wanted to poll everyones thoughts on how to deal with attacks directly on BGP peering ranges (/30's, /127's).
I know that sending an RTBH for our side of the upstream routing range does not resolve the issue, and it would actually make things worse by blackholing all inbound traffic on the carrier I send the null to. What are my options for carriers that are not willing to help investigate the situation or write up a firewall rule to mitigate it on the circuit? I am not a fan of naming and shaming because it has unintended consequences.
Thanks in advance for everyone's suggestions.
Ryan Hamel
Hey Ryan,
I'm assuming edge link in your network facing another administrative domain.
You'll have two scenarios
1) attack coming from your side
2) attack coming from far side
You can easily stop 1, obviously.
But for 2, you really need to have far-side who is cooperative and
understanding of best practices and there isn't any magic you alone
can do with entirely uncooperative far-end.
Things to consider at both ends:
a) edge filter, on all edge interfaces ensure that only udp
traceroute, icmp are sent (policed) to infrastructure addresses
b) do not advertise link networks in iBGP
c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255
Job,
Unfortunately, with my current situation, we have stopped exporting our prefixes with the tier-1 carrier and still use the outbound bandwidth. I highly doubt they will implement such a solution, but is something to keep in mind for the future.
Thanks for the tip!
Ryan Hamel
Saku,
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.
b) do not advertise link networks in iBGP
This has never been an issue.
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.
Thanks for your input!
Ryan Hamel
If the issue is flooding to your interface IP, that's not a relevant countermeasure. You're pretty much limited to asking the upstream to filter traffic to your interface IP, or asking them if you can renumber the interface into non-globally-routed IPs. If they're unwilling to do either, "you've chosen the wrong transit provider" and should start shopping for replacements.
You are not supposed to announce that range anyway as you shouldn't be announcing your infrastructure range for your protection. Ask your upstream providers not to expose that range too.
There are many ways around that selective redistribution or they can just protect that range. How they do it is none of your concern and there are many ways of achieving this. In my view this should
be added on a best practice rfc. I am assuming that you are using that block just for your bgp session.
/nikos
Hey,
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.
I don't understand why that would be true, your customers shouldn't be
using links for anything useful.
But again, in your case the attack is coming from far-end, so they
need to do this, to benefit you.
b) do not advertise link networks in iBGP
This has never been an issue.
If is now. If the links is far-end assigned, and if far-end does not
advertise it, then attack has to come from same far-end router as
where you're connected, greatly reducing attack surface.
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.
If your link isn't protected, then attacking just your BGP session
allows to bring down the BGP with very modest Mbps, like <5Mbps. If
you do GTSM and drop <255 TTL BGP, then typically attacker can't bring
down the BGP session, or at very least they need to congest whole
linerate.
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
You should have iACLs and GTSM enabled, as noted previously.
Ideally, the link should come from an unadvertised range, or a range which is sunk to null0 at the edge, as Job indicated.
If the link is numbered from a range assigned to your peer, they should have iACLs in place to prevent that range being packeted.
If the link is numbered from your own range, you should ask your peer to add that range to their iACLs, as well.
This .pdf preso discusses infrastructure self-protection concepts:
<https://app.box.com/s/osk4po8ietn1zrjjmn8b>
Maybe we are missing a key item here.
Ryan, is the attack on the BGP peering range killing your router or is it an attack saturating the link?
Do you have some netflow samples of one of these attacks or any kind of hints of what happened?
Jean St-Laurent