| Security Guide2.7. Virtual Private Networks (VPNs)Organizations with several satellite offices often connect to each other with dedicated lines for efficiency and protection of sensitive data in transit. For example, many businesses use frame relay or Asynchronous Transfer Mode ( ATM) lines as an end-to-end networking solution to link one office with others. This can be an expensive proposition, especially for small to medium sized businesses ( SMBs) that want to expand without paying the high costs associated with enterprise-level, dedicated digital circuits. To address this need, Virtual Private Networks ( VPNs) were developed. Following the same functional principles as dedicated circuits, VPNs allow for secured digital communication between two parties (or networks), creating a Wide Area Network ( WAN) from existing Local Area Networks ( LANs). Where it differs from frame relay or ATM is in its transport medium. VPNs transmit over IP using datagrams as the transport layer, making it a secure conduit through the Internet to an intended destination. Most free software VPN implementations incorporate open standard encryption methods to further mask data in transit. Some organizations employ hardware VPN solutions to augment security, while others use software or protocol-based implementations. Several vendors provide hardware VPN solutions, such as Cisco, Nortel, IBM, and Checkpoint. There is a free software-based VPN solution for Linux called FreeS/Wan that utilizes a standardized Internet Protocol Security ( IPsec) implementation. These VPN solutions, irrespective of whether they are hardware or software based, act as specialized routers that exist between the IP connection from one office to another. 2.7.1. How Does a VPN Work?When a packet is transmitted from a client, it sends it through the VPN router or gateway, which adds an Authentication Header ( AH) for routing and authentication. The data is then encrypted and, finally, enclosed with an Encapsulating Security Payload ( ESP). This latter constitutes the decryption and handling instructions. The receiving VPN router strips the header information, decrypts the data, and routes it to its intended destination (either a workstation or other node on a network). Using a network-to-network connection, the receiving node on the local network receives the packets already decrypted and ready for processing. The encryption/decryption process in a network-to-network VPN connection is transparent to a local node. With such a heightened level of security, an attacker must not only intercept a packet, but decrypt the packet as well. Intruders who employ a man-in-the-middle attack between a server and client must also have access to at least one of the private keys for authenticating sessions. Because they employ several layers of authentication and encryption, VPNs are a secure and effective means of connecting multiple remote nodes to act as a unified intranet. /etc/ipsec.d - main directory. Stores Openswan related files.
/etc/ipsec.conf - master configuration file. Further *.conf configuration files can be created in /etc/ipsec.d for individual configurations.
/etc/ipsec.secrets - master secrets file. Further *.secrets files can be created in /etc/ipsec.d for individual configurations.
/etc/ipsec.d/cert*.db - Certificate database files. The old default NSS database file is cert8.db. From Red Hat Enterprise Linux 6 onwards, NSS sqlite databases are used in the cert9.db file.
/etc/ipsec.d/key*.db - Key database files. The old default NSS database file is key3.db. From Red Hat Enterprise Linux 6 onwards, NSS sqlite databases are used in the key4.db file.
/etc/ipsec.d/cacerts - Location for Certificate Authority (CA) certificates.
/etc/ipsec.d/certs - Location for user certificates. Not needed when using NSS.
/etc/ipsec.d/policies - Groups policies. Policies can be defined as block, clear, clear-or-private, private, private-or-clear.
/etc/ipsec.d/nsspassword - NSS password file. This file does not exist by default, and is required if the NSS database in use is created with a password.
protostack - defines which protocol stack is used. The default option in Red Hat Enterprise Linux 6 is netkey. Other valid values are auto, klips and mast.
nat_traversal - defines if NAT workaround for connections is accepted. Default is no.
dumpdir - defines the location for core dump files.
nhelpers - When using NSS, defines the number of threads used for cryptographic operations. When not using NSS, defines the number of processes used for cryptographic operations.
virtual_private - subnets allowed for the client connection. Ranges that may exist behind a NAT router through which a client connects.
plutorestartoncrash - set to yes by default.
plutostderr - path for pluto error log. Points to syslog location by default.
connaddrfamily - can be set to either ipv4 or ipv6.
Further details about Openswan configuration can be found in the ipsec.conf(5) manual page. This section explains and gives examples of some of the commands used for Openswan. As shown in the following example, using service ipsec start/stop is the recommended method of changing the state of the ipsec service. This is also the recommended technique for starting and stopping all other services in Red Hat Enterprise Linux 6. Starting and Stopping Openswan: ipsec setup start/stop
service ipsec start/stop
Adding/deleting a connection: Connection establishment/breaking: Generating RSA keys: Checking ipsec policies in Kernel: ip xfrm policy
ip xfrm state
Creating self-signed certificate: Creating user certificate signed by the previous CA:
2.7.2.4. Openswan ResourcesInformation 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 Enterprise Linux includes several tools to assist administrators and security engineers with network-level access control issues. Firewalls are one of the core components of a 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 stand-alone hardware solutions, such as firewall appliances by Cisco, Nokia, and Sonicwall. Vendors such as Checkpoint, McAfee, and Symantec have also developed proprietary software firewall solutions for home and business markets. 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 2.6, "Firewall Types" details three common types of firewalls and how they function: Table 2.6. Firewall Types | Method | Description | Advantages | Disadvantages |
|---|
| NAT | Network Address Translation (NAT) places private IP subnetworks behind one or a small pool of public IP addresses, masquerading all requests to one source rather than several. The Linux kernel has built-in NAT functionality through the Netfilter kernel subsystem. | | � Can be configured transparently to machines on a LAN. | | � Protection of many machines and services behind one or more external IP addresses simplifies 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 | A packet filtering firewall reads each data packet that passes through 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 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 frequently-accessed data locally rather than having to use the Internet connection to request it. This helps to reduce 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 directly from a client to a remote service. |
|
2.8.1. Netfilter and IPTablesThe 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 using the iptables tool. 2.8.1.1. IPTables OverviewThe power and flexibility of Netfilter is implemented using the iptables administration tool, a command line tool similar in syntax to its predecessor, ipchains, which Netfilter/iptables replaced in the Linux kernel 2.4 and above. iptables uses the Netfilter subsystem to enhance network connection, inspection, and processing. iptables features advanced logging, pre- and post-routing actions, network address translation, and port forwarding, all in one command line interface.
2.8.2. Basic Firewall ConfigurationJust as a firewall in a building attempts to prevent a fire from spreading, a computer firewall attempts to prevent malicious software from spreading to your computer. It also helps to prevent unauthorized users from accessing your computer. In a default Red Hat Enterprise Linux installation, a firewall exists between your computer or network and any untrusted networks, for example the Internet. It determines which services on your computer remote users can access. A properly configured firewall can greatly increase the security of your system. It is recommended that you configure a firewall for any Red Hat Enterprise Linux system with an Internet connection. 2.8.2.1. Firewall Configuration ToolDuring the Firewall Configuration screen of the Red Hat Enterprise Linux installation, you were given the option to enable a basic firewall as well as to allow specific devices, incoming services, and ports. After installation, you can change this preference by using the Firewall Configuration Tool. To start this application, either select ⤍ ⤍ from the panel, or type system-config-firewall at a shell prompt. The Firewall Configuration Tool only configures a basic firewall. If the system needs more complex rules, refer to Section 2.8.9, "IPTables" for details on configuring specific iptables rules. 2.8.2.2. Enabling and Disabling the FirewallSelect one of the following options for the firewall: Disabled - Disabling the firewall provides complete access to your system and does no security checking. This should only be selected if you are running on a trusted network (not the Internet) or need to configure a custom firewall using the iptables command line tool. Firewall configurations and any customized firewall rules are stored in the /etc/sysconfig/iptables file. If you choose Disabled and click OK, these configurations and firewall rules will be lost. Enabled - This option configures the system to reject incoming connections that are not in response to outbound requests, such as DNS replies or DHCP requests. If access to services running on this machine is needed, you can choose to allow specific services through the firewall. If you are connecting your system to the Internet, but do not plan to run a server, this is the safest choice.
2.8.2.3. Trusted ServicesEnabling options in the Trusted services list allows the specified service to pass through the firewall. - WWW (HTTP)
The HTTP protocol is used by Apache (and by other Web servers) to serve web pages. If you plan on making your Web server publicly available, select this check box. This option is not required for viewing pages locally or for developing web pages. This service requires that the httpd package be installed. Enabling WWW (HTTP) will not open a port for HTTPS, the SSL version of HTTP. If this service is required, select the Secure WWW (HTTPS) check box. - FTP
The FTP protocol is used to transfer files between machines on a network. If you plan on making your FTP server publicly available, select this check box. This service requires that the vsftpd package be installed. - SSH
Secure Shell (SSH) is a suite of tools for logging into and executing commands on a remote machine. To allow remote access to the machine via ssh, select this check box. This service requires that the openssh-server package be installed. - Telnet
Telnet is a protocol for logging into remote machines. Telnet communications are unencrypted and provide no security from network snooping. Allowing incoming Telnet access is not recommended. To allow remote access to the machine via telnet, select this check box. This service requires that the telnet-server package be installed. - Mail (SMTP)
SMTP is a protocol that allows remote hosts to connect directly to your machine to deliver mail. You do not need to enable this service if you collect your mail from your ISP's server using POP3 or IMAP, or if you use a tool such as fetchmail. To allow delivery of mail to your machine, select this check box. Note that an improperly configured SMTP server can allow remote machines to use your server to send spam. - NFS4
The Network File System (NFS) is a file sharing protocol commonly used on *NIX systems. Version 4 of this protocol is more secure than its predecessors. If you want to share files or directories on your system with other network users, select this check box. - Samba
Samba is an implementation of Microsoft's proprietary SMB networking protocol. If you need to share files, directories, or locally-connected printers with Microsoft Windows machines, select this check box.
The Firewall Configuration Tool includes an Other ports section for specifying custom IP ports as being trusted by iptables. For example, to allow IRC and Internet printing protocol (IPP) to pass through the firewall, add the following to the Other ports section: 194:tcp,631:tcp
2.8.2.5. Saving the SettingsClick OK to save the changes and enable or disable the firewall. If Enable firewall was selected, the options selected are translated to iptables commands and written to the /etc/sysconfig/iptables file. The iptables service is also started so that the firewall is activated immediately after saving the selected options. If Disable firewall was selected, the /etc/sysconfig/iptables file is removed and the iptables service is stopped immediately. The selected options are also written to the /etc/sysconfig/system-config-firewall file so that the settings can be restored the next time the application is started. Do not edit this file by hand. 2.8.2.6. Activating the IPTables ServiceThe firewall rules are only active if the iptables service is running. To manually start the service, use the following command as the root user: ~]# service iptables restartiptables: Applying firewall rules: [ OK ] To ensure that iptables starts when the system is booted, use the following command: ~]# chkconfig --level 345 iptables on The first step in using iptables is to start the iptables service. Use the following command as the root user to start the iptables service: ~]# service iptables restartiptables: Applying firewall rules: [ OK ] The ip6tables service can be turned off if you intend to use the iptables service only. If you deactivate the ip6tables service, remember to deactivate the IPv6 network also. Never leave a network device active without the matching firewall. To force iptables to start by default when the system is booted, use the following command as the root user: ~]# chkconfig --level 345 iptables on This forces iptables to start whenever the system is booted into runlevel 3, 4, or 5. 2.8.3.1. IPTables Command SyntaxThe following sample iptables command illustrates the basic command syntax: iptables -A <chain> -j <target>
The -A option specifies that the rule be appended to <chain>. Each chain is comprised of one or more rules, and is therefore also known as a ruleset. The three built-in chains are INPUT, OUTPUT, and FORWARD. These chains are permanent and cannot be deleted. The chain specifies the point at which a packet is manipulated. The -j <target> option specifies the target of the rule; i.e., what to do if the packet matches the rule. Examples of built-in targets are ACCEPT, DROP, and REJECT. Refer to the iptables man page for more information on the available chains, options, and targets. 2.8.3.2. Basic Firewall PoliciesEstablishing basic firewall policies creates a foundation for building more detailed, user-defined rules. Each iptables chain is comprised of a default policy, and zero or more rules which work in concert with the default policy to define the overall ruleset for the firewall. The default policy for a chain can be either DROP or ACCEPT. Security-minded administrators typically implement a default policy of DROP, and only allow specific packets on a case-by-case basis. For example, the following policies block all incoming and outgoing packets on a network gateway: ~]# iptables -P INPUT DROP~]# iptables -P OUTPUT DROP It is also 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 DROP When you have established the default policies for each chain, you can create and save further rules for your particular network and security requirements. The following sections describe how to save iptables rules and outline some of the rules you might implement in the course of building your iptables firewall. 2.8.3.3. Saving and Restoring IPTables RulesChanges to iptables are transitory; if the system is rebooted or if the iptables service is restarted, the rules are automatically flushed and reset. To save the rules so that they are loaded when the iptables service is started, use the following command as the root user: ~]# service iptables saveiptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ] The rules are stored in the file /etc/sysconfig/iptables and are applied whenever the service is started or the machine is rebooted. 2.8.4. Common IPTables FilteringPreventing remote attackers from accessing a LAN is one of the most important aspects of network security. The integrity of a LAN should be protected from malicious remote users through the use of stringent firewall rules. However, with a default policy set to block all incoming, outgoing, and forwarded packets, it is impossible for the firewall/gateway and internal LAN users to communicate with each other or with external resources. To allow users to perform network-related functions and to use networking applications, administrators must open certain ports for communication. For example, to allow access to port 80 on the firewall, append the following rule: ~]# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT This allows users to browse websites that communicate using the standard port 80. To allow access to secure websites (for example, https://www.example.com/), you also need to provide access to port 443, as follows: ~]# iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT When creating an iptables ruleset, order is important. If a rule specifies that any packets from the 192.168.100.0/24 subnet be dropped, and this is followed by a rule that allows packets from 192.168.100.13 (which is within the dropped subnet), then the second rule is ignored. The rule to allow packets from 192.168.100.13 must precede the rule that drops the remainder of the subnet. To insert a rule in a specific location in an existing chain, use the -I option. For example: ~]# iptables -I INPUT 1 -i lo -p all -j ACCEPT This rule is inserted as the first rule in the INPUT chain to allow local loopback device traffic. There may be times when you require remote access to the LAN. Secure services, for example SSH, can be used for encrypted remote connection to LAN services. Administrators with PPP-based resources (such as modem banks or bulk ISP accounts), dial-up access can be used to securely circumvent firewall barriers. Because they are direct connections, modem connections are typically behind a firewall/gateway. For remote users with broadband connections, however, special cases can be made. You can configure iptables to accept connections from remote SSH clients. For example, the following rules allow remote SSH access: ~]# iptables -A INPUT -p tcp --dport 22 -j ACCEPT~]# iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT These rules allow incoming and outbound access for an individual system, such as a single PC directly connected to the Internet or a firewall/gateway. However, they do not allow nodes behind the firewall/gateway to access these services. To allow LAN access to these services, you can use Network Address Translation ( NAT) with iptables filtering rules. 2.8.5. FORWARD and NAT RulesMost ISPs provide only a limited number of publicly routable IP addresses to the organizations they serve. Administrators must, therefore, find alternative ways to share access to Internet services without giving public IP addresses to every node on the LAN. Using private IP addresses is the most common way of allowing all nodes on a LAN to properly access internal and external network services. Edge routers (such as firewalls) can receive incoming transmissions from the Internet and route the packets to the intended LAN node. At the same time, firewalls/gateways 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 abnormal usage of network resources. The FORWARD chain allows an administrator to control where packets can be routed within a LAN. For example, to allow forwarding for the entire LAN (assuming the firewall/gateway is assigned an internal IP address on eth1), use the following rules: ~]# iptables -A FORWARD -i eth1 -j ACCEPT~]# iptables -A FORWARD -o eth1 -j ACCEPT This rule gives systems behind the firewall/gateway access to the internal network. The gateway routes packets from one LAN node to its intended destination node, passing all packets through its eth1 device. By default, the IPv4 policy in Red Hat Enterprise Linux kernels disables support for IP forwarding. This prevents machines that run Red Hat Enterprise Linux from functioning as dedicated edge routers. To enable IP forwarding, use the following command as the root user: ~]# sysctl -w net.ipv4.ip_forward=1net.ipv4.ip_forward = 1 This configuration change is only valid for the current session; it does not persist beyond a reboot or network service restart. To permanently set IP forwarding, edit the /etc/sysctl.conf file as follows: Locate the following line: net.ipv4.ip_forward = 0 Edit it to read as follows: net.ipv4.ip_forward = 1 As the root user, run the following command to enable the change to the sysctl.conf file: ~]# sysctl -p /etc/sysctl.confnet.ipv4.ip_forward = 1net.ipv4.conf.default.rp_filter = 1net.ipv4.conf.default.accept_source_route = 0[output truncated] 2.8.5.1. Postrouting and IP MasqueradingAccepting forwarded packets via the firewall's internal IP device allows LAN nodes to communicate with each other; however they still cannot communicate externally to the Internet. To allow LAN nodes with private IP addresses to communicate with external public networks, configure the firewall for IP masquerading, which masks requests from LAN nodes with the IP address of the firewall's external device (in this case, eth0): ~]# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE This rule uses the NAT packet matching table (-t nat) and specifies the built-in POSTROUTING chain for NAT (-A POSTROUTING) on the firewall's external networking device (-o eth0). POSTROUTING allows packets to be altered as they are leaving the firewall's external device. The -j MASQUERADE target is specified to mask the private IP address of a node with the external IP address of the firewall/gateway. If you have a server on your internal network that you want make available externally, you can use the -j DNAT target of the PREROUTING chain in NAT to specify a destination IP address and port where incoming packets requesting a connection to your internal service can be forwarded. For example, if you want to forward incoming HTTP requests to your dedicated Apache HTTP Server at 172.31.0.23, use the following command as the root user: ~]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 172.31.0.23:80 This rule specifies that the nat table use the built-in PREROUTING chain to forward incoming HTTP requests exclusively to the listed destination IP address of 172.31.0.23. If you have a default policy of DROP in your FORWARD chain, you must append a rule to forward all incoming HTTP requests so that destination NAT routing is possible. To do this, use the following command as the root user: ~]# iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j ACCEPT This rule forwards all incoming HTTP requests from the firewall to the intended destination; the Apache HTTP Server behind the firewall. 2.8.5.3. DMZs and IPTablesYou can create iptables rules to route traffic to certain machines, such as a dedicated HTTP or FTP server, in a demilitarized zone ( DMZ). A DMZ is a special local subnetwork dedicated to providing services on a public carrier, such as the Internet. For example, to set a rule for routing incoming HTTP requests to a dedicated HTTP server at 10.0.4.2 (outside of the 192.168.1.0/24 range of the LAN), NAT uses the PREROUTING table to forward the packets to the appropriate destination: ~]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \ --to-destination 10.0.4.2:80 With this command, all HTTP connections to port 80 from outside of the LAN are routed to the HTTP server on a network separate 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. 2.8.6. Malicious Software and Spoofed IP AddressesMore elaborate rules can be created that control access to specific subnets, or even specific nodes, within a LAN. You can also restrict certain dubious applications or programs such as trojans, worms, and other client/server viruses from contacting their server. For example, some trojans scan networks for services on ports from 31337 to 31340 (called the elite ports in cracking terminology). Since there are no legitimate services that communicate via these non-standard ports, blocking them can effectively diminish the chances that potentially infected nodes on your network independently communicate with their remote master servers. The following rules drop all TCP traffic that attempts to use port 31337: ~]# iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP~]# iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP You can also block outside connections that attempt to spoof private IP address ranges to infiltrate your LAN. For example, if your LAN uses the 192.168.1.0/24 range, you can design a rule that instructs 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) is rejected automatically. ~]# iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP There is a distinction between the DROP and REJECT targets when dealing with appended rules. The REJECT target denies access and returns a connection refused error to users who attempt to connect to the service. The DROP target, as the name implies, drops the packet without any warning. Administrators can use their own discretion when using these targets. 2.8.7. IPTables and Connection TrackingYou can inspect and restrict connections to services based on their connection state. A module within iptables uses a method called connection tracking to store information about incoming connections. You can allow or deny access based on the following connection states: NEW - A packet requesting a new connection, such as an HTTP request.
ESTABLISHED - A packet that is part of an existing connection.
RELATED - A packet that is requesting a new connection but is part of an existing connection. For example, FTP uses port 21 to establish a connection, but data is transferred on a different port (typically port 20).
INVALID - A packet that is not part of any connections in the connection tracking table.
You can use the stateful functionality of iptables connection tracking with any network protocol, even if the protocol itself is stateless (such as UDP). The following example shows a rule that uses connection tracking to forward only the packets that are associated with an established connection: ~]# iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT The introduction of the next-generation Internet Protocol, called IPv6, expands beyond the 32-bit address limit of IPv4 (or IP). IPv6 supports 128-bit addresses, and carrier networks that are IPv6 aware are therefore able to address a larger number of routable addresses than IPv4. Red Hat Enterprise Linux supports IPv6 firewall rules using the Netfilter 6 subsystem and the ip6tables command. In Red Hat Enterprise Linux 6, both IPv4 and IPv6 services are enabled by default. The ip6tables command syntax is identical to iptables in every aspect except that it supports 128-bit addresses. For example, use the following command to enable SSH connections on an IPv6-aware network server: ~]# ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 --dport 22 -j ACCEPT For more information about IPv6 networking, refer to the IPv6 Information Page at http://www.ipv6.org/. Included with Red Hat Enterprise Linux are advanced tools for network packet filtering - the process of controlling network packets as they enter, move through, and exit the network stack within the kernel. Kernel versions prior to 2.4 relied on ipchains for packet filtering and used lists of rules applied to packets at each step of the filtering process. The 2.4 kernel introduced iptables (also called netfilter), which is similar to ipchains but greatly expands the scope and control available for filtering network packets. This chapter focuses on packet filtering basics, explains various options available with iptables commands, and explains how filtering rules can be preserved between system reboots. The default firewall mechanism in the 2.4 and later kernels is iptables, but iptables cannot be used if ipchains is already running. If ipchains is present at boot time, the kernel issues an error and fails to start iptables. The functionality of ipchains is not affected by these errors. 2.8.9.1. Packet FilteringThe Linux kernel uses the Netfilter facility to filter packets, allowing some of them to be received by or pass through the system while stopping others. This facility is built in to the Linux kernel, and has three built-in tables or rules lists, as follows: filter - The default table for handling network packets.
nat - Used to alter packets that create a new connection and used for Network Address Translation (NAT).
mangle - Used for specific types of packet alteration.
Each table has a group of built-in chains, which correspond to the actions performed on the packet by netfilter. The built-in chains for the filter table are as follows: INPUT - Applies to network packets that are targeted for the host. OUTPUT - Applies to locally-generated network packets. FORWARD - Applies to network packets routed through the host.
The built-in chains for the nat table are as follows: PREROUTING - Alters network packets when they arrive. OUTPUT - Alters locally-generated network packets before they are sent out. POSTROUTING - Alters network packets before they are sent out.
The built-in chains for the mangle table are as follows: INPUT - Alters network packets targeted for the host. OUTPUT - Alters locally-generated network packets before they are sent out. FORWARD - Alters network packets routed through the host. PREROUTING - Alters incoming network packets before they are routed. POSTROUTING - Alters network packets before they are sent out.
Every network packet received by or sent from a Linux system is subject to at least one table. However, a packet may be subjected to multiple rules within each table before emerging at the end of the chain. The structure and purpose of these rules may vary, but they usually seek to identify a packet coming from or going to a particular IP address, or set of addresses, when using a particular protocol and network service. The following image outlines how the flow of packets is examined by the iptables subsystem: By default, firewall rules are saved in the /etc/sysconfig/iptables or /etc/sysconfig/ip6tables files. The iptables service starts before any DNS-related services when a Linux system is booted. This means that firewall rules can only reference numeric IP addresses (for example, 192.168.0.1). Domain names (for example, host.example.com) in such rules produce errors. Regardless of their destination, when packets match a particular rule in one of the tables, a target or action is applied to them. If the rule specifies an ACCEPT target for a matching packet, the packet skips the rest of the rule checks and is allowed to continue to its destination. If a rule specifies a DROP target, that packet is refused access to the system and nothing is sent back to the host that sent the packet. If a rule specifies a QUEUE target, the packet is passed to user-space. If a rule specifies the optional REJECT target, the packet is dropped, but an error packet is sent to the packet's originator. Every chain has a default policy to ACCEPT, DROP, REJECT, or QUEUE. If none of the rules in the chain apply to the packet, then the packet is dealt with in accordance with the default policy. The iptables command configures these tables, as well as sets up new tables if necessary. 2.8.9.2. Command Options for IPTablesRules for filtering packets are created using the iptables command. The following aspects of the packet are most often used as criteria: Packet Type - Specifies the type of packets the command filters. Packet Source/Destination - Specifies which packets the command filters based on the source or destination of the packet. Target - Specifies what action is taken on packets matching the above criteria.
The options used with specific iptables rules must be grouped logically, based on the purpose and conditions of the overall rule, for the rule to be valid. The remainder of this section explains commonly-used options for the iptables command. 2.8.9.2.1. Structure of IPTables Command OptionsMany iptables commands have the following structure: iptables [-t <table-name>] <command> <chain-name> \ <parameter-1> <option-1> \ <parameter-n> <option-n>
<table-name> - Specifies which table the rule applies to. If omitted, the filter table is used.
<command> - Specifies the action to perform, such as appending or deleting a rule.
<chain-name> - Specifies the chain to edit, create, or delete.
<parameter>-<option> pairs - Parameters and associated options that specify how to process a packet that matches the rule.
The length and complexity of an iptables command can change significantly, based on its purpose. For example, a command to remove a rule from a chain can be very short: iptables -D <chain-name> <line-number>
In contrast, a command that adds a rule which filters packets from a particular subnet using a variety of specific parameters and options can be rather long. When constructing iptables commands, it is important to remember that some parameters and options require further parameters and options to construct a valid rule. This can produce a cascading effect, with the further parameters requiring yet more parameters. Until every parameter and option that requires another set of options is satisfied, the rule is not valid. Type iptables -h to view a comprehensive list of iptables command structures. 2.8.9.2.2. Command OptionsCommand options instruct iptables to perform a specific action. Only one command option is allowed per iptables command. With the exception of the help command, all commands are written in upper-case characters. The iptables commands are as follows: -A - Appends the rule to the end of the specified chain. Unlike the -I option described below, it does not take an integer argument. It always appends the rule to the end of the specified chain.
-D <integer> | <rule> - Deletes a rule in a particular chain by number (such as 5 for the fifth rule in a chain), or by rule specification. The rule specification must exactly match an existing rule.
-E - Renames a user-defined chain. A user-defined chain is any chain other than the default, pre-existing chains. (Refer to the -N option, below, for information on creating user-defined chains.) This is a cosmetic change and does not affect the structure of the table.
If you attempt to rename one of the default chains, the system reports a Match not found error. You cannot rename the default chains. -F - Flushes the selected chain, which effectively deletes every rule in the chain. If no chain is specified, this command flushes every rule from every chain.
-h - Provides a list of command structures, as well as a quick summary of command parameters and options.
-I [<integer>] - Inserts the rule in the specified chain at a point specified by a user-defined integer argument. If no argument is specified, the rule is inserted at the top of the chain.
As noted above, the order of rules in a chain determines which rules apply to which packets. This is important to remember when adding rules using either the -A or -I option. This is especially important when adding rules using the -I with an integer argument. If you specify an existing number when adding a rule to a chain, iptables adds the new rule before (or above) the existing rule. -L - Lists all of the rules in the chain specified after the command. To list all rules in all chains in the default filter table, do not specify a chain or table. Otherwise, the following syntax should be used to list the rules in a specific chain in a particular table:
iptables -L <chain-name> -t <table-name>
-N - Creates a new chain with a user-specified name. The chain name must be unique, otherwise an error message is displayed.
-P - Sets the default policy for the specified chain, so that when packets traverse an entire chain without matching a rule, they are sent to the specified target, such as ACCEPT or DROP.
-R - Replaces a rule in the specified chain. The rule's number must be specified after the chain's name. The first rule in a chain corresponds to rule number one.
-X - Deletes a user-specified chain. You cannot delete a built-in chain.
-Z - Sets the byte and packet counters in all chains for a table to zero.
2.8.9.2.3. IPTables Parameter OptionsCertain iptables commands, including those used to add, append, delete, insert, or replace rules within a particular chain, require various parameters to construct a packet filtering rule. -c - Resets the counters for a particular rule. This parameter accepts the PKTS and BYTES options to specify which counter to reset.
-d - Sets the destination hostname, IP address, or network of a packet that matches the rule. When matching a network, the following IP address/netmask formats are supported:
-f - Applies this rule only to fragmented packets.
You can use the exclamation point character (!) option before this parameter to specify that only unfragmented packets are matched. Distinguishing between fragmented and unfragmented packets is desirable, despite fragmented packets being a standard part of the IP protocol. Originally designed to allow IP packets to travel over networks with differing frame sizes, these days fragmentation is more commonly used to generate DoS attacks using malformed packets. It's also worth noting that IPv6 disallows fragmentation entirely. -i - Sets the incoming network interface, such as eth0 or ppp0. With iptables, this optional parameter may only be used with the INPUT and FORWARD chains when used with the filter table and the PREROUTING chain with the nat and mangle tables.
This parameter also supports the following special options: Exclamation point character (!) - Reverses the directive, meaning any specified interfaces are excluded from this rule. Plus character (+) - A wildcard character used to match all interfaces that match the specified string. For example, the parameter -i eth+ would apply this rule to any Ethernet interfaces but exclude any other interfaces, such as ppp0.
If the -i parameter is used but no interface is specified, then every interface is affected by the rule. -j - Jumps to the specified target when a packet matches a particular rule.
The standard targets are ACCEPT, DROP, QUEUE, and RETURN. Extended options are also available through modules loaded by default with the Red Hat Enterprise Linux iptables RPM package. Valid targets in these modules include LOG, MARK, and REJECT, among others. Refer to the iptables man page for more information about these and other targets. This option can also be used to direct a packet matching a particular rule to a user-defined chain outside of the current chain so that other rules can be applied to the packet. If no target is specified, the packet moves past the rule with no action taken. The counter for this rule, however, increases by one. -o - Sets the outgoing network interface for a rule. This option is only valid for the OUTPUT and FORWARD chains in the filter table, and the POSTROUTING chain in the nat and mangle tables. This parameter accepts the same options as the incoming network interface parameter (-i).
-p <protocol> - Sets the IP protocol affected by the rule. This can be either icmp, tcp, udp, or all, or it can be a numeric value, representing one of these or a different protocol. You can also use any protocols listed in the /etc/protocols file.
The "all" protocol means the rule applies to every supported protocol. If no protocol is listed with this rule, it defaults to "all". -s - Sets the source for a particular packet using the same syntax as the destination (-d) parameter.
2.8.9.2.4. IPTables Match OptionsDifferent network protocols provide specialized matching options which can be configured to match a particular packet using that protocol. However, the protocol must first be specified in the iptables command. For example, -p <protocol-name> enables options for the specified protocol. Note that you can also use the protocol ID, instead of the protocol name. Refer to the following examples, each of which have the same effect: ~]# iptables -A INPUT -p icmp --icmp-type any -j ACCEPT~]# iptables -A INPUT -p 5813 --icmp-type any -j ACCEPT Service definitions are provided in the /etc/services file. For readability, it is recommended that you use the service names rather than the port numbers. Secure the /etc/services file to prevent unauthorized editing. If this file is editable, crackers can use it to enable ports on your machine you have otherwise closed. To secure this file, run the following commands as root: ~]# chown root.root /etc/services~]# chmod 0644 /etc/services~]# chattr +i /etc/services This prevents the file from being renamed, deleted or having links made to it. 2.8.9.2.4.1. TCP ProtocolThese match options are available for the TCP protocol (-p tcp): --dport - Sets the destination port for the packet.
To configure this option, use a network service name (such as www or smtp); a port number; or a range of port numbers. To specify a range of port numbers, separate the two numbers with a colon (:). For example: -p tcp --dport 3000:3200. The largest acceptable valid range is 0:65535. Use an exclamation point character (!) after the --dport option to match all packets that do not use that network service or port. To browse the names and aliases of network services and the port numbers they use, view the /etc/services file. The --destination-port match option is synonymous with --dport. --sport - Sets the source port of the packet using the same options as --dport. The --source-port match option is synonymous with --sport.
--syn - Applies to all TCP packets designed to initiate communication, commonly called SYN packets. Any packets that carry a data payload are not touched.
Use an exclamation point character (!) before the --syn option to match all non-SYN packets. --tcp-flags <tested flag list> <set flag list> - Allows TCP packets that have specific bits (flags) set, to match a rule.
The --tcp-flags match option accepts two parameters. The first parameter is the mask; a comma-separated list of flags to be examined in the packet. The second parameter is a comma-separated list of flags that must be set for the rule to match. The possible flags are: ACK
FIN
PSH
RST
SYN
URG
ALL
NONE
For example, an iptables rule that contains the following specification only matches TCP packets that have the SYN flag set and the ACK and FIN flags not set: --tcp-flags ACK,FIN,SYN SYN
Use the exclamation point character (!) after the --tcp-flags to reverse the effect of the match option. --tcp-option - Attempts to match with TCP-specific options that can be set within a particular packet. This match option can also be reversed by using the exclamation point character (!) after the option.
2.8.9.2.4.2. UDP ProtocolThese match options are available for the UDP protocol (-p udp): --dport - Specifies the destination port of the UDP packet, using the service name, port number, or range of port numbers. The --destination-port match option is synonymous with --dport.
--sport - Specifies the source port of the UDP packet, using the service name, port number, or range of port numbers. The --source-port match option is synonymous with --sport.
For the --dport and --sport options, to specify a range of port numbers, separate the two numbers with a colon (:). For example: -p tcp --dport 3000:3200. The largest acceptable valid range is 0:65535. 2.8.9.2.4.3. ICMP ProtocolThe following match options are available for the Internet Control Message Protocol (ICMP) (-p icmp): 2.8.9.2.4.4. Additional Match Option ModulesAdditional match options are available through modules loaded by the iptables command. To use a match option module, load the module by name using the -m <module-name>, where <module-name> is the name of the module. Many modules are available by default. You can also create modules to provide additional functionality. The following is a partial list of the most commonly used modules: limit module - Places limits on how many packets are matched to a particular rule.
When used in conjunction with the LOG target, the limit module can prevent a flood of matching packets from filling up the system log with repetitive messages or using up system resources. The limit module enables the following options: --limit - Sets the maximum number of matches for a particular time period, specified as a <value>/<period>--limit 5/hour allows five rule matches per hour.
Periods can be specified in seconds, minutes, hours, or days. If a number and time modifier are not used, the default value of 3/hour is assumed. --limit-burst - Sets a limit on the number of packets able to match a rule at one time.
This option is specified as an integer and should be used in conjunction with the --limit option. If no value is specified, the default value of five (5) is assumed.
state module - Enables state matching.
The state module enables the following options: --state - match a packet with the following connection states:
ESTABLISHED - The matching packet is associated with other packets in an established connection. You need to accept this state if you want to maintain a connection between a client and a server.
INVALID - The matching packet cannot be tied to a known connection.
NEW - The matching packet is either creating a new connection or is part of a two-way connection not previously seen. You need to accept this state if you want to allow new connections to a service.
RELATED - The matching packet is starting a new connection related in some way to an existing connection. An example of this is FTP, which uses one connection for control traffic (port 21), and a separate connection for data transfer (port 20).
These connection states can be used in combination with one another by separating them with commas, such as -m state --state INVALID,NEW.
mac module - Enables hardware MAC address matching.
The mac module enables the following option:
Refer to the iptables man page for more match options available through modules. 2.8.9.2.5. Target OptionsWhen a packet has matched a particular rule, the rule can direct the packet to a number of different targets which determine the appropriate action. Each chain has a default target, which is used if none of the rules on that chain match a packet or if none of the rules which match the packet specify a target. The following are the standard targets: <user-defined-chain>
ACCEPT - Allows the packet through to its destination or to another chain.
DROP - Drops the packet without responding to the requester. The system that sent the packet is not notified of the failure.
QUEUE - The packet is queued for handling by a user-space application.
RETURN - Stops checking the packet against rules in the current chain. If the packet with a RETURN target matches a rule in a chain called from another chain, the packet is returned to the first chain to resume rule checking where it left off. If the RETURN rule is used on a built-in chain and the packet cannot move up to its previous chain, the default target for the current chain is used.
In addition, extensions are available which allow other targets to be specified. These extensions are called target modules or match option modules and most only apply to specific tables and situations. Refer to Section 2.8.9.2.4.4, "Additional Match Option Modules" for more information about match option modules. Many extended target modules exist, most of which only apply to specific tables or situations. Some of the most popular target modules included by default in Red Hat Enterprise Linux are: LOG - Logs all packets that match this rule. Because the packets are logged by the kernel, the /etc/syslog.conf file determines where these log entries are written. By default, they are placed in the /var/log/messages file.
Additional options can be used after the LOG target to specify the way in which logging occurs: --log-level - Sets the priority level of a logging event. Refer to the syslog.conf man page for a list of priority levels.
--log-ip-options - Logs any options set in the header of an IP packet.
--log-prefix - Places a string of up to 29 characters before the log line when it is written. This is useful for writing syslog filters for use in conjunction with packet logging.
Due to an issue with this option, you should add a trailing space to the log-prefix value. --log-tcp-options - Logs any options set in the header of a TCP packet.
--log-tcp-sequence - Writes the TCP sequence number for the packet in the log.
REJECT - Sends an error packet back to the remote system and drops the packet.
The REJECT target accepts --reject-with <type> (where <type> is the rejection type) allowing more detailed information to be returned with the error packet. The message port-unreachable is the default error type given if no other option is used. Refer to the iptables man page for a full list of <type>
Other target extensions, including several that are useful for IP masquerading using the nat table, or with packet alteration using the mangle table, can be found in the iptables man page. 2.8.9.2.6. Listing OptionsThe default list command, iptables -L [<chain-name>], provides a very basic overview of the default filter table's current chains. Additional options provide more information: -v - Displays verbose output, such as the number of packets and bytes each chain has processed, the number of packets and bytes each rule has matched, and which interfaces apply to a particular rule.
-x - Expands numbers into their exact values. On a busy system, the number of packets and bytes processed by a particular chain or rule may be abbreviated to Kilobytes, Megabytes, or Gigabytes. This option forces the full number to be displayed.
-n - Displays IP addresses and port numbers in numeric format, rather than the default hostname and network service format.
--line-numbers - Lists rules in each chain next to their numeric order in the chain. This option is useful when attempting to delete the specific rule in a chain or to locate where to insert a rule within a chain.
-t <table-name> - Specifies a table name. If omitted, defaults to the filter table.
2.8.9.3. Saving IPTables RulesRules created with the iptables command are stored in memory. If the system is restarted before saving the iptables rule set, all rules are lost. For netfilter rules to persist through a system reboot, they need to be saved. To save netfilter rules, type the following command as root: ~]# /sbin/service iptables saveiptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ] This executes the iptables init script, which runs the /sbin/iptables-save program and writes the current iptables configuration to /etc/sysconfig/iptables. The existing /etc/sysconfig/iptables file is saved as /etc/sysconfig/iptables.save. The next time the system boots, the iptables init script reapplies the rules saved in /etc/sysconfig/iptables by using the /sbin/iptables-restore command. While it is always a good idea to test a new iptables rule before committing it to the /etc/sysconfig/iptables file, it is possible to copy iptables rules into this file from another system's version of this file. This provides a quick way to distribute sets of iptables rules to multiple machines. You can also save the iptables rules to a separate file for distribution, backup, or other purposes. To do so, run the following command as root: iptables-save > <filename>
. . . . . . where <filename> is a user-defined name for your ruleset. If distributing the /etc/sysconfig/iptables file to other machines, type /sbin/service iptables restart for the new rules to take effect. Note the difference between the iptables command (/sbin/iptables), which is used to manipulate the tables and chains that constitute the iptables functionality, and the iptables service (/sbin/service iptables), which is used to enable and disable the iptables service itself. 2.8.9.4. IPTables Control ScriptsThere are two basic methods for controlling iptables in Red Hat Enterprise Linux: To use the same initscript commands to control netfilter for IPv6, substitute ip6tables for iptables in the /sbin/service commands listed in this section. For more information about IPv6 and netfilter, refer to Section 2.8.9.5, "IPTables and IPv6". 2.8.9.4.1. IPTables Control Scripts Configuration FileThe behavior of the iptables initscripts is controlled by the /etc/sysconfig/iptables-config configuration file. The following is a list of directives contained in this file: IPTABLES_MODULES - Specifies a space-separated list of additional iptables modules to load when a firewall is activated. These can include connection tracking and NAT helpers.
IPTABLES_MODULES_UNLOAD - Unloads modules on restart and stop. This directive accepts the following values:
IPTABLES_SAVE_ON_STOP - Saves current firewall rules to /etc/sysconfig/iptables when the firewall is stopped. This directive accepts the following values:
yes - Saves existing rules to /etc/sysconfig/iptables when the firewall is stopped, moving the previous version to the /etc/sysconfig/iptables.save file.
no - The default value. Does not save existing rules when the firewall is stopped.
IPTABLES_SAVE_ON_RESTART - Saves current firewall rules when the firewall is restarted. This directive accepts the following values:
yes - Saves existing rules to /etc/sysconfig/iptables when the firewall is restarted, moving the previous version to the /etc/sysconfig/iptables.save file.
no - The default value. Does not save existing rules when the firewall is restarted.
IPTABLES_SAVE_COUNTER - Saves and restores all packet and byte counters in all chains and rules. This directive accepts the following values:
IPTABLES_STATUS_NUMERIC - Outputs IP addresses in numeric form instead of domain or hostnames. This directive accepts the following values:
2.8.9.5. IPTables and IPv6If the iptables-ipv6 package is installed, netfilter in Red Hat Enterprise Linux can filter the next-generation IPv6 Internet protocol. The command used to manipulate the IPv6 netfilter is ip6tables. Most directives for this command are identical to those used for iptables, except the nat table is not yet supported. This means that it is not yet possible to perform IPv6 network address translation tasks, such as masquerading and port forwarding. Rules for ip6tables are saved in the /etc/sysconfig/ip6tables file. Previous rules saved by the ip6tables initscripts are saved in the /etc/sysconfig/ip6tables.save file. Configuration options for the ip6tables init script are stored in /etc/sysconfig/ip6tables-config, and the names for each directive vary slightly from their iptables counterparts. For example, the iptables-config directive IPTABLES_MODULES:the equivalent in the ip6tables-config file is IP6TABLES_MODULES. 2.8.9.6. Additional ResourcesThere are several aspects to firewalls and the Linux Netfilter subsystem that could not be covered in this chapter. For more information, refer to the following resources. 2.8.9.6.1. Useful Firewall Websiteshttp://www.netfilter.org/ - The home of the netfilter/iptables project. Contains assorted information about iptables, including a FAQ addressing specific problems and various helpful guides by Rusty Russell, the Linux IP firewall maintainer. The HOWTO documents on the site cover subjects such as basic networking concepts, kernel packet filtering, and NAT configurations. http://www.tldp.org/ - The Linux Documentation Project contains several useful guides relating to firewall creation and administration.
2.8.9.6.2. Related DocumentationRed Hat Linux Firewalls, by Bill McCarty; Red Hat Press - a comprehensive reference to building network and server firewalls using open source packet filtering technology such as Netfilter and iptables. It includes topics that cover analyzing firewall logs, developing firewall rules, and customizing your firewall using various graphical tools. Linux Firewalls, by Robert Ziegler; New Riders Press - contains a wealth of information on building firewalls using both 2.2 kernel ipchains as well as Netfilter and iptables. Additional security topics such as remote access issues and intrusion detection systems are also covered.
2.8.9.6.3. Installed IP Tables Documentation2.8.9.6.4. Useful IP Tables Websites |
| |
