All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Newkirk <netfilter@newkirk.us>
To: Roy Sigurd Karlsbakk <roy@karlsbakk.net>
Cc: JUSTIN GERRY <JGERRY@butchers.com>, netfilter@lists.netfilter.org
Subject: Re: Trying to setup two ethernet cards with two websites
Date: Fri, 3 Jan 2003 11:25:59 -0500	[thread overview]
Message-ID: <200301031125.59596.netfilter@newkirk.us> (raw)
In-Reply-To: <2762500A-1F16-11D7-97EA-000393950CC2@karlsbakk.net>

On Friday 03 January 2003 07:23 am, Roy Sigurd Karlsbakk wrote:
> > If you trust that nothing on the box is or ever will connect that
> > you don't want to, then output chain can just have an ACCEPT policy.
> >  If you
> > want to lock down to make it harder for a trojan or such to
> > communicate back from the box, you can set a DROP policy, then:
> >
> > iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> just remember to allow incoming ICMP. Please? ICMP _is_ an integral
> part of IP, and shouldn't be blocked out!

The RELATED state does just this.  If you allow absolutely nothing in but 
tcp 80 and established, and absolutely nothing out but established, only 
the port 80 request and reply will get through.  If you also allow 
related out then so long as an 'established' connection exists then 
supplementary connections are accepted as well, like ICMP fragmentation 
control stuff.  The only /initial/ connection allowed in this 
mini-scenario is to destination port 80 with TCP, but once that 
connection is flowing then the server would be allowed to send related 
packets to the same client, even other ports or protocols, and they will 
get through regardless of whether they are explicitly accepted or 
explicitly dropped by the firewall.  That is the basic purpose of the 
RELATED state.  It's extended with helpers too consider things like FTP 
data to be related to FTP control, and the NAT functions are extended as 
well, but the whole idea of RELATED is to let through stuff that is, 
well, related.

j



  reply	other threads:[~2003-01-03 16:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-02 14:49 Trying to setup two ethernet cards with two websites JUSTIN GERRY
2003-01-02 15:21 ` Joel Newkirk
2003-01-03 12:23   ` Roy Sigurd Karlsbakk
2003-01-03 16:25     ` Joel Newkirk [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-02 20:25 JUSTIN GERRY
2003-01-02 20:36 ` Athanasius
2003-01-02 21:40 ` Rob Sterenborg
2003-01-03 12:23 ` Roy Sigurd Karlsbakk
2002-12-31 16:29 JUSTIN GERRY
2002-12-31 18:49 ` Roy Sigurd Karlsbakk

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=200301031125.59596.netfilter@newkirk.us \
    --to=netfilter@newkirk.us \
    --cc=JGERRY@butchers.com \
    --cc=netfilter@lists.netfilter.org \
    --cc=roy@karlsbakk.net \
    /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.