Chapter 7. Firewalls

Information security is commonly thought of as a process and not a product. However, standard security implementations usually employ some form of dedicated mechanism to control access privileges and restrict network resources to users who are authorized, identifiable, and traceable. Red Hat Linux includes several powerful tools to assist administrators and security engineers with network-level access control issues.

Aside from VPN solutions such as CIPE or IPSec (discussed in Chapter 6 Virtual Private Networks), firewalls are one of the core components of network security implementation. Several vendors market firewall solutions catering to all levels of the marketplace: from home users protecting one PC to data center solutions safeguarding vital enterprise information. Firewalls can be standalone hardware solutions, such as firewall appliances by Cisco, Nokia, and Sonicwall. There are also proprietary software firewall solutions developed for home and business markets by vendors such as Checkpoint, McAfee, and Symantec.

Apart from the differences between hardware and software firewalls, there are also differences in the way firewalls function that separate one solution from another. Table 7-1 details three common types of firewalls and how they function:

Method Description Advantages Disadvantages

NAT

Network Address Translation (NAT) places internal network IP subnetworks behind one or a small pool of external IP addresses, masquerading all requests to one source rather than several

· Can be configured transparently to machines on a LAN

· Protection of many machines and services behind one or more external IP address(es), simplifying administration duties

· Restriction of user access to and from the LAN can be configured by opening and closing ports on the NAT firewall/gateway

· Cannot prevent malicious activity once users connect to a service outside of the firewall

Packet Filter

Packet filtering firewalls read each data packet that passes within and outside of a LAN. It can read and process packets by header information and filters the packet based on sets of programmable rules implemented by the firewall administrator. The Linux kernel has built-in packet filtering functionality through the netfilter kernel subsystem.

· Customizable through the iptables front-end utility

· Does not require any customization on the client side, as all network activity is filtered at the router level rather than at the application level

· Since packets are not transmitted through a proxy, network performance is faster due to direct connection from client to remote host

· Cannot filter packets for content like proxy firewalls

· Processes packets at the protocol layer, but cannot filter packets at an application layer

· Complex network architectures can make establishing packet filtering rules difficult, especially if coupled with IP masquerading or local subnets and DMZ networks

Proxy

Proxy firewalls filter all requests of a certain protocol or type from LAN clients to a proxy machine, which then makes those requests to the Internet on behalf of the local client. A proxy machine acts as a buffer between malicious remote users and the internal network client machines.

· Gives administrators control over what applications and protocols function outside of the LAN

· Some proxy servers can cache data so that clients can access frequently requested data from the local cache rather than having to use the Internet connection to request it, which is convenient for cutting down on unnecessary bandwidth consumption

· Proxy services can be logged and monitored closely, allowing tighter control over resource utilization on the network

· Proxies are often application specific (HTTP, telnet, etc.) or protocol restricted (most proxies work with TCP connected services only)

· Application services cannot run behind a proxy, so your application servers must use a separate form of network security

Proxies can become a network bottleneck, as all requests and transmissions are passed through one source rather than direct client to remote service connections

Table 7-1. Firewall Types

7.1. Netfilter and IPTables

The Linux kernel features a powerful networking subsystem called netfilter. The netfilter subsystem provides stateful or stateless packet filtering as well as NAT and IP masquerading services. Netfilter also has the ability to mangle IP header information for advanced routing and connection state management. Netfilter is controlled through the IPTables utility.

7.1.1. IPTables Overview

The power and flexibility of netfilter is implemented through the IPTables interface. This command-line tool is similar in syntax to its predecessor, IPChains; however, IPTables uses the netfilter subsystem to enhance network connection, inspection, and processing; whereas IPChains used intricate rule sets for filtering source and destination paths, as well as connection ports for both. IPTables features advanced logging, pre- and post-routing actions, network address translation, and port forwarding all in one command-line interface.

This section provides an overview of IPTables. For more detailed information about IPTables, refer to the Red Hat Linux Reference Guide.

7.1.2. Using IPTables

The first step in using IPTables is to start the IPTables service. This can be done with the command:

service iptables start

Warning

The IPChains and IP6Tables services must be turned off to use the IPTables service with the following commands:

service ipchains stop
chkconfig ipchains off

service ip6tables stop
chkconfig ip6tables off

To make IPTables start by default whenever the system is booted, you must change runlevel status on the service using chkconfig.

chkconfig --level 345 iptables on

The syntax of IPTables is separated into tiers. The main tier is the chain. A chain specifies the state at which a packet will be manipulated. The usage is as follows:

iptables -A chain -j target

The -A appends a rule at the end of an existing ruleset. The chain is the name of the chain for a rule. The three built-in chains of IPTables (that is, the chains that affect every packet which traverses a network) are INPUT, OUTPUT, and FORWARD. These chains are permanent and cannot be deleted.

Important

When creating an IPTables ruleset, it is critical to remember that order is important. For example, a chain that specifies that any packets from the local 192.168.100.0/24 subnet be dropped, and then a chain is appended (-A) which allows packets from 192.168.100.13 (which is within the dropped restricted subnet), then the appended rule is ignored. You must set a rule to allow 192.168.100.13 first, and then set a drop rule on the subnet.

The only exception to rule ordering and IPTables is with setting default policies (-P ), as IPTables will honor any rules that follow default policies.

7.1.2.1. Basic Firewall Policies

Some basic policies established from the beginning can aid as a foundation for building more detailed, user-defined rules. IPTables uses policies (-P) to create default rules. Security-minded administrators usually elect to drop all packets as a policy and only allow specific packets on a case-by-case basis. The following rules will block all incoming and outgoing packets on a network gateway:

iptables -P INPUT DENY
iptables -P OUTPUT REJECT

Additionally, it is recommended that any forwarded packets — network traffic that is to be routed from the firewall to its destination node — be denied as well, to restrict internal clients from inadvertent exposure to the Internet. To do this, use the following rule:

iptables -P FORWARD REJECT

After setting the policy chains, you can now create new rules for your particular network and security requirements. The following sections will outline some common rules you may implement in the course of building your IPTables firewall.

7.1.2.2. Saving and Restoring IPTables Rules

Firewall rules are only valid for the time the computer is on. If the system is rebooted, the rules are automatically flushed and reset. To save the rules so that they will load later, use the following command:

/sbin/service iptables save

The rules will be stored in the file /etc/sysconfig/iptables and will be applied whenever the service is started, restarted, or the machine rebooted.

7.1.3. `INPUT` Filtering

Keeping remote attackers out of a LAN is an important aspect of network security, if not the most important. The integrity of a LAN should be protected from malicious remote users through the use of stringent firewall rules. In the following example, The LAN (which uses a private class C 192.168.1.0/24 IP range) rejects telnet access to the firewall from the outside:

iptables -A INPUT -p tcp --sport telnet -j REJECT
iptables -A INPUT -p udp --sport telnet -j REJECT

The rule rejects all outside tcp and udp connections using the telnet protocol (typically port 23) with a connection refused error message. Rules using the --sport or --dport options can use either port numbers or common service names. So, using both --sport telnet and --sport 23 are acceptable. However, if the port number is changed in /etc/services, then using the telnet option, instead of explicitly stating the port number, will not work.

Note

There is a distinction between the REJECT and DROP target actions. The REJECT target denies access and returns a connection refused error to users who attempt to connect to the service. The DROP, as the name implies, drops the packet without any warning to telnet users. Administrators can use their own discretion when using these targets; however, to avoid user confusion and attempts to continue connecting, the REJECT target is recommended.

There may be times when certain users require remote access to the LAN from outside the LAN. Secure services, such as SSH and CIPE, can be used for encrypted remote connection to LAN services. For administrators with PPP-based resources (such as modem banks or bulk ISP accounts), dialup access can be used to circumvent firewall barriers securely, as modem connections are typically behind a firewall/gateway because they are direct connections. However, for remote users with broadband connections, special cases can be made. You can configure IPTables to accept connections from remote SSH and CIPE clients. For example, to allow remote SSH access to the LAN, the following may be used:

iptables -A INPUT -p tcp --sport 22 -j ACCEPT
iptables -A INPUT -p udp --sport 22 -j ACCEPT

CIPE connection requests from the outside can be accepted with the following command (replacing x with your device number):

iptables -A INPUT -p udp -i cipcbx  -j ACCEPT

Since CIPE uses its own virtual device which transmits datagram (UDP) packets, the rule allows the cipcb interface for incoming connections, instead of source or destination ports (though they can be used in place of device options). For information about using CIPE, refer to Chapter 6 Virtual Private Networks.

There are other services for which you may need to define INPUT rules. Refer to the Red Hat Linux Reference Guide for comprehensive information on IPTables and its various options.

7.1.4. `OUTPUT` Filtering

There may be instances when an administrator must allow certain users on the internal network to make outbound connections. Perhaps the administrator wants an accountant to connect to a special port specialized rules can be established using OUTPUT action in IPTables. The OUTPUT action places restrictions on outbound data.

For example, it may be prudent for an administrator to install a VPN client on the gateway to allow the entire internal network to access a remote LAN (such as a satelite office). To use CIPE as the VPN client installed on the gateway, use a rule similar to the following:

iptables -A OUTPUT -p udp -i cipcbx  -j ACCEPT

More elaborate rules can be created that control access to specific subnets, or even specific nodes, within a LAN. You can also restrict certain dubious services such as trojans, worms, and other client/server viruses from contacting their server. For example, there are some trojans that scan networks for services on ports from 31337 to 31340 (called the elite ports in cracking lingo). Since there are no legitimate services that communicate via these non-standard ports, blocking it can effectively diminish the chances that potentially infected nodes on your network independently communicate with their remote master servers. Note that the following rule is only useful if your default OUTPUT policy is set to ACCEPT. If you set OUTPUT policy to REJECT, then this rule is not needed.

iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP

7.1.5. `FORWARD` and NAT Rules

Most organizations are allotted a limited number of publicly routable IP addresses from their ISP. Due to this limited allowance, administrators must find creative ways to share access to Internet services without giving scarce IP addresses to every node on the LAN. Using class C private IP address is the common way to allow all nodes on a LAN to properly access network services internally and externally. Edge routers (such as firewalls) can receive incoming transmissions from the Internet and route the bits to the intended LAN node; at the same time, it can also route outgoing requests from a LAN node to the remote Internet service. This forwarding of network traffic can become dangerous at times, especially with the availability of modern cracking tools that can spoof internal IP addresses and make the remote attacker's machine act as a node on your LAN. To prevent this, IPTables provides routing and forwarding policies that can be implemented to prevent aberrant usage of network resources.

The FORWARD policy allows an administrator to control where packets can be routed. For example, to allow forwarding for an entire internal IP address range (assuming the gateway has an internal IP address on eth1), the following rule can be set:

iptables -A FORWARD -i eth1 -j ACCEPT

In this example, the -i is used to only accept incoming packets on the internal interface. The -i option is used for packets bound for that device (in this case, an internally assigned device).

Note

By default, IPv4 policy in Red Hat Linux kernels disables support for IP forwarding, which prevents boxes running Red Hat Linux from functioning as dedicated edge routers. To enable IP forwarding, run the following command or place it in your firewall initialization script:

echo "1" > /proc/sys/net/ipv4/ip_forward

If this command is run via shell prompt, then the setting is not remembered after a reboot. Thus it is recommended that it be added to the firewall initialization script.

FORWARD rules can be implemented to restrict certain types of traffic to the LAN only, such as local network file shares through NFS or Samba. The following rules reject outside connections to Samba shares:

iptables -A FORWARD -p tcp --sport 137:139 -j DROP
iptables -A FORWARD -p udp --sport 137:139 -j DROP

To take the restrictions a step further, block all outside connections that attempt to spoof private IP address ranges to infiltrate your LAN. If a LAN uses the 192.168.1.0/24 range, a rule can set the Internet facing network device (for example, eth0) to drop any packets to that device with an address in your LAN IP range. Because it is recommended to reject forwarded packets as a default policy, any other spoofed IP address to the external-facing device (eth0) will be rejected automatically.

iptables -A FORWARD -p tcp -s 192.168.1.0/24 -i eth0 -j DROP
iptables -A FORWARD -p udp -s 192.168.1.0/24 -i eth0 -j DROP

Rules can also be set to route traffic to certain machines, such as a dedicated HTTP or FTP server, preferably one that is isolated from the internal network on a de-militarized zone (DMZ). To set a rule for routing all incoming HTTP requests to a dedicated HTTP server at IP address 10.0.4.2 and port 80 (outside of the 192.168.1.0/24 range of the LAN), network address translation (NAT) calls a PREROUTING table to forward the packets to the proper destination:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 10.0.4.2:80

With this command, all HTTP connections to port 80 from the outside of the LAN are routed to the HTTP server on a separate network from the rest of the internal network. This form of network segmentation can prove safer than allowing HTTP connections to a machine on the network. If the HTTP server is configured to accept secure connections, then port 443 must be forwarded as well.