Hello Everyone,
I really hope this is not against group policy etc.. however our network is
being hit
hard by a China IP for the past 6 months. Our systems our up to date,
passwordless
ssh etc.. but they're DOS attempts are getting more and more aggressive.
Tried to
contact their phone number to no success (not valid). Emails don't get any
response.
The IP is 218.77.79.43. Do we have any options?
Terrance
Hello Terrance,
I've seen this IP several times in our threat logs.It is a known threat and
has even been called out by Norse (
http://www.norse-corp.com/blog-thursday-140828.html).
I recommend blocking the ip at the edge of your network. If it becomes more
of a problem, ask one of your upstream providers to block him you upstream
of you as well. They shouldn't hesitate as it is clearly labeled a known
threat.
Thanks,
Hello Everyone,
I really hope this is not against group policy etc.. however our network is
being hit
hard by a China IP for the past 6 months. Our systems our up to date,
passwordless
ssh etc.. but they're DOS attempts are getting more and more aggressive.
please define 'dos attempts' ... perhaps you have some logs?
Tried to
contact their phone number to no success (not valid). Emails don't get any
response.
you are not the only one.
The IP is 218.77.79.43. Do we have any options?
probably not?
S/RTBH and/or ACLs at your transit/peering edge, for starters:
<https://app.box.com/s/xznjloitly2apixr5xge>
Also, asking your upstreams/peers to block traffic sourced from this IP to your netblock(s) on their networks.
It would also be a good idea to ensure that your systems which are being targeted aren't themselves compromised, and being used by miscreants as botnet C&Cs or whatever. A lot of 'inexplicable' attacks are actually internecine disputes amongst miscreants, with compromised systems under the control of miscreant A being targeted by miscreant B - and the legitimate owner/operator of the hosts in question has no idea that they're compromised.
I'm actually curious how many transit providers would implement data plane filters on their side to block source traffic bound for their downstreams.
Personally, as a transit provider, I'm less inclined to filtering traffic in any way; impact to hardware e.t.c. notwithstanding...
Perhaps times are changing.
Mark.
All 6 of my upstreams (Most of them tier 1s, except Internap which is a tier 3?) have cooperated just fine in blocking problematic IPs if needed in emergencies.
I did not have to argue.
In the data plane for the link facing you, or through RTBH?
Mark.
use block firewall country flags, use strict packet compliance checking, dont bother with abuse email comms as is ignored, mentioned to trade missions but ignored
colin
The assumption is that that OP is an end-customer/endpoint network, and willing to pay for same, if necessary.
Even if that's not the case, that's how DDoS attacks are routinely and cooperatively mitigated between providers, when it's possible to block based on source, number of sources isn't overwhelming, etc.
I null route those IPs that stand out above the background noise at
our edge. Seems to work relatively well so far.
I do have a request for Roland. Would you mind sharing more details
on what you've seen regarding the various miscreants screwing with
each others' devices?
The assumption is that that OP is an end-customer/endpoint network, and willing to pay for same, if necessary.
My general experience is that customers are not willing to pay for implementation of data plane filters. They'd be willing to pay for traffic scrubbing, however.
Even if that's not the case, that's how DDoS attacks are routinely and cooperatively mitigated between providers, when it's possible to block based on source, number of sources isn't overwhelming, etc.
That's one of two issues - if the sources are overwhelming how does one scale that up without the use of some scrubbing service? Writing data plane filters that are customer-specific works (assuming you have the hardware for it), but can get unwieldy.
The other issues are the chance to boo-boo things when filtering a customer-facing port, and/or forgetting to remove filters after they are needed and customer (or the remote end) ends up having reachability issues.
Mark.
Data plane.
PCCW on a separate project even offered to do specific filters like 'drop all udp to port n targetting block x.' My subscription to them is normal internet transit.
Suppose I've been lucky, eh.
If you don't want to spend more than 2 minutes on this, then move sshd to a
different (randomish) port. Sounds naive, but it's dirt cheap and really helps.
Robert
They will DDoS and/or work to subvert the C&C infrastructure of botnets run by other miscreants due as a form of retaliation for illicit deals gone wrong, in order to inconvenience perceived competitors, due to 'talking smack' on underground forums, etc.
It is quite common for compromised servers to be utilized as botnet C&C servers, with the legitimate owners/operators of said servers being totally unaware of this activity - and thus surprised when they're suddenly on the receiving end of DDoS attacks which are actually spurred by inter-miscreant rivalries. We've observed intra-IDC DDoS attacks launched from hosts belonging to one customer of a host/colocation/VPS provider against hosts belonging to another customer of the same provider, for example; we've even seen the same server compromised by two different groups of miscreants attacked by both groups of miscreants, in this context.
That's one of two issues - if the sources are overwhelming how does one scale that up without the use of some scrubbing service? Writing data plane filters that are customer-specific works (assuming you have the hardware for it), but can get unwieldy.
Some operators have specialized DDoS mitigation capabilities. Others rely exclusively on basic network infrastructure-based mechanisms like D/RTBH, S/RTBH, and/or flowspec.
The other issues are the chance to boo-boo things when filtering a customer-facing port, and/or forgetting to remove filters after they are needed and customer (or the remote end) ends up having reachability issues.
Sure. But this doesn't obviate the fact that cooperative DDoS mitigation amongst network operators routinely takes place on the Internet today, and is increasingly made available in one form or another to end-customers who request same.
would be interested to know of providers using bgp to auto block ranges from china
colin
This is not an optimal approach, and most providers are unlikely to engage in such behavior due to its potential negative impact (I'm assuming you mean via S/RTBH and/or flowspec).
Here's one counterexample:
<https://ripe68.ripe.net/presentations/176-RIPE68_JSnijders_DDoS_Damage_Control.pdf>
why not try if chinanet folks refuse to respond to abuse,apac details
colin