Thanks Mel. You are not being difficult, I meant DoS. The network I inherited doesn’t have BGP yet so I have asked our upstream to blackhole it and I emailed abuse neither have happened yet. I do block it but that’s after it hits our side.
//Jason
Blackholing isn't what you want. That will still permit his source IP into your network, and only blackhole replies from your network, so the attack will still consume bandwidth. What you should request is a source IP ACL blocking that address at your upstream' border.
BGP is no help in these situations, unless you use a BGP-based DDoS protection service.
-mel beckman
Source based black holing would work in this case providing it was done at
GoDaddy's edge.
Anyone can set up S/RTBH on their transit-/peering-edge routers, even if they aren't using BGP for routing.
Likewise flowspec, on routers which support it.
If attack volume is high, it still may flood the link, but keeping the traffic off one's own core and off the actual target(s) of the attack are still very worthwhile.
I don’t see how. Blackholing works on destination address — it’s a route to null0. The source address isn’t considered and thus the traffic will still leave GoDaddy. GoDaddy could, I suppose, implement a policy route based on source address, but that’s really no different than an ACL. And it’s not a blackhole.
Anyway, since it's the GoDaddy edge your talking about, GoDaddy can simply disconnect the customer.
-mel
There are two problems with Source-Based Remote Triggered Black Hole (S/RTBH):
1. From the RFC itself, you by definition sacrifice the victims address:
3.1. ...While this does "complete" the attack in that the target address(es)
are made unreachable, collateral damage is minimized. It may also be
possible to move the host or service on the target IP address(es) to
another address and keep the service up, for example, by updating
associated DNS resource records.
2. No ISP I know of supports it (e.g., via BGP communities)
-mel
1. From the RFC itself, you by definition sacrifice the victims address:
3.1. ...While this does "complete" the attack in that the target address(es)
are made unreachable, collateral damage is minimized. It may also be
possible to move the host or service on the target IP address(es) to
another address and keep the service up, for example, by updating
associated DNS resource records.
This is incorrect. I've used S/RTBH for the last 15 years or so to mitigate attacks. One absolutely does *not* 'sacrifice the victim's IP address'.
The section you're quoting is describing D/RTBH, by way of explaining its deficiencies. It would probably be a good idea to read the RFC in its entirety. S/RTBH is described in Section 4 - e.g., the very next section.
2. No ISP I know of supports it (e.g., via BGP communities)
As noted in my previous message in this thread, one applies this on one's own transit-/peering-edge router. While it won't prevent said link from being saturated, it keeps traffic from the blackholed source off one's own core, and off the targeted IP(s), which is of operational utility.
Thanks Mel.
The ISP got back to me and has asked me to build a Juniper block list ACL for them so I am doing that now.
//Jason