New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
http://bgp.he.net/AS33387#_prefixes
Assume you can probably block all the ranges listed on the ASN.
@daxterfellowes Thanks for your helpful link! exactly what I want.
what did datashack do
They are spammy for starters. i've had many spammers and hack attempts from their ip ranges aswell as digital ocean's IP's
The level of brute force and application specific attacks from their IP space lately is rivaling ecatel.
ok
For anyone else who finds this thread after an attack by DataShack and happens to be running nginx, here's the following file I added at the usual location of /etc/nginx/conf.d/blockedips.conf to reject DataShack calls, and also calls from a couple of other companies who were associated in my case (you may want to include only the DataShack section). If you're still getting hit by IPs that aren't covered, then you may also want to update this from the very useful link given above by daxterfellowes: http://bgp.he.net/AS33387#_prefixes
# AS33387 DataShack, LC http://bgp.he.net/AS33387#_prefixes
# Datashack was DDoS'ing sandbox 2016-10-14 with GET /addyn* calls
deny 63.141.224.0/19;
deny 107.150.32.0/19;
deny 142.54.160.0/19;
deny 179.0.64.0/19;
deny 179.0.32.0/19;
deny 201.218.160.0/19;
deny 190.113.32.0/19;
deny 192.187.96.0/19;
deny 198.204.224.0/19;
deny 74.91.16.0/20;
deny 179.0.96.0/20;
deny 179.0.112.0/20;
deny 192.151.144.0/20;
deny 199.168.96.0/21;
deny 153.89.0.0/16;
deny 103.25.63.0/24;
deny 208.67.0.0/24;
deny 208.67.1.0/24;
# WholeSale Internet, Inc. United States http://bgp.he.net/AS32097#_prefixes
# These appear to have been used by DataShack; May be blocking more than necessary here:
deny 63.141.241.0/24;
deny 69.30.192.0/18;
deny 69.30.244.0/24;
deny 69.197.128.0/18;
deny 162.251.120.0/22;
deny 173.208.128.0/17;
deny 173.208.180.0/24;
deny 173.208.250.0/24;
deny 192.187.113.0/24;
deny 198.204.241.0/24;
deny 204.10.160.0/22;
deny 204.12.192.0/18;
deny 208.67.0.0/21;
deny 208.110.64.0/19;
deny 208.110.72.0/24;
# Krypt Technologies - guessed at subnet - http://bgp.he.net/ip/67.229.101.6
deny 67.229.101.0/24 ;
https://enjen.net/asn-blocklist/index.php?asn=33387&type=iplist
https://enjen.net/asn-blocklist/index.php?asn=AS33387&type=iptables
It is kinda why this exists.
Helpful thread!
block datashack, wholesaleinternet and ndevix.
just block the whole internet
this
Always with cool stuff K
Blocking IP ranges is a terrible idea.
Being abusive is as well.
Sure, but that's hardly relevant to the issue at hand. Blocking IP ranges will just break a lot of shit for people who have done absolutely nothing wrong, while still not solving your problem adequately.
Instead of throwing out the baby with the bathwater, try neutralizing the actual abuse - you know, the thing you are having a problem with. Blocking IP ranges may be the easy and lazy option, but it's neither effective nor reasonable.
I do agree with you however we are blocking IP addresses for a data centre, not a home ISP such as BT or Virgin. Some websites or services do not permit VPNs/proxies. He may also wish to block the ranges due to bruteforce which I have admittedly done whilst also having fail2ban and alternate ports
Who is to say its even for a public site or what his use case is. There's legit reasons to want to block full IP ranges.
I'm a WSI customer (migrating the last two boxes to hetzner) .
A member of this forum has told me he gets scanned from wsi after being ditched as a customer ( don't recall everything exactly like if he managed to become a client or not, etc but all the rest is what he said)
My remarks extend to datacenter IPs as well. They're not any different. It's still a terrible idea to block IPs, and completely unnecessary.
Which is also a terrible approach.
"Changing ports" is security through obscurity and completely ineffective. fail2ban can kind of sort of work, but is highly inefficient and still doesn't solve the actual problem.
So again, solve the actual problem you're having, instead of some hackjob around it. For SSH for example, disable password authentication and only allow keypair authentication. No need for "alternate ports", fail2ban, IP range blocking or whatever else, because you've already solved the problem.
Agree RE: keypair, though, have you seen any empirical data wrt changing SSH ports and whether it reduces the number of "internet noise" login attempts? If the proportion of login attempts are "dumb and hard encoded to try port 22", then it may be a nice saving of resources simply to change it.
Not sure RE: original post, but it's a popular method of keeping things clean. Up to you philosophers to decide whether it's right or wrong...
"Terrible" is a relative concept.
Agree RE: keypair, though, have you seen any empirical data wrt changing SSH ports and whether it reduces the number of "internet noise" login attempts? If the proportion of login attempts are "dumb and hard encoded to try port 22", then it may be a nice saving of resources simply to change it.
Sure, the amount of attempts goes down. But I've also personally had to clean up a VPS that was compromised within 3 days of being installed, despite SSH running on a random port. For all practical purposes, it just doesn't matter - it's more a feel-good measure than anything else.
There's not really anything to "keep clean". Failed attempts will happen regardless of the port, and successful attempts can be seen by piping your
auth.logthroughgrep "Accepted"or by usinglast. There's really no merit to changing the port whatsoever.Sure, grep can solve 'things you would ignore', I suppose I was thinking more about resources, including logging writing stuff to disk. Much easier if the OS knows the port is closed and says 'go away' than the SSH daemon negotiating for a while and then saying 'go away'.
There is valid usages for ASN blocking, even if you don't personally consider them valid. At the end of the day, it is up to you to decide what the right approach is for your application / setup.
There's more than one way to skin a cat. You can use grep if you want, I prefer to not have the chaff in the logs in the first place. Changing to an alternate port makes an enormous difference in the amount of log junk, I can blatantly see that with large sample sets.
The mantra is "do what you can", perfect solutions are hard to come by.