Linux Netfilter discussions
 help / color / mirror / Atom feed
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 :).


  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