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), 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, Sonicwall, and Nokia. 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:
Table 7-1. Firewall Types
| 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 |
|
| ||||||
| 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. |
|
| ||||||
| 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. |
|
|
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 executable.
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 Official Red Hat Linux Reference Guide.
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:
|
To make IPTables start by default whenever the system is booted, you must change runlevel status on the service using chkconfig.
chkconfig --level 345 ip6tables 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. For example:
iptables -P OUTPUT ACCEPT |
The OUTPUT chain specifies any packets that originate from inside a LAN and travels outside (for example, to a remote website). In the example above, the rule states that all packets coming from the inside to the outside of the local network is allowed to pass through the firewall. This is usually an acceptable rule for administrators because the likelihood of dangerous packets going out into an untrusted carrier network such as the Internet is small compared to malicious packets going into the local network. 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, whereas user-defined chains can be.
Some basic rules established from the outset can aid as a foundation for building more detailed, user-defined rules. For example, you may want to allow all connections originating from the inside by default and then customize unique cases with their own rule sets. Accepting all OUTPUT by default is a sufficient foundation to build upon regarding outbound connections. It is also recommended that, by default, all incoming connections be denied by your firewall. The following rule will block all incoming connections:
iptables -P INPUT 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 (for example, if a LAN user accidentally turns on a service on some arbitrary port, then your network becomes vulnerable because of that machine's service). To do this, use the following rule:
iptables -P FORWARD REJECT |
After setting basic rules, 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.
Saving and Restoring IPTables Rules
Firewall rules are only valid for the time the computer is on. If you reboot your system, the rules will be automatically flushed and reset. To save your rules so that they will load later, use the following command:
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.
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 from the outside. The rule for this looks like the following:
iptables -A INPUT -p tcp --sport telnet -j REJECT |
The rule rejects all outside tcp 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.
 | 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 telnet users. The DROP, as the name implies, simply 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 the road or from a field office. 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 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 set iptables INPUT 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 |
CIPE connection requests from the outside can be accepted with the following command:
iptables -A INPUT -p udp -i cipcb0 -j ACCEPT |
Since CIPE uses its own virtual device which transmits datagram (UDP) packets, the rule allows the cipcb0 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.
There are other services for which you may need to define INPUT rules. Refer to the Official Red Hat Linux Reference Guide for comprehensive information on iptables and its various options.
OUTPUT Filtering
There may be instances when an administrator must block certain users on the internal network from making outbound connections. Perhaps the administrator intends to curtail malicious trojans from contacting their intended hosts or wants to keep an employee from misusing network resources for inappropriate or illicit reasons. In these cases, specialized rules can be established using OUTPUT action in iptables. The OUTPUT action places restrictions on outbound data.
Suppose an administrator notices heavy amounts of network traffic on port 6699 (a commonly used port for peer-to-peer file sharing services). To stop the traffic and conserve bandwidth for legitimate business purposes, the administrator can block LAN users from communicating on this port. After a thorough examination of what other services may be adversely affected by the blockage of port 6699, the administrator can add the following rule to the firewall and effectively block outbound traffic from the source port:
iptables -A OUTPUT -p TCP --sport 6699 -j REJECT |
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.
iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP |
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 you can implement 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, the following rule can be set:
iptables -A FORWARD -i eth1 -j ACCEPT |
| 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:
|
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, you can 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 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 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 ( the \ denotes a continuation of a one-line command):
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 will be 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.