[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 ================================================================================
|