[179001] in North American Network Operators' Group
Re: Getting hit hard by CHINANET
daemon@ATHENA.MIT.EDU (Colin Johnston)
Mon Mar 23 09:19:11 2015
X-Original-To: nanog@nanog.org
From: Colin Johnston <colinj@gt86car.org.uk>
In-Reply-To: <CALFTrnOevE+nsmowb2ZSxJzWQHM5eJZUAxG0joumq32G9Hpqzg@mail.gmail.com>
Date: Mon, 23 Mar 2015 13:19:04 +0000
To: Ray Soucy <rps@maine.edu>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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:
>=20
> 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.
>=20
> Working for a public university I can't block China outright, but =
there are
> times it has been tempting. :-)
>=20
> 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.
>=20
>=20
> On Wed, Mar 18, 2015 at 8:32 AM, Eric Rogers =
<ecrogers@precisionds.com>
> wrote:
>=20
>> 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.
>>=20
>> 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.
>>=20
>> Eric Rogers
>> PDSConnect
>> www.pdsconnect.me
>> (317) 831-3000 x200
>>=20
>>=20
>> -----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
>>=20
>>=20
>> On 18 Mar 2015, at 17:00, Roland Dobbins wrote:
>>=20
>>> 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).
>>=20
>> Here's one counterexample:
>>=20
>> =
<https://ripe68.ripe.net/presentations/176-RIPE68_JSnijders_DDoS_Damage_
>> Control.pdf>
>>=20
>> -----------------------------------
>> Roland Dobbins <rdobbins@arbor.net>
>>=20
>=20
>=20
>=20
> --=20
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
>=20
> T: 207-561-3526
> F: 207-561-3531
>=20
> MaineREN, Maine's Research and Education Network
> www.maineren.net