109

I'm wondering if it's possible to get UFW to list the configured firewall rules even when it's not enabled. I only have ssh access to the server at this time, and I don't want to enable UFW if there's not a rule configured allowing ssh. However, since UFW is currently not enabled, I just get an "inactive" message when I run "ufw status".

Is there a special flag I can use or even some config file I can look at to see what rules are configured even when the firewall is disabled?

Jorge Castro
  • 70,934
  • 124
  • 466
  • 653
Bryan
  • 2,157
  • 5
  • 18
  • 21

5 Answers5

166

There is now a ufw show added command that will list the configured rules for you, even when the firewall is inactive. It was added as a fix for this bug report and added in v0.33

So now you can do:

# ufw status
Status: inactive
# ufw allow ssh
Rules updated
Rules updated (v6)
# ufw show added
Added user rules (see 'ufw status' for running firewall):
ufw allow 22
# ufw enable
Firewall is active and enabled on system startup
# ufw status
Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere
22 (v6)                    ALLOW       Anywhere (v6)

The format of the output from ufw show added makes it much easier to write the delete command for each rule too.

Simon
  • 1,761
  • 2
  • 10
  • 5
34

There is currently not a way to show the rules you have entered before enabling the firewall via the CLI command. You can inspect the rules files directly however. /lib/ufw/user*.rules contain the rules controlled via the 'ufw' CLI command. Eg:

 $ sudo grep '^### tuple' /lib/ufw/user*.rules

This will show output like the following (for the rule added with 'sudo ufw allow OpenSSH):

 /lib/ufw/user.rules:### tuple ### allow tcp 22 0.0.0.0/0 any 0.0.0.0/0 OpenSSH - in

The 'tuple' is the shorthand used internally by ufw to keep track of rules, and can be interpreted as one of these:

 ### tuple ### <action> <proto> <dst port> <dst> <src port> <src> <direction>
 ### tuple ### <action> <proto> <dst port> <dst> <src port> <src> <dst app name> <src app name> <direction>

It might be useful to be able to add another status command to support this. Please consider filing a bug.

jdstrand
  • 1,738
  • 12
  • 12
  • 5
    putting the files in `/lib` is pretty strange in my opinion – pqnet Jul 26 '14 at 13:48
  • 2
    @pqnet maybe they agree 'cos at some point they moved it to no longer `/lib/ufw/user*.rules` it's now `/etc/ufw/user*.rules` – barlop Jul 28 '22 at 11:49
19

General rules are in /etc/ufw. User defined rules are in /lib/ufw/user*.

arrange
  • 14,727
  • 4
  • 42
  • 32
12

In Ubuntu 16.04, user defined rules are stored in /etc/ufw/user.rules. Therefore, you can see the rules with:

sudo cat /etc/ufw/user.rules
Andrea Lazzarotto
  • 7,823
  • 3
  • 38
  • 56
pstadler
  • 229
  • 2
  • 4
4

From the command line, there doesn't seem to be a way. However, if you're SSH'ing from an Ubuntu box (to an Ubuntu box), you might want to try this, slightly convoluted method :

Basically, install gufw on the remote box, then connect with X forwarding and run the GUI.

On the remote device, after connecting with -X as an option :

sudo apt-get install gufw
sudo gufw

That will show you the ruleset without having to activate it.

Be warned that if the remote device is a true "headless" server, then installing GUFW might pull down an unpleasant number of dependencies. But unless someone here know a trick to make UFW show you the output you need without activating it first, then this might be your only option.

I did try sudo ufw show raw, but that shows the iptables output, which I can't make head nor tail of.

Scaine
  • 11,023
  • 5
  • 45
  • 58
  • Thanks for the tidbit about "ufw show raw" - I must have missed that in the man pages. When I run it, I don't see anything that jumps out at me as being rules, which means I may not have any configured, but I don't want to chance it just yet. And yes, installing gufw would require a very large number of dependencies to be installed so I think I'll shy away from that approach. – Bryan Mar 17 '11 at 16:14