ufw should support insertion of rules

Bug #260745 reported by bodhi.zazen on 2008-08-23
6
Affects Status Importance Assigned to Milestone
ufw (Ubuntu)
Wishlist
Jamie Strandboge

Bug Description

Binary package hint: ufw

I do not know if this is a "bug report" or a feature request ...

If there is a better mechanism to give feedback, feel free to let me know ;)

At any rate, it would be nice if there were an easier way to modify UFW rules. The "problem" is iptables processes rules in order.

So say we have a long list of ufw rules.

Start with default deny.

Now say we are running a mix of public and private servers ... so we generate a list of allows

# Public server
ufw allow 80

# "Public# ssh access
ufw allow 22

# Private Samba server
ufw allow proto tcp from 192.168.1.0/24 to 192.168.1.0/24 port 135

ufw allow proto tcp from 192.168.1.0/24 to 192.168.1.0/24 port 139

ufw allow proto tcp from 192.168.1.0/24 to 192.168.1.0/24 port 445

ufw allow proto udp from 192.168.1.0/24 to 192.168.1.0/24 port 137

ufw allow proto udp from 192.168.1.0/24 to 192.168.1.0/24 port 138

Now say we are monitoring our network, and find someone is exploiting ssh and or port 80 :(

Say the ip address is 111.222.3.44

If we simply

ufw deny 111.222.3.44 => it will not block this IP (because it was allowed earlier in the chain).

So it is either a manual edit to /etc/ufw/before.rules (assuming someone also understands IP Tables syntax, that they know to edit /etc/ufw/before.rules, and where they need to add the rule :) )

-A ufw-before-input -s 111.222.3.44 -j DROP #Assuming no loging is desired of course)

==================

So i suggest two things (sorry for the long background):

ufw -n # deny 111.222.3.44

where the -n # specifies where to insert the rule

ufw -n 1 111.222.3.44

which would put the rule at the top of the chain :)

Related branches

Jamie Strandboge (jdstrand) wrote :

Thanks for your feedback. I think having the ability to insert rules rather than simply append is a good idea and have marked the bug accordingly.

Changed in ufw:
assignee: nobody → jdstrand
importance: Undecided → Wishlist
status: New → Confirmed
Roland Latour (rolandl-cavenet) wrote :

I would like to suggest having ufw read a configuration file instead of getting all its rules from the command line.

Order is important, and getting that order right is the biggest PITA. If I mess up the order, I can just edit the
config file and re-run 'sudo ufw enable'. That should clear all previous rules automatically and set up rules
as stated in the config file. Hint: provide a sample config file. Thanks.

Roland Latour (rolandl-cavenet) wrote :

'sudo ufw status' report:
To Action From
Anywhere DENY 221.192.199.36 80:tcp
80:tcp ALLOW Anywhere
80:udp ALLOW Anywhere
Anywhere DENY 221.192.199.36

But command syntax is:
ufw allow proto tcp from 192.168.1.0/24 to 192.168.1.0/24 port 135

I suggest you change one or the other so they match a bit more closely. If the status reports on '80:tcp'
then I should be able to use that syntax in the command. Or leave the command as is and change the
status display so there's a column on the left labeled 'proto' and one on the right labeled 'port'. Fight confusion with consistency. Users are by definition unfamiliar with your program. And syntax like 'to Anywhere' and
'from Anywhere' doesn't work--why not change it to just 'any' to match the manpage. Thanks.

I've run into what Roland is describing, and I quite agree that the status output (or perhaps another command like 'ufw rules') should match input commands. I once set a rule that was wrong and it took me ages to figure out exactly the right syntax to remove it - it should not even be necessary for me to look at a man page to do it, after all, the whole point of using ufw instad of plain iptables is that it's supposedly easier to use. Also agree on putting source rules in a config file - in fact why not use /etc/ufw/ufw.conf since it's only being used for 'ENABLED' at present - and have it regenerate the native rules files on a restart of ufw.

JeSTeR7 (cblocker) wrote :

I'd like to agree that this seems like a necessary feature of any firewall software. Anybody who actively monitors their firewall would need the ability to block IP addresses that attempt intrusion. I thought I was doing this, seeing as giving a 'ufw status' command would tell me that the IP address was being blocked, but my apache access log proved otherwise.

I was able to use the OP's command in my before.rules file, but I am not familiar enough with iptables to do anything with it on my own. That's why I'm using ufw to begin with ;).

bodhi.zazen (bodhi.zazen) wrote :

You are most welcome JeSTeR7.

When you have the time, and if you have the interest, one thing that I really like about UFW is that the syntax of UFW rules is very similar to the actual iptables rules.

With many of the "others" you have to learn what sometimes seems like esoteric rules that do not always apply to iptables. And Firestarter teaches nothing :)

At any rate, to see your iptables rules use

sudo iptables -L

Jamie Strandboge (jdstrand) wrote :

Regarding status output, the intent is for the status output to be easy to be as easy to understand as possible. That said, recently ufw has 'ufw status verbose' and 'ufw status raw' which should help in some ways. I do agree that it would be helpful to show the ufw rules as well, and will be adding a 'ufw status rules' command that will show the rules used.

Jamie Strandboge (jdstrand) wrote :

Regarding status output, the intent is for the status output to be as easy to understand as possible. That said, recently ufw has 'ufw status verbose' and 'ufw status raw' which should help in some ways. I do agree that it would be helpful to show the ufw rules as well, and will be adding a 'ufw status rules' command that will show the rules used.

Changed in ufw:
status: Confirmed → In Progress
Changed in ufw:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ufw - 0.27~r416-0ubuntu1

---------------
ufw (0.27~r416-0ubuntu1) jaunty; urgency=low

  * new upstream release
    - don't do symlink check anymore (LP: #317700)
    - don't do hidden file check anymore (LP: #319226)
    - add insert rule support (LP: #260745)
    - clear up status output (LP: #262975)
    - add log level support
    - add per rule logging
  * debian/ufw.init: use mountall for Required-Start rather than mountall.sh
  * added allow_custom_ports debconf option
  * debian/postinst: don't exit on ufw error
  * ship debian/sysctl.conf instead of upstream. This file now only lists
    settings that do are non-default in Ubuntu
  * adjust initscript to tell it is using /etc/ufw/sysctl.conf
  * debian/*md5sums: updated for new upstream defaults
  * debian/config: update has_existing() to also check old md5sums
  * debian/postinst: don't error out when processing triggers, as this causes
    dpkg errors (LP: #270285, #328728)

 -- Jamie Strandboge <email address hidden> Wed, 18 Feb 2009 16:53:15 -0600

Changed in ufw:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers