All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Loïc Minier" <lool+netfilter@via.ecp.fr>
To: Netfilter <netfilter@lists.netfilter.org>
Subject: Re: Connections with SYN aren't NEW
Date: Sun, 14 Dec 2003 18:24:08 +0100	[thread overview]
Message-ID: <20031214172408.GC897@via.ecp.fr> (raw)
In-Reply-To: <200312141654.41489.Antony@Soft-Solutions.co.uk>

Antony Stone <Antony@Soft-Solutions.co.uk> - Sun, Dec 14, 2003:

> What do you gain from having them match NEW, which isn't already true if they 
> match --syn?

 Frankly speaking, I am not certain of the true benefits I will ever
 enjoy of forcing both NEW and --syn. But the topic of where to place
 the limit in the types of traffic you accept would be too much of a
 troll to discuss here... ;)
   I see the TCP flags and the conntrack as two different providers for
 the information "this is a new TCP connections". I think I should only
 believe a new connection takes place when both agree, because my goal
 is to stop suspicious traffic.

 As a dumb example of traffic I could reject with such a rule, I could
 take an injected SYN packet in the middle of a real TCP connection
 generating a tcp-reset and effectively closing the connection. This
 could be an efficient manner of closing a connection in a way which
 couldn't easily be seen. Call me paranoid, I prefer to call myself
 ignorant of what somebody could do if I don't disallow this :)

 Is this clear enough? or too far-fetched?

   Sincerely,

-- 
Loïc Minier <lool@dooz.org>


      reply	other threads:[~2003-12-14 17:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-14 16:23 Connections with SYN aren't NEW Loïc Minier
2003-12-14 16:34 ` Antony Stone
2003-12-14 16:59   ` Loïc Minier
2003-12-14 16:54 ` Antony Stone
2003-12-14 17:24   ` Loïc Minier [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=20031214172408.GC897@via.ecp.fr \
    --to=lool+netfilter@via.ecp.fr \
    --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.