[EMAIL PROTECTED] wrote:
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.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
The following DROP rule should work for an xmas tree scan: iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROPWhat 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
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
