I have a separate log file for the default vhost that's not parsed by log aggregation tools. Most scanners just hit your IP rather than an actual hostname (unless your site is very popular and well-known), so most spam ends up there. That keeps your actual log file much cleaner.

https://docbot.onetwoseven.one/services/nginx/#the-go-away-v...

This is a neat little solution. Thanks. I'll set this up and test it out.

You don't, because there's no point.

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.

I've been enough in the SSH code to be somewhat terrified by it. The main server loop has so many nested macro conditionals it's exceptionally difficult to read precisely.

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.

qmail has one of the most notoriously inscrutable codebases of all time, and it has a startlingly good track record, because there's a coherent security design behind it; the same --- to a greater extent! --- goes for OpenSSH.

There's a side of this that I agree with, however there's other sides.

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.

I wouldn't trust external patches to OpenSSH either.

Maybe qmail and SSH have their good track record because of security by inscrutability

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

httpd is the one service I don't use fail2ban for, preferring a DIY solution instead.

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.

You could also consider https://crowdsec.net/ - it's a pretty advanced framework for detecting malevolent traffic by using a combination of local rules and threat intelligence from other users. Apache is supported https://hub.crowdsec.net/author/crowdsecurity/collections/ap....

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

Fail2ban is decent indeed. But consider https://crowdsec.net/ instead if you want a tool that can detect pretty advanced L7 attacks, mitigate bad traffic using captcha and use crowd sourced threat intelligence to block bad guys in advance

Except for your one comment 55 days ago, every other comment you've ever posted to HN has been (within about hour of each other, about six hours ago, and is) just spamming this bullshit.

(And that one other comment is a little shady as well.)

Give it up already.

Goodbye!