-----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 ([EMAIL PROTECTED]), 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-----
