Anything that wouldn't normally happen in a normal tcp exchange or that
violates the RFCs. A good example is all flags set. A real tcp message
would never do that according to how the tcp flags are supposed to be
used. There is also a bit of logic involved(e.g. Setting the SYN and FIN
bits on the same packet makes no sense in the context of a normal tcp
handshake.). Therefore, such a packet is either a test packet that was,
possibly, mistakenly allowed to get off of a local network somewhere, or
it is malicious. Given the potential damage(loss) that might occur if
you assume it is a test packet and it turns out to be malicious, the
safe bet is to assume it is malicious and drop the packet. You may wish
to investigate further, or you may simply prefer to keep anyone who is
sending out bad bit combos off of your network to avoid mucking up your
local network with a bunch of errors from malformed packets. To quote
Damon Runyon, "The race may not be always to the swift nor the battle to
the strong, but that's sure the way to bet." This is a man who would
have been quite at home with the idea of mathematical expectation as
applied to firewall security.
RD
Christian Seberino wrote:
RD
BTW, I did read about TCP Stealth Scans....seems there
really is only 4...
bare FIN scan (just FIN bit)
Xmas Tree scan (FIN, PSG and URG bits)
NULL scan (no flag bits)
Bogus scan (improper bit combos)
1st 3 are well defined.....last one is unclear
what falls under that type of scan.
Chris
On Tue, 2005-04-05 at 09:08, Robert Donovan wrote:
[EMAIL PROTECTED] wrote:
Why are these flag combos in iptables rules good to drop???
# Is the explanation for these because SYN starts a
# connection and it doesn't make sense to reset (RST)
# or terminate (FIN) at the same time your initiating (SYN)???
--tcp-flags SYN,RST SYN,RST -j DROP
--tcp-flags SYN,FIN SYN,FIN -j DROP
# Is this obvious in that you can't finish (FIN) and
# reset (RST) at the same time?
--tcp-flags FIN,RST FIN,RST -j DROP
# Can these be explained by simple fact that *ALL* packets
# must have ACK set after connection established?? Is that right?
# (if yes, could we add 'ACK,RST RST' to drop list as well?)
--tcp-flags ACK,FIN FIN -j DROP
--tcp-flags ACK,PSH PSH -j DROP
--tcp-flags ACK,URG URG -j DROP
Yes and yes. These packet settings are used in stealth atacks. The idea
is that firewalls block connections and connection attempts. Each of
these packets may get a response, but won't actually establish a
connection, and therefore, may not show up in the logs, particularly on
older firewalls that only check for the SYN and ACK flags. If neither
one is set, the firewall might just pass the packet through. Also,
tricking a host to send an error message can be used to map a network
behind a firewall. Hence the term, stealth scan.
What would DROP rule look like to protect against Xmas tree scan?
You'd want to drop packets with FIN, PSH and URG /all/ set right?
Thanks!
Chris
The following DROP rule should work for an xmas tree scan: iptables -A
INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
This rule tests for the ACK and FIN bits set, and will drop any packets
with the FIN bit set without the accompanying ACK. This includes the
case of an Xmas tree scan, in which you could have FIN-PSH, FIN-URG, and
FIN-PSH-URG with no accompanying ACK bit set. All of these would be
dropped by this rule.
You could also do separate rules testing for ACK,PSH,FIN FIN,PSH,
ACK,URG,FIN FIN,URG and ACK,PSH,URG,FIN FIN,PSH,URG if you have an
Adrian-Monk affinity for explicitly denying each Xmas tree packet type.
Robert Donovan
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
