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
Hi, On Wed, 18 Apr 2018 at 11:39, Ryan Hamel <Ryan.Hamel@quadranet.com> wrote:
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.
Some carriers offer “unreachable linknets”, linknets that are carved from netblocks that aren’t announced in the DFZ or are firewalled off. If the carrier doesn’t want to help, your best course of action may be to disconnect the circuit to stop the attack traffic. Kind regards, Job
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 ________________________________ From: Job Snijders <job@instituut.net> Sent: Wednesday, April 18, 2018 3:44 AM To: Ryan Hamel Cc: nanog@nanog.org Subject: Re: Attacks on BGP Routing Ranges Hi, On Wed, 18 Apr 2018 at 11:39, Ryan Hamel <Ryan.Hamel@quadranet.com<mailto:Ryan.Hamel@quadranet.com>> wrote: 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. Some carriers offer "unreachable linknets", linknets that are carved from netblocks that aren't announced in the DFZ or are firewalled off. If the carrier doesn't want to help, your best course of action may be to disconnect the circuit to stop the attack traffic. Kind regards, Job
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 On 18 April 2018 at 13:37, Ryan Hamel <Ryan.Hamel@quadranet.com> wrote:
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
-- ++ytti
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 ________________________________________ From: Saku Ytti <saku@ytti.fi> Sent: Wednesday, April 18, 2018 3:48 AM To: Ryan Hamel Cc: nanog@nanog.org Subject: Re: Attacks on BGP Routing Ranges 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 On 18 April 2018 at 13:37, Ryan Hamel <Ryan.Hamel@quadranet.com> wrote:
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
-- ++ytti
On Wed, 18 Apr 2018, Ryan Hamel wrote:
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 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. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Hey, On 18 April 2018 at 14:03, Ryan Hamel <Ryan.Hamel@quadranet.com> wrote:
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. -- ++ytti
On Wed, Apr 18, 2018 at 7:03 AM, Ryan Hamel <Ryan.Hamel@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@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
On 18 Apr 2018, at 18:03, Ryan Hamel wrote:
Could you explain how this can resolve my issue? I am not sure how this would work.
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> ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
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 On 04/18/2018 11:01 PM, Roland Dobbins wrote:
On 18 Apr 2018, at 18:03, Ryan Hamel wrote:
Could you explain how this can resolve my issue? I am not sure how this would work.
You should have iACLs and GTSM enabled, as noted previously.
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 -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Ryan Hamel Sent: Wednesday, April 18, 2018 11:38 AM To: nanog@nanog.org Subject: Attacks on BGP Routing Ranges 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 This email is from Equinix (EMEA) B.V. or one of its associated companies in the territory from where this email has been sent. This email, and any files transmitted with it, contains information which is confidential, is solely for the use of the intended recipient and may be legally privileged. If you have received this email in error, please notify the sender and delete this email immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889.
participants (8)
-
Jean | ddostest.me -
Job Snijders -
Jon Lewis -
Nikos Leontsinis -
Roland Dobbins -
Ryan Hamel -
Saku Ytti -
William Herrin