[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