- reject: BDAT/DATA from (gh-2927)
- (since regex is more precise now) token selector changed to `[A-Z]{4}`, e. g. no matter what a command is supplied now (RCPT, EHLO, VRFY, DATA, BDAT or something else)
- matches "Command rejected" and "Data command rejected" now
- RCPT from unknown, 504 5.5.2, need fully-qualified hostname, gh-2995
- 550 5.7.25 Client host rejected, gh-2996
review combining several regex to single one
This commit adds a new function checkconfig() to the OpenRC service
script. All it does is run the server with the "--test" flag in
addition to the usual command-line arguments.
The new command is not user-facing, but lets us avoid restarting the
daemon with a broken config. That helps when the user changes his
configuration while the daemon is running, and then tries to restart()
not knowing that the new config is broken. A priori, we would stop the
daemon and then the error would only become visible when the subsequent
start() command failed. Refusing to stop() with a broken configuration
is a nicer thing to do.
OpenRC functions will exit with the return code from the last command
by default, so there's no need for the "|| return 1" in our
single-line start_pre() phase.
The description of the "reload" OpenRC command just said that it would
reload the configuration, which is true but not totally helpful. This
commit updates it to mention that your existing bans won't be dropped,
in contrast with the "restart" command that does drop your bans.
This commit renames fail2ban-openrc.init to fail2ban-openrc.init.in,
and replaces the hard-coded value "/usr/bin" with "@BINDIR@"
therein. At build-time, setup.py will replace that string with the
correct value, and rename the file (without the ".in" suffix).
This mimics the procedure done for "fail2ban-service.in" entirely.
The socket location needs to be set in the service script for the same
reason that the PID file location does: because the service script is
taking responsibility for ensuring that its parent directory exists
and has the correct permissions. We can't do that if the end user is
allowed to move the PID file or socket somewhere else (without parsing
the config file, which has other security implications).
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
sebres