| 2021-06-21 14:26:49 |
Derek Ramsey |
bug |
|
|
added bug |
| 2021-06-21 14:39:57 |
Derek Ramsey |
description |
UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)
If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted.
This is repeatable with the following script:
ufw insert 1 allow from 1.1.1.1/26 to any port 22
ufw insert 2 allow from 1.2.3.4/26 to any port 22
ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
iptables -L -n | grep -A 6 "Chain ufw-user-input"
yes | ufw delete 3
iptables -L -n | grep -A 4 "Chain ufw-user-input"
The output is as follows:
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0 udp dpt:22
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:
To Action From
-- ------ ----
22/tcp ALLOW 1.2.3.0/26
22 ALLOW 1.1.1.0/26
Mixing ALLOW and DROP/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible. |
UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)
If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted.
This is repeatable with the following script:
ufw insert 1 allow from 1.1.1.1/26 to any port 22
ufw insert 2 allow from 1.2.3.4/26 to any port 22
ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
iptables -L -n | grep -A 6 "Chain ufw-user-input"
yes | ufw delete 3
iptables -L -n | grep -A 4 "Chain ufw-user-input"
The output is as follows:
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0 udp dpt:22
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:
To Action From
-- ------ ----
22/tcp ALLOW 1.2.3.0/26
22 ALLOW 1.1.1.0/26
Mixing ALLOW and DROP/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible.
A reboot is required to fix the issue. |
|
| 2021-06-21 15:00:47 |
Derek Ramsey |
description |
UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)
If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted.
This is repeatable with the following script:
ufw insert 1 allow from 1.1.1.1/26 to any port 22
ufw insert 2 allow from 1.2.3.4/26 to any port 22
ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
iptables -L -n | grep -A 6 "Chain ufw-user-input"
yes | ufw delete 3
iptables -L -n | grep -A 4 "Chain ufw-user-input"
The output is as follows:
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0 udp dpt:22
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:
To Action From
-- ------ ----
22/tcp ALLOW 1.2.3.0/26
22 ALLOW 1.1.1.0/26
Mixing ALLOW and DROP/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible.
A reboot is required to fix the issue. |
UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)
If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted.
This is repeatable with the following script:
ufw insert 1 allow from 1.1.1.1/26 to any port 22
ufw insert 2 allow from 1.2.3.4/26 to any port 22
ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
iptables -L -n | grep -A 6 "Chain ufw-user-input"
yes | ufw delete 3
iptables -L -n | grep -A 4 "Chain ufw-user-input"
The output is as follows:
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0 udp dpt:22
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:
To Action From
-- ------ ----
22/tcp ALLOW 1.2.3.0/26
22 ALLOW 1.1.1.0/26
Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible.
For example, if one had initially set up the following rule to port 22 (TCP and UDP)...
ufw insert 1 allow from 1.2.3.4 to any port 22
...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections...
ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
ufw insert 2 reject from any to any port 22
yes | ufw delete 3
...this would result in SSH becoming inaccessible.
Instead if one had the initial configuration...
ufw insert 1 reject from 1.0.0.0/8 to any port 22
ufw insert 2 allow from any to any port 22
...which was later updated to be...
ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp
ufw insert 2 allow from any to any port 22 proto tcp
yes | ufw delete 3
...this would result in 1.0.0.0/8 incorrectly being allowed to access port 22. While this is a contrived scenario, it is possible and reproducible.
A reboot is required to fix the issue, as it reloads the configuration to the expected order. |
|
| 2021-06-21 15:04:41 |
Derek Ramsey |
description |
UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)
If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted.
This is repeatable with the following script:
ufw insert 1 allow from 1.1.1.1/26 to any port 22
ufw insert 2 allow from 1.2.3.4/26 to any port 22
ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
iptables -L -n | grep -A 6 "Chain ufw-user-input"
yes | ufw delete 3
iptables -L -n | grep -A 4 "Chain ufw-user-input"
The output is as follows:
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0 udp dpt:22
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:
To Action From
-- ------ ----
22/tcp ALLOW 1.2.3.0/26
22 ALLOW 1.1.1.0/26
Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible.
For example, if one had initially set up the following rule to port 22 (TCP and UDP)...
ufw insert 1 allow from 1.2.3.4 to any port 22
...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections...
ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
ufw insert 2 reject from any to any port 22
yes | ufw delete 3
...this would result in SSH becoming inaccessible.
Instead if one had the initial configuration...
ufw insert 1 reject from 1.0.0.0/8 to any port 22
ufw insert 2 allow from any to any port 22
...which was later updated to be...
ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp
ufw insert 2 allow from any to any port 22 proto tcp
yes | ufw delete 3
...this would result in 1.0.0.0/8 incorrectly being allowed to access port 22. While this is a contrived scenario, it is possible and reproducible.
A reboot is required to fix the issue, as it reloads the configuration to the expected order. |
UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)
If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted.
This is repeatable with the following script:
ufw insert 1 allow from 1.1.1.1/26 to any port 22
ufw insert 2 allow from 1.2.3.4/26 to any port 22
ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
iptables -L -n | grep -A 6 "Chain ufw-user-input"
yes | ufw delete 3
iptables -L -n | grep -A 4 "Chain ufw-user-input"
The output is as follows:
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0 udp dpt:22
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:
To Action From
-- ------ ----
22/tcp ALLOW 1.2.3.0/26
22 ALLOW 1.1.1.0/26
Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible.
For example, if one had initially set up the following rule to port 22 (TCP and UDP)...
ufw insert 1 allow from 1.2.3.4 to any port 22
...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections...
ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp
ufw insert 2 reject from any to any port 22
yes | ufw delete 3
...this would result in SSH becoming inaccessible.
Instead if one had the initial configuration...
ufw insert 1 reject from 1.0.0.0/8 to any port 22
ufw insert 2 allow from any to any port 22
...which was later updated to be...
ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp
ufw insert 2 allow from any to any port 22 proto tcp
yes | ufw delete 3
...this would result in 1.0.0.0/8 incorrectly being allowed to access port 22. While this is a contrived scenario, it is possible and reproducible.
A reboot is required to fix the issue, as it reloads the configuration to the expected order. |
|
| 2021-06-21 15:45:51 |
Derek Ramsey |
information type |
Public |
Private Security |
|
| 2021-09-18 23:15:14 |
Jamie Strandboge |
information type |
Private Security |
Public Security |
|
| 2021-09-18 23:15:30 |
Jamie Strandboge |
ufw: importance |
Undecided |
High |
|
| 2021-09-18 23:15:30 |
Jamie Strandboge |
ufw: status |
New |
Triaged |
|
| 2021-09-18 23:47:19 |
Jamie Strandboge |
summary |
ufw deletes entries in wrong order |
ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule |
|
| 2021-09-18 23:47:23 |
Jamie Strandboge |
ufw: assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2021-09-19 00:38:59 |
Jamie Strandboge |
ufw: status |
Triaged |
Fix Committed |
|
| 2021-09-19 01:34:59 |
Jamie Strandboge |
ufw: status |
Fix Committed |
Fix Released |
|
| 2021-09-19 05:50:04 |
Jamie Strandboge |
bug task added |
|
ufw (Ubuntu) |
|
| 2021-09-19 05:50:12 |
Jamie Strandboge |
ufw (Ubuntu): status |
New |
In Progress |
|
| 2021-09-19 05:50:15 |
Jamie Strandboge |
ufw (Ubuntu): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2021-09-20 16:14:45 |
Launchpad Janitor |
ufw (Ubuntu): status |
In Progress |
Fix Released |
|
| 2021-10-25 21:30:46 |
Mauricio Faria de Oliveira |
tags |
|
seg sts-sponsor-mfo |
|
| 2021-10-25 21:38:02 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Focal |
|
| 2021-10-25 21:38:02 |
Mauricio Faria de Oliveira |
bug task added |
|
ufw (Ubuntu Focal) |
|
| 2021-10-25 21:38:02 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Hirsute |
|
| 2021-10-25 21:38:02 |
Mauricio Faria de Oliveira |
bug task added |
|
ufw (Ubuntu Hirsute) |
|
| 2021-10-25 21:38:02 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Bionic |
|
| 2021-10-25 21:38:02 |
Mauricio Faria de Oliveira |
bug task added |
|
ufw (Ubuntu Bionic) |
|
| 2021-10-25 21:38:09 |
Mauricio Faria de Oliveira |
ufw (Ubuntu Bionic): status |
New |
In Progress |
|
| 2021-10-25 21:38:13 |
Mauricio Faria de Oliveira |
ufw (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2021-10-25 21:38:16 |
Mauricio Faria de Oliveira |
ufw (Ubuntu Bionic): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2021-10-25 21:38:18 |
Mauricio Faria de Oliveira |
ufw (Ubuntu Focal): status |
New |
In Progress |
|
| 2021-10-25 21:38:21 |
Mauricio Faria de Oliveira |
ufw (Ubuntu Focal): importance |
Undecided |
Medium |
|
| 2021-10-25 21:38:23 |
Mauricio Faria de Oliveira |
ufw (Ubuntu Focal): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2021-10-25 21:38:26 |
Mauricio Faria de Oliveira |
ufw (Ubuntu Hirsute): status |
New |
In Progress |
|
| 2021-10-25 21:38:28 |
Mauricio Faria de Oliveira |
ufw (Ubuntu Hirsute): importance |
Undecided |
Medium |
|
| 2021-10-25 21:38:30 |
Mauricio Faria de Oliveira |
ufw (Ubuntu Hirsute): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2021-10-27 18:10:29 |
Mauricio Faria de Oliveira |
description |
UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)
If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted.
This is repeatable with the following script:
ufw insert 1 allow from 1.1.1.1/26 to any port 22
ufw insert 2 allow from 1.2.3.4/26 to any port 22
ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
iptables -L -n | grep -A 6 "Chain ufw-user-input"
yes | ufw delete 3
iptables -L -n | grep -A 4 "Chain ufw-user-input"
The output is as follows:
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0 udp dpt:22
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:
To Action From
-- ------ ----
22/tcp ALLOW 1.2.3.0/26
22 ALLOW 1.1.1.0/26
Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible.
For example, if one had initially set up the following rule to port 22 (TCP and UDP)...
ufw insert 1 allow from 1.2.3.4 to any port 22
...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections...
ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp
ufw insert 2 reject from any to any port 22
yes | ufw delete 3
...this would result in SSH becoming inaccessible.
Instead if one had the initial configuration...
ufw insert 1 reject from 1.0.0.0/8 to any port 22
ufw insert 2 allow from any to any port 22
...which was later updated to be...
ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp
ufw insert 2 allow from any to any port 22 proto tcp
yes | ufw delete 3
...this would result in 1.0.0.0/8 incorrectly being allowed to access port 22. While this is a contrived scenario, it is possible and reproducible.
A reboot is required to fix the issue, as it reloads the configuration to the expected order. |
[Impact]
* The deletion of a rule without the 'proto' field
that has a similar rule *with* the 'proto' field
might delete the wrong rule (the latter).
* This might cause services to be inaccessible or
incorrectly allowed, depending on rule ordering
(read original description below for examples.)
[Test Steps]
* Add rules:
ufw allow from 1.1.1.1 port 1111 proto tcp
ufw allow from 2.2.2.2 port 2222 proto tcp
ufw allow from 1.1.1.1 port 1111
* Check iptables:
iptables -L ufw-user-input -n
...
ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt:1111
ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt:2222
ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt:1111
ACCEPT udp -- 1.1.1.1 0.0.0.0/0 udp spt:1111
* Delete the third rule above
ufw status numbered
yes | ufw delete 3
* Check iptables again:
iptables -L ufw-user-input -n
Observed: (deleted tcp line from first rule, and udp line from third rule)
...
ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt:2222
ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt:1111
Expected: (deleted both tcp and udp lines from third rule)
...
ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt:1111
ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt:2222
[Regression Potential]
* Potential regressions would be observed when deleting rules.
* This fix has been suggested for SRU by jdstrand [1],
and has already been available in 21.04 and the snap.
[1] https://code.launchpad.net/~mfo/ufw/+git/ufw/+merge/410091/comments/1083005
[Original Description]
UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)
If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted.
This is repeatable with the following script:
ufw insert 1 allow from 1.1.1.1/26 to any port 22
ufw insert 2 allow from 1.2.3.4/26 to any port 22
ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
iptables -L -n | grep -A 6 "Chain ufw-user-input"
yes | ufw delete 3
iptables -L -n | grep -A 4 "Chain ufw-user-input"
The output is as follows:
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0 udp dpt:22
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22
ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22
ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22
UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:
To Action From
-- ------ ----
22/tcp ALLOW 1.2.3.0/26
22 ALLOW 1.1.1.0/26
Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible.
For example, if one had initially set up the following rule to port 22 (TCP and UDP)...
ufw insert 1 allow from 1.2.3.4 to any port 22
...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections...
ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp
ufw insert 2 reject from any to any port 22
yes | ufw delete 3
...this would result in SSH becoming inaccessible.
Instead if one had the initial configuration...
ufw insert 1 reject from 1.0.0.0/8 to any port 22
ufw insert 2 allow from any to any port 22
...which was later updated to be...
ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp
ufw insert 2 allow from any to any port 22 proto tcp
yes | ufw delete 3
...this would result in 1.0.0.0/8 incorrectly being allowed to access port 22. While this is a contrived scenario, it is possible and reproducible.
A reboot is required to fix the issue, as it reloads the configuration to the expected order. |
|
| 2021-11-02 22:07:46 |
Brian Murray |
ufw (Ubuntu Hirsute): status |
In Progress |
Fix Committed |
|
| 2021-11-02 22:07:48 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-11-02 22:07:51 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2021-11-02 22:07:55 |
Brian Murray |
tags |
seg sts-sponsor-mfo |
seg sts-sponsor-mfo verification-needed verification-needed-hirsute |
|
| 2021-11-02 22:09:15 |
Brian Murray |
ufw (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2021-11-02 22:09:21 |
Brian Murray |
tags |
seg sts-sponsor-mfo verification-needed verification-needed-hirsute |
seg sts-sponsor-mfo verification-needed verification-needed-focal verification-needed-hirsute |
|
| 2021-11-02 22:10:20 |
Brian Murray |
ufw (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2021-11-02 22:10:28 |
Brian Murray |
tags |
seg sts-sponsor-mfo verification-needed verification-needed-focal verification-needed-hirsute |
seg sts-sponsor-mfo verification-needed verification-needed-bionic verification-needed-focal verification-needed-hirsute |
|
| 2021-11-03 12:57:10 |
Jamie Strandboge |
tags |
seg sts-sponsor-mfo verification-needed verification-needed-bionic verification-needed-focal verification-needed-hirsute |
seg sts-sponsor-mfo verification-done-focal verification-needed verification-needed-bionic verification-needed-hirsute |
|
| 2021-11-03 13:40:27 |
Jamie Strandboge |
tags |
seg sts-sponsor-mfo verification-done-focal verification-needed verification-needed-bionic verification-needed-hirsute |
seg sts-sponsor-mfo verification-done-bionic verification-done-focal verification-needed verification-needed-hirsute |
|
| 2021-11-03 18:34:03 |
Mauricio Faria de Oliveira |
tags |
seg sts-sponsor-mfo verification-done-bionic verification-done-focal verification-needed verification-needed-hirsute |
seg sts-sponsor-mfo verification-done verification-done-bionic verification-done-focal verification-done-hirsute |
|
| 2021-11-10 18:32:04 |
Launchpad Janitor |
ufw (Ubuntu Hirsute): status |
Fix Committed |
Fix Released |
|
| 2021-11-10 18:32:11 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-11-10 18:33:04 |
Launchpad Janitor |
ufw (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2021-11-10 18:33:35 |
Launchpad Janitor |
ufw (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
