[luau] TCP Packet filtering

MonMotha monmotha at indy.rr.com
Wed May 7 10:38:00 PDT 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben Beeson wrote:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 >
 > Aloha all,
 >
 >       I saw the following advisory today in the Linux Today news letter and was
 > wondering if the MonMotha firewall is effected by this behavior in its as
 > delivered form.
 >

I don't remember if the INVALID match matches those (it probably should, but I 
don't know if it does).

The problem arises in that the proper behavior for such a packet is (so I've 
been told; need to actually read the RFC) to reply as if only the SYN bit were 
set (that is, treat it as a normal connection attempt).  Many fw admins would 
think otherwise.

I don't use TCP flags at all (though I'm plannign to do so in an effort to 
combat nmap scans, such as SYN/FIN, XMAS, NULL [no flags], etc).  I rely on the 
state match for everything.  The vulneribility report does not seem to indicate 
if the iptables state match (including ESTABLISHED or INVALID) is affected at 
all.  If it is, the firewall is vulnerible.  If it is not, the firewall has a 
default drop policy so the port should remain closed (though it will probably, 
possibly erroniously, reply with a TCP reset...I'd have to go trace the path of 
the packet), or at least somehow unreachable.

Basically, the only thing I trust completely is the ESTABLISHED state.  If 
someone can convince the netfilter that a particular packet is part of an 
already established connection, it will be allowed through with little question 
(only BLACKHOLE will apply, and possibly DENY_ALL, if that still exists, again 
I'd have to check).  I do first run a state INVALID match on all packets, which 
will drop any packet the filter can't class (those not making a NEW connect, 
normally with the SYN flag ONLY set, and those not ESTABLISHED or making a new 
RELATED connection).

The RELATED state is pretty trusted as well, but only on high ports, pretty much 
eliminating the risk of this kind of thing (or, more commonly, a bug in a 
conntrack module) allowing access to a privilaged port (less than 1024) where 
most system services live.

Conclusion: If the netfilter itself is vulnerible (via the state match), then my 
script is. Otherwise, due to my default DROP policy and lack of use of explicit 
TCP flags matches, I shouldn't be vulnerible to this.  This vulneribility 
appears to be more of a "lazy admin" thing than an actual software issue.

If anyone DOES find a vulneribility in my firewall, please email me privately 
(monmotha at indy.rr.com), ecrypting using PGP is preferred (my keyid is 1B0390E 
and is on the keyservers).  I will correct the situation and issue a security 
alert ASAP in event of such a vulneribility.

- --MonMotha
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+uW8Lp/ynIBsDkOARApWTAJ94en7ubZPnGMMXRSR0uM5zy0EbPACfRa7c
Z9qfDyENEjDHxT7VQI4Fh9U=
=zXMD
-----END PGP SIGNATURE-----




More information about the LUAU mailing list