Configuration Options for a Trusted Home LAN | Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort

You must consider two kinds of internal network traffic. The first kind is local access to the gateway firewall, through the internal interface, as shown in Figure 6.4. The second is local access to the Internet, through the gateway machine's external interface.

Figure 6.4. LAN traffic to the firewall machine and to the Internet.

Presumably, most small systems have no reason to filter packets between the firewall and the local network in general. However, because most home-based sites are assigned a single IP address, one exception arises: NAT. Presumably, the only internal filtering-related action you must take will be to enable your own form of source address spoofing by applying NAT packets moving between your internal machines and the Internet. Most of the emphasis is on filtering packets between the firewall and the Internet.

HOW TRUSTWORTHY ARE "TRUSTED HOME LANS"?

Although small-business and residential sites often like to view their networks as "trusted," this is often not the case. The problem isn't the local users, but rather the high incidence rate of compromise among these systems. For more information, see CERT Advisory CA-2001-20, "Continuing Threats to Home Users," at http://www.cert.org/advisories/CA-2001-20.html. For additional information on networking in general, and security in particular, see CERT's informational paper, "Home Network Security," at http://www.cert.org/tech_tips/home_networks.html.

LAN Access to the Gateway Firewall

In a home environment, chances are good that you'll want to enable unrestricted access between the LAN machines and the gateway firewall. (Some parents have reason to disagree.)

The assumption in this section is that any public services are hosted on the firewall. LAN hosts are purely client machines. The LAN is allowed to initiate connections to the firewall, but the firewall is not allowed to initiate connections to the LAN. There will be exceptions to this rule of thumb. You might want the firewall host to have access to a local, networked printer, for example. (A business site would never make this choice. The firewall would be as protected against problems originating in the LAN as it is from problems originating on the public Internet.)

Starting with the firewall developed in Chapter 4 as the basis, two more constants are needed in the firewall example to refer to the internal interface connecting to the LAN. This example defines the internal network interface as eth1; the LAN is defined as including Class C addresses ranging from 192.168.1.0 to 192.168.1.255:

 LAN_INTERFACE="eth1" LAN_ADDRESSES="192.168.1.0/24"

Allowing unrestricted access across the interfaces is a simple matter of allowing all protocols and all ports by default. Notice that the LAN can initiate new connections to remote servers, but new incoming connections from remote sites are not accepted:

 $IPT -A FORWARD  -i $LAN_INTERFACE -o $EXTERNAL_INTERFACE \          -p tcp -s $LAN_ADDRESSES --sport $UNPRIVPORTS \          -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A FORWARD -i $EXTERNAL_INTERFACE_1 -o $LAN_INTERFACE \          -m state --state ESTABLISHED,RELATED -j ACCEPT

Notice also that these two rules forward traffic. They do not affect local traffic between the LAN and the firewall itself. To access services on the firewall host, local INPUT and OUTPUT rules are needed as well:

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

Both the forwarding and the internal interface rules could be as service-specific as the external interface rules in Chapter 4. In today's world, the internal interface and forwarding rules should be that specific. The rules in this section merely lay the groundwork, introducing the forwarding rules themselves.

LAN Access to Other LANs: Forwarding Local Traffic Among Multiple LANs

If the machines on your LAN, or on multiple LANs, require routing among themselves, you need to allow access among the machines for the service ports that they require, unless they have alternate internal connection paths. In the former case, any local routing done between LANs would be done by the firewall.

The assumption in this section is that there is a gateway firewall with two network interfaces, a DMZ server network, an internal choke firewall with two network interfaces, and the LAN private network. This is the setup shown earlier in Figure 6.1. Traffic between the LAN and the Internet crosses through the DMZ network between the choke and gateway firewalls. This setup is common in smaller sites.

This example renames the internal network interface on the gateway as DMZ_INTERFACE. Another constant is needed for the firewall. The DMZ is defined as including Class C private addresses ranging from 192.168.3.0 to 192.168.3.255:

 DMZ_INTERFACE="eth1" DMZ_ADDRESSES="192.168.3.0/24"

The following first two rules allow local access to the gateway firewall host from the LAN. In practice, the LAN would not be allowed access to all ports on the firewall. The second two rules allow the firewall itself to access specific services offered in the DMZ on a server-by-server basis. Again, a firewall in a larger setting would have little or no reason to access services hosted in the DMZ. In most cases, the firewall host wouldn't offer any services to the DMZ at all. In larger sites, it's probable that the firewall wouldn't offer any services to the LAN either:

 $IPT -A INPUT  -i $DMZ_INTERFACE -s $LAN_ADDRESSES -d $GATEWAY \          -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -o $DMZ_INTERFACE -s $GATEWAY -d $LAN_ADDRESSES \          -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -o $DMZ_INTERFACE -s $GATEWAY -d $DMZ_ADDRESSES \          -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A INPUT  -i $DMZ_INTERFACE -s $DMZ_ADDRESSES -d $GATEWAY \          -m state --state ESTABLISHED,RELATED -j ACCEPT

The next rules forward traffic between the internal networks and the Internet. The DMZ and LAN traffic are handled separately. The DMZ traffic represents incoming connection requests from the Internet. The LAN traffic represents outgoing connection requests to the Internet. Again, in practice the DMZ rules would be very specific by server address and service:

 $IPT -A FORWARD  -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE \          -d $DMZ_ADDRESSES \          -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE \          -s $DMZ_ADDRESSES \          -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE \          -s $LAN_ADDRESSES \          -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A FORWARD  -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE \          -d $LAN_ADDRESSES \          -m state --state ESTABLISHED,RELATED -j ACCEPT

Note that the preceding forwarding rules for the DMZ are not complete. Servers in the DMZ sometimes initiate outgoing connections as well, such as connection requests from a web proxy server or a mail gateway server.

On the choke firewall, the following rules forward traffic between the LAN and DMZ networks. Notice that the LAN can initiate new connections, but new incoming connections from either the DMZ or the Internet to the LAN are not accepted. Again, in practice, the LAN would be given more controlled access to the DMZ as well as to the gateway firewall, assuming that the gateway provided any services:

 $IPT -A FORWARD  -i $LAN_INTERFACE -o $DMZ_INTERFACE \          -s $LAN_ADDRESSES \          -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $LAN_INTERFACE \          -m state --state ESTABLISHED,RELATED -j ACCEPT