ufw

Rule insertion fails if ruleset is empty

Bug #1586258 reported by Neil Harvey
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ufw
Fix Released
Medium
Jamie Strandboge

Bug Description

I am setting up a server with a cloud host, where their firewall is responsible for port blocking. Therefore I am setting ufw+fail2ban up for IP blocking only. Before enabling ufw I set the default policy to allow and cleared the default rules.

To integrate with ufw, fail2ban performs commands in the form of "ufw insert 1 deny from [ipaddress] to any". However, this command will ALWAYS fail if there are no existing rules, with the error of "Invalid position '1'". The cause appears to be the ruleset being empty. Adding any rule, even a dummy "accept all from any" allows this to function properly. If this is intended behaviour then the documentation should be updated to note that inserting a numbered rule into an empty ruleset is specifically invalid. Otherwise it seems like a bug to me.

user@persephone:~# ufw version
ufw 0.35
Copyright 2008-2015 Canonical Ltd.
user@persephone:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04 LTS
Release: 16.04
Codename: xenial

Revision history for this message
Neil Harvey (nhar) wrote :

So I couldn't sleep. This patch should solve the problem by bypassing the checks that cause it. Because of the way the rulesets get rebuilt anyway I can't see this causing any problems down the road, but you never know.

I looked at writing a test but couldn't quite figure out how to do it. I did install the modified version into a prefix and test the following possible bug-trigger.

$ PYTHONPATH=$PYTHONPATH:/tmp/ufw/lib/python /tmp/ufw/usr/sbin/ufw insert 1 allow from any to any

and it functioned correctly. The backend changes seem the least invasive way to solve the problem, but I'm not entirely happy with the frontend changes; they may benefit from a more experienced tweak.

Revision history for this message
Neil Harvey (nhar) wrote :

Another sleepless night. This time I've cleaned up the frontend a little (much more obvious why the bool is used now) and written a test case for values that should and should not fail (which passes). As far as I can see it's complete and functional.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

FYI, the recommended approach for using ufw with fail2ban is to use the new 'ufw prepend' command in the upcoming 0.36 release.

Changed in ufw:
status: New → Fix Committed
Changed in ufw:
importance: Undecided → Medium
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

This is fixed in the new 0.36 release.

Changed in ufw:
assignee: nobody → Jamie Strandboge (jdstrand)
status: Fix Committed → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Proposed package upload rejected

An upload of ufw to cosmic-proposed has been rejected from the upload queue for the following reason: "All bugs mentioned in the .changes file (so therefore also in the new debian/changelog entries) need to comply with SRU standards (test-case, regression potential). Please re-upload after filling out the required info or modify changelog to exclude irrelevant bug numbers.".

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

Other bug subscribers

Remote bug watches

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