Configuration Options for a Larger or Less Trusted LAN

A business or an organization, and many home sites, would use more elaborate, specific mechanisms than the simple, generic forwarding firewall rules presented in the preceding two sections for a trusted home LAN. In less trusted environments, firewall machines are protected from internal users as strongly as from external users.

Port-specific firewall rules are defined for the internal interfaces as well as for the external interfaces. Internal rules might be a mirror image of the rules for the external interfaces, or the rules might be more inclusive. What is allowed through the choke firewall machine's internal network interface depends on the types of systems running on the LAN and the types of local services running in the DMZ, as well as which Internet services are accessible to the LAN according to local security policies.

For example, you might want to block local broadcast messages from reaching the gateway firewall. If not all your users are completely trusted, you might want to restrict what passes into the choke firewall from internal machines as strongly as what comes in from the Internet. Additionally, you should keep the number of user accounts to a bare minimum on the firewall machine. Ideally, a firewall has no user accounts, with the exception of a single unprivileged administrative account.

A home-based business might have a single IP address, requiring LAN Network Address Translation. However, businesses often lease several publicly registered IP addresses or an entire network address block. Public addresses are usually assigned to a business's public servers. With public IP addresses, outgoing connections are forwarded and incoming connections are routed normally. A local subnet can be defined to create a local, public DMZ.

Dividing Address Space to Create Multiple Networks

IP addresses are divided into two pieces: a network address and a host address within that network. As stated in Chapter 1, "Preliminary Concepts Underlying Packet-Filtering Firewalls," Class A, B, and C addresses are something of an artifact, but they remain the easiest addresses to use as examples because their network and host fields fall on byte boundaries. Class A, B, and C network addresses are defined by their first 8, 16, and 24 bits, respectively. Within each address class, the remaining bits define the host part of the IP address. This is shown visually in Table 6.1.

Table 6.1. Network and Host Fields in an IP Address

	CLASS A	CLASS B	CLASS C
Leading Network Bits	0	10	110
Network Field	1 byte	2 bytes	3 bytes
Host Field	3 bytes	2 bytes	1 byte
Network Prefix	/8	/16	/24
Address Range	1126	128191	192223
Network Mask	255.0.0.0	255.255.0.0	255.255.255.0

Subnetting is a local extension to the network address part of the local IP addresses. A local network mask is defined as one that treats some of the most significant host address bits as if they were part of the network address. These additional network address bits serve to define multiple networks locally. Remote sites are not aware of local subnets. They see the address range as normal Class A, B, or C addresses.

For example, let's take the Class C private address block, 192.168.1.0. The base address, known as the network address, is 192.168.1.0 for this example. The network mask for this example is 255.255.255.0, exactly matching the first 24 bits, the network address, of the 192.168.1.0/24 network.

This network can be divided into two local networks by defining the first 25 bits, rather than the first 24 bits, as the network portion of the address. In current parlance, we say that the local network has a prefix length of 25 rather than 24. The most significant bit of the host address field is now treated as part of the network address field. The host field now contains 7 bits rather than 8. The network mask becomes 255.255.255.128, or /25 in CIDR notation. Two subnetworks are defined: 192.168.1.0, addressing hosts from 1 to 126, and 192.168.1.128, addressing hosts from 129 to 254. Each subnet loses two host addresses because each subnet uses the lowest host address, 0 or 128, as the network address, and uses the highest host address, 127 or 255, as the broadcast address. Table 6.2 shows this in tabular form.

Table 6.2. Class C Network 192.168.1.0 Subnetted into Two Subnets

SUBNET NUMBER	NONE	0	1
Network Address	192.168.1.0	192.168.1.0	192.168.1.128
Network Mask	255.255.255.0	255.255.255.128	255.255.255.128
First Host Address	192.168.1.1	192.168.1.1	192.168.1.129
Last Host Address	192.168.1.254	192.168.1.126	192.168.1.254
Broadcast Address	192.168.1.255	192.168.1.127	192.168.1.255
Total Hosts	254	126	126

Subnetworks 192.168.1.0 and 192.168.1.128 can be assigned to two separate internal network interface cards. Each subnet consists of two independent networks, each containing up to 126 hosts.

Subnetting allows for the creation of multiple internal networks, each containing different classes of client or server machines and each with its own independent routing. Different firewall policies can then be applied to the networks.

Of course, this example showed the network being divided into two portions. The network can in fact be divided into many parts in order to create a number of smaller networks. It's quite common to see a network with a subnet mask of 255.255.255.252 or /30 used between routers at two locations. Table 6.3 takes the process one step further and shows the same network divided into four subnets.

Table 6.3. Class C Network 192.168.1.0 Subnetted into Four Subnets

SUBNET NUMBER	0	1	2	3
Network Address	192.168.1.0	192.168.1.64	192.168.1.128	192.18.1.192
Network Mask	255.255.255.192	255.255.255.192	255.255.255.192	255.255.255.192
First Host Address	192.168.1.1	192.168.1.65	192.168.1.129	192.168.1.193
Last Host Address	192.168.1.62	192.168.1.126	192.168.1.190	192.168.1.254
Broadcast Address	192.168.1.63	192.168.1.127	192.168.1.191	192.168.1.255
Total Hosts	62	62	62	62

Selective Internal Access by Host, Address Range, or Port

Traffic through a firewall machine's internal interface can be selectively limited, just as traffic through the external interface is. For example, on a firewall for a small, residential site, rather than letting everything through on the internal interface, traffic could be limited to DNS, SMTP, POP, and HTTP. In this case, let's say that a firewall machine provides these services for the LAN. Local machines are not allowed any other access to outside services. In this case, forwarding isn't done.

POINT OF INTEREST

In this example, local hosts are limited to the specific services: DNS, SMTP, POP, and HTTP. Because POP is a local mail-retrieval service in this case, and because DNS, SMTP, and HTTP are proxied services, no direct Internet access is being made by LAN clients. In each case, the local clients are connecting to local servers. POP is a local LAN service. The three other servers establish remote connections on the client's behalf.

This example would be used only by a small, likely residential, site. Placing the mail gateway and POP services on the firewall host can require the host to have user accounts. It is not necessary that these accounts be login accounts, however.

CONFIGURATION OPTIONS FOR AN INTERNAL LAN

The following example considers a firewall machine with an internal interface connected to a LAN. Constants for the internal interface are as shown here:

 LAN_INTERFACE="eth1"               # internal interface to the LAN LAN_GATEWAY="192.168.1.1"          # firewall machine's internal                                    # interface address LAN_ADDRESSES="192.168.1.0/24"     # range of addresses used on the LAN 

LAN machines point to the firewall machine's internal interface as their name server:

 # Generic gateway response rule $IPT -A OUTPUT  -o $LAN_INTERFACE \          -s $LAN_GATEWAY \          -d $LAN_ADDRESSES --dport $UNPRIVPORTS \          -m state --state ESTABLISHED,RELATED -j ACCEPT # Service-specific LAN request rules $IPT -A INPUT -i $LAN_INTERFACE -p udp \          -s $LAN_ADDRESSES --sport $UNPRIVPORTS \          -d $LAN_GATEWAY --dport 53 \          -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A INPUT -i $LAN_INTERFACE -p tcp \          -s $LAN_ADDRESSES --sport $UNPRIVPORTS \          -d $LAN_GATEWAY --dport 53 \          -state --state NEW,ESTABLISHED,RELATED -j ACCEPT 

LAN machines also point to the firewall as their SMTP and POP server:

 # Sending mail - SMTP $IPT -A INPUT  -i $LAN_INTERFACE -p tcp \          -s $LAN_ADDRESSES --sport $UNPRIVPORTS \          -d $GATEWAY --dport 25 \          -state --state NEW,ESTABLISHED,RELATED -j ACCEPT # Receiving Mail - POP $IPT -A INPUT  -i $LAN_INTERFACE -p tcp \          -s $LAN_ADDRESSES --sport $UNPRIVPORTS \          -d $GATEWAY --dport 110 \          -state --state NEW,ESTABLISHED,RELATED -j ACCEPT 

The sendmail server will initiate an AUTH lookup request to the mail client. You won't likely be running the AUTH daemon, but you can send a REJECT for AUTH requests which can, on certain mail configurations, prevent a delay:

 $IPT -A OUTPUT -o $LAN_INTERFACE -p tcp \          -s $GATEWAY --sport $UNPRIVPORTS  \          -d $LAN_ADDRESSES --dport 113 -j REJECT $IPT -A INPUT  -i $LAN_INTERFACE ! --syn -p tcp \          -s $LAN_ADDRESSES --sport 113 \          -d $GATEWAY --dport $UNPRIVPORTS -j REJECT 

Finally, a local web caching proxy server is running on the firewall machine on port 8080. Internal machines point to the web server on the firewall as their proxy, and the web server forwards any outgoing requests on their behalf, along with caching any pages retrieved from the Internet. All connections to the proxy are via port 8080. Secure web and FTP access to remote sites is initiated by the proxy server:

 $IPT -A INPUT  -i $LAN_INTERFACE -p tcp \          -s $LAN_ADDRESSES --sport $UNPRIVPORTS \          -d $GATEWAY --dport 8080 \          -state --state NEW,ESTABLISHED,RELATED -j ACCEPT 

Remember that the web server will use the FTP passive mode protocol to retrieve data from remote FTP sites. The firewall's external interface will need input and output rules to access remote FTP, HTTP, and HTTPS service ports. The gateway host must also have rules for the external interface to account for email and local DNS queries to remote hosts.

CONFIGURATION OPTIONS FOR MULTIPLE LANS

Adding a second internal LAN allows this example to be developed further. The next example can be better secured than the preceding example. As shown in Figure 6.5, the DNS, SMTP, POP, and HTTP services are offered from server machines in a second LAN rather than from the firewall machine. The second LAN may or may not serve as a public DMZ. It's equally possible that the second LAN represents an internal service LAN, and its services are not offered to the Internet (although, in that case, the firewall could be required to at least be a mail gateway, depending on the local firewall configuration). In either case, firewall hosts do not typically host services. In this example, traffic is routed between the two LANs by the internal interfaces on the firewall machine.

Figure 6.5. Separating clients and servers in multiple LANs.

The following variables are used to define the LAN, network interfaces, and server machines in this example:

 CLIENT_LAN_INTERFACE="eth1"         # internal interface to the LAN SERVER_LAN_INTERFACE="eth2"         # internal interface to the LAN CLIENT_ADDRESSES="192.168.1.0/24"   # range of addresses used on the client LAN SERVER_ADDRESSES="192.168.3.0/24"   # range of addresses used on the server LAN DNS_SERVER="192.168.3.2"            # LAN DNS server MAIL_SERVER="192.168.3.3"           # LAN Mail and POP server POP_SERVER="192.168.3.3"            # LAN Mail and POP server WEB_SERVER="192.168.3.4"            # LAN Web server 

The first rule covers all server responses back to clients in the client LAN:

 $IPT -A FORWARD  -i $SERVER_LAN_INTERFACE -o $CLIENT_LAN_INTERFACE \          -s $SERVER_ADDRESSES -d $CLIENT_ADDRESSES \          -m state --state ESTABLISHED,RELATED -j ACCEPT 

The second rule covers all ongoing connection traffic from the LAN clients to the local servers in the server LAN:

 $IPT -A FORWARD  -i $CLIENT_LAN_INTERFACE -o $SERVER_LAN_INTERFACE \          -s $CLIENT_ADDRESSES -d $SERVER_ADDRESSES \          -m state --state ESTABLISHED,RELATED -j ACCEPT 

The third rule covers all remote server responses back to client requests from the local servers in the server LAN:

 $IPT -A FORWARD  -i $EXTERNAL_INTERFACE -o $SERVER_LAN_INTERFACE \          -d $SERVER_ADDRESSES \          -m state --state ESTABLISHED,RELATED -j ACCEPT 

The fourth rule covers all local server responses back to client requests from the remote hosts on the Internet:

 $IPT -A FORWARD  -i $SERVER_LAN_INTERFACE -o $EXTERNAL_INTERFACE \          -s $SERVER_ADDRESSES \          -m state --state ESTABLISHED,RELATED -j ACCEPT 

Local machines use the DNS server in the SERVER_LAN as their name server. Just as with the rules between the firewall's internal interface and external interface, server access rules are defined for the client LAN's interface. Client access rules are defined for the server LAN's interface:

 $IPT -A FORWARD -i $CLIENT_LAN_INTERFACE -o $SERVER_LAN_INTERFACE -p udp \          -s $CLIENT_ADDRESSES --sport $UNPRIVPORTS \          -d $DNS_SERVER --dport 53 \          -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $CLIENT_LAN_INTERFACE -o $SERVER_LAN_INTERFACE -p tcp \          -s $CLIENT_ADDRESSES --sport $UNPRIVPORTS \          -d $DNS_SERVER --dport 53 \          -m state --state NEW -j ACCEPT 

The DNS server on the second LAN needs to get its information from an external source. If the local server were a cache-and-forward server to an external server, forwarding unresolved lookups to the external server, the firewall's forwarding rules for its internal server LAN interface and external Internet interface would be this:

 $IPT -A FORWARD -i $SERVER_LAN_INTERFACE -o $EXTERNAL_INTERFACE -p udp \          -s $DNS_SERVER --sport 53 \          -d $NAME_SERVER_1 --dport 53 \          -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $SERVER_LAN_INTERFACE -o $EXTERNAL_INTERFACE -p udp \          -s $DNS_SERVER --sport $UNPRIVPORTS \          -d $NAME_SERVER_1 --dport 53 \          -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $SERVER_LAN_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \          -s $DNS_SERVER --sport $UNPRIVPORTS \          -d $NAME_SERVER_1 --dport 53 \          -m state --state NEW -j ACCEPT 

The hosts in the CLIENT_LAN point to the MAIL_SERVER as their mail gateway for sending mail:

 # Sending Mail - SMTP # ------------------- $IPT -A FORWARD -i $CLIENT_LAN_INTERFACE -o $SERVER_LAN_INTERFACE -p tcp \          -s $CLIENT_ADDRESSES --sport $UNPRIVPORTS \          -d $MAIL_SERVER --dport 25 \          -m state --state NEW -j ACCEPT 

The SMTP server on the SERVER_LAN needs to send the mail to remote destinations. The server requires access through the firewall to the Internet:

 $IPT -A FORWARD -i $SERVER_LAN_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \          -s $MAIL_SERVER --sport $UNPRIVPORTS --dport 25 \          -m state --state NEW -j ACCEPT 

The local mail server also needs to receive incoming mail from remote sites:

 $IPT -A FORWARD  -i $EXTERNAL_INTERFACE -o $SERVER_LAN_INTERFACE -p tcp \          --sport $UNPRIVPORTS -d $MAIL_SERVER --dport 25 \          -m state --state NEW -j ACCEPT 

Note that, for incoming mail to be addressed to the mail server, the name server must have a publicly accessible MX record advertising the host as the site's mail server. In this particular set of examples, the DNS rules do not allow for incoming DNS queries from the Internet. Thus, the remote name server would need to provide this service. (Alternative solutions using NAT and host forwarding are described in Chapter 7.) Be aware that some spam conscious Internet providers prevent incoming and outgoing connections on port 25, the common SMTP port. This of course breaks the end-to-end nature of the Internet.

The clients on the CLIENT_LAN point to the POP_SERVER machine to retrieve mail:

 # Receiving Mail - POP # -------------------- $IPT -A FORWARD -i $CLIENT_LAN_INTERFACE -o $SERVER_LAN_INTERFACE -p tcp \          -s $CLIENT_ADDRESSES --sport $UNPRIVPORTS \          -d $POP_SERVER --dport 110 \          -m state --state NEW -j ACCEPT 

Finally, a local web proxy server is running on a server machine in the server LAN, bound to port 8080. Internal machines point to the web server as their caching proxy, and the web server forwards any outgoing requests on their behalf:

 # WWW PROXY # --------- $IPT -A FORWARD -i $CLIENT_LAN_INTERFACE -o $SERVER_LAN_INTERFACE -p tcp \          -s $LAN_ADDRESSES --sport $UNPRIVPORTS \          -d $WEB_SERVER --dport 8080 \          -state --state NEW -j ACCEPT 

The web server on the server LAN needs Internet access to remote servers listening on TCP ports 80 and 443, as well as FTP's TCP port 21:

 $IPT -A FORWARD  -i $SERVER_LAN_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \          -m multiport --destination-port 80,443,21 \          --syn -s $WEB_SERVER --sport $UNPRIVPORTS \          -m state --state NEW -j ACCEPT