ufw allow filtering pre-empts limit filtering

Bug #1089262 reported by Gary Gapinski
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ufw (Ubuntu)
Fix Released
Low
Jamie Strandboge

Bug Description

Version: ufw 0.33-0ubuntu2
Description: Ubuntu 12.10
Release: 12.10
ufw:
  Installed: 0.33-0ubuntu2
  Candidate: 0.33-0ubuntu2
  Version table:
 *** 0.33-0ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages
        100 /var/lib/dpkg/status

It appears that limit filtering is pre-empted by allow filtering.

If I execute the commands

    ufw allow OpenSSH
    ufw limit ssh/tcp

the resulting ufw-user-input chain appears to allow SSH prior to imposing rate limiting, because the accept rule for ssh appears earlier in the chain than the ufw-user-limit rule for ssh.

I would have expected rate limiting to occur prior to general acceptance.

Regards,

Gary

Related branches

Revision history for this message
Gary Gapinski (5wtq-gary) wrote :
Revision history for this message
Gary Gapinski (5wtq-gary) wrote :

I must note that reversing the order of commands achieves the correct chain rule order (found belatedly after bug submission).

While this is documented in the man page for ufw, I suspect rate limiting should always take precedence.

Revision history for this message
Gary Gapinski (5wtq-gary) wrote :

And (yet more belatedly), it appears that

    ufw limit ssh/tcp
    ufw allow OpenSSH

renders the «allow Openssh» superfluous, which is not obvious without looking at the resulting chain.

In other words, limit is an implicit allow, rather than just a rate limit (I would have preferred just the rate limit, though the current situation is acceptable).

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

Thanks for the bug report. If something is limited it is by definition allowed but with some boundary. This is the case of the ufw limit command. The man page could be clarified and I've committed a change to trunk for that which will be included in ufw 0.34.

Changed in ufw (Ubuntu):
status: New → Fix Committed
importance: Undecided → Low
assignee: nobody → Jamie Strandboge (jdstrand)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ufw - 0.34~rc-0ubuntu1

---------------
ufw (0.34~rc-0ubuntu1) trusty; urgency=medium

  * New upstream pre-release (LP: #1059060, #1065297, #1062521, #1101304,
    LP: #1075975, #1089262, #262421)
  * Dropped the following patches now included upstream:
    - 0002-lp1044361.patch
    - 0003-fix-typeerror-on-error.patch
    - 0004-lp1039729.patch
    - 0005-lp1191197.patch
  * Remaining changes:
    - 0001-optimize-boot.patch: only read in /etc/ufw/ufw.conf when disabled
  * debian/before[6].rules.md5sum: adjusted for new release
  * debian/control: update Standards-Version to 3.9.5
  * debian/rules:
    - only ship /usr/share/ufw/iptables/*rules and not /usr/share/ufw/
    - *.init files should also be config files
  * debian/ufw.links: added to makes symlinks from /usr/share/ufw/iptables/*
    to /usr/share/ufw/ (so ucf is happy on upgrades)
  * debian/ufw.postinst:
    - use TEMPLATE_PATH/iptables/*rules instead of TEMPLATE_PATH/*rules (not
      strictly required since we are using dh_link, but makes the intent
      clearer)
    - copy /usr/share/ufw/*.init in to /etc/ufw
 -- Jamie Strandboge <email address hidden> Thu, 20 Feb 2014 09:23:54 -0600

Changed in ufw (Ubuntu):
status: Fix Committed → Fix Released
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.