Hello,
I''ve been doing some tests on a firewall system running Shorewall 1.4,
and
have been getting some unexpected behavior when enabling the
"newnotsyn"
option.
In the test setup, I have:
----------------------------------------
/etc/shorewall/interfaces
net eth0 detect routefilter,tcpflags,blacklist
loc eth1 10.0.0.255 dhcp,tcpflags,newnotsyn
dmz eth2 detect tcpflags
/etc/shorewall/policy
all all REJECT info
/etc/shorewall/rules
ACCEPT net:192.168.0.6 $FW tcp ssh -
/etc/shorewall/shorewall.conf
NEWNOTSYN=No
----------------------------------------
Note that "newnotsyn" is enabled on eth1 (loc). With this setup, I
expected
it to be impossible for any traffic to flow from nodes in "loc" to
those on
"net," however this is not the case. If I send TCP packets with the
ACK bit
set from a machine in on "loc" to arbitrary addresses on the
"net" using any
port at all, they go through, thanks to the "newnotsyn" option set on
the
"loc" interface. If I remove that option, such packets are stopped at
the
firewall.
Looking at the iptables rules, it''s clear why this is happening. The
newnotsyn chain is essentially a blanket ACCEPT of any newnotsyn traffic
from the loc zone:
12 480 ACCEPT tcp -- eth1 any anywhere anywhere
tcp flags:ACK/ACK
0 0 ACCEPT tcp -- eth1 any anywhere anywhere
tcp flags:RST/RST
0 0 ACCEPT tcp -- eth1 any anywhere anywhere
tcp flags:FIN/FIN
A second surprise was that, even if I modify my rules file to explicitly
block a particular port (2000 here):
----------------------------------------
ACCEPT net:192.168.0.6 $FW tcp ssh -
DROP:info loc net tcp 2000 -
----------------------------------------
if I then try to send packets from loc to port 2000 on the net (again with
the ACK bit set) these will go through, even though traffic to that port is
explicitly denied.
It seems like this behavior is not ideal, and could be exploited. Tests on
Shorewall 2.0 show the same thing.
As a workaround, I wondered if it would be possible to do away with the
newnotsyn chain, and instead, when newnotsyn is enabled on an interface (or
on all interfaces), modify the specification of each explicit ACCEPT rule
from those interfaces so that, in addition to implied NEW SYN traffic, NEW
packets with !SYN,ACK, !SYN,RST, !SYN,FIN are also allowed. That way,
newnotsyn traffic for otherwise acceptable ports would get through, but
nothing else. I guess this would bloat the rules quite a bit, but it seems
better than the observed behavior.
This is strange enough that I wonder if I have some basic misunderstanding
of the setup. If so, please let me know.
Thanks!
Tim
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
N Body wrote:> > As a workaround, I wondered if it would be possible to do away with the > newnotsyn chain, and instead, when newnotsyn is enabled on an interface > (or on all interfaces), modify the specification of each explicit ACCEPT > rule from those interfaces so that, in addition to implied NEW SYN > traffic, NEW packets with !SYN,ACK, !SYN,RST, !SYN,FIN are also allowed. > That way, newnotsyn traffic for otherwise acceptable ports would get > through, but nothing else. I guess this would bloat the rules quite a > bit, but it seems better than the observed behavior.A better approach is to replace the ACCEPT with RETURN in the ACK, RST and FIN rules in ''newnotsyn'' and do away with the blanket RETURN at the end. You can do that with this /etc/shorewall/newnotsyn file: run_iptables -F newnotsyn for interface in $(find_interfaces_by_option newnotsyn); do run_iptables -A newnotsyn -i $interface -p tcp --tcp-flags ACK ACK \ -j RETURN run_iptables -D newnotsyn -i $interface -p tcp --tcp-flags RST RST \ -j RETURN run_iptables -D newnotsyn -i $interface -p tcp --tcp-flags FIN FIN \ -j RETURN done> > This is strange enough that I wonder if I have some basic > misunderstanding of the setup. If so, please let me know.If I do anything to NEWNOTSYN/newnotsyn it will likely be to rip the whole %$#@ thing out. It has certainly been more trouble than it is worth. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> > If I do anything to NEWNOTSYN/newnotsyn it will likely be to rip the > whole %$#@ thing out. It has certainly been more trouble than it is worth. >Just a reminder that there is now a ''dropNonSyn'' builtin action in Shorewall 2.0 -- so can DROP newNotSyn packets in rules and don''t have to rely on the built-in features. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> Tom Eastep wrote: > >> >> If I do anything to NEWNOTSYN/newnotsyn it will likely be to rip the >> whole %$#@ thing out. It has certainly been more trouble than it is >> worth. >> > > Just a reminder that there is now a ''dropNonSyn'' builtin action in > Shorewall 2.0 -- so you can DROP newNotSyn packets in rules and don''t have > to rely on the built-in features. >So for example, if you want to drop New-Not-Syn packets from the net but allow them elsewhere, just set NEWNOTSYN=Yes in shorewall.conf and add this rule at the top of your rules file: dropNonSyn net all tcp -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> > dropNonSyn net all tcp >Creating an action to LOG New-not-syn is a little trickier: a) add ''LogNonSyn'' to /etc/shorewall/actions. b) Create an empty /etc/shorewall/actions.LogNonSyn c) Create /etc/shorewall/LogNonSyn containing: run_iptables -A LogNonSyn -p tcp ! syn \ -j LOG --log-prefix "Shorewall:LogNonSyn:LOG:" --log-level info or whatever... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> b) Create an empty /etc/shorewall/actions.LogNonSynMake that /etc/shorewall/action.LogNonSyn -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Hello!>A better approach is to replace the ACCEPT with RETURN in the ACK, RST and >FIN rules in ''newnotsyn'' and do away with the blanket RETURN at the end. >You can do that with this /etc/shorewall/newnotsyn file:Thanks very much! Your solution works like a charm! Tim _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus