sshguard.service uses wrong path for iptables; nothing actually gets blocked

Bug #1884848 reported by Malcolm Scott
266
This bug affects 2 people
Affects Status Importance Assigned to Milestone
sshguard (Ubuntu)
Fix Released
Undecided
Unassigned
Focal
Fix Released
High
Unassigned

Bug Description

[Impact]

 * sshguard.service does not start correctly on systems upgraded from bionic to focal.
 * sshguard.service hardcodes paths to iptables binary. However, said path has changed in focal+ in the iptables package.
 * This issue impacts installations of bionic that upgrade to focal, but not new installs of focal. Newly installed focal systems have usr-merge feature, which all binaries accessible from either / or /usr prefix. This is not the case yet, when upgrading from bionic.

[Test Case]

 * Install bionic
 * Install sshguard, check that it starts
 * dist-upgrade to focal
 * Check that sshguard runs and that iptables rules are updated

[Workaround]

 * Users can convert their systems to usrmerge to mitigate the issue by doing:
   $ sudo apt install usrmerge

[Regression Potential]

 * The bugfix to update to the correct path will work on either upgraded, or freshly installed systems. Currently sshguard is quite broken without sshguard firewall rules applied correctly. After installing this update, users may experience that sshguard is enforcing/blocking access, whilst previously it was very ineffective at doing so.

[Other Info]

 * Original bug report

sshguard 2.3.1-1ubuntu1; focal

/lib/systemd/system/sshguard.service has:

ExecStartPre=-/sbin/iptables -N sshguard
ExecStartPre=-/sbin/ip6tables -N sshguard
ExecStopPost=-/sbin/iptables -X sshguard
ExecStopPost=-/sbin/ip6tables -X sshguard

iptables and ip6tables are now in /usr/sbin, not /sbin. So the sshguard chain never gets created/deleted.

sshg-fw-iptables assumes that this chain exists, so it fails to actually block any attacker:

Jun 23 22:54:18 fenrir sshguard[677248]: Attack from "192.0.2.1" on service 110 with danger 10.
Jun 23 22:54:18 fenrir sshguard[677248]: Blocking "192.0.2.1/32" for 122880 secs (3 attacks in 1 secs, after 11 abuses over 184099 secs.)
Jun 23 22:54:18 fenrir sshguard[1191669]: iptables: No chain/target/match by that name.
Jun 23 23:46:49 fenrir sshguard[1198650]: iptables: Bad rule (does a matching rule exist in that chain?).

Revision history for this message
Seth Arnold (seth-arnold) wrote :

There should be several symlinks to make this work:

$ namei -l /sbin/iptables
f: /sbin/iptables
drwxr-xr-x root root /
lrwxrwxrwx root root sbin -> usr/sbin
drwxr-xr-x root root usr
drwxr-xr-x root root sbin
lrwxrwxrwx root root iptables -> /etc/alternatives/iptables
drwxr-xr-x root root /
drwxr-xr-x root root etc
drwxr-xr-x root root alternatives
lrwxrwxrwx root root iptables -> /usr/sbin/iptables-legacy
drwxr-xr-x root root /
drwxr-xr-x root root usr
drwxr-xr-x root root sbin
lrwxrwxrwx root root iptables-legacy -> xtables-legacy-multi
-rwxr-xr-x root root xtables-legacy-multi

Are you missing any of the symlinks?

Thanks

information type: Private Security → Public Security
Changed in sshguard (Ubuntu):
status: New → Incomplete
Revision history for this message
Malcolm Scott (malcscott) wrote :

None of the machines I've upgraded to focal from bionic have a symlink in /sbin/iptables.

$ namei -l /sbin/iptables
f: /sbin/iptables
drwxr-xr-x root root /
drwxr-xr-x root root sbin
                     iptables - No such file or directory

However you're right that a fresh install does have them. I'm not sure what is supposed to install the symlinks, but it doesn't seem to happen on upgrades.

Changed in sshguard (Ubuntu):
status: Incomplete → New
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

@malcscott

At the moment we support split-usr & merged-usr.

Newly installed machines should all be merged-usr, with symlinks making any paths work.

The dpkg .deb itself, is built as split-usr and existing installations upgrade and keep split-usr (will be fixed for upgrades to 22.04).

So the deb encodes split-usr paths, and the unit somehow has the wrong path inside it.

So you have identified a bug.

Changed in sshguard (Ubuntu):
status: New → Confirmed
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Well, this is not a usr-merge bug per-se, but just a bug that usr-merge actually fixes for people.

iptables in focal has moved from /sbin/iptables to /usr/sbin/iptables. The hardcoded path in sshguard.service was not updated, and thus is broken. usr-merged systems do not experience this issue, because any binary is accesible from either / or /usr prefix.

description: updated
Changed in sshguard (Ubuntu):
status: Confirmed → Fix Committed
Changed in sshguard (Ubuntu Focal):
status: New → Confirmed
importance: Undecided → High
status: Confirmed → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package sshguard - 2.3.1-1ubuntu2

---------------
sshguard (2.3.1-1ubuntu2) groovy; urgency=medium

  * Fix path to iptables binaries in the .service unit. LP: #1884848

 -- Dimitri John Ledkov <email address hidden> Wed, 24 Jun 2020 11:53:44 +0100

Changed in sshguard (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Malcolm, or anyone else affected,

Accepted sshguard into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sshguard/2.3.1-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in sshguard (Ubuntu Focal):
milestone: none → ubuntu-20.04.1
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-focal
Revision history for this message
Toni Förster (stonerl) wrote :

I can confirm that the bug is fixed.

sshguard/now 2.3.1-1ubuntu1.1 amd64

tags: added: verification-done-focal
removed: verification-needed verification-needed-focal
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package sshguard - 2.3.1-1ubuntu1.1

---------------
sshguard (2.3.1-1ubuntu1.1) focal; urgency=medium

  * Fix path to iptables binaries in the .service unit. LP: #1884848

 -- Dimitri John Ledkov <email address hidden> Wed, 24 Jun 2020 11:53:44 +0100

Changed in sshguard (Ubuntu Focal):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

The verification of the Stable Release Update for sshguard has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.