From: Daniel Lopes <lopsch@lopsch.com>
To: netfilter@lists.netfilter.org
Subject: Re: Are these firewall rules impossible to understand?..........
Date: Fri, 11 Mar 2005 18:46:49 +0100 [thread overview]
Message-ID: <4231D989.5030408@lopsch.com> (raw)
In-Reply-To: <20050311171253.GA17683@spawar.navy.mil>
seberino@spawar.navy.mil schrieb:
> Smart firewallers drop packets based on funky TCP flag settings
> that suggest they are from network sniffers and other nasties.
>
> Many of these settings make sense, but, some are so funky I'm not
> sure even reading the RFCs would have explained them. If anyone
> has any suggestions on how one can understand the wisdom of all
> these rules I really want to know. (I want to understand
> EVERYTHING in my firewall script.)
>
> For example, see these from
> http://www.stearns.org/modwall/sample/tcpchk-sample
>
>
> /usr/bin/sudo /sbin/iptables -N tcpchk
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --sport 0:19 -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --dport 0:19 -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL ACK -m state --state ESTABLISHED -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL ACK -m state --state NEW,RELATED -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL PSH,ACK -m state --state ESTABLISHED -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL PSH,ACK -m state --state NEW -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL PSH,ACK -m state --state RELATED -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL NONE -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL ALL -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags RST,FIN RST,FIN -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags SYN,URG SYN,URG -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL SYN,PSH -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL SYN,ACK,PSH -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ACK,FIN FIN -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ACK,PSH PSH -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ACK,URG URG -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL RST -m state --state ESTABLISHED -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL RST -m state --state NEW,RELATED -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags SYN,ACK NONE -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL SYN -m state --state NEW -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL SYN -m state --state RELATED -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL SYN -m state --state ESTABLISHED -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL SYN,ACK -m state --state ESTABLISHED -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL SYN,ACK -m state --state NEW,RELATED -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL FIN,ACK -m state --state ESTABLISHED -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL FIN,ACK -m state --state NEW,RELATED -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL RST,ACK -m state --state ESTABLISHED -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL RST,ACK -m state --state NEW -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL RST,ACK -m state --state RELATED -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL ACK,PSH,RST -m state --state ESTABLISHED -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL ACK,PSH,RST -m state --state NEW,RELATED -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL FIN,PSH,ACK -m state --state ESTABLISHED -j RETURN
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL FIN,PSH,ACK -m state --state NEW,RELATED -j DROP
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL RST,ACK,PSH
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL RST,ACK,URG
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL RST,ACK,PSH,URG
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL FIN,PSH,ACK,URG
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL ACK,URG
> /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ALL ACK,URG,FIN
> /usr/bin/sudo /sbin/iptables -A INPUT -i ! lo -p tcp -j tcpchk
> /usr/bin/sudo /sbin/iptables -A FORWARD -p tcp -j tcpchk
> /usr/bin/sudo /sbin/iptables -A OUTPUT -p tcp -j tcpchk
>
>
>
> I'm skeptical ANYONE really understands all of these. The ones that really bug me are the ones that insist that all FIN, PSH and URG packets
> must have ACK set. Who would have know that?
>
> e.g. /usr/bin/sudo /sbin/iptables -A tcpchk -p tcp --tcp-flags ACK,FIN
> FIN -j DROP
>
>
> Chris
>
>
AFAIK in the RFC is not meant how TCP should react e.g. when FIN is sent
without ACK. So the reaction is given away to the implementation of the
network stack. By sending such packets and analysing the response you
can conclude what OS for example is being used because every stack
reacts in a different way. And every OS implements it in some different
way. So you intercept those packets and drop them. Not allowing TCP to
do its work you can block such conclusions. That´s the problem of TCP it
is described how to tear a connection down with FIN ACK packets but it
is not said what to do when a FIN comes without ACK.
Hope someone can confirm what I have written :).
next prev parent reply other threads:[~2005-03-11 17:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-11 17:12 Are these firewall rules impossible to understand? seberino
2005-03-11 17:46 ` Daniel Lopes [this message]
2005-03-11 18:59 ` Jason Opperisano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4231D989.5030408@lopsch.com \
--to=lopsch@lopsch.com \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox