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, - Anthony On Mon, Mar 16, 2015 at 7:06 PM, Terrance Devor <ter.devor@gmail.com> wrote:
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
On Mon, Mar 16, 2015 at 10:06 PM, Terrance Devor <ter.devor@gmail.com> wrote:
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?
Terrance
On 17 Mar 2015, at 9:06, Terrance Devor wrote:
Do we have any options?
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. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 18 Mar 2015, at 9:13, Roland Dobbins wrote:
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. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 18/Mar/15 04:13, Roland Dobbins wrote:
Also, asking your upstreams/peers to block traffic sourced from this IP to your netblock(s) on their networks.
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. On 3/18/2015 午後 02:26, Mark Tinka wrote:
On 18/Mar/15 04:13, Roland Dobbins wrote:
Also, asking your upstreams/peers to block traffic sourced from this IP to your netblock(s) on their networks.
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.
On 3/18/2015 午後 02:44, Mark Tinka wrote:
On 18/Mar/15 07:31, Paul S. wrote:
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.
In the data plane for the link facing you, or through RTBH?
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.
On 18 Mar 2015, at 12:26, Mark Tinka wrote:
I'm actually curious how many transit providers would implement data plane filters on their side to block source traffic bound for their downstreams.
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. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 18/Mar/15 08:19, Roland Dobbins wrote:
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.
On 18 Mar 2015, at 13:32, Mark Tinka wrote:
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. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
would be interested to know of providers using bgp to auto block ranges from china colin Sent from my iPhone
On 18 Mar 2015, at 09:49, "Roland Dobbins" <rdobbins@arbor.net> wrote:
On 18 Mar 2015, at 13:32, Mark Tinka wrote:
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.
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 18 Mar 2015, at 16:55, Colin Johnston wrote:
would be interested to know of providers using bgp to auto block ranges from china
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). ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 18 Mar 2015, at 17:00, Roland Dobbins wrote:
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> ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
interesting use of ripe atlas info :) was thinking same myself colin Sent from my iPhone
On 18 Mar 2015, at 10:04, "Roland Dobbins" <rdobbins@arbor.net> wrote:
On 18 Mar 2015, at 17:00, Roland Dobbins wrote:
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>
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
We are using Mikrotik for a BGP blackhole server that collects BOGONs from CYMRU and we also have our servers (web, email, etc.) use fail2ban to add a bad IP to the Mikrotik. We then use BGP on all our core routers to null route those IPs. The ban-time is for a few days, and totally dynamic, so it isn't a permanent ban. Seems to have cut down on the attempts considerably. Eric Rogers PDSConnect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Roland Dobbins Sent: Wednesday, March 18, 2015 6:04 AM To: nanog@nanog.org Subject: Re: Getting hit hard by CHINANET On 18 Mar 2015, at 17:00, Roland Dobbins wrote:
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> ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
I did a test on my personal server of filtering every IP network assigned to China for a few months and over 90% of SSH attempts and other noise just went away. It was pretty remarkable. Working for a public university I can't block China outright, but there are times it has been tempting. :-) The majority of DDOS attacks I see are sourced from addresses in the US, though (likely spoofed). Just saw a pretty large one last week which was SSDP 1900 to UDP port 80, 50K+ unique host addresses involved. On Wed, Mar 18, 2015 at 8:32 AM, Eric Rogers <ecrogers@precisionds.com> wrote:
We are using Mikrotik for a BGP blackhole server that collects BOGONs from CYMRU and we also have our servers (web, email, etc.) use fail2ban to add a bad IP to the Mikrotik. We then use BGP on all our core routers to null route those IPs.
The ban-time is for a few days, and totally dynamic, so it isn't a permanent ban. Seems to have cut down on the attempts considerably.
Eric Rogers PDSConnect www.pdsconnect.me (317) 831-3000 x200
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Roland Dobbins Sent: Wednesday, March 18, 2015 6:04 AM To: nanog@nanog.org Subject: Re: Getting hit hard by CHINANET
On 18 Mar 2015, at 17:00, Roland Dobbins wrote:
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>
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
China network blocks work great, I wish did not have to use but they never respond to admin or abuse contacts either Colin
On 23 Mar 2015, at 13:06, Ray Soucy <rps@maine.edu> wrote:
I did a test on my personal server of filtering every IP network assigned to China for a few months and over 90% of SSH attempts and other noise just went away. It was pretty remarkable.
Working for a public university I can't block China outright, but there are times it has been tempting. :-)
The majority of DDOS attacks I see are sourced from addresses in the US, though (likely spoofed). Just saw a pretty large one last week which was SSDP 1900 to UDP port 80, 50K+ unique host addresses involved.
On Wed, Mar 18, 2015 at 8:32 AM, Eric Rogers <ecrogers@precisionds.com> wrote:
We are using Mikrotik for a BGP blackhole server that collects BOGONs from CYMRU and we also have our servers (web, email, etc.) use fail2ban to add a bad IP to the Mikrotik. We then use BGP on all our core routers to null route those IPs.
The ban-time is for a few days, and totally dynamic, so it isn't a permanent ban. Seems to have cut down on the attempts considerably.
Eric Rogers PDSConnect www.pdsconnect.me (317) 831-3000 x200
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Roland Dobbins Sent: Wednesday, March 18, 2015 6:04 AM To: nanog@nanog.org Subject: Re: Getting hit hard by CHINANET
On 18 Mar 2015, at 17:00, Roland Dobbins wrote:
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>
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
-- Ray Patrick Soucy Network Engineer University of Maine System
T: 207-561-3526 F: 207-561-3531
MaineREN, Maine's Research and Education Network www.maineren.net
On Monday, March 23, 2015, Ray Soucy <rps@maine.edu> wrote:
I did a test on my personal server of filtering every IP network assigned to China for a few months and over 90% of SSH attempts and other noise just went away. It was pretty remarkable.
Working for a public university I can't block China outright, but there are times it has been tempting. :-)
The majority of DDOS attacks I see are sourced from addresses in the US, though (likely spoofed). Just saw a pretty large one last week which was SSDP 1900 to UDP port 80, 50K+ unique host addresses involved.
Having your upstream apply a permanent udp bw policer, say 5 or 10x busy hour baseline, works well for this.
On Wed, Mar 18, 2015 at 8:32 AM, Eric Rogers <ecrogers@precisionds.com <javascript:;>> wrote:
We are using Mikrotik for a BGP blackhole server that collects BOGONs from CYMRU and we also have our servers (web, email, etc.) use fail2ban to add a bad IP to the Mikrotik. We then use BGP on all our core routers to null route those IPs.
The ban-time is for a few days, and totally dynamic, so it isn't a permanent ban. Seems to have cut down on the attempts considerably.
Eric Rogers PDSConnect www.pdsconnect.me (317) 831-3000 x200
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org <javascript:;>] On Behalf Of Roland Dobbins Sent: Wednesday, March 18, 2015 6:04 AM To: nanog@nanog.org <javascript:;> Subject: Re: Getting hit hard by CHINANET
On 18 Mar 2015, at 17:00, Roland Dobbins wrote:
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>
----------------------------------- Roland Dobbins <rdobbins@arbor.net <javascript:;>>
-- Ray Patrick Soucy Network Engineer University of Maine System
T: 207-561-3526 F: 207-561-3531
MaineREN, Maine's Research and Education Network www.maineren.net
On Mon, 23 Mar 2015, Ca By wrote:
Having your upstream apply a permanent udp bw policer, say 5 or 10x busy hour baseline, works well for this.
Many upstreams will not do that, particularly on a permanent basis. They might do something temporarily to deal with an incident, but many of the bigger carriers probably wouldn't want to leave that in place permanently. jms
On Sun, Mar 23, 2014 at 3:43 AM, Justin M. Streiner <streiner@cluebyfour.org
wrote:
On Mon, 23 Mar 2015, Ca By wrote:
Having your upstream apply a permanent udp bw policer, say 5 or 10x busy
hour baseline, works well for this.
Many upstreams will not do that, particularly on a permanent basis. They might do something temporarily to deal with an incident, but many of the bigger carriers probably wouldn't want to leave that in place permanently.
jms
Mine Tier 1 up-streams are fine with it permanent. YMMV. I did have to get my account team involved, but from a technical perspective, a one line policer (all UDP rate-limit to 10% of link speed) is not a technical challenge, and the one-off config element is not overly burdensome. Again, YMMV. And, your frequency and impact of IPv4 UDP based attacks will dictate your needs. CB
+1, I've had good luck with this as well. My experiences pretty much mirror yours, NOC says no, had to ask my SE to take care of it. Didn't have any issues after. On 3/23/2015 午後 11:55, Ca By wrote:
On Sun, Mar 23, 2014 at 3:43 AM, Justin M. Streiner <streiner@cluebyfour.org
wrote: On Mon, 23 Mar 2015, Ca By wrote:
Having your upstream apply a permanent udp bw policer, say 5 or 10x busy
hour baseline, works well for this.
Many upstreams will not do that, particularly on a permanent basis. They might do something temporarily to deal with an incident, but many of the bigger carriers probably wouldn't want to leave that in place permanently.
jms
Mine Tier 1 up-streams are fine with it permanent. YMMV. I did have to get my account team involved, but from a technical perspective, a one line policer (all UDP rate-limit to 10% of link speed) is not a technical challenge, and the one-off config element is not overly burdensome.
Again, YMMV. And, your frequency and impact of IPv4 UDP based attacks will dictate your needs.
CB
why not try if chinanet folks refuse to respond to abuse,apac details colin Sent from my iPhone
On 18 Mar 2015, at 10:00, "Roland Dobbins" <rdobbins@arbor.net> wrote:
On 18 Mar 2015, at 16:55, Colin Johnston wrote:
would be interested to know of providers using bgp to auto block ranges from china
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).
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
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 Sent from my iPhone
On 17 Mar 2015, at 02:06, Terrance Devor <ter.devor@gmail.com> wrote:
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
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? On Tue, Mar 17, 2015 at 11:18 PM, Colin Johnston <colinj@gt86car.org.uk> wrote:
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
Sent from my iPhone
On 17 Mar 2015, at 02:06, Terrance Devor <ter.devor@gmail.com> wrote:
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
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
On 18 Mar 2015, at 13:24, Mike Hale wrote:
Would you mind sharing more details on what you've seen regarding the various miscreants screwing with each others' devices?
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. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 2015-03-17 3:06, Terrance Devor wrote:
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
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
participants (13)
-
Anthony Kosednar -
Ca By -
Christopher Morrow -
Colin Johnston -
Eric Rogers -
Justin M. Streiner -
Mark Tinka -
Mike Hale -
Paul S. -
Ray Soucy -
Robert Kisteleki -
Roland Dobbins -
Terrance Devor