I've removed the stale socket cleanup from our OpenRC service script:
* Cleaning up stale sockets isn't really the job of the service script.
* The ability to ignore a stale socket is already built into the server.
With it gone, maybe the "-x" is a useful example to have in the conf
file (although it's commented-out by default, anyway).
There are two ways that it would make sense to write the OpenRC
service script for fail2ban:
1. Use the fail2ban-client program to stop, start, reload, etc. the
server; and try to figure out whether or not it worked afterwards.
2. Use the start-stop-daemon program built into OpenRC to manage the
fail2ban-server process. This works only for starting and stopping,
because the "reload" command is sent over an undocumented protocol,
but has the benefit that you get immediate feedback about the result
of calling fail2ban-server.
The existing service script combined the two in a way that appeared to
work, but didn't make too much sense. It used start-stop-daemon to
initiate the fail2ban-client program with either a "start" or "stop"
argument. So long as everything goes fine, that appears to work. But
the start-stop-daemon is not actually monitoring the fail2ban-client
program; it's supposed to be monitoring the fail2ban-server process
that gets started as side-effect.
The existing stop() function does not do quite what you'd expect; for
example the "stop" command is never sent. Again, the daemon does
ultimately get stopped so long as the hard-coded PID file contains
what you think it does -- so it "works" -- but is misleading.
This commit changes everything to use the second approach above, where
start-stop-daemon manages everything. This was done mainly to simplify
the service script, because now the default start() and stop() phases
can be used, allowing us to delete them from our copy. One might worry
that there is some special magic behind "fail2ban-client start" and
"fail2ban-client stop", however that does not appear to be the
case. Admittedly, if in the future those two commands begin to do
something nonstandard, the service script would need to be changed
again to take the first approach above and use fail2ban-client for
everything.
The extra "showlog" command in our OpenRC service script was more
trouble than it was worth: the only thing it did was call "less" on a
log file, and the service script is only guessing at the location of
the log file (only the fail2ban server knows its true location).
It's not like "/etc/init.d/fail2ban showlog" is that much easier to type
than "less /var/log/fail2ban.log" in the first place, so I think the
extra complexity (5 more lines in the service script) is not worth it.
Prerequisites:
* The ss command is available, kernel is compiled with option CONFIG_INET_DIAG_DESTROY.
* Ufw version is => 0.36 (released in 2018)
* Now using "prepend" instead of "insert" to be able to handle IPv6 addresses correctly. The current action will fail for IPv6 addresses.
* Now application names containing a space should handled correctly, solves https://github.com/fail2ban/fail2ban/pull/1532
* Now closing IPv4 and IPv6 connections (if any) from the ip that is being banned. The current action will leave them open.
Using ss to accomplish this. For this to work the kernel needs to be compiled with the CONFIG_INET_DIAG_DESTROY option.
My system apparently is compiled that way.
`filter.d/nginx-http-auth.conf` - extended with parameter mode, so additionally to `auth` (or `normal`) mode `fallback` (or combined as `aggressive`) can find SSL errors while SSL handshaking
Michael Orlitzky