Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Patrick Schaaf <bof@bof.de>
To: Christian Seberino <seberino@spawar.navy.mil>
Cc: Antony Stone <Antony@Soft-Solutions.co.uk>, netfilter@lists.samba.org
Subject: Re: how is this stuff getting thru default deny iptables firewall?....
Date: Sun, 23 Jun 2002 09:53:51 +0200	[thread overview]
Message-ID: <20020623095351.M5183@oknodo.bof.de> (raw)
In-Reply-To: <20020623001302.A949@spawar.navy.mil>; from seberino@spawar.navy.mil on Sun, Jun 23, 2002 at 12:13:02AM -0700

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



  reply	other threads:[~2002-06-23  7:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-22 17:30 how is this stuff getting thru default deny iptables firewall? Christian Seberino
2002-06-22 17:38 ` Antony Stone
2002-06-23  7:13   ` Christian Seberino
2002-06-23  7:53     ` Patrick Schaaf [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2002-06-22 21:43 James T. Moore
2002-06-23  7:13 ` Christian Seberino
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

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=20020623095351.M5183@oknodo.bof.de \
    --to=bof@bof.de \
    --cc=Antony@Soft-Solutions.co.uk \
    --cc=netfilter@lists.samba.org \
    --cc=seberino@spawar.navy.mil \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox