ufw

FEATURE REQUEST: if INSERT matches existing rule, "Re-Order" rule to insert location

Bug #1922123 reported by Aaron Galbraith
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ufw
Won't Fix
Undecided
Unassigned

Bug Description

ufw version 0.36

Note: I'm typing this by hand as an "in my head emulation", my firewall is in production but it will explain the issue, and numbers made up to protect the innocent :P)

Current behavior

--- BEGIN SNIP of Example as if in shell ----

> sudo ufw allow dns
Rule added
> sudo ufw allow proto tcp from 192.168.2.0/24 to any port 22,80,443,853,2222,8080,8443,8843,8880,8883
Rule added
> sudo ufw allow proto tcp from 192.168.2.14 to any port 25,465,587
Rule added
> sudo ufw allow proto tcp from 192.168.2.11 to any port 25,465,587
Rule added
> sudo ufw allow proto tcp from 192.168.2.10 to any port 25,465,587
Rule added
> sudo ufw allow proto tcp from 192.168.2.1 to any port 25,465,587
Rule added
> sudo ufw allow proto udp from 192.168.2.0/24 to any port 1900,3478,5514,5656:5699,10000:10001
Rule added

> sudo ufw status numbered
Status: active

     To Action From
     -- ------ ----
[ 1] DNS ALLOW IN Anywhere
[ 2] 22,80,443,853,2222,8080,8443,8843,8880,8883,27117/tcp ALLOW IN 192.168.10.0/24
[ 3] 25,465,587/tcp ALLOW IN 192.168.10.14
[ 4] 25,465,587/tcp ALLOW IN 192.168.10.11
[ 5] 25,465,587/tcp ALLOW IN 192.168.10.10
[ 6] 25,465,587/tcp ALLOW IN 192.168.10.1
[ 7] 1900,3478,5514,5656:5699,10000:10001/udp ALLOW IN 192.168.10.0/24
[ 8] DNS (v6) ALLOW IN Anywhere (v6)

> sudo ufw insert 3 allow proto udp from 192.168.2.0/24 to any port 1900,3478,5514,5656:5699,10000:10001
Skipping inserting existing rule

> sudo ufw status numbered
Status: active

     To Action From
     -- ------ ----
[ 1] DNS ALLOW IN Anywhere
[ 2] 22,80,443,853,2222,8080,8443,8843,8880,8883,27117/tcp ALLOW IN 192.168.10.0/24
[ 3] 25,465,587/tcp ALLOW IN 192.168.10.14
[ 4] 25,465,587/tcp ALLOW IN 192.168.10.11
[ 5] 25,465,587/tcp ALLOW IN 192.168.10.10
[ 6] 25,465,587/tcp ALLOW IN 192.168.10.1
[ 7] 1900,3478,5514,5656:5699,10000:10001/udp ALLOW IN 192.168.10.0/24
[ 8] DNS (v6) ALLOW IN Anywhere (v6)

------ END OF EXAMPLE ----
***Noting that the rule was NOT duplicated but also was not moved to index 3***

==========================================================
Expected (or since this is a feature request: Desired)
---- BEGIN SNIP of Example --- same as above but replacing ONLY last ufw allow command and response ----

> sudo ufw insert 3 allow proto udp from 192.168.2.0/24 to any port 1900,3478,5514,5656:5699,10000:10001
Moved existing rule

> sudo ufw status numbered
Status: active

     To Action From
     -- ------ ----
[ 1] DNS ALLOW IN Anywhere
[ 2] 22,80,443,853,2222,8080,8443,8843,8880,8883,27117/tcp ALLOW IN 192.168.10.0/24
[ 3] 1900,3478,5514,5656:5699,10000:10001/udp ALLOW IN 192.168.10.0/24
[ 4] 25,465,587/tcp ALLOW IN 192.168.10.14
[ 5] 25,465,587/tcp ALLOW IN 192.168.10.11
[ 6] 25,465,587/tcp ALLOW IN 192.168.10.10
[ 7] 25,465,587/tcp ALLOW IN 192.168.10.1
[ 8] DNS (v6) ALLOW IN Anywhere (v6)

----- END OF EXAMPLE -----

the response verbiage "Moved existing rule" is of course at your discretion, I tried to maintain the simple, precise language already used:
Rule added
Rule inserted
Skipping existing rule
Skipping inserting existing rule [would still exist if the insert request was the SAME index as the current rule]

etc.

description: updated
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Thanks for filing a bug!

I recognize the ask and will say that currently you must remove the existing rule and then perform the insert after. I'm disinclined to implement this feature since the insert functionality is quite tricky wrt to matching rules that match both ipv4 and ipv6 and I'm not sure how to present a sensible UI to the user when say, an ipv4 rule moves from one place and the ipv6 rule moves to another (since rule ordering is so important, context is key; with an ipv4 or ipv6 only rule we can assume the user knows the context for the action they are trying to perform, but its possible when both match that they've only considered one or the other). As such, I'm going to mark this as Won't Fix for now, but it is possible it could be implemented at a future date.

Changed in ufw:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.