Dynamic NAT

Greenmet29

Is it me or is this kind of useless? I mean, I understand that you can use it if you have overlapping ip addresses, but .... why not just reconfigure your dhcp pool? I would imagine that even most big companies don't have a huge amount of static servers and it would just seem like more trouble than its worth to me.

Roguetadhg

While Dynamic NAT is perfect for outbound connections initiated by client computers protected by your firewall, it won’t help you when you want to make servers available for inbound connections from any Internet user. Since Dynamic NAT presents all your internal IP addresses to the world as the same single IP address (your Firebox’s External address), in most cases when new connection requests from the outside hit the Firebox, it (silently) discards them. But what if you want the world to access services on public IP addresses other than your Firebox’s External address? If you need to make only one service externally visible, you could use port forwarding (send inbound port 80 requests to one inside Web server, for example). But in many cases -- for example, if you run a server that provides HTTP, SSL, and FTP services to clients on the Internet -- you will need to make several ports and possibly several servers externally visible. Generally speaking, your public-facing servers need their own public addresses -- that is, they need to be 1:1 NATted.

With 1:1 NAT, you can bind a public address for each Web and other (DNS, mail) server to the private address you assigned to each server located on your trusted or optional networks. So, in a nutshell, Dynamic NAT is generally useful for hiding addresses of internal hosts when they access public services ; 1:1 NAT is useful for permitting public hosts access to internal servers.

Before you 1:1 NAT, take time to consider what must be done to secure public-facing servers:

1. Consider placing public-accessible servers on your Optional interface, separated from servers (and clients) operating on your trusted networks. This separation protects against attacks from one compromised server to another. Don’t worry, client computers on your trusted networks will be able to access servers on your Optional interface.
2. Apply all OS updates, security patches, and hot fixes, and “harden” your OS against attacks, then install server grade anti-virus and system integrity software such as ServerLock.
3. Disable all services you don’t explicitly wish to make available on your public servers, especially file access and sharing services. And of course, remove any information that is sensitive or useful to an attacker.
4. Where possible, use separate servers to host public Web, DNS, and SMTP mail services. This separation, coupled with previously stated measures, protects against an attacker who has gained administrative privileges through one service (e.g., SMTP mail) from gaining control of and misusing other essential services (e.g., public DNS).
5. Configure your Firebox to limit access to only those services you wish to make public on 1:1 NATted servers.

This is admittedly the 50,000 foot view of preparing a public server, but this column is about NAT. Plenty of resources on the Web can provide you details of how to diligently pursue the steps above.

Source:WatchGuard LiveSecurity