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
next prev parent 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.