Error could not load logging rules

I encountered the same problem, I discover that UFW internally check the existence of ufw-user-input chain in iptables for knowing if ufw is in an enabled or disabled state.

Using ufw-user-input in -A FOO-CHAIN -j ufw-user-input will prevent ufw-user-input do be deleted when you do ufw reload or ufw disable, the chain will still be there because iptables did not accept the change. Then UFW state will be mess up and even ufw status will be broken.

You need to ensure your rules are correctly cleaned up after ufw disable or ufw reload.

The simplest way is to add iptables -F FOO-CHAIN || true or something similar to delete all the lines mentioning ufw-user-input chain in /etc/ufw/before.init.

/etc/ufw/before.init

set -e

case "$1" in
start)
    # typically required
    ;;
stop)
    # typically required
    iptables -F FOO-CHAIN || true
    # You may want to add other lines here to reset your chain in a desirable state if UFW is disabled like 
    # iptables -A FOO-CHAIN -j RETURN || true
    ;;
status)
    # optional
    ;;
flush-all)
    # optional
    ;;
*)
    echo "'$1' not supported"
    echo "Usage: before.init {start|stop|flush-all|status}"
    ;;
esac

Don’t forget to make before.init executable with chmod +x /etc/ufw/before.init.

I confirm you need :ufw-user-input - [0:0], it’s due to the internal of UFW, I think ufw-user-input is inserted after the after.rules.

Following @ariddell’s contribution, I switched my server to use ufw instead of ferm, and ran into this problem:

TASK: [Check status of ufw] ***************************************************
ok: [vps1.lukecyca.com]

TASK: [Enable ufw] ************************************************************
failed: [vps1.lukecyca.com] => {"changed": true, "cmd": ["ufw", "--force", "enable"],
"delta": "0:00:00.720280", "end": "2013-10-27 21:17:00.421354", "item": "", "rc": 1,
"start": "2013-10-27 21:16:59.701074"}
stderr: ERROR: problem running ufw-init

I logged in and ran it manually, and got a different error:

root@vps1:~# ufw --force enable
ERROR: Could not load logging rules

The firewall is running and operating properly, but the enable command fails to mark itself as enabled in /etc/ufw/ufw.conf, so it fails to start at boot (which I think is a problem).

Upon further investigation, it seems there is a bug whereby ufw logging is incompatible with our version of iptables. A fix has been committed, but it’s not fixed in the version we’re using (0.31.1-2).

If we turn logging off, this bug goes away and the enable command works fully, but I’m not sure that’s a good solution.

This topic has been deleted. Only users with topic management privileges can see it.

• Hello all,

  after I installed UT on my phone, I was curious about the firewall. So I ran
  «sudo ufw status» and realized that the fw was not running at all.
  Thought «uhhh», no problem lets enable it.

  And this led to my question. What needs to be done to get the firewall up and running?
  Does someone made the same experience and was able to fix it?

  Thanks for your hints,
  Tellina

  Steps I processed:

  sudo ufw enable

  Error: problem running ufw-init
  modprobe: ERROR ../libkmod/libkmod.c:586
  …..

  ERROR: problem running ufw-init
  iptables-restore: line 77 failed
  iptables-restore: line 30 failed
  iptables-restore: line 35 failed

  Running script check-requirements in /usr/share/ufw
  Output:
  Has python: ERROR: could not find valid python

  Checking python used with ufw:
  sudo find /usr/lib/ -name «ufw»
  -> /usr/lib/python3/dist-packages/ufw

  Checking python version:
  python3 ––version
  -> Python 3.5.2

  Running out of ideas.

  Phone: Volla Phone
  OS: Ubuntu 16.04 (2020-08-07)

• @Tellina Due to the lack of other issues with my phone I looked a second time to ufw.

  First I set default rules:
  sudo ufw default deny incoming
  sudo ufw default allow outgoing
  And activated access from my internal network:

  SSH: sudo ufw allow from 192.XXX.XXX.1/24 to any port 22
  FTP: sudo ufw allow from 192.XXX.XXX.1/24 to any port 21

  Because no errors poped up, I also ran to display the maintained rules:
  sudo ufw status verbose

  Then started the firewall:
  sudo ufw enable

  Unfortunately I got this errors:
  ERROR: problem running ufw-init
  ERROR: Could not load logging rules

  So what to do? To fix the problem with «logging rules» I switched them off.
  sudo ufw logging off

  And in case problems occure with IPv6 this is disabled in ufw config with:
  sudo nano /etc/default/ufw
  by setting: IPV6=no

  After this modifications I tried again to start ufw:
  sudo ufw enable

  And firewall has been activated.

  But, I recognized until now one additional issue. After a boot of the device ufw is not acitve. Damn!

  To fix this, I tried:

  sudo nano /lib/systemd/system/ufw.service
  To edit the UNIT section in the ufw.service file.
  Change: Before=network.target to After=network-online.target

  What a pitty, I ended up with this message:
  unable to create directory /root/.nano: Read-only system

  Two questions to the community:

  1. How to overcome the read-only issue?
  2. Did I have overseen something how to configure ufw just to get it up and running?

  Thanks
  T.

• @Tellina said in Error when enabeling ufw:

  Two questions to the community:

  How to overcome the read-only issue?

  You can remount the Filesystem RW, but it’s not recommended.
  Your issue is to modify the file, so you can use vi instead of nano ; vi does not create a file in the home directory if not explicitly asked.

  Did I have overseen something how to configure ufw just to get it up and running?

  UT is not a traditional Linux distro so it’s a bit hacky to make modifications like that to your system.
  About how to run a script automatically after a reboot, there is an open thread here in the forum.

• When checking ufw status my OP3T returns

  Warn: Uid is 0 but ‘/’ is owned by 109
  Status: Active

  Could anyone explain please?

• This question was covered in the last Q&A https://youtu.be/50Ar0aJuGWk basically it is not enabled as UT has no open ports that need blocking. The blog and audio of Q&A83 will be released shortly for full details or use YouTube link.

• @Lakotaubp
  Thank you for your response and link. The Q&A is over 1:17h so I will try to capture that moment.

  Without having heard the specific answer on the Q&A 83, do you mean UFW isn’t useful on UT regardless of what my terminal output says?

• @3T_Ed

  Firewall in UT

  Telnina said “don’t want to be nasty but” is there a plan or a timeline for a firewall in UT? We have not enabled a firewall in UT because the architecture is unusual. There are no ports open in UT by default. There are also no services running by default. A firewall would add a medium amount of weight to the system and would consume battery. Provided that there is nothing open, there is nothing that needs blocking. It is one of those issues which is worth revisiting periodically and Marius will dig into it a little deeper with the Canonical engineers who initially decided to exclude it.

  Florian commented that if someone was able to do something malicious with UT, to force a port to open, then a firewall could play a useful role by closing it. One thing for sure is that a firewall is very dependent on the kernel and since we are often working with old kernels, that could make any introduction of a firewall messy.

  In a follow up, it was asked if it could have a role in blocking certain outbound traffic? Well the issue there is one of complexity. For the average user controlling functions like that would need a graphical interface and how would they make sense of the settings? That difficulty really suggests the option of an app installable from the OpenStore for those who do know what they are doing, rather than exposing a confusing settings dialogue in
  the installed system.

  To save you looking a bit of a preview of the blog don’t tell

• @Lakotaubp : So I wonder, if it is not needed at UT, why don´t we skip the UFW from the standard installation and update the documents that inexperienced user do not ask for such topic? And away from the FW.
  Would you be so kind and explain whats the root cause of «Warn: Uid is 0 but ‘/’ is owned by 109» (as per my understanding this was the question). Please enlighten me. Thanks

• @Lakotaubp
  Thank you very much for taking the time to do the write up regarding UT view on UFW.

  Like @Tellina I’m still interested in the initial question regarding the error stated above. If you could explain that would be highly appreciated.

• The write up is by the UBports Writers team, so not me and as for the the other stuff again I have not a clue on the tech reasons. Somone will though I’m sure.

• @Alter posted a comment in todays Q&A 84 thread today. A link was included to an earlier blog post about using the firewall. In that section a screenshot shows the error ‘…is owned by 109’ mentioned earlier.

  Besides the really interesting question raised by @Alter’s question, I wonder if anyone can answer the question as to what does the error tells us and warns about?

• Back in the [Canonical] time there was : https://open-store.io/app/antivirus.iprogramer

  With fonctions :

  This is an App For Scanning and Protecting Ubuntu Devices from Malware, Viruses and RootKits.

  Features:
  Scan your Device For «Malicious Apps»
  Scan your Device For «Malicious Connections»
  Scan your Device For «Listening Ports»
  Scan your Device For «Malicious Startup Commands»

  Manage your «Firewall»
  Manage your «Active Services»

  Check an IP for «Malicious Activity»
  Generate «Password with Pattern»

  Don’t know why it’s been deprecated.

• @Keneda said in Error when enabeling ufw:

  Don’t know why it’s been deprecated.

  This app was not deprecated as such. Simply that the author never recompiled it to run 9against 16.04 when. The underlying OS was updated.

  I also seem to remember claims that the app did not do all that it advertised. The code is out lucky hosted on Launchpad though, so anyone with time available who can read code (including me) could examine it.

  I took a quick look at the C code on my phone (not ideal, I know) and it does use some interesting techniques I might be applying in my own apps.

• @arubislander Your right on that. It was pointed out a few times that the app was doing very little if not nothing by flohack.

• @Lakotaubp
  I found post of him about that :
  https://forums.ubports.com/topic/2768/are-there-any-attack-vectors-based-on-sd-card/3?_=1599561104795

  He tells that the app was confined, beside it was unconfined with full system access.

  Did Brian Douglass published unconfined apps without reviewing it?

  Scanning polemic appart, it had a firewall interface, that too was bullshit?

• @Keneda It states the app was fully confined so could not do anything other than scan it’s self. As for the full app history I cannot remember but it was about a long time age so might have been a hang around from canonical day. As for Firewall thing again I have no idea but it seems it was just a pretty interface doing nothing. Maybe @Flohack can remember full details.

• @Lakotaubp said in Error when enabeling ufw:

  It states the app was fully confined

  It wasn’t in 2016 when app was released and i installed it, and it’s still tagged as «full system access» right now.
  But maybe it was a fake «unconfined» app after all, but that would mean crap can be released on store without review, no?

  Sources are still available on launchpad i believe.
  https://bazaar.launchpad.net/~hosein-iprogramer/antivirus/trunk/files

• @Keneda @bhdouglass can you please check this app, this fake virus scanner should be removed I think, it was either an experiment or just a bad joke.

• @Flohack What’s the problem? It’s not available for xenial and if I recall there wasn’t anything wrong with it back in the day. I also think it was a beta and not fully completed.

• @bhdouglass Ok if its not in xenial I am fine with it

Hello, and thanks for the help.
In a fresh install of Debian Buster, «ufw» fails to enable on bootup.
Also, «ufw enable» gives the message: «ERROR: Could not load logging rules».

Updates don’t fix the problem.

I’ve tested two different computers (one Intel based, the other AMD based), and I’ve gotten the same failure.
So it’s not hardware specific.

Web searches show that this ufw problem appeared in 2013, but nothing within the last year (2018).
2013: github.com/sovereign/sovereign/issues/73
2013: superuser.com/questions/590600/ufw-is-active-but-not-enabled-why
I tried these older suggested fixes, but they failed.

Below is a synopses of what I’ve tried:
1) Fresh install of Debian Buster & KDE.
2) Install ufw and reboot.
3) ufw does not enable on bootup:

me@Test:~$ su -
Password: 
root@Test:~# ufw status
Status: inactive

4) Enabling ufw gives an error message (does not enable on reboot):

me@Test:~$ su -
Password: 
root@Test:~# ufw status
Status: inactive
root@Test:~# ufw enable
ERROR: Could not load logging rules
root@Test:~# ufw status
Status: active
root@Test:~# reboot
<reboot and login> 
me@Test:~$ su -
Password: 
root@Test:~# ufw status
Status: inactive

5) First suggested fix: disabling logging (does not enable on reboot):

me@Test:~$ su -
Password: 
root@Test:~# ufw status
Status: inactive
root@Test:~# ufw logging off
Logging disabled
root@Test:~# ufw status
Status: inactive
root@Test:~# ufw enable
ERROR: Could not load logging rules
root@Test:~# ufw status
Status: active
root@Test:~# reboot
<reboot and login>
me@Test:~$ su -
Password: 
root@Test:~# ufw status
Status: inactive

6) Second suggested fix: manually force enable (if disabled/enabled before reboot, then does not enable on reboot):

me@Test:~$ su -
Password: 
root@Test:~# ufw status
Status: inactive
root@Test:~# vi /etc/ufw/ufw.conf
<change "ENABLED=no" to "ENABLED=yes">
<change "LOGLEVEL=low" to "LOGLEVEL=off">
root@Test:~# ufw status
Status: inactive
root@Test:~# ufw enable
Firewall is active and enabled on system startup
root@Test:~# ufw status
Status: active
root@Test:~# ufw disable
Firewall stopped and disabled on system startup
root@Test:~# ufw status
Status: inactive
root@Test:~# ufw enable
ERROR: Could not load logging rules
root@Test:~# ufw status
Status: active
root@Test:~# reboot 
<reboot and login>
me@Test:~$ su -
Password: 
root@Test:~# ufw status
Status: inactive

How can I fix this problem of ufw failing to enable on bootup?
Again, thanks for the help.

Problem

This problem has been around for a long time.

Disable iptables in Docker will take other problems.

Rollback changes first

If you have modified your server according to the current solution that we find on the internet, please rollback these changes first, including:

• Enable Docker’s iptables feature.
  Remove all changes like --iptables=false , including configuration file /etc/docker/daemon.json.
• UFW’s default FORWARD rule changes back to the default DROP instead of ACCEPT.
• Remove the rules related to the Docker network in the UFW configuration file /etc/ufw/after.rules.
• If you have modified Docker configuration files, restart Docker first. We will modify the UFW configuration later, and we can restart it then.

Solving UFW and Docker issues

This solution needs to modify only one UFW configuration file, all Docker configurations and options remain the default. Doesn’t need to disable the docker iptables function.

Modify the UFW configuration file /etc/ufw/after.rules and add the following rules at the end of the file:

# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

-A DOCKER-USER -j ufw-user-forward

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER

Using the command sudo systemctl restart ufw to restart UFW after changing the file. Now the public network can’t access any published docker ports, the container and the private network can visit each other regularly, and the containers can also access the external network from inside.

If you want to allow public networks to access the services provided by the Docker container, for example, the service port of a container is 80. Run the following command to allow the public networks to access this service:

ufw route allow proto tcp from any to any port 80

This command allows the public network to access all published ports whose container port is 80.

Note: If we publish a port by using option -p 8080:80, we should use the container port 80, not the host port 8080.

If there are multiple containers with a service port of 80, but we only want the external network to access a particular container. For example, if the private address of the container is 172.17.0.2, use the following command:

ufw route allow proto tcp from any to 172.17.0.2 port 80

If the network protocol of service is UDP, for example, a DNS service, you can use the following command to allow the external network to access all published DNS services:

ufw route allow proto udp from any to any port 53

Similarly, if only for a specific container, such as IP address 172.17.0.2:

ufw route allow proto udp from any to 172.17.0.2 port 53

How it works?

The following rules allow the private networks to be able to visit each other. Typically, private networks are more trusted than public networks.

-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

The following rules allow UFW to manage whether the public networks are allowed to visit the services provided by the Docker container. So that we can manage all firewall rules in one place.

-A DOCKER-USER -j ufw-user-forward

The following rules block connection requests initiated by all public networks, but allow internal networks to access external networks. For TCP protocol, it prevents from actively establishing a TCP connection from public networks. For UDP protocol, all accesses to ports which is less then 32767 are blocked. Why is this port? Since the UDP protocol is stateless, it is not possible to block the handshake signal that initiates the connection request as TCP does. For GNU/Linux we can find the local port range in the file /proc/sys/net/ipv4/ip_local_port_range. The default range is 32768 60999. When accessing a UDP protocol service from a running container, the local port will be randomly selected one from the port range, and the server will return the data to this random port. Therefore, we can assume that the listening port of the UDP protocol inside all containers are less then 32768. This is the reason that we don’t want public networks to access the UDP ports that less then 32768.

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN

More

https://github.com/chaifeng/ufw-docker

sudo wget -O /usr/local/bin/ufw-docker https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker
chmod +x /usr/local/bin/ufw-docker

Usage

ufw-docker help
ufw-docker install
ufw-docker status
ufw-docker allow webapp
ufw-docker allow webapp 80
ufw-docker allow webapp 53/udp
ufw-docker list webapp
ufw-docker delete allow webapp 80/tcp
ufw-docker delete allow webapp

Update: 2018-09-10

The reason for choosing ufw-user-forward, not ufw-user-input

using ufw-user-input

Pro:

Easy to use and understand, supports older versions of Ubuntu.

For example, to allow the public to visit a published port whose container port is 8080, use the command:

ufw allow 8080

Con:

It not only exposes ports of containers but also exposes ports of the host.

For example, if a service is running on the host, and the port is 8080. The command ufw allow 8080 allows the public network to visit the service and all published ports whose containers’ port is 8080. But we just want to expose the service running on the host, or just the service running inside containers, not the both.

To avoid this problem, we may need to use a command similar to the following for all containers:

ufw allow proto tcp from any to 172.16.0.3 port 8080

using ufw-user-forward

Pro:

Cannot expose services running on hosts and containers at the same time by the same command.

For example, if we want to publish the port 8080 of containers, use the following command:

ufw route allow 8080

The public network can access all published ports whose container ports are 8080.

But the port 8080 of the host is still not be accessed by the public network. If we want to do so, execute the following command to allow the public access the port on the host separately:

ufw allow 8080

Con:

Doesn’t support older versions of Ubuntu, and the command is a bit more complicated. But you can use my script https://github.com/chaifeng/ufw-docker.

Conclusion

If we are using an older version of Ubuntu, we can use ufw-user-input chain. But be careful to avoid exposing services that should not be exposed.

If we are using a newer version of Ubuntu which is support ufw route sub-command, we’d better use ufw-user-forward chain, and use ufw route command to manage firewall rules for containers.

Update: Oct 6, 2018

The script ufw-docker supports Docker Swarm now. Please see the latest code for more, https://github.com/chaifeng/ufw-docker

Install for Docker Swarm mode

We can only use this script on manager nodes to manage firewall rules when using in Swarm mode.

• Modifying all after.rules files on all nodes, including managers and workers
• Deploying this script on manager nodes

Running in Docker Swarm mode, this script will add a global service ufw-docker-agent. The image chaifeng/ufw-docker-agent is also automatically built from this project.

mateusz@debian:~$ sudo ufw disable
Firewall stopped and disabled on system startup

mateusz@debian:~$ sudo ufw status verbose
Status: inactive

mateusz@debian:~$ sudo ufw enable
ERROR: problem running ufw-init

Даже если ошибка происходит, вы можете проверить, что UFW работает.

mateusz@debian:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW IN    Anywhere
22/tcp                     ALLOW IN    Anywhere

или же

mateusz@debian:~$ sudo service ufw status
[ ok all is running...done.

Вы можете легко настроить вручную ENABLED=yes в конфигурации UFW

sudo nano /etc/ufw/ufw.conf

который содержит:

# /etc/ufw/ufw.conf
#

# Set to yes to start on boot. If setting this remotely, be sure to add a rule
# to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
ENABLED=no

# Please use the 'ufw' command to set the loglevel. Eg: 'ufw logging medium'.
# See 'man ufw' for details.
LOGLEVEL=low