questions about chain traversal, new ascii diagram

questions about chain traversal, new ascii diagram

[Curby .]

Hi, I'm in the process of building a three-interface firewall and I have 
some questions about how the different chains see NAT packets and 
locally-generated packets.

Firstly, if I just do filtering in the INPUT/OUTPUT chains, NAT-ed packets 
will not traverse those chains, so I figure I should probably put similar 
filtering rules in the FORWARD chain? (For example, I'd like to be able to 
block all my internal users from accessing certain sites, or block incoming 
traffic sent by bad hosts from being port-forwarded to internal servers).

If I was trying to block incoming traffic from bad hosts, why not simply put 
the filters in the PREROUTING chain instead of both INPUT and FORWARD?  Is 
it because the nat table is intended for just nat and doing filtering there 
would be ugly, or would it actually fail to work?

I read in http://davidcoulson.net/writing/lxf/14/iptables.pdf (on the 
netfilter.org documentation page) that nat's OUTPUT chain performs DNAT on 
outgoing packets originating from the server, and POSTROUTING performs SNAT 
on outgoing packets passing through the firewall from other hosts.  If I 
have two Internet-facing IPs and would like to SNAT locally-generated 
traffic to one or the other, it would appear that iptables wouldn't let me 
do that very easily, right?  What is the purpose of nat's OUTPUT chain (in 
other words, when would I want to DNAT locally-generated traffic)?

In what order does locally-generated traffic traverse the OUTPUT chains of 
filter and nat tables?

Lastly, aside from those issues, is the diagram below a reasonable 
representation?  The only diagrams I found on chain traversal dealt with the 
nat and filter tables separately, but I'm hoping that it's possible to show 
them together.  (I hope hotmail doesn't completely destroy this ascii hehe).

# -->n.PREROUT-->routing decision-->f.FORWARD-->n.POSTROUT--,-->
#                       |                     ,-------------^
#                       v                     |
#                     f.INPUT              f.OUTPUT, n.OUTPUT
#                       |                     ^
#                       `--->local process----'

Thanks!

--curby

Re: questions about chain traversal, new ascii diagram

[Lopsch]

[-- Attachment #1: Type: text/plain, Size: 2427 bytes --]

Curby . schrieb:
> Hi, I'm in the process of building a three-interface firewall and I have
> some questions about how the different chains see NAT packets and
> locally-generated packets.
>
> Firstly, if I just do filtering in the INPUT/OUTPUT chains, NAT-ed
> packets will not traverse those chains, so I figure I should probably
> put similar filtering rules in the FORWARD chain? (For example, I'd like
> to be able to block all my internal users from accessing certain sites,
> or block incoming traffic sent by bad hosts from being port-forwarded to
> internal servers).
>
> If I was trying to block incoming traffic from bad hosts, why not simply
> put the filters in the PREROUTING chain instead of both INPUT and
> FORWARD?  Is it because the nat table is intended for just nat and doing
> filtering there would be ugly, or would it actually fail to work?
>
> I read in http://davidcoulson.net/writing/lxf/14/iptables.pdf (on the
> netfilter.org documentation page) that nat's OUTPUT chain performs DNAT
> on outgoing packets originating from the server, and POSTROUTING
> performs SNAT on outgoing packets passing through the firewall from
> other hosts.  If I have two Internet-facing IPs and would like to SNAT
> locally-generated traffic to one or the other, it would appear that
> iptables wouldn't let me do that very easily, right?  What is the
> purpose of nat's OUTPUT chain (in other words, when would I want to DNAT
> locally-generated traffic)?
>
> In what order does locally-generated traffic traverse the OUTPUT chains
> of filter and nat tables?
>
> Lastly, aside from those issues, is the diagram below a reasonable
> representation?  The only diagrams I found on chain traversal dealt with
> the nat and filter tables separately, but I'm hoping that it's possible
> to show them together.  (I hope hotmail doesn't completely destroy this
> ascii hehe).
>
> # -->n.PREROUT-->routing decision-->f.FORWARD-->n.POSTROUT--,-->
> #                       |                     ,-------------^
> #                       v                     |
> #                     f.INPUT              f.OUTPUT, n.OUTPUT
> #                       |                     ^
> #                       `--->local process----'
>
> Thanks!
>
> --curby
>
>
http://joerg.fruehbrodt.bei.t-online.de/pics/abb3_netfilter_ablaufdiagramm.jpg

What about the mangle decisions, do you also want to include them :D?

--

PGP-ID 0xF8EAF138

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: questions about chain traversal, new ascii diagram

[Curby .]

----Original Message Follows----
>http://joerg.fruehbrodt.bei.t-online.de/pics/abb3_netfilter_ablaufdiagramm.jpg
>
>What about the mangle decisions, do you also want to include them :D?

It looks reasonable, but if this is true then the article I mentioned was 
wrong.  Perhaps there should be a disclaimer by the link on the netfilter 
documentation page?

Does anyone know the answers to my other questions? Specifically, is it due 
to style or technical reasons that people don't filter traffic in 
PREROUTING, and instead put the same rules in both FORWARD and INPUT?

I think you were probably just being facetious, but I wouldn't mind knowing 
when the mangle chains come into play.  If we have to jump to them 
explicitly though, then I'll just RTFM. =)

Thanks again!

--Curby

Re: questions about chain traversal, new ascii diagram

[John A. Sullivan III]

On Thu, 2005-01-06 at 19:20 +0000, Curby . wrote:
> ----Original Message Follows----
> >http://joerg.fruehbrodt.bei.t-online.de/pics/abb3_netfilter_ablaufdiagramm.jpg
> >
> >What about the mangle decisions, do you also want to include them :D?
> 
> It looks reasonable, but if this is true then the article I mentioned was 
> wrong.  Perhaps there should be a disclaimer by the link on the netfilter 
> documentation page?
> 
> Does anyone know the answers to my other questions? Specifically, is it due 
> to style or technical reasons that people don't filter traffic in 
> PREROUTING, and instead put the same rules in both FORWARD and INPUT?
> 
> I think you were probably just being facetious, but I wouldn't mind knowing 
> when the mangle chains come into play.  If we have to jump to them 
> explicitly though, then I'll just RTFM. =)
<snip>
While it is not a good idea to put filtering rules in the nat table, it
is very common to put them in the PREROUTING chain of the mangle table.
In the ISCS network security management project
(http://iscs.sourceforge.net), we place all the "junk" filters in the
mangle table.

There are other targets that are only appropriate in the mangle table,
e.g., marking a packet (particularly useful with 2.6 ipsec traffic) or
changing TOS.
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

Financially sustainable open source development
http://www.opensourcedevel.com

Re: questions about chain traversal, new ascii diagram

[Andy Furniss]

Curby . wrote:
> ----Original Message Follows----
> 
>> http://joerg.fruehbrodt.bei.t-online.de/pics/abb3_netfilter_ablaufdiagramm.jpg 
>>
>>
>> What about the mangle decisions, do you also want to include them :D?
> 
> 
> It looks reasonable, but if this is true then the article I mentioned 
> was wrong.  Perhaps there should be a disclaimer by the link on the 
> netfilter documentation page?
> 
> Does anyone know the answers to my other questions? Specifically, is it 
> due to style or technical reasons that people don't filter traffic in 
> PREROUTING, and instead put the same rules in both FORWARD and INPUT?

Respecting johns answer - as I don't do much firewall stuff, but I 
thought it was because there are no filter tables in pre/post.

http://www.docum.org/docum.org/kptd/

> 
> I think you were probably just being facetious, but I wouldn't mind 
> knowing when the mangle chains come into play.  If we have to jump to 
> them explicitly though, then I'll just RTFM. =)

AIUI use mangle if you want to mark/change(mangle) packets eg TOS bits.


> 
> Thanks again!
> 
> --Curby
> 
> 
> 
> 

Ipfilter for DHCP client

[sisdis]

Dear people,

I have  two machines Sun Solaris 7 with ipfilter package in order to filter 
traffic from Internet. Last week I have the machines connected to a 
cablemodem with IP fixed by MAC address and they run OK.

But today I have to change of ISP and reconnect using a cablemodem again. In 
order to get the Sun machines assigned with an dynamic IP, I configured DHCP 
client in each Sun. But they can't get an public IP assigned by DHCP yet, 
they have been connected to the cablemodem since 2 hours, and they have the 
ipfilter running...but the IP is not assigned !!!

Now I don't know if my ipfilter rules are blocking the IP assignment in this 
DHCP client scenario, so I want you to get your opinion. The rules are:

pass in quick on hme0 proto udp from any to any port = 67 #Only permit DGCP 
incoming traffic
pass in quick on hme0 proto udp from any to any port = 68 #Only permit DHCP 
incoming traffic
block in quick on hme0 from 10.0.0.0/8 to any
block in quick on hme0 from 172.16.0.0/12 to any
block in quick on hme0 from 192.168.0.0/16 to any
block in quick on hme0 from 127.0.0.0/24 to any 
block in on hme0 all
pass out quick on hme0 proto tcp from any to any flags S keep state
pass out quick on hme0 proto udp from any to any keep state
pass out quick on hme0 proto icmp from any to any keep state

Special thanks !!!!!!!!!

Alejandro Cabrera