NETWORK PRESENCE ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT
 


Search
display results
words begin  exact words  any words part 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [FW1] Web server in DMZ



I don't think that's right. Remember, firewall-1 works in this fashion:

1) packet received, check rule base for match
2) assuming packet is not dropped, it is then routed based on the route
table
of the FW. So packet now moves to it's exit interface.
3) NAT rules are checked for a match, if found packet header is rewritten
per
the nat tab.
4) Packet is then re-checked against the rulebase prior to leaving the exit
interface.

This is assuming that you have selected the EITHERBOUND rulebase method
which
is generally accepted to be more secure. So remember,
rulebase-route-nat-rulebase.

So what happens if you have this bastion host 192.168.10.10 with an Internet
NAT'd address 200.200.200.200 and your internal network is a 10.x.x.x net?
First (assuming you are not doubly natting this bastion), you have a route
entry that looks like:
route add -p 200.200.200.200 192.168.10.10
and a local arp entry for 200.200.200.200
and a rulebase entry to accept traffic to the 200.200.200.200 and
192.168.10.10 addresses.
and a 2 nat tab entries to statically nat the host in either direction:
(src, dest, svc, 			xlate-src, xlate-dst, xlate-svc)
any, 200.200.200.200, any,	orig, 192.168.10.10(static), orig
192.168.10.10, any, any,	200.200.200.200(static), orig, orig

You were worried that a packet from your 10 net would "leak" out to the
Internet
before getting to the bastion if sent to 200.200.200.200. Let's see what
really happens.
Your packet looks like (SA=10.1.1.1 DA=200.200.200.200 PORT 21)
it arrives at the firewall where it is checked against rulebase, it matches.
Firewall then "routes" and remember that routing is based on DESTINATION
ADDR, so
your firewall finds the 200.200.200.200 192.168.10.10 mask 255.255.255.255
entry
and slaps the packet onto the interface where 192.168.10.10 is found.
(note, this is not the external interface of the firewall!)
Next your FW1 will NAT the packet via the 1st nat tab rule above, so now
your
packet looks like this (SA=10.1.1.1 DA=192.168.10.10 PORT 21)
The rulebase is then applied again as the packet leaves the interface
because your
rules are EITHERBOUND.

Your packet never EVER reaches the external interface of your firewall. It
routes
internally within the tcp/ip stack on the firewall and arrives at the
bastion/DMZ
network with headers rewritten.

Assuming your internal 10net routers know to route 192.168.x.x to your
firewall,
then your internal hosts could access the bastion via either address.
However,
unless you add another nat tab rule, all replies will come from
200.200.200.200
because of the 2nd nat rule above. You might want to add a nat tab entry
like:
(src, dest, svc, xlate-src, xlate-dst, xlate-svc)
192.168.10.10, 10.x.x.x, any, orig, orig, orig

It is often a good idea to have a couple entries at the top of your nat tab.
1) to prevent the firewall from trying to do any nat between it's own
interfaces
FW1, FW1, any, orig, orig, orig
2) any internal networks that you don't require any natting to reach
RFC1918, RFC1918, any, orig, orig, orig
3) any other devices that you require no natting to occur, followed by all
the
rest of the rules to NAT using "any" in source or destination addresses.

Assuming you are using RFC1918 addressing internally, you should then add an
access list to your internet router to filter any RFC1918 sourced packets.
This is the "egress" filter that has been discussed.

The next question is why would you want just anyone internally to access a
"bastion" in the first place, but that is another matter.

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of
[email protected]
Sent: Friday, June 08, 2001 5:46 AM
To: Juppunov, George
Cc: [email protected]
Subject: RE: [FW1] Web server in DMZ




Pardon my jumping in, but isn't it common practice to have a different
network for the DMZ, not in the same address space as the external address
of the firewall? Otherwise internal requests to the public address of a DMZ
system would get "out" on the Internet first and then back in, right?

Example:

We used to have a 10.41.x.x DMZ network, because all internal networks were
also using 10.x networks and the routing from the LAN to the DMZ hosts (for
internal guys doing maintenance or whatever) was easier that way.

For the Internet the FW of course held a "virtual", public address for any
DMZ server and routed all requests for it to the NATted DMZ address.

Did I miss something here?

Best regards
Ralf G.






============================================================================
====
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
============================================================================
====




================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================



 
----------------------------------

ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT SITE MAP LEGAL
   All contents © 2004 Network Presence, LLC. All rights reserved.