Andy Kurth created VCL-996:
------------------------------
Summary: Linux firewall subroutines do not sort rule numbers
correctly
Key: VCL-996
URL: https://issues.apache.org/jira/browse/VCL-996
Project: VCL
Issue Type: Bug
Components: vcld (backend)
Affects Versions: 2.4.2
Reporter: Andy Kurth
Assignee: Andy Kurth
Fix For: 2.5
The {{enable_firewall_port}} and {{disable_firewall_port}} subroutines in
Linux.pm retrieve the existing iptables rules. The proper scope is then
calculated. They then construct a long command that deletes existing rules
with _iptables -D_ then add rules back with _iptables -I_. All of the
individual iptables commands are chained by _&&_. Example:
{code}iptables -D INPUT 4 && iptables -D INPUT 3 && iptables -D INPUT 2 &&
iptables -v -I INPUT 1 -p tcp...{code}
Existing rules are deleted by rule ID. It is critical to delete them in order
from highest to lowest otherwise the ID of subsequent rules will change. For
example, suppose you want to delete rules B, C and D which currently have IDs
2, 3 and 4:
# A
# *{color:green}B{color}*
# *{color:green}C{color}*
# *{color:green}D{color}*
# E
# F
If the rules are deleted in ascending order (2,3,4), after the first deletion
(B, ID=2) the IDs immediately become:
# A
# *{color:green}C{color}*
# *{color:green}D{color}*
# E
# F
Then rule 3 (currently D) is deleted, the IDs immediately become:
# A
# *{color:green}C{color}*
# E
# *{color:red}F{color}*
When the command finally deletes rule 4 it is deleting an unintended rule (F).
The code in Linux.pm is constructing the command with the IDs reverse sorted
(good). However, it's using Perl's default lexical sort instead of numeric
(bad). Because of this, rules are deleted in an order such as:
3
2
11
10
1
This causes various problems, including the possibility of locking the
management node out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
