* RE: how is this stuff getting thru default deny iptables firewall?....
@ 2002-06-22 21:43 James T. Moore
2002-06-23 7:13 ` Christian Seberino
0 siblings, 1 reply; 16+ messages in thread
From: James T. Moore @ 2002-06-22 21:43 UTC (permalink / raw)
To: seberino; +Cc: netfilter
Chris,
My guess would be that the firewall is allowing reponses to connections
that are already established, but its impossible to say for sure without
seeing the script used to create the firewall.
Here is an example:
$IPTABLES -A FORWARD -o $INET_IFACE -d $DNS_SERV1 -s $PRIV_LAN -p
udp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -i $INET_IFACE -s $DNS_SERV1 -d $PRIV_LAN -p
udp --sport 53 -m state --state ESTABLISHED -j ACCEPT
The first rule allows the clients on the private LAN to query the dns
server. These packets can be part of a new or established connection so the
clients can create new connections to connect to the DNS server.
The second rule allows the DNS server to respond to the clients' request.
These packets can only be part of an established connection so the DNS
server (or any other host) can not create a new connection into the private
LAN unless there are other rules to allow it.
J.T.
>Date: Sat, 22 Jun 2002 10:30:55 -0700
>From: Christian Seberino <seberino@spawar.navy.mil>
>To: netfilter@lists.samba.org
>Subject: how is this stuff getting thru default deny iptables firewall?....
>
>My firewall *only* forwards SSH stuff to private LAN.
>
>It forwards *everything* _from_ private LAN to Internet however.
>
>How can the private LAN use DNS which it does????
>
>How is DNS server returning the info thru firewall
>if it *only* allows SSH??!?!?!?
>
>Chris
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: how is this stuff getting thru default deny iptables firewall?....
2002-06-22 21:43 how is this stuff getting thru default deny iptables firewall? James T. Moore
@ 2002-06-23 7:13 ` Christian Seberino
0 siblings, 0 replies; 16+ messages in thread
From: Christian Seberino @ 2002-06-23 7:13 UTC (permalink / raw)
To: James T. Moore; +Cc: netfilter
James
Thanks, I sent rule set to thread in another email.
I don't have anything with ESTABLISHED or RELATED in it.
Chris
On Sat, Jun 22, 2002 at 05:43:22PM -0400, James T. Moore wrote:
> Chris,
>
> My guess would be that the firewall is allowing reponses to connections
> that are already established, but its impossible to say for sure without
> seeing the script used to create the firewall.
>
> Here is an example:
>
> $IPTABLES -A FORWARD -o $INET_IFACE -d $DNS_SERV1 -s $PRIV_LAN -p
> udp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
>
> $IPTABLES -A FORWARD -i $INET_IFACE -s $DNS_SERV1 -d $PRIV_LAN -p
> udp --sport 53 -m state --state ESTABLISHED -j ACCEPT
>
>
> The first rule allows the clients on the private LAN to query the dns
> server. These packets can be part of a new or established connection so the
> clients can create new connections to connect to the DNS server.
>
> The second rule allows the DNS server to respond to the clients' request.
> These packets can only be part of an established connection so the DNS
> server (or any other host) can not create a new connection into the private
> LAN unless there are other rules to allow it.
>
>
> J.T.
>
>
>
>
> >Date: Sat, 22 Jun 2002 10:30:55 -0700
> >From: Christian Seberino <seberino@spawar.navy.mil>
> >To: netfilter@lists.samba.org
> >Subject: how is this stuff getting thru default deny iptables firewall?....
> >
> >My firewall *only* forwards SSH stuff to private LAN.
> >
> >It forwards *everything* _from_ private LAN to Internet however.
> >
> >How can the private LAN use DNS which it does????
> >
> >How is DNS server returning the info thru firewall
> >if it *only* allows SSH??!?!?!?
> >
> >Chris
--
_______________________________________
Dr. Christian Seberino
SPAWAR Systems Center San Diego
Code 2363
53560 Hull Street
San Diego, CA 92152-5001
U.S.A.
Phone: (619) 553-7940
Fax: (619) 553-2836
Email: seberino@spawar.navy.mil
_______________________________________
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: how is this stuff getting thru default deny iptables firewall?....
@ 2002-07-09 19:43 j davis
2002-07-09 21:41 ` Christian Seberino
2002-07-09 21:43 ` Christian Seberino
0 siblings, 2 replies; 16+ messages in thread
From: j davis @ 2002-07-09 19:43 UTC (permalink / raw)
To: netfilter
ipchains is not stateful so it doesnt need contrak...right?
jd
>From: Christian Seberino <seberino@spawar.navy.mil>
>To: Patrick Schaaf <bof@bof.de>
>CC: netfilter@lists.samba.org
>Subject: Re: how is this stuff getting thru default deny iptables
>firewall?....
>Date: Tue, 9 Jul 2002 12:08:52 -0700
>MIME-Version: 1.0
>Received: from [198.186.203.85] by hotmail.com (3.2) with ESMTP id
>MHotMailBEF485390058400431CEC6BACB5599E90; Tue, 09 Jul 2002 12:32:25 -0700
>Received: from va.samba.org (localhost [127.0.0.1])by lists.samba.org
>(Postfix) with ESMTPid BD14F424A; Tue, 9 Jul 2002 12:32:11 -0700 (PDT)
>Received: from dt092n42.san.rr.com (dt092n42.san.rr.com [204.210.48.66])by
>lists.samba.org (Postfix) with ESMTP id 8B4534A48for
><netfilter@lists.samba.org>; Tue, 9 Jul 2002 12:07:26 -0700 (PDT)
>Received: from seberino by dt092n42.san.rr.com with local (Exim 3.32 #1)id
>17S0M0-0006ST-00; Tue, 09 Jul 2002 12:08:52 -0700
From netfilter-admin@lists.samba.org Tue, 09 Jul 2002 12:33:44 -0700
>Delivered-To: netfilter@lists.samba.org
>Message-ID: <20020709120852.A24804@spawar.navy.mil>
>References: <20020622103055.B32585@spawar.navy.mil>
><20020622173842.AGM19225.mta07-svc.ntlworld.com@there>
><20020623001302.A949@spawar.navy.mil> <20020623095351.M5183@oknodo.bof.de>
><20020627002144.B13910@spawar.navy.mil>
><20020627093730.C1873@oknodo.bof.de>
>User-Agent: Mutt/1.2.5i
>In-Reply-To: <20020627093730.C1873@oknodo.bof.de>; from bof@bof.de on Thu,
>Jun 27, 2002 at 09:37:30AM +0200
>Sender: netfilter-admin@lists.samba.org
>Errors-To: netfilter-admin@lists.samba.org
>X-BeenThere: netfilter@lists.samba.org
>X-Mailman-Version: 2.0.8
>Precedence: bulk
>List-Help: <mailto:netfilter-request@lists.samba.org?subject=help>
>List-Post: <mailto:netfilter@lists.samba.org>
>List-Subscribe:
><http://lists.samba.org/listinfo/netfilter>,<mailto:netfilter-request@lists.samba.org?subject=subscribe>
>List-Id: netfilter user discussion list <netfilter.lists.samba.org>
>List-Unsubscribe:
><http://lists.samba.org/listinfo/netfilter>,<mailto:netfilter-request@lists.samba.org?subject=unsubscribe>
>List-Archive: <http://lists.samba.org/pipermail/netfilter/>
>
> > On the other hand, if there is not yet a conntrack record in existence
> > for the packet, the nat PREROUTING table is consulted
>
>Patrick
>
>I appreciate all your help and after thinking about this on my vacation
>last week I think I got it now thanks to your feedback!
>Can I ask you few questions to verify I got what you said regarding
>how a private LAN can use DNS, HTTP, SMTP, etc. thru an SSH-only
>firewall?...
>
>My main confusion I believe was that packets associated with preexisting
>conntracks are handled differently than packets *not* associated
>with a previous conntrack.
>
>Q1: The conntrack is the "memory" of netfilter that allows it to make
>decisions based on "history" of PC traffic right?
>
>Q2: Packets with a previous associated conntrack are handled *differently*
>than ones
>without previous conntrack... and any attempt to try to understand
>behavior of firewall *without* this concept is doomed
>to confusion right?
>
>Q3: Is conntrack a new "iptables only" feature? I imagine ancient
>ipchains/ipfwadmin
>would have had same issues and therefore would need something like
>"conntrack" to work correctly right?
>
>Sincerely,
>
>Chris
>--
>_______________________________________
>
>Dr. Christian Seberino
>SPAWAR Systems Center San Diego
>Code 2363
>53560 Hull Street
>San Diego, CA 92152-5001
>U.S.A.
>
>Phone: (619) 553-7940
>Fax: (619) 553-2836
>Email: seberino@spawar.navy.mil
>_______________________________________
>
thanks,
jd
jd@taproot.bz
http://www.taproot.bz
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: how is this stuff getting thru default deny iptables firewall?....
2002-07-09 19:43 j davis
@ 2002-07-09 21:41 ` Christian Seberino
2002-07-09 21:43 ` Christian Seberino
1 sibling, 0 replies; 16+ messages in thread
From: Christian Seberino @ 2002-07-09 21:41 UTC (permalink / raw)
To: j davis; +Cc: netfilter
I read somewhere that ipchains is not stateful so I agree
but yet.. then it would seem that ipchains would have
the problem associated with this thread then!
(i.e. you could not do DNS, HTTP, SMTP, etc. from private
LAN with an ipchains SSH-only Firewall!?!?!?!?)
Chris
On Tue, Jul 09, 2002 at 07:43:42PM +0000, j davis wrote:
>
> ipchains is not stateful so it doesnt need contrak...right?
> jd
>
> >From: Christian Seberino <seberino@spawar.navy.mil>
> >To: Patrick Schaaf <bof@bof.de>
> >CC: netfilter@lists.samba.org
> >Subject: Re: how is this stuff getting thru default deny iptables
> >firewall?....
> >Date: Tue, 9 Jul 2002 12:08:52 -0700
> >MIME-Version: 1.0
> >Received: from [198.186.203.85] by hotmail.com (3.2) with ESMTP id
> >MHotMailBEF485390058400431CEC6BACB5599E90; Tue, 09 Jul 2002 12:32:25 -0700
> >Received: from va.samba.org (localhost [127.0.0.1])by lists.samba.org
> >(Postfix) with ESMTPid BD14F424A; Tue, 9 Jul 2002 12:32:11 -0700 (PDT)
> >Received: from dt092n42.san.rr.com (dt092n42.san.rr.com [204.210.48.66])by
> >lists.samba.org (Postfix) with ESMTP id 8B4534A48for
> ><netfilter@lists.samba.org>; Tue, 9 Jul 2002 12:07:26 -0700 (PDT)
> >Received: from seberino by dt092n42.san.rr.com with local (Exim 3.32 #1)id
> >17S0M0-0006ST-00; Tue, 09 Jul 2002 12:08:52 -0700
> >From netfilter-admin@lists.samba.org Tue, 09 Jul 2002 12:33:44 -0700
> >Delivered-To: netfilter@lists.samba.org
> >Message-ID: <20020709120852.A24804@spawar.navy.mil>
> >References: <20020622103055.B32585@spawar.navy.mil>
> ><20020622173842.AGM19225.mta07-svc.ntlworld.com@there>
> ><20020623001302.A949@spawar.navy.mil> <20020623095351.M5183@oknodo.bof.de>
> ><20020627002144.B13910@spawar.navy.mil>
> ><20020627093730.C1873@oknodo.bof.de>
> >User-Agent: Mutt/1.2.5i
> >In-Reply-To: <20020627093730.C1873@oknodo.bof.de>; from bof@bof.de on Thu,
> >Jun 27, 2002 at 09:37:30AM +0200
> >Sender: netfilter-admin@lists.samba.org
> >Errors-To: netfilter-admin@lists.samba.org
> >X-BeenThere: netfilter@lists.samba.org
> >X-Mailman-Version: 2.0.8
> >Precedence: bulk
> >List-Help: <mailto:netfilter-request@lists.samba.org?subject=help>
> >List-Post: <mailto:netfilter@lists.samba.org>
> >List-Subscribe:
> ><http://lists.samba.org/listinfo/netfilter>,<mailto:netfilter-request@lists.samba.org?subject=subscribe>
> >List-Id: netfilter user discussion list <netfilter.lists.samba.org>
> >List-Unsubscribe:
> ><http://lists.samba.org/listinfo/netfilter>,<mailto:netfilter-request@lists.samba.org?subject=unsubscribe>
> >List-Archive: <http://lists.samba.org/pipermail/netfilter/>
> >
> > > On the other hand, if there is not yet a conntrack record in existence
> > > for the packet, the nat PREROUTING table is consulted
> >
> >Patrick
> >
> >I appreciate all your help and after thinking about this on my vacation
> >last week I think I got it now thanks to your feedback!
> >Can I ask you few questions to verify I got what you said regarding
> >how a private LAN can use DNS, HTTP, SMTP, etc. thru an SSH-only
> >firewall?...
> >
> >My main confusion I believe was that packets associated with preexisting
> >conntracks are handled differently than packets *not* associated
> >with a previous conntrack.
> >
> >Q1: The conntrack is the "memory" of netfilter that allows it to make
> >decisions based on "history" of PC traffic right?
> >
> >Q2: Packets with a previous associated conntrack are handled *differently*
> >than ones
> >without previous conntrack... and any attempt to try to understand
> >behavior of firewall *without* this concept is doomed
> >to confusion right?
> >
> >Q3: Is conntrack a new "iptables only" feature? I imagine ancient
> >ipchains/ipfwadmin
> >would have had same issues and therefore would need something like
> >"conntrack" to work correctly right?
> >
> >Sincerely,
> >
> >Chris
> >--
> >_______________________________________
> >
> >Dr. Christian Seberino
> >SPAWAR Systems Center San Diego
> >Code 2363
> >53560 Hull Street
> >San Diego, CA 92152-5001
> >U.S.A.
> >
> >Phone: (619) 553-7940
> >Fax: (619) 553-2836
> >Email: seberino@spawar.navy.mil
> >_______________________________________
> >
>
>
> thanks,
> jd
>
> jd@taproot.bz
> http://www.taproot.bz
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
--
_______________________________________
Dr. Christian Seberino
SPAWAR Systems Center San Diego
Code 2363
53560 Hull Street
San Diego, CA 92152-5001
U.S.A.
Phone: (619) 553-7940
Fax: (619) 553-2836
Email: seberino@spawar.navy.mil
_______________________________________
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: how is this stuff getting thru default deny iptables firewall?....
2002-07-09 19:43 j davis
2002-07-09 21:41 ` Christian Seberino
@ 2002-07-09 21:43 ` Christian Seberino
[not found] ` <Pine.LNX.4.33.0207101903030.1723-100000@dodobirdy.nestac.com>
1 sibling, 1 reply; 16+ messages in thread
From: Christian Seberino @ 2002-07-09 21:43 UTC (permalink / raw)
To: j davis; +Cc: netfilter
With no conntrack how would ipchains know to treat
packets of an ESTABLISHED connection differently?
CS
On Tue, Jul 09, 2002 at 07:43:42PM +0000, j davis wrote:
>
> ipchains is not stateful so it doesnt need contrak...right?
> jd
>
> >From: Christian Seberino <seberino@spawar.navy.mil>
> >To: Patrick Schaaf <bof@bof.de>
> >CC: netfilter@lists.samba.org
> >Subject: Re: how is this stuff getting thru default deny iptables
> >firewall?....
> >Date: Tue, 9 Jul 2002 12:08:52 -0700
> >MIME-Version: 1.0
> >Received: from [198.186.203.85] by hotmail.com (3.2) with ESMTP id
> >MHotMailBEF485390058400431CEC6BACB5599E90; Tue, 09 Jul 2002 12:32:25 -0700
> >Received: from va.samba.org (localhost [127.0.0.1])by lists.samba.org
> >(Postfix) with ESMTPid BD14F424A; Tue, 9 Jul 2002 12:32:11 -0700 (PDT)
> >Received: from dt092n42.san.rr.com (dt092n42.san.rr.com [204.210.48.66])by
> >lists.samba.org (Postfix) with ESMTP id 8B4534A48for
> ><netfilter@lists.samba.org>; Tue, 9 Jul 2002 12:07:26 -0700 (PDT)
> >Received: from seberino by dt092n42.san.rr.com with local (Exim 3.32 #1)id
> >17S0M0-0006ST-00; Tue, 09 Jul 2002 12:08:52 -0700
> >From netfilter-admin@lists.samba.org Tue, 09 Jul 2002 12:33:44 -0700
> >Delivered-To: netfilter@lists.samba.org
> >Message-ID: <20020709120852.A24804@spawar.navy.mil>
> >References: <20020622103055.B32585@spawar.navy.mil>
> ><20020622173842.AGM19225.mta07-svc.ntlworld.com@there>
> ><20020623001302.A949@spawar.navy.mil> <20020623095351.M5183@oknodo.bof.de>
> ><20020627002144.B13910@spawar.navy.mil>
> ><20020627093730.C1873@oknodo.bof.de>
> >User-Agent: Mutt/1.2.5i
> >In-Reply-To: <20020627093730.C1873@oknodo.bof.de>; from bof@bof.de on Thu,
> >Jun 27, 2002 at 09:37:30AM +0200
> >Sender: netfilter-admin@lists.samba.org
> >Errors-To: netfilter-admin@lists.samba.org
> >X-BeenThere: netfilter@lists.samba.org
> >X-Mailman-Version: 2.0.8
> >Precedence: bulk
> >List-Help: <mailto:netfilter-request@lists.samba.org?subject=help>
> >List-Post: <mailto:netfilter@lists.samba.org>
> >List-Subscribe:
> ><http://lists.samba.org/listinfo/netfilter>,<mailto:netfilter-request@lists.samba.org?subject=subscribe>
> >List-Id: netfilter user discussion list <netfilter.lists.samba.org>
> >List-Unsubscribe:
> ><http://lists.samba.org/listinfo/netfilter>,<mailto:netfilter-request@lists.samba.org?subject=unsubscribe>
> >List-Archive: <http://lists.samba.org/pipermail/netfilter/>
> >
> > > On the other hand, if there is not yet a conntrack record in existence
> > > for the packet, the nat PREROUTING table is consulted
> >
> >Patrick
> >
> >I appreciate all your help and after thinking about this on my vacation
> >last week I think I got it now thanks to your feedback!
> >Can I ask you few questions to verify I got what you said regarding
> >how a private LAN can use DNS, HTTP, SMTP, etc. thru an SSH-only
> >firewall?...
> >
> >My main confusion I believe was that packets associated with preexisting
> >conntracks are handled differently than packets *not* associated
> >with a previous conntrack.
> >
> >Q1: The conntrack is the "memory" of netfilter that allows it to make
> >decisions based on "history" of PC traffic right?
> >
> >Q2: Packets with a previous associated conntrack are handled *differently*
> >than ones
> >without previous conntrack... and any attempt to try to understand
> >behavior of firewall *without* this concept is doomed
> >to confusion right?
> >
> >Q3: Is conntrack a new "iptables only" feature? I imagine ancient
> >ipchains/ipfwadmin
> >would have had same issues and therefore would need something like
> >"conntrack" to work correctly right?
> >
> >Sincerely,
> >
> >Chris
> >--
> >_______________________________________
> >
> >Dr. Christian Seberino
> >SPAWAR Systems Center San Diego
> >Code 2363
> >53560 Hull Street
> >San Diego, CA 92152-5001
> >U.S.A.
> >
> >Phone: (619) 553-7940
> >Fax: (619) 553-2836
> >Email: seberino@spawar.navy.mil
> >_______________________________________
> >
>
>
> thanks,
> jd
>
> jd@taproot.bz
> http://www.taproot.bz
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
--
_______________________________________
Dr. Christian Seberino
SPAWAR Systems Center San Diego
Code 2363
53560 Hull Street
San Diego, CA 92152-5001
U.S.A.
Phone: (619) 553-7940
Fax: (619) 553-2836
Email: seberino@spawar.navy.mil
_______________________________________
^ permalink raw reply [flat|nested] 16+ messages in thread
* how is this stuff getting thru default deny iptables firewall?....
@ 2002-06-22 17:30 Christian Seberino
2002-06-22 17:38 ` Antony Stone
0 siblings, 1 reply; 16+ messages in thread
From: Christian Seberino @ 2002-06-22 17:30 UTC (permalink / raw)
To: netfilter
My firewall *only* forwards SSH stuff to private LAN.
It forwards *everything* _from_ private LAN to Internet however.
How can the private LAN use DNS which it does????
How is DNS server returning the info thru firewall
if it *only* allows SSH??!?!?!?
Chris
--
_______________________________________
Dr. Christian Seberino
SPAWAR Systems Center San Diego
Code 2363
53560 Hull Street
San Diego, CA 92152-5001
U.S.A.
Phone: (619) 553-7940
Fax: (619) 553-2836
Email: seberino@spawar.navy.mil
_______________________________________
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: how is this stuff getting thru default deny iptables firewall?....
2002-06-22 17:30 Christian Seberino
@ 2002-06-22 17:38 ` Antony Stone
2002-06-23 7:13 ` Christian Seberino
0 siblings, 1 reply; 16+ messages in thread
From: Antony Stone @ 2002-06-22 17:38 UTC (permalink / raw)
To: netfilter
On Saturday 22 June 2002 6:30 pm, Christian Seberino wrote:
> My firewall *only* forwards SSH stuff to private LAN.
>
> It forwards *everything* _from_ private LAN to Internet however.
>
> How can the private LAN use DNS which it does????
>
> How is DNS server returning the info thru firewall
> if it *only* allows SSH??!?!?!?
Do you have a rule allowing reply packets from, say, a website back to your
internal clients ?
Maybe:
iptables -A FORWARD -i $EXTIF -m state --state RELATED,ESTABLISHED -j ACCEPT
Same rule will allow replies to DNS requests.
If you don't have anything like that, post your ruleset and we'll have a
think about it.
Antony.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: how is this stuff getting thru default deny iptables firewall?....
2002-06-22 17:38 ` Antony Stone
@ 2002-06-23 7:13 ` Christian Seberino
2002-06-23 7:53 ` Patrick Schaaf
2002-06-23 8:07 ` Antony Stone
0 siblings, 2 replies; 16+ messages in thread
From: Christian Seberino @ 2002-06-23 7:13 UTC (permalink / raw)
To: Antony Stone; +Cc: netfilter
Antony
Thanks again.
Here is my rule set... it is preceded by the usual stuff
like flushing chains, dropping certain classes of packets, etc.
These are the *only* rules with "-j ACCEPT" in my entire firewall script
and somehow DNS sneaks thru...
$PROTECTED_NETWORK = 192.168.0.0/29
$PROTECTED_NETWORK_SPACE = 192.168.0.0/16
...
# Allow all thru loopback.
$IPTABLES -t filter -A INPUT -i $LOOPBACK_INTERFACE -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $LOOPBACK_INTERFACE -j ACCEPT
# Only SSH from Internet but anything *to* Internet.
$IPTABLES -t filter -A FORWARD -i $INTERNET_INTERFACE \
-s ! $PROTECTED_NETWORK_SPACE -d $PROTECTED_PC_IP_ADDRESS \
-p tcp --dport $SSH_PORT \
-j ACCEPT
$IPTABLES -t filter -A FORWARD -o $INTERNET_INTERFACE \
-s $PROTECTED_NETWORK -d ! $PROTECTED_NETWORK_SPACE \
-j ACCEPT
# Allow all thru priviate LAN NIC.
$IPTABLES -t filter -A FORWARD -i $PROTECTED_NETWORK_INTERFACE \
-s $PROTECTED_NETWORK -d ! $PROTECTED_NETWORK_SPACE \
-j ACCEPT
$IPTABLES -t filter -A FORWARD -o $PROTECTED_NETWORK_INTERFACE \
-s ! $PROTECTED_NETWORK_SPACE -d $PROTECTED_NETWORK \
-j ACCEPT
# The usual NAT stuff here.
$IPTABLES -t nat -A PREROUTING -i $INTERNET_INTERFACE \
-s ! $PROTECTED_NETWORK_SPACE -d $INTERNET_IP_ADDRESS \
-p tcp --dport $SSH_PORT \
-j DNAT --to-destination $PROTECTED_PC_IP_ADDRESS
$IPTABLES -t nat -A POSTROUTING -o $INTERNET_INTERFACE \
-s $PROTECTED_NETWORK -d ! $PROTECTED_NETWORK_SPACE \
-j SNAT --to-source $INTERNET_IP_ADDRESS
I don't have *anything* with ESTABLISHED or RELATED that would allow
DNS to sneak in...... *but it does*!?!?!?!?
Chris
On Sat, Jun 22, 2002 at 06:38:40PM +0100, Antony Stone wrote:
> On Saturday 22 June 2002 6:30 pm, Christian Seberino wrote:
>
> > My firewall *only* forwards SSH stuff to private LAN.
> >
> > It forwards *everything* _from_ private LAN to Internet however.
> >
> > How can the private LAN use DNS which it does????
> >
> > How is DNS server returning the info thru firewall
> > if it *only* allows SSH??!?!?!?
>
> Do you have a rule allowing reply packets from, say, a website back to your
> internal clients ?
>
> Maybe:
>
> iptables -A FORWARD -i $EXTIF -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> Same rule will allow replies to DNS requests.
>
> If you don't have anything like that, post your ruleset and we'll have a
> think about it.
>
>
>
> Antony.
--
_______________________________________
Dr. Christian Seberino
SPAWAR Systems Center San Diego
Code 2363
53560 Hull Street
San Diego, CA 92152-5001
U.S.A.
Phone: (619) 553-7940
Fax: (619) 553-2836
Email: seberino@spawar.navy.mil
_______________________________________
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: how is this stuff getting thru default deny iptables firewall?....
2002-06-23 7:13 ` Christian Seberino
@ 2002-06-23 7:53 ` Patrick Schaaf
2002-06-27 7:21 ` Christian Seberino
2002-06-23 8:07 ` Antony Stone
1 sibling, 1 reply; 16+ messages in thread
From: Patrick Schaaf @ 2002-06-23 7:53 UTC (permalink / raw)
To: Christian Seberino; +Cc: Antony Stone, netfilter
Hi Christian,
I'll venture a guess. If I understand your question, you want to know
why a machine in $PROTECTED_NETWORK is able to make DNS queries
to a DNS server on the outside.
ESTABLISHED/RELATED were kind of a red herring. What you need to
understand, is that
I)
When you use the "nat" table, you get "conntrack" underneath.
II)
when a routed packet does not already have a "conntrack",
it gets a new one, and the "nat" table is consulted.
III)
In case B), when a DNAT or SNAT target hits in the "nat" chain,
it modifies the new "conntrack" to remember how to manipulate
the packet.
IV)
Otherwise, when a routed packet already has a "conntrack"
entry, the "nat" table is NOT consulted. Instead, the
conntrack data structure determines whether the packet
has to be modified for NAT.
Now here's what happens when an internal IP address, let's call it PAUL,
queries an outside DNS server, called DNS. Here is the processing done
on your firewall for the request packet from PAUL to DNS:
1) a packet with source PAUL and destination DNS / udp port 53,
arrives at the internal interface of your firewall.
2) it is an unknown connection, so a new conntrack entry is created.
3) the PREROUTING nat chain does not specify a NAT action, so none
is set up at that point.
4) the network stack makes a routing decision. The packet is to
be routed out INTERNET_INTERFACE. Thus, it will pass through
the filter table's FORWARD chain.
5) your second filter table FORWARD rule permits the packet to pass,
as it is routed out INTERNET_INTERFACE, comes from the
PROTECTED_NETWORK, and goes to somewhere else. ACCEPT.
6) before hitting the wire, now the packet has to finally pass
through the nat table's POSTROUTING chain. There, you have
a nice rule which SNATs the internal IP address to the outside
IP address of your firewall. PAUL becomes INTERNET_IP_ADDRESS.
As explained above, this _also_ primes the "conntrack" from
step 2) to make the reverse modification when the packet
hears back from DNS.
So now, a packet is travelling the internet from INTERNET_IP_ADDRESS to
DNS, and eventually, DNS will reply. Here is what happens when the
reply packet comes back in INTERNET_INTERFACE of your firewall:
A) A packet with source DNS and destination INTERNET_IP_ADDRESS,
type udp, and destination port 53, arrives at the external
interface of your firewall.
B) First, the conntracking finds the "conntrack" set up in step 6)
C) Because step 6) marked the "conntrack" appropriately, the dest
IP address, which is INTERNET_IP_ADDRESS, is modified to be PAUL.
NOTE: this is NOT done with explicit new rules in the "nat"
table. The "nat" table is NOT consulted for "second or more"
packet of an existing conntrack.
D) The networking stack makes a routing decision. The destination
IP address is PAUL, so the packet will be routed out the internal
interface of your firewall. But it will first pass through the
FORWARD chain.
E) Your fourth filter table FORWARD rule permits the packet to pass:
it goes out PROTECTED_NETWORK_INTERFACE, comes from an outside IP,
and goes to PROTECTED_NETWORK (PAUL, to be exact). ACCEPT.
F) Before hitting the wire, now the packet has to finally pass
through the nat table's POSTROUTING chain. But no more harm
is done, no rule there matches our packet.
So finally, PAUL hears back from DNS.
I hope I got everything correct; people please flame me if not.
best regards
Patrick
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: how is this stuff getting thru default deny iptables firewall?....
2002-06-23 7:53 ` Patrick Schaaf
@ 2002-06-27 7:21 ` Christian Seberino
2002-06-27 7:37 ` Patrick Schaaf
0 siblings, 1 reply; 16+ messages in thread
From: Christian Seberino @ 2002-06-27 7:21 UTC (permalink / raw)
To: Patrick Schaaf; +Cc: netfilter
Patrick
Wow, were getting into the deep nitty gritty now!...
> The "nat" table is NOT consulted for "second or more"
> packet of an existing conntrack.
I needed to sit down and get a glass of water for this one.
This is one to lose sleep over....
I thought /ALL/ packets first went thru -t nat PREROUTING
and then -t filter and then -t nat POSTROUTING.
"of an existing conntrack" seems to be the same
as an ESTABLISHED packet....
*If I did not explicitly allow ESTABLISHED & RELATED
packets thru FORWARD chain then how can they pass?!?*
It almost seems like there is some hard coded ACCEPT
rules implied in iptables that you can't turn off!?!???
Is this correct to summarize?
0. conntrack = ESTABLISHED
1. ESTABLISHED packets don't have to deal with -t nat table.
2. Somehow I don't have to ACCEPT these ESTABLISHED packets
for them to go thru?!?!?
Chris
--
_______________________________________
Dr. Christian Seberino
SPAWAR Systems Center San Diego
Code 2363
53560 Hull Street
San Diego, CA 92152-5001
U.S.A.
Phone: (619) 553-7940
Fax: (619) 553-2836
Email: seberino@spawar.navy.mil
_______________________________________
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: how is this stuff getting thru default deny iptables firewall?....
2002-06-27 7:21 ` Christian Seberino
@ 2002-06-27 7:37 ` Patrick Schaaf
2002-07-09 19:08 ` Christian Seberino
0 siblings, 1 reply; 16+ messages in thread
From: Patrick Schaaf @ 2002-06-27 7:37 UTC (permalink / raw)
To: Christian Seberino; +Cc: netfilter
> > The "nat" table is NOT consulted for "second or more"
> > packet of an existing conntrack.
>
> I thought /ALL/ packets first went thru -t nat PREROUTING
> and then -t filter and then -t nat POSTROUTING.
No, that's not the case. I'll try again explaining that path slowly.
At PREROUTING, if there is already a conntrack record in existence,
that record determines how the addresses and ports of the packet are
to be rewritten. That rewrite is then done.
On the other hand, if there is not yet a conntrack record in existence
for the packet, the nat PREROUTING table is consulted, and rules there
modify the fresh conntrack record to remember how exactly to do future
rewriting for BOTH directions of the connection. This is the point in
time where, for NAT action to multiple IPs and/or ports, the exact
address information for that single connection is determined.
You CAN use the DROP target in the NAT chain, that way ABORTING
creation / setup of the conntrack. But that's not usually done.
Next, a routing decision is made, depending (usually) on the destination
IP of the possibly rewritten packet. This decision determines whether the
packet (each packet!) will then pass through the filter table's FORWARD,
or INPUT chain. It will pass INPUT when the destination is localhost
(in all its disguises), or it will pass FORWARD when it is to be routed
out of the box.
Again, EVERY packet passes the filter table.
Nat table tells how to rewrite. Filter table filters. It's all clean
and simple (given the complexities of what NAT has to accomplish...)
OK now?
best regards
Patrick
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: how is this stuff getting thru default deny iptables firewall?....
2002-06-27 7:37 ` Patrick Schaaf
@ 2002-07-09 19:08 ` Christian Seberino
0 siblings, 0 replies; 16+ messages in thread
From: Christian Seberino @ 2002-07-09 19:08 UTC (permalink / raw)
To: Patrick Schaaf; +Cc: netfilter
> On the other hand, if there is not yet a conntrack record in existence
> for the packet, the nat PREROUTING table is consulted
Patrick
I appreciate all your help and after thinking about this on my vacation
last week I think I got it now thanks to your feedback!
Can I ask you few questions to verify I got what you said regarding
how a private LAN can use DNS, HTTP, SMTP, etc. thru an SSH-only firewall?...
My main confusion I believe was that packets associated with preexisting
conntracks are handled differently than packets *not* associated
with a previous conntrack.
Q1: The conntrack is the "memory" of netfilter that allows it to make
decisions based on "history" of PC traffic right?
Q2: Packets with a previous associated conntrack are handled *differently* than ones
without previous conntrack... and any attempt to try to understand
behavior of firewall *without* this concept is doomed
to confusion right?
Q3: Is conntrack a new "iptables only" feature? I imagine ancient ipchains/ipfwadmin
would have had same issues and therefore would need something like
"conntrack" to work correctly right?
Sincerely,
Chris
--
_______________________________________
Dr. Christian Seberino
SPAWAR Systems Center San Diego
Code 2363
53560 Hull Street
San Diego, CA 92152-5001
U.S.A.
Phone: (619) 553-7940
Fax: (619) 553-2836
Email: seberino@spawar.navy.mil
_______________________________________
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: how is this stuff getting thru default deny iptables firewall?....
2002-06-23 7:13 ` Christian Seberino
2002-06-23 7:53 ` Patrick Schaaf
@ 2002-06-23 8:07 ` Antony Stone
2002-06-27 7:14 ` Christian Seberino
1 sibling, 1 reply; 16+ messages in thread
From: Antony Stone @ 2002-06-23 8:07 UTC (permalink / raw)
To: netfilter
On Sunday 23 June 2002 8:13 am, Christian Seberino wrote:
> Here is my rule set... it is preceded by the usual stuff
> like flushing chains, dropping certain classes of packets, etc.
>
> These are the *only* rules with "-j ACCEPT" in my entire firewall script
> and somehow DNS sneaks thru...
Okay, let's look at just two of your filtering rules for a moment....
> # Allow all thru priviate LAN NIC.
> $IPTABLES -t filter -A FORWARD -i $PROTECTED_NETWORK_INTERFACE \
> -s $PROTECTED_NETWORK -d ! $PROTECTED_NETWORK_SPACE \
> -j ACCEPT
> $IPTABLES -t filter -A FORWARD -o $PROTECTED_NETWORK_INTERFACE \
> -s ! $PROTECTED_NETWORK_SPACE -d $PROTECTED_NETWORK \
> -j ACCEPT
The first one says "packets coming in the internal nterface from an internal
address, and going to an external address (not internal) are allowed through".
The second one says "packets coming out of the internal interface, from an
external address (not internal), and going to an internal address are allowed
through".
No port numbers are specified, therefore the first rule allows an internal
client to connect to anything it likes out on the internet, and the second
rule allows the internet to reply.
However, you're using private addresses, soweneed some sort of address
translation rule:
> # The usual NAT stuff here.
> $IPTABLES -t nat -A POSTROUTING -o $INTERNET_INTERFACE \
> -s $PROTECTED_NETWORK -d ! $PROTECTED_NETWORK_SPACE \
> -j SNAT --to-source $INTERNET_IP_ADDRESS
"Any packet going out of the external interface, from an internal address, to
an external address (not internal) shall be source natted to the external IP
of the firewall."
Reverse nat for replying packets is automatic, therefore replies get
destination natted when they come back in.
This is how your internal clients can contact DNS servers; it is also how
they can contact web servers, telnet, time, news, in fact anything which
doesn't require a specific 'helper' on the firewall such as ftp, irc, h323.
Antony.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: how is this stuff getting thru default deny iptables firewall?....
2002-06-23 8:07 ` Antony Stone
@ 2002-06-27 7:14 ` Christian Seberino
2002-06-27 7:28 ` Patrick Schaaf
0 siblings, 1 reply; 16+ messages in thread
From: Christian Seberino @ 2002-06-27 7:14 UTC (permalink / raw)
To: Antony Stone; +Cc: netfilter
> Reverse nat for replying packets is automatic, therefore replies get
> destination natted when they come back in.
This scares me. So you are saying that there are "implicit" NAT
rules for "replying packets" that are immune to iptables DROP rules?!
If a packet is part of an ESTABLISHED tcp connection then it
can by pass an "SSH only" firewall?!??
I *didn't* allow /any/ ESTABLISHED connections on FORWARD
chain?!?!? How is iptables
behaving as though I did!?!?!? This is default hardcoded
behavior for iptables?!?!?
Chris
--
_______________________________________
Dr. Christian Seberino
SPAWAR Systems Center San Diego
Code 2363
53560 Hull Street
San Diego, CA 92152-5001
U.S.A.
Phone: (619) 553-7940
Fax: (619) 553-2836
Email: seberino@spawar.navy.mil
_______________________________________
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: how is this stuff getting thru default deny iptables firewall?....
2002-06-27 7:14 ` Christian Seberino
@ 2002-06-27 7:28 ` Patrick Schaaf
0 siblings, 0 replies; 16+ messages in thread
From: Patrick Schaaf @ 2002-06-27 7:28 UTC (permalink / raw)
To: Christian Seberino; +Cc: netfilter
On Thu, Jun 27, 2002 at 12:14:18AM -0700, Christian Seberino wrote:
> > Reverse nat for replying packets is automatic, therefore replies get
> > destination natted when they come back in.
>
> This scares me. So you are saying that there are "implicit" NAT
> rules for "replying packets" that are immune to iptables DROP rules?!
NO. You filter in the filter table's INPUT, OUTPUT, and FORWARD chains.
You can filter ANY packet there.
The NAT action (i.e. appropriate modification of IP addresses and ports)
is what happens automatically for the reverse direction - and that is
absolutely NECCESSARY for NAT to work. It's still up to you to filter
each packet after modifications have been applied.
> If a packet is part of an ESTABLISHED tcp connection then it
> can by pass an "SSH only" firewall?!??
If you have an indiscriminate ESTABLISHED/ACCEPT rule, and you did permit
the creation of the connection in the first place, then yes, that's the
case. It's all up to your own ruleset. A packet cannot become part of
an ESTABLISHED tcp connection if you do not permit an earlier packet
of the same connection to pass.
Please, Christian, tone down a bit, take a walk, take a deep breath,
and consider that we are not idiots. You don't yet know the full
picture, and painting your horrors onto your half-understanding
will just cause stress here, and make you progress more slowly.
Finally, please learn how to do test setups, and try out your suspicions
before whining about them publicly. It is very hard to guess from your
writing so far what exactly it is that you fear. If you progress by
first testing, you can describe your test setup here in detail, and
we can respond much more pointedly.
thanks for listening
Patrick
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2002-07-10 16:34 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-06-22 21:43 how is this stuff getting thru default deny iptables firewall? James T. Moore
2002-06-23 7:13 ` Christian Seberino
-- strict thread matches above, loose matches on Subject: below --
2002-07-09 19:43 j davis
2002-07-09 21:41 ` Christian Seberino
2002-07-09 21:43 ` Christian Seberino
[not found] ` <Pine.LNX.4.33.0207101903030.1723-100000@dodobirdy.nestac.com>
2002-07-10 16:34 ` Christian Seberino
2002-06-22 17:30 Christian Seberino
2002-06-22 17:38 ` Antony Stone
2002-06-23 7:13 ` Christian Seberino
2002-06-23 7:53 ` Patrick Schaaf
2002-06-27 7:21 ` Christian Seberino
2002-06-27 7:37 ` Patrick Schaaf
2002-07-09 19:08 ` Christian Seberino
2002-06-23 8:07 ` Antony Stone
2002-06-27 7:14 ` Christian Seberino
2002-06-27 7:28 ` Patrick Schaaf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox