Firewall question

thekillerbean · 08-06-2005, 05:46 PM

I was following a tutorial on setting up a Linux Firewall (iptables) and it worked flawlessly. However, I'm trying to understand what the following rule does:

Code:

-A bad_tcp_packets -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset

Could someone please explain what the -m state --state NEW means in the above rule? If I removed it from the rule, would all friendly connection attempts to my server fail?

Thanks.

Noth · 08-06-2005, 07:13 PM

"-m state --state new" tells iptables to use the state module and to only apply that rules to traffic belonging to NEW connections. Anything that is associated with a previous connection would fall under ESTABLISHED, RELATED or possibly INVALID.

thekillerbean · 08-26-2005, 06:24 AM

Okay, maybe I did not clearly state my problem with the rule:

why is the SYN,ACK SYN,ACK repeated twice in the rule?

Tia.

primo · 08-26-2005, 08:13 PM

This rule is an overkill example of many tutorials. They want to setup a rule for everything and they end up with redundant rules.

Quote:

-A bad_tcp_packets -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset
why is the SYN,ACK SYN,ACK repeated twice in the rule?

"SYN,ACK SYN,ACK" matchs any packet that has BOTH the SYN and ACK bits set, while "SYN,ACK ACK" matchs any packet with the ACK bit set, but the SYN bit off.
The first set are the bits to test... The second set specifies the bits that must be on. (You may think of it as being a subset of the former).

That rule is 2-times redundant, because of
1- From the nmap manpage:

Quote:

-sS TCP SYN scan: This technique is often referred to as "half-open"
scanning, because you don't open a full TCP connection. You send
a SYN packet, as if you are going to open a real connection and
you wait for a response. A SYN|ACK indicates the port is listen-
ing. A RST is indicative of a non-listener. If a SYN|ACK is
received, a RST is immediately sent to tear down the connection
(actually our OS kernel does this for us).

You don't need to implement a TCP/IP stack with your firewall rules...

2- This rule alone catchs many invalid combinations of TCP flags:
iptables -A bad_tcp -p tcp -m state --state INVALID -j DROP
(I prefer DROP to REJECT)
So you don't need to specify every combination of TCP flags under the sun....

My script uses this:

Quote:

${ipt} -N IN_TCP

# Log/Drop TCP SYN|FIN's
# This will foil the TCP/IP OS Fingerprinting done by Queso,
# and the SYN|FIN|PUSH|URG used by Nmap...
# Note: We need this rule here right before the next one, because no test
# is done for the FIN flag with the --syn option... Earlier iptables(8)
# manpages had a bug in which they stated that --syn will "only match
# TCP packets with the SYN bit set and the ACK and FIN bits cleared".
# This is a bug inherited from the ipchains(8) manpage.
# Really, --syn EQUALS --tcp-flags SYN,RST,ACK SYN
${ipt} -A IN_TCP -p tcp --tcp-flags SYN,FIN SYN,FIN -j ${X_INVALID}

# Make sure that only SYNs are accounted for NEW entries in the state table
# This will halt the FIN, FIN|URG|PUSH (Xmas) & ACK portscans
${ipt} -A IN_TCP -p tcp ! --syn $state NEW -j ${X_INVALID}

# Log/Drop INVALID TCP packets
# This will catch NULL TCP scans (-sN in nmap)
${ipt} -A IN_TCP -p tcp $state INVALID -j ${X_INVALID}

# Accept legitimate TCP traffic
${ipt} -A IN_TCP -p tcp $state ESTABLISHED,RELATED -j ACCEPT

thekillerbean · 08-27-2005, 01:59 AM

Thanks a ton, primo.

I apparently lost patience while reading the iptables manpage and did not scroll further down to see the explanation. I'm still in the early learning phases so I'm not very conversant with the commands available to me when using manpages.

I put in some effort today to learn (

) how to search through the manpages and hence found the explanation you have above.