The firewall rules have a policy to accept all network traffic as the setting. In other words, there are no protective rules.

When firewall rules have been applied during system startup, the output of this command will be similar to that shown in Figure 3-2.

Figure 3-2: Red Hat Linux, firewall rules enabled

In this example, the settings the user implemented offer little protection as the policy settings on the input rules permit traffic to be accepted.

The steps you have just completed have positively determined whether firewall rules are present. The point of this chapter is that you need appropriate rules to ensure that the Linux system is hardened against unwanted activities or assault. Firewall rules and filters are only part of the answer, but they are most important and should not be glossed over.

The firewall rules can be easily enabled on a SLES 8 system using the YaST tool that will be described later in this chapter. The resulting firewall rules are complex and lengthy. You can gain valuable insight in how complex firewalls function by examining the script that is produced on SLES8/9 systems. A brief review is provided at the end of this chapter. If you delight in simpler solutions, the alternative script provided may also prove useful.

Dealing with Existing Firewall Rules

If you find that a firewall configuration has already been implemented, it is necessary to determine its suitability. Obviously, if the rules presently in effect are sufficient they should not be tampered with. On the other hand, if inadequate or inappropriate the rules must be replaced with the correct solution.

If a firewall is found on a freshly installed Linux system, it can be removed or reconfigured using standard operating system tools. If a firewall script is found on a Linux system that has been installed for some time, your best recourse is to find the person who performed the installation to identify how the firewall rules were implemented.

It is important to realize that a Linux system that has been within network reach, and has been inadequately protected, may already have been compromised. In many situations like this the most time-effective way to deal with the problem is to reinstall the system from an installation source that is of known integrity. Correction of damage done to a compromised system will almost certainly be more costly (at least in time) than reinstallation.

Check Packet Filter Configuration

Commercial Linux servers like Red Hat Enterprise Linux AS 3.0 and SLES8 implement a facility known as tcp_wrappers , a technique that was designed to protect services that are implemented using the internetworking superdaemon ( inetd or xinetd ).

The tcp_wrappers are implemented using two files, one controlling what is specifically accepted and the other that specifies denials. The files are respectively called /etc/hosts.allow and /etc/ hosts .deny. These files provide the ability to define access to network services based on IP addresses or hostnames.

Many programs have the capability to support tcp_wrappers, including FTP and telnet, as well as other popular protocols except for HTTP and the X Windows System, among the most notable exceptions that use their own logging and access control systems.

Some open source applications have built-in support for tcp_wrappers. The best known example of this is Samba, where control of tcp_wrappers is effected using control statements inside Samba s smb.conf file. The two parameters that effect tcp_wrappers are hosts allow and hosts deny . You should refer to the online manual page for Samba s smb.conf file for specific guidance regarding these parameters.

For example, to find the manual entry for hosts allow in the smb.conf file, execute:

[root@sandpiper root]# man smb.conf

The tcp_wrappers facility can log connections as they come in, so your service sessions that weren t necessarily logged can be logged with detailed information on the nature of the connection. The syntax for entries in both files is

daemon_list

:

client_list

[:

options

]

The daemon_list and client_list entries are mandatory. The options shown in brackets are optional. The most common option is to specify a shell script that can be executed when a rule is invoked as a result of the matching of an allow or deny rule with an incoming connection packet.

The default setting does not include rules and therefore allows all communications to take place. The default behavior of tcp_wrappers is to deny access to services defined in hosts.deny unless there is a specific rule in hosts.allow to allow it (/etc/hosts.allow takes precedence over /etc/hosts.deny). Each rule is evaluated from the top down. Rules are evaluated starting at the top of the hosts.deny and the hosts.allow files so that a later rule can override an earlier rule. The ordering of rules within each file is significant.

SLES8/9 are provided with Web (HTML) formatted man pages. Many sites object to providing external access to man pages. The default SUSE tcp_wrappers configuration disables external access to the remote man pages. This is effected using an entry in the /etc/hosts.deny file as follows :

http-rman: ALL EXCEPT LOCAL

The client list in both hosts.allow and hosts.deny can be set up to show the types of entries shown in Table 3-1.

Note that when using domain names or hostnames, DNS failures can cause problems accessing the machines, especially when used with the wildcards described in Table 3-2. When possible, use IP addresses for maximum safety.

tcp_wrappers also can use the EXCEPT operator to allow you to exclude certain clients from a match.

So if your server, which is linux1 (192.168.1.1), needed to allow SSH connections from linux2 (192.168.1.100) and deny connections from other machines, you could set up your /etc/hosts.allow to show:

[root@sandpiper root]# cat /etc/hosts.allow
#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
sshd: 192.168.1.100
ALL: ALL: DENY

In the following hosts.allow file you can see additional entries that demonstrate the principals of operation recommended in this book:

Listing 3-1: A typical hosts.allow configuration file

#
# hosts.allow    This file describes the names of the hosts which are
#                 allowed to use the local INET services, as described
#                 by the '/usr/sbin/tcpd' server.
#
sshd: .domain EXCEPT bad.domain
in.telnetd: 192.168.1.6, 10.0.0.0/255.0.0.0 EXCEPT 10.0.0.5
portmap: 192.168.1.100
ALL: ALL : DENY

In this example, you are allowing all machines on the .domain network to connect to your server using SSH except for bad.domain, which is denied . On line 2, you allow 192.168.1.6 and the whole class A range of 10.0.0.0 except for 10.0.0.5 access this machine via telnet. On the next line, you allow portmap from 192.168.1.100 since this is the NFS server, and for NFS to work properly you need to allow portmapper access for machines using NFS. On the last line, you deny all connections not specifically noted.

Another interesting capability of tcp_wrappers is that it can run commands when a condition is matched. This should be used sparingly, but for advanced customization it can provide some important functionality. For instance, you can place the following line in your /etc/hosts.deny file to have an e-mail be sent to jdoe@my.domain whenever a connection fails:

ALL:ALL : spawn (/bin/echo Security Alert from %a on %d on 'date'  \
tee -a /var/log/security_Alert  mail jdoe@linux1.domain)

You are having anything that doesn t match any of the rules in /etc/hosts.allow and that matches the ALL:ALL condition in /etc/hosts.deny write

Security Alert from

hostname

on

daemon_process

on

date

and sending that to /var/log/security_alert as well as e-mailing the information to jdoe@linux1.domain. The %a and %d within the spawned command are expansions available from tcp_wrappers. The listing of available expansions are shown in Table 3-3.

tcp_wrappers can provide an extra layer of security even when using iptables or other firewalling software, and can provide some interesting alerting mechanisms with the spawn option.

tcp_wrappers support is supplied in an unconfigured state by default on commercial Linux systems. It is left to the discretion of the administrator to configure this facility.

Understand Network Basics

Network managers are constantly bombarded by companies that sell Internet security devices. Many pretend to offer a simple-to-use device that solves all network security problems. Nothing can be farther from the truth. Network security is not a simple issue at all, nor is a device the only viable solution to effect network security. But that does not mean network security is so complex that mortals can t understand the issues. Network security issues can be addressed in easily digestible steps.

The information provided in this section is designed to help you, the administrator, understand the basics of firewalls and network filters.

The core issue we are addressing in this chapter is that of the security of network connectivity. All network connectivity involves the use of a network interface controller (NIC). A NIC provides physical media access capability (an Ethernet connection ”usually an RJ-45 connector that supports 10Base-T, 100Base-T, Gigabit Ethernet, or similar protocols).

Every NIC has a unique 48-bit address that is by convention reported as 6 octets (hexadecimal numbers ), each separated by a colon . For example, 1b:23:5e:1d:7f:01. Companies that manufacture NICs can obtain from IANA a unique identifier that involves the first three octets (from left to right) of the address of the devices they produce. This address is called the media access controller address, or MAC address.

All physical network communications involve the use of MAC addresses. The MAC address contains two parts : a vendor identifier and a serial number (see Figure 3-3).

Figure 3-3: The anatomy of a MAC address

A NIC may be assigned a primary IP address, plus additional addresses (known as IP aliases). The relationship between the elements of the TCP/IP protocols is shown in Figure 3-4.

Figure 3-4: The addressing layers in TCP/IP

Network cards respond to two MAC addresses: their own unique address and the all ones address (ff:ff:ff:ff:ff:ff).

The Address Resolution Protocol (ARP), as well as the Reverse Address Resolution Protocol (RARP), makes use of the fact that the NIC will respond to the all ones MAC address. The protocols that make use of this behavior include ARP, RARP, ICMP, and UDP (broadcast). Excessive use of such protocols will interrupt the smooth operation of network devices and under extreme load may deny legitimate network operation.

TCP and UDP make use of port addresses. For example, the Hypertext Transport Protocol (HTTP) used for web services uses TCP port 80. Network traffic follows standards that document the structure of network messages or packets. It is from the contents of the network packet (the sequence of information that passes over the physical transport medium) that the TCP/IP protocol implementation can decode what type of information is being transmitted as well as how it should be handled within the computer.

A network packet may contain data that continues a current communication session. It may contain information that will attempt to start up a new session or close a session. Normal network traffic also includes packets from each end of a TCP session which inform the other end that the session is progressing correctly.

Any element of network communications can potentially be involved in firewall rules that will affect packet handling.

A network client or server may have one network interface (called a single-homed host) that is attached to an internal (private) network, or may be attached to a public network (called an external host). A network client or server that has more than one NIC is said to be multi-homed . Multi- homed machines may act as routers between each of the networks they are connected to.

The default configuration of the Linux kernel has ip_forwarding between interfaces disabled. Most Linux vendors implement a system to enable ip_forwarding (routing) when more than one NIC is enabled on the system. The TCP/IP protocol stack forwards an incoming packet that is destined for the interface that received it to the loopback adapter so that the machine can process its content. The kernel based ip_forwarding only deals with the routing of IP packets between interfaces other than the loopback adapter.

Understand Firewall Rules

Firewall configuration involves creation and application of policies that specify default handling of incoming packets and outbound packets, as well as forwarding of packets from the receiving interface to the destination address.

Packets that are destined for the machine itself must be routed to the loopback interface (IP address 127.0.0.1). All packets that are received from a network interface that are not destined for the machine itself must be routed to the destination or dropped. A dropped packet is effectively one that is ignored and disposed of.

Rules may be applied either to accept a packet, reject (deny) the packet, or drop it. A packet that is rejected will result in a message sent to the source address advising the reason for the rejection . The advisory packet may provide information that an attacker can use to implement an attack on the system. The dropping of packets results in no information being returned to the originator, with the effect that it will appear to the originator that the destination machine does not exist.

Rules specified may cause the firewall to examine any part of the incoming packet header information and determine how the packet will be processed if particular conditions are met.

Figure 3-5 illustrates the points of control in a dual-homed host. Firewall rules may be based on conditions at each point. The implementation of the rules is based on inbound, outbound, or forwarding requirements. As a result, rules that affect points A and E are collated under the rules table for outgoing packets, for B and D as part of the rules table for incoming packets, and forwarding between the NICs and the host itself is specified in the rules table for forwarding of packets.

Figure 3-5: Firewall rule bounds in a dual-homed host

IP Masquerading

A firewall may additionally be configured to hide the identity of hosts (IP addresses) that are present on a private (internal) network from the world at large. The most common modes of protection make use of IP masquerading or of network address translation (NAT).

IP Masquerade, also called IPMASQ or MASQ, allows one or more computers in a network without assigned IP addresses to communicate with the Internet using the Linux server s assigned IP address. The IPMASQ server acts as a gateway, and the other devices are invisible behind it, so to other machines on the Internet the outgoing traffic appears to be coming from the IPMASQ server and not the internal PCs.

It is much easier to guard a single point of entry than it is to guard many potential points of entry. The principle behind the Internet firewall is a machine that divides the network into the inside and the outside , with all traffic passing through the firewall. By protecting the single network firewall, the entire internal network can be protected. Masquerading allows machines on the inside to get out, without allowing foreign machine access to systems inside the private network. Masquerading rewrites the IP headers of outbound internal packets, making it appear that they all came from the firewall. Reply packets are treated by the reverse of the outgoing IP header translation, and are then forwarded to the appropriate internal machine. Thus, internal machines are allowed to connect to the outside world. However, external machines cannot find internal machines, since they are aware of only the IP address of the firewall external interface. The result is that they cannot attack the internal machines directly.

Network Address Translation

Network address translation is a more general process whereby IP addresses in one address space (perhaps a private network) will be translated into another address space (say, a public address range) by a router or equivalent device. Unlike IP masquerading, NAT may map each address that originates from an internal network to its own external address. Additionally, an internal IP address that has been translated to an external address may well be capable of being reached by a foreign system simply by connecting to the unique external address that the internal address has been mapped to. This makes possible the use of NAT for a very wide range of applications, including:

• Load distribution routing

• Clustering of network servers and services

• Virtual server implementations

NAT was invented in the early 1990s. It is specified by RFC 1631 and was mainly meant to save IP address space on the Internet. Modern use of NAT extends the concept well beyond the original design intent. All modes of use, other than simple static NAT, require the maintenance of state information for each translated IP address. This adds significant overhead compared with the simplicity of IP masquerading.

The Linux kernel version 2.4 and more recent supports a wide array of IP masquerading and NAT techniques. Additionally, Red Hat Enterprise Linux AS 3.0 and SLES8 both provide the Linux Virtual Server (LVS) application, which makes it possible to implement load distribution routing as well as load distribution NAT.

NAT may be used to implement IP masquerading in the Linux operating system kernel, therefore it is important to be aware what NAT entails. It is beyond the scope of this book to address the details of IP masquerading and NAT technologies, other than to briefly mention the role each may have in the process of hardening a Linux server against external or internal assault.