> 1) If a chain consisted of a single RETURN rule, optimize level 4 > would handle it incorrectly by moving the RETURN rule to the > chain(s) that jumped to the single-rule chain. The optimizer now > simply eliminate the chain and rule. That works now.
> As part of this change, the optimizer now deletes trailing RETURN > rules from chains. I wasn't able to test this. How is this produced? > 1) There are now 'Related', 'Untracked' and 'Established' actions that > match packets in the RELATED and UNTRACKED states respectively. > > These actions are in-line and have a single parameter that > specifies the action to be taken. The action may be anything that > is valid in the ACTION column of the rules file. 1. Issue warning/error when state rules will never execute: rules ~~~~~ SECTION ESTABLISHED Invalid(DROP) all all or shorewall.conf ~~~~~~~~~~~~~~ BLACKLIST="NEW,UNTRACKED" blrules ~~~~~~~ Invalid(DROP) all all The above Invalid(DROP) rules will never execute since the outline state is NEW (rules) and "NEW,UNTRACKED" (blrules). 2. The old dropInvalid and the new Invalid/Established/... actions are not optimised: rules ~~~~~ SECTION ALL Invalid(DROP) fw net [...] SECTION NEW dropInvalid fw net creates the following: -A fw2net -m conntrack --ctstate INVALID -j DROP -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT -A fw2net -m conntrack --ctstate RELATED -j +fw2net -A fw2net -m conntrack --ctstate INVALID -j DROP Please note that there is no SECTION INVALID present in my "rules" file. The case is also the same when I have something like: rules ~~~~~ SECTION ALL Invalid(DROP) all all Invalid(A_DROP) fw net [...] SECTION INVALID DROP fw net udp ACCEPT all all [...] SECTION NEW dropInvalid all all [...] This produces: [...] -A _fw2net -p 17 -j DROP -A _fw2net -j ACCEPT [...] -A fw2net -m conntrack --ctstate INVALID -j DROP -A fw2net -m conntrack --ctstate INVALID -j A_DROP -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT -A fw2net -m conntrack --ctstate RELATED -j ACCEPT -A fw2net -m conntrack --ctstate INVALID -j _fw2net -A fw2net -m conntrack --ctstate UNTRACKED -j DROP -A fw2net -m conntrack --ctstate INVALID -j DROP All of the above "INVALID" state statements should have been optimised or combined in _fw2net. 3. Internal error: ERROR: "process_rule1" is not exported by the Shorewall::Rules module rules ~~~~~ SECTION RELATED Related(IELOG(-,fw2NeT,2)) $FW net IELOG is inline action taking 3 parameters: (custom) disposition, (custom) chain and NFLOG class number. The full error message is: ERROR: "process_rule1" is not exported by the Shorewall::Rules module Can't continue after import errors at /usr/share/shorewall/action.Related line 40 BEGIN failed--compilation aborted at /usr/share/shorewall/action.Related line 40. I get the same error with "Established" and "Untracked". "Invalid" passes, though I have another 2 problems: -A +fw2net -m conntrack --ctstate INVALID -j LOG --log-tcp-options --log-ip-options --log-macdecode --log-tcp-sequence --log-uid --log-level 6 --log-prefix "Shorewall:fw2NeT::" -A +fw2net -m conntrack --ctstate INVALID -j NFLOG --nflog-group 2 --nflog-range 0 --nflog-threshold 1 --nflog-prefix "Shorewall:fw2NeT::" Notice the "--cstate INVALID" matches - these could all be optimised in a single chain. I have tried custom actions with more statements (7 to be exact) and I had the same number of "--cstate INVALID" matches, which is wrong. I am ignoring the fact that in the RELATED state, the above statements will never execute (as the match is against INVALID), but this has already been raised. so I am not going to repeat it again. The second problem is this: rules ~~~~~ SECTION RELATED IELOG(-,fw2NeT,2) Invalid(IELOG(-,fw2NeT,2)) $FW net produces: -A +fw2net -m conntrack -j LOG --log-tcp-options --log-ip-options --log-macdecode --log-tcp-sequence --log-uid --log-level 6 --log-prefix "Shorewall:fw2NeT::" -A +fw2net -m conntrack -j NFLOG --nflog-group 2 --nflog-range 0 --nflog-threshold 1 --nflog-prefix "Shorewall:fw2NeT::" In other words, not even a hint of "--cstate INVALID" (it could have been "optimised away" by mistake). In general, if the action above Invalid seems to be inline, the whole "Invalid(...)" statement seems to be totally ignored. 4. "normal" (not inline) actions now seem to be ignored by shorewall: actions ~~~~~~~ IELOG inline ELOG Please note that I have action.ELOG symlinked to action.IELOG. In other words, these are exactly the same, only the definition in "actions" is different. rules ~~~~~ SECTION NEW ELOG(-,fw2NeT,2) $FW net [...] produces: -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT -A fw2net -m conntrack --ctstate RELATED -j +fw2net -A fw2net [...] Note the last statement above - that won't even compile! The same nonsensical statement is produced when I have the above ELOG statement placed in SECTION ALL. If I place ELOG in RELATED, that is completely ignored (as if it isn't there). Same goes for: - SECTION ESTABLISHED (the rule produced is "-A fw2net -m conntrack --ctstate ESTABLISHED"); - SECTION UNTRACKED (the rule produced is "-A fw2net -m conntrack --ctstate UNTRACKED -j ~comb0" where "~comb0" consists of a single "-j DROP" statement); and - SECTION INVALID (the rule produced is similar: "-A fw2net -m conntrack --ctstate INVALID -j ~comb0"). > 3) To allow finer-grained selection of the connection-tracking states > that are passed through blacklists (both dynamic and static), a > BLACKLIST option has been added in shorewall.conf and > shorewall6.conf. That works to perfection now. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
