Re-work the fail2ban and nftables interaction. Use systemd's PartOf
to indicate that fail2ban is part of the nftables service, which
tells systemd to propogate stop/start signals to it. Then we tell
the firehol update script to restart nftables instead of reload.
The different between restart and reload is meaningless for nftables
but we want systemd to propagate the stop/start signals to fail2ban.
This service does not actually depend on nftables, at least not in
the systemd sense of dependency. Furthermore, this hard dependency
was causing the service to fail when it restarts nftables at the
end, which causes systemd to start it again and again until it hits
a restarting too quickly error.
This is apparently the default and recommended by Mozilla's server-
side SSL configurator also recommends. This lets the client choose
the ciphers best for them (and the ciphers in TLS 1.2 and 1.3 are
not currently known to be dangerous).
The old default has not been changed in eight years and I see that
there have been some discussions over the years about this. I will
change this from the slightly extreme 1400 bytes to 4k (nginx def-
ault is still 16k so this is more "optimal" for HTML/CSS content).
See: https://github.com/igrigorik/istlsfastyet.com/issues/63
I still wouldn't want to deploy WordPress on Caddy until it's more
obvious and standard to block paths that shouldn't be accessible.
It seems that this is still left as an exercise to the site admin.
This discussion has some tips, but it is four years old and hasn't
changed since I last looked.
See: https://caddy.community/t/using-caddy-to-harden-wordpress/13575
Use firehol instead of all the others. AbuseIPDB.com can't be upd-
ated automatically, Abuse.ch is no longer maintained, and Spamhaus
is already in firehol.
Actually, we do want to run fail2ban on all hosts because the sshd
monitoring via systemd is nice. At the very least it reduces spam
from failed logins in our systemd journal.
We can only run fail2ban when we have logs to monitor. When a host
is running Caddy we don't have logs, so fail2ban doesn't have any-
thing to monitor out of the box. For now I will restrict the task
to hosts running nginx.
