A consequence of providing Internet-facing services is that they will be subjected to brute-force password cracking attacks. A common defence for these attacks is to employ solutions like fail2ban or sshguard on the affected systems.

Unfortunately, I am running our services within systemd-nspawn containers which exhibit the characteristic that kernel features cannot be modified. As fail2ban and sshguard make use of firewall tables to implement IP address blocking this is not an option for me.

I employ Shorewall to provide firewalling and routing functions within the host operating system and it has a few features useful for blocking these attacks although they require manual configuration.

At this point I should acknowledge that Postfix and Shorewall permit rate-limiting of incoming traffic. While this has the effect of slowing the progress of a brute-force attack, it doesn't provide a preventative solution - only by blocking the offender can safety be assured.

Shorewall provides the facility to drop or reject incoming packets from either a single IP address, an IP address subnet or a range of IP addresses. The former of these can be performed on the command line while the latter two require the editing of a configuration file and reloading of the Shorewall daemon.

To block a single IP address you can execute the following command on the firewall host:

shorewall drop nnn.nnn.nnn.nnn

To block a subnet of IP addresses the following can be entered into /etc/shorewall/blrules:

BLACKLIST net:nnn.nnn.nnn.nnn/24

To block a range of IP addresses the following can be entered into /etc/shorewall/blrules:

BLACKLIST net:sss.sss.sss.sss-eee.eee.eee.eee all

Further configuration of /etc/shorewall/shorewall.conf is required to use these methods i.e. DYNAMIC_BLACKLIST=Yes is required for blocking single IP addresses using the shorewall command line method. Similarly, BLACKLIST_DISPOSITION=DROP and, optionally, BLACKLIST_LOG_LEVEL determine how IP address subnets and ranges are handled and whether logging is performed.

Using both of these methods I block single, perhaps transient, offending IP addresses with the command line method. Firewall rules added using this method don't persist when Shorewall is stopped/started again unless they are explicitly saved. More persistent attacks from single IP addresses, subnets or ranges of IP addresses are added to /etc/shorewall/blrules for longer-term application.

While not as convenient as fail2ban or sshguard with their automation of blocking actions, Shorewall does provide an effective means of mitigating brute-force password cracking attacks - provided you are proactive in monitoring your service log files and take appropriate action to update Shorewall with the offending IP addresses.

No, I'm not talking about a new human member of the family. Today marks the first week of life for our ARM-based Home Server and, so far, things are going very well. What's been achieved during this short period?

The Postfix and Dovecot mailserver has been verified as working. OpenDKIM and OpenDMARC checks and report generation are working fine. ClamAV has been scanning incoming and outgoing email and caught a few incoming virus-infected ones. Needless to say, SMTP and IMAP services are both experiencing brute-force password cracking attacks at moderate levels.

Lighttpd has been provisioned with Let's Encrypt certificates for the small number of virtual-hosted domains it serves. HTTP to HTTPS request promotion has been implemented and this blog is being served on the primary domain. Certificate updates are handled by acme.sh and its deployment mechanism distributes them to the containers providing the hosted services.

Prosody is serving, at the moment, one multi-user chatroom (MUC) with less than a dozen participants. The configuration has been updated to add server-to-server two-way communication over a single connection (mod_bidi) and stream management (mod_smacks) for message retrieval following a disconnect and subsequent reconnect from either a client or server connection. Audio and video calling hasn't yet been tested but should be functional.

General infrastructure management is operating well with DHCP, DNS, NTP, firewall and routing functions operating correctly. Memory usage is good with 600MB-800MB of the 2GB RAM being available as spare under normal operating conditions. Networking performance is good, achieving a 160Mbps download speed with 5G WiFi for our 200Mbps cable Internet connection.