All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Spenneberg <lists@spenneberg.org>
To: Michael K <micke@klintan.se>
Cc: 'Netfilter' <netfilter@lists.netfilter.org>
Subject: RE: discard TCP SYN
Date: 07 Aug 2003 07:50:16 +0200	[thread overview]
Message-ID: <1060235415.1886.2.camel@kermit> (raw)
In-Reply-To: <000001c35c39$ae1be1e0$c800a8c0@klintan.local>

Am Mit, 2003-08-06 um 18.42 schrieb Michael K:
> Thank you.
>  
> So iptables that uses connection-tracking is safe. And the old ipchains
> is not, including the old ipfwadm?
> Hurray for iptables :-)
Well, kind of. The old ipchains had a safe syn check. 
Manpage extract:
 -y, --syn       Only match TCP packets with the SYN bit set and the
              	  ACK and FIN bits cleared.

But when using iptables' connection tracking you are usually safe.

Cheers,

Ralf
> 
> /Klintan
> 
> > -----Original Message-----
> > From: netfilter-admin@lists.netfilter.org 
> > [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of 
> > Ralf Spenneberg
> > Sent: Wednesday, August 06, 2003 2:43 PM
> > To: Michael K
> > Cc: Netfilter
> > Subject: Re: discard TCP SYN
> > 
> > 
> > Am Mit, 2003-08-06 um 13.32 schrieb Michael K:
> > > My firewall have default policy to drop (in, out & fwd)
> > > Some protocols are open for communications, such as tcp/80, ftp/21 
> > > from the internet Then I use stateful inspection, accepting 
> > > estabished,related. However, the nessus scanner is reporting this:
> > > -----
> > > The remote host does not discard TCP SYN packets which
> > > have the FIN flag set.
> > > 
> > > Depending on the kind of firewall you are using, an
> > > attacker may use this flaw to bypass its rules.
> > 
> > The better solution would be to only accept SYN Packets which 
> > actually are SYN packets. iptables -A FORWARD -p tcp --syn -m 
> > state --state NEW -s whatever -j ACCEPT
> > 
> > But ....
> > This SYN/FIN stuff comes from an old packetfilter 
> > implementation which implemented a very simple SYN test: Is 
> > only the SYN-Bit set? Yes, then it is a SYN-packet! If you 
> > relied on this test to implement the firewall-rules on this 
> > non-stateful packetfilter, you would create two rules:
> > 
> > Allow everything from the inside to the outside including 
> > SYN. Allow everything from the outside to the inside but SYN.
> > 
> > Now, TCP-connection could only be initiated (meaning a SYN could be
> > send) from the inside, right? No, you could send a SYN from 
> > the outside, once you have figured out that you needed a 
> > second flag set. 
> > Well, I wonder what happens if you use SYN/FIN? The firewall 
> > passes it and most (all?) operating systems ignore the FIN 
> > and operate on the SYN. Connection Established!
> > 
> > Remember this is only possible on non-stateful packetfilters 
> > (read: These packetfilters do not use connection tracking)
> > 
> > Once you use connection tracking that code decides in which 
> > direction the connection is initiated. It is not just a 
> > matter of the SYN-packet.
> > 
> > Cheers,
> > 
> > Ralf
> > -- 
> > Ralf Spenneberg
> > RHCE, RHCX
> > 
> > Book: Intrusion Detection für Linux Server   http://www.spenneberg.com
> > IPsec-Howto				     http://www.ipsec-howto.org
> > Honeynet Project Mirror:                     
> > http://honeynet.spenneberg.org
> > 
> > 
-- 
Ralf Spenneberg
RHCE, RHCX

Book: Intrusion Detection für Linux Server   http://www.spenneberg.com
IPsec-Howto				     http://www.ipsec-howto.org
Honeynet Project Mirror:                     http://honeynet.spenneberg.org


      reply	other threads:[~2003-08-07  5:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-06 11:32 discard TCP SYN Michael K
2003-08-06 12:27 ` Cedric Blancher
2003-08-06 16:43   ` Michael
2003-08-06 12:43 ` Ralf Spenneberg
2003-08-06 16:42   ` Michael K
2003-08-07  5:50     ` Ralf Spenneberg [this message]

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=1060235415.1886.2.camel@kermit \
    --to=lists@spenneberg.org \
    --cc=micke@klintan.se \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.