Take Stock


During installation of the Linux operating system, firewall rules may already have been created. Those new to Linux may simply accept defaults that are offered during installation. Beware of options that appear to sidestep the configuration of firewall settings but actually cause it to be implemented. This can be a trap for new players. Before moving on, you should prove beyond doubt whether or not firewall rules already exist.

Check for Existing Firewall Rules

The Linux operating system kernel supports the loading of application modules that allow you to add kernel-level processes as they are required. This design helps to minimize the size (memory requirements) of the kernel while still permitting the addition of device drivers as well as kernel-level (privileged) processes as needed. The Linux kernel design makes it possible to maintain and use older drivers even where newer technologies may have replaced the earlier one. One example of this is firewall support. In version 2.4. x of the Linux kernel, it is possible to use the older style ipchains -based firewall facilities, or to use the newer iptables -based filters simply by loading the respective kernel modules.

Immediately after the firewall filtering module has been loaded into kernel memory, it is autoconfigured to accept all network traffic as the default setting. Each module includes a user -level utility that can be used to set firewall rules in place. It can also be used to report what rules are currently in effect.

Firewall rules are normally set as early as possible to minimize the opportunity for potential system intrusion during system startup.

The firewall rules may be examined using the following command:

 iptables L v 

The command for ipchains -based facilities is

 ipchains L v 

To discover what rules are in effect on your system, follow these steps:

  1. Start your Linux server.

  2. Log in as root.

  3. Open a terminal session:

    • For Red Hat Enterprise Linux AS 3.0, select Red Hat System Tools Terminal.

    • For SLES8/9, click the Terminal button on the toolbar.

  4. When the terminal shell has opened up, execute iptables -L -v .

The output you obtain will show whether firewall settings have been implemented. Figure 3-1 shows output from a system that is in its default state where rules have not been applied.

click to expand
Figure 3-1: Red Hat Linux, no firewall rules present

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.

click to expand
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.

Heads Up  

A simple firewall rule set may not offer the level of protection necessary, while undue complexity is a maintenance liability. Every firewall configuration must be rigorously validated to prove its adequacy. It must log intrusion attempts, port scans , and any connection attempts to ports and services from blocked source addresses.

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.

Heads Up  

Careless and incorrect ordering of rules within the hosts.allow and hosts.deny files may result in incorrect tcp_wrappers operation and may result in many hours lost trying to debug a tcp_wrappers rules file. Always build the rules file one step at a time and test each entry as soon as it is added.

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 
Heads Up  

Most documentation available on the Internet will tell you to put ALL : ALL in /etc/hosts.deny and then define services allowed in /etc/hosts.allowed. This is fine in most cases, but doesn't achieve what the user thinks it does, as someone with proper privileges can add a service to /etc/hosts.allow or accidentally remove /etc/hosts.deny, removing all restrictions that ALL: ALL had in the /etc/hosts.deny file. A better way to block all services not explicitly defined is to make the last entry in /etc/hosts.allow ALL: ALL: DENY removing the need for a /etc/hosts.deny file (for better security it should be present with the ALL: DENY statement as well).

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.

Table 3-1: hosts.allow and hosts.deny Entry Types

Client List Entry Types

Example

IP address

192.168.1.100 matches single IP

192.168.1. matches entire class C network of 192.168.1.0 (if a portion of the entry

is left out, everything to the right of the entry are treated as zero)

Hostname

fake.domain would match any requests from the fake.domain

.fake.domain would match any requests from anything within the fake.domain

Network/Netmask

192.168.0.0/255.255.255.0 would match everything in the class C 192.168.0 network

NIS (YP) netgroup

Anything with @ as the leading character is treated as an NIS netgroup

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.

Table 3-2: TCP Wrappers Wildcards

Wildcard

Description

ALL

Always matches

KNOWN

Matches a host whose name and address are known (via name services)

LOCAL

Any name that does not contain a dot (linux2 would match, linux2.domain would not)

PARANOID

Matches a host whose name does not match the address ( putting ALL: PARANOID
in /etc/hosts.allow would deny access to all machines whose IP didn't match its host address)

UNKNOWN

When a hostname or address is unknown because it cannot be resolved using the gethostbyXXXX() system calls that implement name resolution services

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
start example
 # # 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 
end example
 

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.

Table 3-3: TCP Wrapper Expansions

Expansion

Description

%a

Client's host address

%A

Server's host address

%c

As much client information as available

%d

Daemon process information

%h

Client hostname or address if no hostname is available

%H

Server hostname or address if no hostname is available

%n

Client hostname (or unknown or paranoid)

%N

Server hostname (or unknown or paranoid)

%p

Daemon process ID

%s

As much server information as available

%u

Client username (or unknown)

%%

Expands to a single %

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.

Table 3-4: Firewall Interface Access Policy Guidelines

Protocol

Inside Interfaces

External Interfaces

HTTP

Yes

Yes

HTTPS

Yes

Yes

SMTP

Yes

Yes

POP/IMAP

Yes

No

DNS

Yes

Yes (lookup only)

DHCP

Yes

No

NBNS

Yes

No

NBSS

Yes

No

FTP

Yes

Yes (read only)

Proxy

Yes

No

Print (515, 631)

Yes

No

High order ports (ports >1024)

Yes

Yes (only for existing connections)

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.

Stateless and Stateful Firewalls

Now that you know what a firewall is, there is one important factor that radically differentiates one type of firewall from another. Many old-style firewalls are stateless, meaning they lack capacity to remember connection states. Each connection that passes through it is a new connection. A stateful firewall maintains a history of connection contexts and dynamically updates the connection history.

A stateful firewall knows the context of each connection between its interfaces. This context information mitigates against the likelihood of third-party intrusion into the communication session. Connection context maintenance works in favor of the legitimate connection user and helps to prevent the hijacking of connection traffic.

The Linux kernel iptables facility can track connection state and permits its use to set up conditions for which an incoming packet may be accepted or rejected. The most common use of this capability is to accept only incoming connections for established outgoing connections. Incoming packets that attempt to set up a new TCP/IP connection will be rejected. iptables is a stateful instrument.




Hardening Linux
Hardening Linux
ISBN: 0072254971
EAN: 2147483647
Year: 2004
Pages: 113

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net