ufw

import/export rules command

Bug #916961 reported by Giacomo Picchiarelli on 2012-01-15
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ufw
Wishlist
Unassigned

Bug Description

Is there an ufw command to export/import rules from a computer to another? (or backup purpose)
Thank you!

description: updated
description: updated
Jamie Strandboge (jdstrand) wrote :

Thank you for using ufw and reporting a bug. I don't think I want to support an import or export command. This files themselves are simple iptables-restore compatible files, so backing up is straightforward. The files to backup are:
/lib/ufw/*rules
/etc/ufw/*.rules

To backup everything, grab /lib/ufw, /etc/ufw and /etc/default/ufw.

I'm going to mark this as "Won't Fix" for now. Please feel free to file any other bugs you may find.

Changed in ufw:
status: New → Won't Fix

OK!! Thank you!
Is there a documentation about the /lib/ufw/*rules /etc/ufw/*.rules files syntax?

Jamie Strandboge (jdstrand) wrote :

See 'man ufw' and 'man ufw-framework' for specifics with ufw. You can see 'man iptables-restore' and 'man iptables-save' for how to use iptables-restore, but they doesn't discuss the syntax. In general, iptables-restore syntax is simply 'iptables' rules without 'iptables' prepended to the line. You do have to make sure that the different tables get setup properly, and that is where the ufw man pages can help a bit.

costales (costales) wrote :

Hi Jamie! :)
I think an ufw command for import/export rules will be an important feature. Why? Because when the users want migrate the same rules or reinstall Ubuntu, they could backup their rules with a simple ufw command (or a GUI as Gufw). Know where are the files is not an intuitive way for end users and a GUI can't overwrite ufw files by the Debian policies.
Please, could be possible include this option in ufw? Thanks in advance!

Florido Paganelli (bjaast) wrote :

Well, uncomplicated firewall, but then I have to understand what I typed by looking at iptables?

Guys I am in the process of moving my machines from SuSE to ubuntu, I am sorry but ufw is far far far away from being uncomplicated. I'd better go back reading iptables stuff...

Export/import of rules might help keeping things clean. If I have to mess up with three directories to do a backup, or to try to understand the complexity of how a set of ufw rules translate into three dirs, I am sorry but it sucks.

Closing it as wontfix really doesn't make me happy.

Jamie Strandboge (jdstrand) wrote :

You can see what rules you added (normalized) with:
$ sudo ufw show added

Incidentally, saying that something sucks is not a great way to motivate someone to implement a feature you would like to see. If someone submits a patch that implements this functionality, I'd happily to review it.

Jamie Strandboge (jdstrand) wrote :

I thought about this a little more. If someone was interested in submitting a patch, I think the way to do it for the export would be to iterate through UFWBackend::files and create a tar archive. The import would similarly iterate through UFWBackend::files and then run reload. If the tar archive contains anything that the import is not expecting, it should fail. This will provide the necessary security as well as ensure that an import can only come from a similar ufw. We may want to add a compatibility file in the tar archive, but this probably isn't needed initially.

Changed in ufw:
importance: Undecided → Wishlist
status: Won't Fix → Triaged
Jamie Strandboge (jdstrand) wrote :

It would be nice if the import would support an export on one distribution and an import on another. This would require a mapping of some sort, perhaps via a manifest file. This manifest mapping could be something like using the keys in UFWBackend::files{} and mapping them to the file in the tar archive.

If we are doing all that, it might be easier to just export a json dump where we have a dictionary with the same keys that are in the UFWBackend::files{} dictionary with the values being the file contents. json should work cause these are all flat text files.

msth67 (msth67) wrote :

It seems only reasonable that an uncomplicated firewall might also have an uncomplicated way of exporting rules,as noted in comment #5:that would indeed make things a lot easier when setting up a new installation.
If it could be done with a single json file,and work across distributions,that would be great.

Massimo S. (smassimo) wrote :

UFW store config files in /lib dir ?!!!

IMHO this is a serius bug!
All config files should be in /etc dir

jeancarlos (invaderjiks) wrote :

hello guys, how i import a rulez on GUFW?
i do backup of my rules more don´t know export.
on GUFW don´t have option.

thankyou.

Hi! Just for gufw 13.10 (ubuntu 13.10) and for rules added from this
version ;)
Cheers
On Sep 13, 2013 11:35 PM, "jeancarlos" <email address hidden> wrote:

> hello guys, how i import a rulez on GUFW?
> i do backup of my rules more don´t know export.
> on GUFW don´t have option.
>
> thankyou.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/916961
>
> Title:
> import/export rules command
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ufw/+bug/916961/+subscriptions
>

rob cain (rcain-3) wrote :

Hi chaps,

I know this thread is rather old, and that it is indeed 'wish-list' rather than 'bug', but I too would like to add my support to the request for 'import/export' feature for UFW rules.

Reasons: firewall is one of those things users need to add to/remove from on a regular basis, and the chances of screwing up at some point or other become significant. Under such circumstance, the ability to 'restore' (import) from a previous backup (export) becomes paramount.

In addition, I am currently writing a bash script to maintain UFW via a flat file containing simple list of IP's collected from logs & online blacklists; too simplify admin of this process, I need to clear down all previous UFW chain beforehand, and once again, the chances of screwing something up can become significant, hence the need to produce a UFW backup prior to my batch run.

I am aware of ufw-framework - far too complicated/abstruse IMO for this simple task. Am also aware of fail2ban & the like, which I use for slightly different purpose.

ufw export/import would really simplify things. (Alternatively, if you could provide me with precise command line/bash commands to run in order to effect same from within my bash file).

Thanks for an (otherwise) great little utility.

Rob Cain

GeorgeAllen (glallen01) wrote :

I know this is an old thread - but here is another example of how this could be useful:

if I had a device setup where `ufw status numbered` resulted in:
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] Anywhere ALLOW IN 10.10.0.0/16
[ 3] Anywhere ALLOW IN 172.16.20.2
[ 4] Anywhere ALLOW IN 172.16.20.3
[ 5] Anywhere ALLOW IN 172.16.20.4
[ 6] 22,4505,4506,7736/tcp ALLOW IN 172.16.30.2
[ 7] 22,4505,4506,7736/tcp ALLOW IN 172.16.30.3
[ 8] 22,4505,4506,7736/tcp ALLOW IN 172.16.30.4
[ 9] 443,7734/tcp ALLOW IN 172.16.20.0/24

And I wanted to change this, by changing all the 172.16 IPs to 192.168. Following the unix philosophy of compose-able text outputs, I should be able to do this through pipes.
If I were on a vyatta system, I could fairly simply do something like:

show config commands | grep firewall | grep '172\.16' > tmp;
cat tmp | sed "s/set/delete/" > update.sh
cat tmp | sed "s/172\.16/192.168/" >> update.sh
config
. ./update.sh
commit
save

This selects the firewall rules, selects the rules for these IPs, removes the old and adds the new.

To do the equivalent with UFW, I have to do the follwing to delete the exiting rules:
while [[ $(ufw status numbered | grep '172\.16') ]]; do
  LINE=$( ufw status numbered | awk '/172\.16/{print substr($0,match($0,/\[/)+1,2) }' | head -n 1);
  ufw delete ${LINE}
done

This is unfortunate - not just because of the complicated awk, but deleting by line number requires a new test subshell under while after each deletion, rather than one for-loop, because the rule line numbers change.

If `ufw show added` could either allow an option for line numbers, or if you could delete a rule by naming the rule it self (ie prepend delete to that line-output of show added) then you'd have a feasbile means of using sed/awk/grep to filter and update the rules in a scriptable fashion.

The reason I had to script this out with the grep/awk above, is because I'm about to updates several dozen machines in a very similar scenario - where virtual clones have been deployed in one training environment, and we redeployed in a slightly different one with different IP spaces.

Either way - build in unix commands should support ways to compose what you want with pipes, and there should be a way to change the output just a bit on ufw to make this possible. (for instance, get rid of the '[' ']' around line numbers for `ufw status numbered`

GeorgeAllen (glallen01) wrote :

oh nevermind. Just read the rest of the man-page... you can prepend delete to show added output. Oops.

GeorgeAllen (glallen01) wrote :

Sorry - but this still isn't working:
# Given this:
root@onion-VirtualBox:~# ufw show added
Added user rules (see 'ufw status' for running firewall):
ufw allow 22/tcp
ufw allow 514
...
ufw allow Salt
ufw allow from 192.168.3.13
ufw allow from 192.168.3.0/24 to any port 443,7734 proto tcp

# And this output:
root@onion-VirtualBox:~# awk '/192\.168/{ sub(/ufw /,""); print}' /tmp/ufw-added | \
   xargs -i echo ufw delete {}
ufw delete allow from 192.168.3.12
ufw delete allow from 192.168.3.13
ufw delete allow from 192.168.3.0/24 to any port 443,7734 proto tcp

# Shouldn't this work?
root@onion-VirtualBox:~# awk '/192\.168/{ sub(/ufw /,""); print}' /tmp/ufw-added | xargs -i ufw delete {}

Jamie Strandboge (jdstrand) wrote :

@GeorgeAllen: the problem is with your xargs command. What is being run is:

ufw delete 'allow from 192.168.3.12' # ie, as one string

You want the spaces in there:

ufw delete allow from 192.168.3.12

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

Other bug subscribers