Enabling Traffic To A Web Server On An Internal Network - D-Link NetDefend DFL-210 User Manual

7.4.1. Translation of a Single IP
Address (1:1)
These two rules allow us to access the web server via the NetDefend Firewall's external IP address. Rule 1 states
that address translation can take place if the connection has been permitted, and rule 2 permits the connection.
Of course, we also need a rule that allows internal machines to be dynamically address translated to the Internet.
In this example, we use a rule that permits everything from the internal network to access the Internet via NAT
hide:
# Action
3 NAT
Now, what is wrong with this rule set?
If we assume that we want to implement address translation for reasons of security as well as functionality, we
discover that this rule set makes our internal addresses visible to machines in the DMZ. When internal machines
connect to wan_ip port 80, they will be allowed to proceed by rule 2 as it matches that communication. From an
internal perspective, all machines in the DMZ should be regarded as any other Internet-connected servers; we do
not trust them, which is the reason for locating them in a DMZ in the first place.
There are two possible solutions:
1. You can change rule 2 so that it only applies to external traffic.
2. You can swap rules 2 and 3 so that the NAT rule is carried out for internal traffic before the Allow rule
matches.
Which of these two options is the best? For this configuration, it makes no difference. Both solutions work just as
well.
However, suppose that we use another interface, ext2, in the NetDefend Firewall and connect it to another
network, perhaps to that of a neighboring company so that they can communicate much faster with our servers.
If option 1 was selected, the rule set must be adjusted like this:
# Action
1 SAT
2 Allow
3 Allow
4 NAT
This increases the number of rules for each interface allowed to communicate with the web server. However, the
rule ordering is unimportant, which may help avoid errors.
If option 2 was selected, the rule set must be adjusted like this:
# Action
1 SAT
2 NAT
3 Allow
This means that the number of rules does not need to be increased. This is good as long as all interfaces can be
trusted to communicate with the web server. If, however, at a later point we add an interface that cannot be
trusted to communicate with the web server, separate Drop rules would have to be placed before the rule granting
all machines access to the web server.
Determining the best course of action must be done on a case-by-case basis, taking all circumstances into
account.
Example 7.4. Enabling Traffic to a Web Server on an Internal Network
The example we have decided to use is that of a web server with a private address located on an internal
network. From a security standpoint, this approach is wrong, as web servers are very vulnerable to attack and
should therefore be located in a DMZ. However, due to its simplicity, we have chosen to use this model in our
example.
Src Iface Src Net Dest Iface
lan lannet
Src Iface Src Net Dest Iface
any all-nets
wan all-nets
ext2 ext2net
lan lannet
Src Iface Src Net Dest Iface
any all-nets
lan lannet
any all-nets
Dest Net
any all-nets
Dest Net
core wan_ip
core wan_ip
core wan_ip
any all-nets
Dest Net
core wan_ip
any all-nets
core wan_ip
308
Chapter 7. Address Translation
Parameters
All
Parameters
http SETDEST 10.10.10.5 80
http
http
All
Parameters
http SETDEST 10.10.10.5 80
All
http