"after-logging" rules are not loaded by default

[Emmanuel Bailleul]

version :ufw version 0.29.1 (built from source)
OS : Zenwalk 6.2

Description :

When starting ufw, in "ufw-init-functions" one can find :
(...)
            # setup ufw${type}-user chain
            if [ -s "$USER_PATH" ]; then
                $exe -N ufw${type}-user-input || error="yes"
                $exe -N ufw${type}-user-output || error="yes"
                $exe -N ufw${type}-user-forward || error="yes"
                $exe -A ufw${type}-before-input -j ufw${type}-user-input || error="yes"
                $exe -A ufw${type}-before-output -j ufw${type}-user-output || error="yes"
                $exe -A ufw${type}-before-forward -j ufw${type}-user-forward || error="yes"
                if ! $exe-restore -n < $USER_RULES ; then
                    out="${out}\nProblem running '$USER_RULES'"
                    error="yes"
                fi
(...)

The important part is the "iptables-restore" stuff that will load user.rules and create new chains accordingly. In particular, in my case, it creates "*-after-logging" rules (cause these ones have been saved in user.rules file).

However, later on in the code, one can find :
(...)
            # setup ufw${type}-after-logging-* chains
            if ! $exe -L ufw${type}-after-logging-input -n >/dev/null 2>&1 ; then
                $exe -N ufw${type}-after-logging-input || error="yes"
                $exe -N ufw${type}-after-logging-output || error="yes"
                $exe -N ufw${type}-after-logging-forward || error="yes"
                $exe -A INPUT -j ufw${type}-after-logging-input || error="yes"
                $exe -A OUTPUT -j ufw${type}-after-logging-output || error="yes"
                $exe -A FORWARD -j ufw${type}-after-logging-forward || error="yes"
            fi
(...)
so the condition is not met, and "after-logging" rules are not added to the builtin chains.

this lead to dropped packets not being logged at all at any loglevel.

Evidence :

(...)
root[src]# iptables -L INPUT
Chain INPUT (policy DROP)
target prot opt source destination
ufw-before-logging-input all -- anywhere anywhere
ufw-before-input all -- anywhere anywhere
ufw-after-input all -- anywhere anywhere
ufw-reject-input all -- anywhere anywhere
ufw-track-input all -- anywhere anywhere
(...)

[Jamie Strandboge (jdstrand)]

Thank you for using ufw and taking the time to report a bug.

For a little background, if you haven't already, see the Chains section in the README in the source or /usr/share/doc/ufw/README.gz on Debian-based systems.

I don't see the problem here:
$ sudo iptables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
...
ufw-after-logging-input all -- 0.0.0.0/0 0.0.0.0/0
...

Chain FORWARD (policy DROP)
target prot opt source destination
...
ufw-after-logging-forward all -- 0.0.0.0/0 0.0.0.0/0
...

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
...
ufw-after-logging-output all -- 0.0.0.0/0 0.0.0.0/0
...

Can you give the steps to reproduce your problem and what you expect the behavior to be? Thanks!

[Emmanuel Bailleul (emmanuel-bailleul)]

OK. For example : on an existing installation (built from source) :

1. Disable firewall :
   #ufw disable
2. Flush all iptables rules :
   #/lib/ufw/ufw-init flush-all
3. Enable firewall :
   #ufw enable
4. Check INPUT chain :
   #iptables -L INPUT -n

Chain INPUT (policy DROP)
target prot opt source destination
ufw-before-logging-input all -- 0.0.0.0/0 0.0.0.0/0
ufw-before-input all -- 0.0.0.0/0 0.0.0.0/0
ufw-after-input all -- 0.0.0.0/0 0.0.0.0/0
ufw-reject-input all -- 0.0.0.0/0 0.0.0.0/0
ufw-track-input all -- 0.0.0.0/0 0.0.0.0/0

[Jamie Strandboge (jdstrand)]

Confirmed, but this particular bug has already been reported and is a duplicate of bug 459925, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.

[Jamie Strandboge (jdstrand)]

Actually, I was wrong about it being a duplicate since your bug is still present in 0.29.1. That said, I have an some changes going into trunk that should fix it.

[Emmanuel Bailleul (emmanuel-bailleul)]

Did try with rev 595 to no avail.

May I propose you to examine the patch below which seems to produce the expected behaviour ?

--- src/ufw-init-functions 2010-01-28 02:18:21.540277174 +0100
+++ src/ufw-init-functions.orig 2010-01-28 02:17:59.712213999 +0100
@@ -271,10 +271,10 @@
                 $exe -N ufw${type}-after-logging-input || error="yes"
                 $exe -N ufw${type}-after-logging-output || error="yes"
                 $exe -N ufw${type}-after-logging-forward || error="yes"
- fi
                 $exe -A INPUT -j ufw${type}-after-logging-input || error="yes"
                 $exe -A OUTPUT -j ufw${type}-after-logging-output || error="yes"
                 $exe -A FORWARD -j ufw${type}-after-logging-forward || error="yes"
+ fi

             # now setup the REJECT chains
             if ! $exe -L ufw${type}-reject-input -n >/dev/null 2>&1 ; then

[Jamie Strandboge (jdstrand)]

I know the problem, and it was introduced in the fix for bug #459925. What is happening is that ufw now adds stuff to the top of user.rules to make sure that logging state is setup when running /lib/ufw/ufw-init, like on boot. Eg:

In user.rules:
*filter
...
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-logging-forward - [0:0]
...

When we iptables-restore this file, it creates the above 3 logging chains. The problem is that in /lib/ufw/ufw-init-functions we call iptables-restore on user.rules before this:
# setup ufw${type}-after-logging-* chains
if ! $exe -L ufw${type}-after-logging-input -n >/dev/null 2>&1 ; then
  $exe -N ufw${type}-after-logging-input || error="yes"
  $exe -N ufw${type}-after-logging-output || error="yes"
  $exe -N ufw${type}-after-logging-forward || error="yes"
  $exe -A INPUT -j ufw${type}-after-logging-input || error="yes"
  $exe -A OUTPUT -j ufw${type}-after-logging-output || error="yes"
  $exe -A FORWARD -j ufw${type}-after-logging-forward || error="yes"
fi

Therefore the after-logging chains already exist and are not added to the builtin chains. This is a regression in 0.29.1 over 0.29.

The fix is simply to move all the iptables-restore blocks to the end of ufw_start().

[Jamie Strandboge (jdstrand)]

On Thu, 2010-01-28 at 01:21 +0000, Emmanuel Bailleul wrote:
> Did try with rev 595 to no avail.

I didn't commit it at this time. The patch is in r596.

[Jamie Strandboge (jdstrand)]

FYI -- r596 - 598 should fully address this.

[Jamie Strandboge (jdstrand)]

Fixed in 0.29.2.

[Emmanuel Bailleul (emmanuel-bailleul)]

Confirmed.
Thx