Junos OS

Hi,

I'm not sure if this is really relevant or not but thought I would ask given that someone may have come across this.

We have 2 sites.... One sites upstream ISP offers a "Blackhole" service, where a route we do not want can be sent to them to be blocked at their side, thus saving our interfaces from becomming over utilised. This is great and is a superb service.....

However, the other sites upstream ISP does not offer this type of service. I have heard that there is a generic internet "Blackhole" service that uses Communities with a 666 string. I have searched for this service and cannot find any information regarding it.

Have any of you utilised this type of service before and if so, how?

Thanks

Apologies. As an add on to the above, I understand about RTBH and configuring null interfaces.

Whatour BH upstream ISP offers us is the ability for us to send them the target and for them to stop, at THEIR side, all traffic to that target address until the attack has ceased. RTBH does not seem to stop the packets hitting our interfaces still, and that is what I want to achieve.

Thanks

Most ISP offer the upstream blackhole service to customers that you note.  In order to be effective the ISP that is doing the blackhole operation has to have the subnet where your /32 address exists coming across their network.  This is why this is done by your directly connected ISPs because they are definately transiting your traffic.  Since blackhole routes are always the host or a very small subnet under attack, they really can't be done from a central internet location and be effective.

The 666 community you reference is a recent addition to the well known community list by the IETF attempting to standardize this for BGP users.  But reality is that already pretty much every carrier is already setup using their own designated community that you need to get from them. 

https://tools.ietf.org/html/rfc7999

Hello,

---

@adgwytc wrote:

RTBH does not seem to stop the packets hitting our interfaces still, and that is what I want to achieve.

 

---

 Whose IP space is assigned to these interfaces? I reckon this is provider address space and provider won't accept Your announcements of this IP space towards self (i.e. provider has a prefix-list allowing only certain IP blocks from You and it does not include interface IP space).

Please talk to them to correct their ingress BGP policy to include /32s from that space but only when a /32 has a blackhole community.

Alternatively, if You don't use Your interface IPs for NAT then You can ask provider to to the following:

1/ use GTSM (https://tools.ietf.org/html/rfc5082) - BGP with TTL 255 - to easily distinguish control traffic even if it may be spoofed 

2/ put an outbound filter on the interface towards You that :

2a/ allows BGP w/TTL 255

2b/ rate-limits ICMP towards Your interface IP/32 (for incoming pings and tracert/tracert replies). You may ask how the incoming UDP and TCP traceroute will be allowed - I would say You don't need to. Tell everyone to use Windows tracert which is ICMP based.

2c/ block anything that has dst IP == Your interface IP/32

2d/ else allow 

HTH

Thx

Alex

Great answers from both. Thank you guys.

On the side where the upstream ISP offers a BH service, it's all good. I just create the peering (which is all good) and then provide the /32 destination prefix with the "discard" statement to the upsteam ISP and also ensure that the originating ttraffic is sent to a 5k queue so that the bandwidth is limited and we can examine the packets. So, a double stop there. 

I have e-mailed our account manager at the other upstream ISP to let them know that we want this service offered as well.

Obviously, written policies will have to be put in place for the monitoring of this traffic as the destination prefix is blocked which will also stop legitimate traffic to our customer. It's a little difficult to get source IPs if it is a DDoS attack we are eliminating.

Thanks again for your help. 

Both of the answers are accepted solutions but I can only accept one as "solution", so, it's down to a flip of a coin.... 🙂

If you do want to try to more surgically deal with DDoS events, you are right you need to know more about the specific sources and protocols used by the attacker.  For this you can configure jflow on the Junos edge device and send the interface data to a flow collector.  Nfsen is an open source free one that you could use.

During the attack you can then see what the nature of the traffic is and choose to use firewall filters or BGP flow spec to drop specifc flows at your incoming edge. 

This is the same method that most of the DDoS providers use only they have deep automation to automatically detect the threat patterns from the flow data.

Naturally, if the issue is pure volume and they are sending more traffic than you have purchased from the upstream you have no choice but to engage with the blackhole.