Home > Articles > Security > Network Security

  • Print
  • + Share This
This chapter is from the book

Sample Configurations

The following three situations presented are representative of situations I have come across in the real world. Each is designed to demonstrate what people typically do with NAT and how the situations would be implemented on the chosen platform.

A Simple Network with NAT

The Situation

You work for a small company with a few hosts on a flat network segment. Your firewall runs on a Windows NT platform. The ISP has only given you a /29 net block, which effectively gives you six hosts you can use on the outside segment. Because the firewall and Internet router each need a unique IP address, this leaves a total of four addresses that can be used for other hosts. (See Figure 9-9.)

The Goals

  • Allow Internet users access to the Mail and Web Servers via SMTP and HTTP, respectively. In the future, these services will be provided on separate systems, so setting up each service with a unique IP is desirable to make future migration easier.

  • Figure 9-9 Sample configuration network #1

  • Allow internal users to access anything on the Internet. All outbound users will be hidden behind a single IP address; however, this IP address should be different from the firewall.

Checklist

  • Determine which IP addresses will be used for translation.

  • Set up the necessary proxy-ARPs.

  • Set up the necessary static host routes.

  • Create the necessary network objects.

  • Make the necessary modifications to anti-spoofing.

  • Create the necessary rulebase rules to permit the desired traffic.

  • Create the NAT rules.

  • Install the security policy.

Implementation

You must first determine which IPs you will use. Your usable IPs are 192.168.0.2– 192.168.0.5. Let's make 192.168.0.2 the IP you use for your external clients to hide behind, 192.168.0.3 for the SMTP server, and 192.168.0.4 for the HTTP server.

Next, set up the static ARPs for the translated addresses. In order to do this, you need to determine the MAC address of your external interface. Use the command ipconfig /all to determine this address:

    Ethernet adapter 3C5x91 :
        Description . . . . . . . . : 3Com 3C5x9 Ethernet Adapter
    Physical Address. . . . . . : 00-22-44-66-88-AA
    DHCP Enabled. . . . . . . . : No
    IP Address. . . . . . . . . : 192.168.0.1
    Subnet Mask . . . . . . . . : 255.255.255.248
    Default Gateway . . . . . . : 192.168.0.6
    Ethernet adapter 3C5x92:
        Description . . . . . . . . : 3Com 3C5x9 Ethernet Adapter
    Physical Address. . . . . . : 00-00-87-20-66-69
    DHCP Enabled. . . . . . . . : No
    IP Address. . . . . . . . . : 10.0.0.1
    Subnet Mask . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . :

The external MAC is 00-22-44-66-88-AA, which you will enter along with the IP addresses in the %FWDIR%\state\local.arp:

    192.168.0.2 00-22-44-66-88-AA
    192.168.0.3 00-22-44-66-88-AA
    192.168.0.4 00-22-44-66-88-AA

Both 192.168.0.3 and 192.168.0.4 each need a static host route. The 192.168.0.2 address does not need one, as users should never be directly connecting to 192.168.0.2. Because the real host is on the same subnet as the firewall, the static route should be directed at the host itself:

    route -p add 192.168.0.3 10.0.0.5
    route -p add 192.168.0.4 10.0.0.5

Because you are using the -p option, these routes will be available after a reboot; they will be stored in the Registry.

Table 9-8 lists the network objects you will create.

Table 9-8 Network objects for sample configuration #1

Name

Object Type

IP/Net Mask/Group Objects

Description

Net-internal

Network

10.0.0.0/255.255.255.0

The network that represents the Internal Network

mail-web-server

Workstation

10.0.0.5

Mail/Web Server on theInternal Network

mail-ext

Workstation

192.168.0.3

Translated IP for Mail Server

web-ext

Workstation

192.168.0.4

Translated IP for Web Server

external-hide

Workstation

192.168.0.2

IP that users will hide behind when going out

valid-internal

Group

net-internal + mail-ext + web-ext

Represents your internalinterface's valid addresses for anti-spoofing

firewall

Workstation

192.168.0.1

Your firewall


When configuring your firewall object, set your valid address settings according to the settings shown in Table 9-9.

Table 9-9 Valid address settings for firewall

Interface

Valid Address Setting

Internal

Specific: valid-internal

External

Others


The valid address settings are set on the Interfaces tab. Also, make sure that each interface has the Spoof Tracking set to "Log" to catch any errors in the anti-spoofing configuration.

The rulebase should look similar to the rules shown in Figure 9-10.

The NAT rules should look like the rules shown in Figure 9-11.

Save and install the policy.

Figure 9-10 Security policy for sample configuration #1

Figure 9-11 NAT policy for sample configuration #1

Notes

It is not a wise idea to have your internal hosts on the same LAN segment as hosts that are accessible from an untrusted network like the Internet. However, this is a situation that, for various reasons, all too many security administrators find themselves in. From a security standpoint, you are much better off trying to move externally accessible servers to a DMZ. It will cost a couple hundred dollars to purchase an extra LAN adaptor, an extra switch or hub, and a few extra cables, but the extra security gained will be well worth it.

You will not be able to access the Mail/Web server from the internal segment via its translated addresses without some additional configuration.

Migrating to a Larger Net with NAT

The Situation

The company you work for has grown. Your ISP has given you an external segment with a few more addresses (192.168.1.64/28), and you have a separate LAN segment for your DMZ, which now also has a few more hosts in it. Your firewall platform has also changed from Windows NT to Solaris.

A certain amount of "backward compatibility" needs to be maintained with the old setup; that is, certain hosts need to be reachable by their old addresses. For the external addresses, the ISP is continuing to route the 192.168.0.0/29 segment to you until such time as the address space is no longer needed. (See Figure 9-12.)

Figure 9-12 Sample configuration network #2

The Goals

  • Allow Internet users access to the Mail and Web Servers via SMTP and HTTP, respectively. Note that the servers will have to be accessible by their old, historical IPs as well as their new IPs.

  • Allow internal users to access anything on the Internet. All outbound users will be hidden behind a single IP address; however, this IP address should be different from the firewall.

  • Allow internal users to access the Intranet Web server by its old IP address (10.0.0.5). This server will not be accessible from the Internet.

Checklist

  • Determine which IP addresses will be used for translation.

  • Set up the necessary proxy-ARPs.

  • Set up the necessary static host routes.

  • Create the necessary network objects.

  • Make the necessary modifications to anti-spoofing.

  • Create the necessary rulebase rules to permit the desired traffic.

  • Create the NAT rules.

  • Install the security policy.

Implementation

To simplify your NAT configuration a bit, assign the 192.168.0.0/29 network to the DMZ. Make sure the external router is configured to route all requests for this network to the firewall. You also need to give the firewall an IP address of 192.168.0.1 on the DMZ interface. In Solaris, you add an /etc/hostname.qe3:1 file with this IP address. You also have to modify /etc/netmasks so that 192.168.0.0 has the correct net mask (255.255.255.248). So that you don't have to reboot for this to take effect, execute the following set of commands:

    # ifconfig qe3:1 plumb
    # ifconfig qe3:1 inet 192.168.0.1 netmask 255.255.255.248 
      broadcast 192.168.0.7 up

The SMTP and HTTP servers need to have secondary IP addresses of 192.168.0.3 and 192.168.0.4, respectively. Similar steps need to be taken on these servers.

You must then determine which IPs you will use for translation. Your new usable address range is 192.168.1.66-192.168.1.77. Let's make 192.168.1.66 the IP you use for your external clients to hide behind, 192.168.1.67 the new IP for your SMTP server, and 192.168.1.68 for your HTTP server. You are also translating 10.0.0.5 to 172.17.0.81.

Next, set up the static ARPs for the translated addresses. Because you are translating both internal and external addresses to the DMZ, you need both the external and internal interfaces' MAC address. An ifconfig -a shows you the following:

    lo0: flags=849 <UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
                  inet 127.0.0.1 netmask ff000000
le0: flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING, MULTICAST> mtu
1500
                  inet 192.168.1.65 netmask fffffff0 broadcast 
                  192.168.1.79
                  ether 0:12:34:56:78:9a
qe0: flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING, MULTICAST> mtu
1500
                  inet 10.0.0.1 netmask ffffff00 broadcast 10.0.0.255
                  ether 8:0:20:6d:0:20
qe3: flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 
1500
                  inet 172.17.0.1 netmask ffffff00 broadcast 172.17.0.255
                  ether 8:0:20:20:0:6d
qe3:1 flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING, MULTICAST> mtu 
1500
                  inet 192.168.0.1 netmask fffffff8 broadcast 192.168.0.7

The external MAC is 00:12:34:56:78:9a, and the internal MAC address is 8:0:20:20:0:6d. The ARPs you would do are as follows:

    arp -s 192.168.1.66 0:12:34:56:78:9a pub
    arp -s 192.168.1.67 0:12:34:56:78:9a pub
    arp -s 192.168.1.68 0:12:34:56:78:9a pub
    arp -s 10.0.0.5   8:0:20:20:0:6d  pub

Static routes are as follows (note that you still need static routes for the "old" addresses, even if you don't need ARPs for them):

    route add 192.168.1.67 172.17.0.25 1
    route add 192.168.1.68 172.17.0.80 1
    route add 10.0.0.5   172.17.0.81 1

Because this is a UNIX platform, these ARPs and routes will disappear after a reboot. You need to add these routes and ARPs to a startup file. It is recommended that you create a new script for this purpose (such as /etc/rc3.d/S94addroutes), and add the preceding commands to this file.

Table 9-10 shows the network objects that will be created.

When configuring your firewall object, set your valid address settings according to the settings shown in Table 9-11.

These settings are configured on the Interfaces tab. Also, make sure that each interface has the Spoof Tracking set to "Log" to catch any errors in the anti-spoofing configuration.

The rulebase should look similar to the rules shown in Figure 9-13.

The NAT rules should look like the rules shown in Figure 9-14.

Save and install the policy.

Notes

Sites on the DMZ should be accessible by their translated IP addresses, even from the internal network. This is because the communication is now mediated by the firewall. In the previous example, this was not the case.

Table 9-10 Network objects for sample configuration

Name

Object Type

IP/Net Mask/Group Objects

Description

net-internal

Network

10.0.0.0/255.255.255.0

The network that represents the Internal Network

net-dmz

Network

172.17.0.0/255.255.255.0

The network that represents the DMZ

net-external- old

Network

192.168.0.0/255.255.255.248

The old external network now on the DMZ

mail-server

Workstation

172.17.0.25

The Mail Server

mail-server-ext

Workstation

192.168.1.67

Translated IP for the Mail Server

mail-server- ext-old

Workstation

192.168.0.3

Translated IP for theMail Server (historical)

web-server

Workstation

172.17.0.80

The Web Server

web-server-ext

Workstation

192.168.1.68

Translated IP for the Web Server

web-server- ext-old

Workstation

192.168.0.4

Translated IP for the Web Server (historical)

intranet-web- server

Workstation

172.17.0.81

The Intranet Web Server

intranet-web-server-int

Workstation

10.0.0.5

Translated IP for the Intranet Web Server

external-hide

Workstation

192.168.1.66

IP that users will hide behind when going out

valid-dmz

Group

net-dmz + intranet-web-server-int + mail-server-ext + web-server-ext + net-external-old

Represents your DMZ interface's valid addresses for anti-spoofing

valid-internal

Group

net-internal

Represents your internal interface's valid addresses for anti-spoofing

firewall

Workstation

192.168.1.65

Your firewall


Table 9-11 Valid address settings for firewall

Interface

Valid Address Setting

DMZ

Specific: valid-dmz

Internal

Specific: valid-internal

External

Others


Figure 9-13 Security policy for sample configuration #2

Figure 9-14 NAT policy for sample configuration #2

Double-Blind Network Configuration

The Situation

There is a device within your network that has a faulty IP implementation and can only talk to hosts on the same subnet as it is on (i.e., it has no concept of routing).8 Because it is also not desirable to allow everyone to access this host, a firewall is necessary to restrict access to this host. The host is using nonroutable addresses and cannot be seen by the rest of the network. It must be given a routable address so that it can be accessed. Because neither side of the connection can know the true IP address of its peer, this is referred to as a double-blind network configuration.

A Nokia IP330 will be used to protect this device, which will be directly connected to the device via a crossover cable. The rest of the network (the entire 10.0.0.0/8) is used internally. Figure 9-15 only shows the relevant parts of the network.

Figure 9-15 Sample configuration network #3

The Goals

  • Allow FTP and Telnet access to 10.20.30.6 (the translated IP address for this device).

  • Allow HTTP access to the IP330 for management purposes from a specific management console (10.250.0.5, not pictured here).

  • Allow SSH access to the IP330 for management purposes from anywhere.

Checklist

  • Determine which IP addresses will be used for translation.

  • Set up the necessary proxy-ARPs.

  • Set up the necessary static host routes.

  • Create the necessary network objects.

  • Make the necessary modifications to anti-spoofing.

  • Create the necessary rulebase rules to permit the desired traffic.

  • Create the NAT rules.

  • Install the security policy.

Implementation

From the preceding goals, you know that you will be translating 10.20.30.6 to 192.168.255.2. You also know that all access to this protected device must appear to be coming from a device on the same subnet. The firewall is appropriate in this case.

You need to create an ARP for 10.20.30.6 using the MAC address of the external interface of the IP330. You can easily do this in Voyager. Figure 9-16 shows the interface ARP entries, which are on the ARP configuration page.

Figure 9-16 Interface ARP entries in Voyager

You can see the two interfaces and their MAC addresses. For 10.20.30.6, you will use 0:a0:8e:6:26:68. Right above the Interface ARP entries on the Voyager page is where you create this ARP entry (see Figure 9-17).

Figure 9-17 Create ARP entries in Voyager.

Click the Apply button at the bottom of the page. You then need to set the MAC address for this entry (see Figure 9-18).

Figure 9-18 Add MAC to ARP entries in Voyager.

Click Apply again. Go to the bottom of the static route page in Voyager, and add a static route to route 10.20.30.6 to 192.168.255.2 (see Figure 9-19).

Figure 9-19 Add static route in Voyager.

Click Apply, and then click Save. This configuration is now active across reboots.

The network objects you will create are shown in Table 9-12.

Table 9-12 Network objects for sample configuration

Name

Object Type

IP/Net Mask/Group Objects

Description

net-protected-device

Network

192.168.255.0/255.255.255.0

The network that the protected device is on

net-internal

Network

10.0.0.0/255.0.0.0

The internal network

protected-device

Workstation

192.168.255.2

The protected device's internal IP

protected-device-xlate

Workstation

10.20.30.6

Translated IP for the protected device

management-device

Workstation

10.250.0.5

Host allowed to connect to IP330 via HTTP

firewall-eth-s4p1

Workstation

192.168.255.1

A workstation object (defined without FireWall-1 installed) that represents the system's interface facing the protected device. You will need this later.

valid-eth-s4p1

Group

net-protected-device + protected-device-xlate

Represents the valid address setting for eth-s4p1, the interface that the protected device is hooked to

Firewall

Workstation

10.20.30.5

Your firewall


When configuring your firewall object, set your valid address settings according to the settings shown in Table 9-13.

Table 9-13 Valid address setting for firewall

Interface

Valid Address Setting

eth-s4p1c0

Specific: valid-eth-s4p1

eth-s3p1c0

Others


These settings are configured on the Interfaces tab. Also, make sure that each interface has the Spoof Tracking set to "Log" to catch any errors in the anti-spoofing configuration.

The rulebase should look similar to the rules shown in Figure 9-20.

Figure 9-20 Security policy for sample configuration #3

The NAT rules should look like the rule shown in Figure 9-21.

Save and install the policy.

Figure 9-21 NAT policy for sample configuration #3

Notes

You could do this in the reverse direction as well (i.e., have the protected device access hosts on the other side of the firewall as if they were on the same subnet), but this sample configuration only shows the connections occurring in one direction.

  • + Share This
  • 🔖 Save To Your Account