Firewalls, VPNs, and SSL Tunnels

Transcription

1 Chapter 20 Firewalls, VPNs, and SSL Tunnels IN THIS CHAPTER Using a packet-filtering firewall Using Squid as a firewall Using FreeS/Wan A FIREWALL IS A device that implements your security policy by shielding your network from external threats. This device can take various forms from dedicated, commercial hardware that you buy from a vendor to a Linux system with special software. This chapter covers turning your Linux system into various types of firewalls to implement your security policy and protect your network. Because network security is big business, many classifications of firewalls exist; thanks to commercial computer security vendors, many firewall systems are really hybrids that perform diverse functions. Here I focus on two types of firewall the packet filter and the proxy firewall and examine how you can use virtual private networks (VPNs) to help implement secure access to your system. Packet-Filtering Firewalls A packet filter (sometimes called a filtering gateway or a screening router) is a firewall that analyzes all IP packets flowing through it and determines the fate of each packet according to rules that you create. A packet filter operates at the network and transport layer of the TCP/IP protocol stack. It examines every packet that enters the protocol stack. The network and the transport headers of a packet are examined for information on The protocol being used Source and destination addresses Source and destination ports Connection status 491

2 492 Part V: Firewalls You can set a packet filter to use certain features of a packet as criteria for allowing or denying access: Protocols. A typical filter can identify the TCP, UDP, and ICMP protocols, so you can allow or deny packets that operate under these protocols. Source/destination. You can allow or deny packets that come from a particular source and/or are inbound to a particular destination (whether an IP address or port). Status information. You can specify field settings that either qualify or disqualify a packet for admission to your system. For example, if a TCP packet has the ACK field set to 0, you can deny the packet under a policy that does not allow incoming connection requests to your network. Fortunately, Linux kernel 2.4.x comes with a highly configurable packet-filtering infrastructure called netfilter. The netfilter Web site is: The netfilter subsystem of the Linux kernel 2.4 allows you to set up, maintain, and inspect the packet-filtering rules in the kernel itself. It is a brand new packetfiltering solution, more advanced than what was available to Linux kernel before 2.4.x; netfilter provides a number of improvements, and it has now become an even more mature and robust solution for protecting corporate networks. However, don t think of netfilter as merely a new packet-filter implementation. It is a complete framework for manipulating packets as they traverse the parts of the kernel. netfilter includes Packet filtering, IP masquerading, and network-address translation (NAT). Support for stateful inspection of packets (in which the kernel keeps track of the packets state and context). Support for the development of custom modules to perform specific functions. Netfilter contains data structures called tables within the kernel to provide packetfiltering. Each table contains lists of rules called chains. There are three tables: filter nat mangle Each rule contains a set of criteria and a target. When the criteria are met, the target is applied to the packet. For example, the filter table (which is the default table), contains the INPUT, FORWARD, and OUPUT chains. These function as follows:

3 Chapter 20: Firewalls, VPNs, and SSL Tunnels 493 The INPUT chain within the filter table holds the rules for the packets that are meant for the system that is examining the packet. The FORWARD chain contains the rules for the packets that are passing through the system that is examining the packets. The OUTPUT chain holds the rules for packets that are created by the system itself (which is also examining the packets). The following listing shows a way to visualize the relationship among tables, chains, and rules. For example, the filter table has INPUT, FORWARD, and OUTPUT chains where each of these chains can have 1 to N number of rules. filter table +---INPUT +---input rule input rule input rule input rule N +---FORWARD +---forward rule forward rule forward rule forward rule N +---OUTPUT +---output rule output rule output rule output rule N nat table +---PREROUTING +---pre routing rule pre routing rule pre routing rule pre routing rule N

4 494 Part V: Firewalls +---OUTPUT +---output rule output rule output rule output rule N +---POSTROUTING +---post routing rule post routing rule post routing rule post routing rule N mangle table +---PREROUTING +---pre routing rule pre routing rule pre routing rule pre routing rule N +---OUTPUT +---output rule output rule output rule output rule N When a packet enters the packet-filter-and-firewall system, the packet-filtering subsystem of netfilter determines whether the packet is for itself (INPUT) or is simply being forwarded through itself (FORWARD), or is being generated by itself (OUTPUT). In the case of an input packet, the rules in the INPUT chain are applied in order. The first rule to match the packet criteria wins. The target of the matched rule then becomes the action for the packet. The mangle table is used to change or modify packets both before they are routed and after routing has been decided. The mangle table has two chains: PREROUTING and POSTROUTING to store rules that apply prior to routing and post of routing, respectively. The third table, nat, is used for Network Address Translation (NAT), which is a process of substituting an Internet-routable IP address for (typically) private addresses in IP packets. This is also known as IP masquerading.

5 Chapter 20: Firewalls, VPNs, and SSL Tunnels 495 The target of a rule can vary according to the table or even the chain it occupies. Table 20-1 is a list of targets available in each table. TABLE 20-1: TARGETS FOR RULES IN FILTER, MANGLE, AND NAT TABLES Target filter mangle nat Description REJECT Yes Yes Yes When this target is used for a matched packet, an error response is sent back to the system that created the packet. DENY Yes Yes Yes The matched packet is simply dropped when this is the target of a rule. Unlike REJECT, no error response is sent to the system generating the packet. ACCEPT Yes Yes Yes The matched packet is accepted when this target is in use. TOS No Yes No This target allows you to set the Type Of Service (TOS) byte (8-bits) field in the IP header of the packet. MIRROR Yes Yes Yes When this target is in use, the matched packet s source and destination addresses are reversed and the packet is retransmitted. MARK No Yes No This target is used to set the mark field value of a packet. The marking of a packet can be used by routers to change the routing behavior for such packets. MASQUERADE No No Yes This target is used to alter the source address of the matched packet. The source address is replaced with the IP address of the packet filter s interface, which the packet will go out from. This target is used for packet-filtering systems that use dynamic IP address to connect to another network (such as the Internet) and also acts as a gateway between the networks. If you have static a IP address for the interface that connects to the outside network, use SNAT target instead. Continued

6 496 Part V: Firewalls TABLE 20-1: TARGETS FOR RULES IN FILTER, MANGLE, AND NAT TABLES (Continued) Target filter mangle nat Description DNAT No No Yes This target specifies that the destination address of the packet should be modified. SNAT No No Yes This target specifies that the source address of the packet should be modified, including all future packets in this connection. REDIRECT No No Yes Redirect is another special type of NAT. All incoming connections are mapped onto the incoming interface s address, causing the packets to come to the local machine instead of passing through. This is useful for transparent proxies. LOG Yes Yes Yes This target allows you to log information regarding a matched IP packet. TTL No Yes No This target is used to modify the Time To Live (TTL) field of a matched IP packet. The iptables extended packet matching modules supply additional capabilities in the form of shared library add-ons and small kernel modules that provide additional functionality. The old ipchains and ipfwadm modules maintain backward compatibility. You can only load one of these two modules at a time. You can t have ipchains and iptables rules at the same time. I recommend upgrading to the latest, stable kernel so that you can use iptables of the netfilter subsystem. Enabling netfilter in the kernel To enable netfilter support you must ensure that you have enabled the netfilter support in the kernel itself. Here is how you can do that. 1. As root, run the menu config command from the /usr/src/linux directory.

7 Chapter 20: Firewalls, VPNs, and SSL Tunnels 497 I assume that you have downloaded and extracted the latest, stable Linux kernel from or a geographically closer mirror site. 2. From the main menu select Networking options submenu. From the Networking options submenu select the Network packet filtering (replaces ipchains) option to enable netfilter support. 3. Enter the IP: Netfilter Configuration submenu that appears when you complete step 2. Select the following options to be included as modules as shown, using <M>. <M> Connection tracking (required for masq/nat) <M> FTP protocol support (NEW) <M> Userspace queuing via NETLINK (EXPERIMENTAL) <M> IP tables support (required for filtering/masq/nat) <M> limit match support (NEW) <M> MAC address match support (NEW) <M> netfilter MARK match support (NEW) <M> Multiple port match support (NEW) <M> TOS match support (NEW) <M> Connection state match support (NEW) <M> Unclean match support (EXPERIMENTAL) (NEW) <M> Owner match support (EXPERIMENTAL) (NEW) <M> Packet filtering (NEW) <M> REJECT target support (NEW) <M> MIRROR target support (EXPERIMENTAL) (NEW) <M> Full NAT (NEW) <M> MASQUERADE target support (NEW) <M> REDIRECT target support (NEW) <M> Packet mangling (NEW) <M> TOS target support (NEW) <M> MARK target support (NEW) <M> LOG target support (NEW) < > ipchains (2.2-style) support < > ipfwadm (2.0-style) support I don t recommend using ipchains and ipfwadm support; they are in Linux past and, therefore, let them stay there! Don t select the Fast switching option; it s incompatible with packetfiltering support.

8 498 Part V: Firewalls 4. Compile, install, and boot up the new kernel. When the kernel is installed and compiled, you can start creating your packetfiltering rules. The next section shows how to do so with use of iptables. Creating Packet-Filtering Rules with iptables The iptables program is used to administer packet-filtering rules under the netfilter infrastructure. Here I provide you with the basics of how you can use this tool, but I strongly encourage you to read the man pages for iptables after you read this section. Another reason to read the man pages is that the iptables program has many command-line switches, but only the common ones are discussed here. Creating a default policy You can create a default policy for a given chain using the following syntax: /sbin/iptables -P chain_name target For example: /sbin/iptables -P input DENY /sbin/iptables -P output REJECT /sbin/iptables -P forward REJECT This is often considered as a preferred default policy for the filter table. Here all packets are denied or rejected by default. All packets that are input to the firewall system are denied; all packets that are generated by the firewall system itself are rejected; all packets that are to be forwarded through the system are also rejected. This is called the deny everything by default policy. Security experts prefer the concept of locking all doors and windows down and then opening the ones that are needed. This default packet-filtering policy serves the same purpose and is recommended by me. This policy, created using the combination of these three rules, should be always part of your packet-filtering firewall policy. Appending a rule To append a new rule to a specific chain, the syntax is /sbin/iptables -A chain_name rule_parameters -j target

9 Chapter 20: Firewalls, VPNs, and SSL Tunnels 499 For example: /sbin/iptables -A input -s j ACCEPT /sbin/iptables -A input -s /24 -j DROP Here both of the rules are appended to the input chain of the default table (filter). You can explicitly specify the filter table using the -t table_name option. For example, the following lines of code are exactly equivalent to the two rules mentioned earlier: /sbin/iptables -A input -t filter -s j ACCEPT /sbin/iptables -A input -t filter -s /24 -j DROP The very first rule specifies that any packet destined for the system from another host whose IP address is be accepted by the system. The second rule specifies that all IP packets from any host in the entire /24 network be dropped. Avid readers will notice that the first IP address is within the /24 network. So the second rule drops it! However, since the first matching rule wins, all the packets from the host are accepted even if the next rule says they should be dropped. So the order of rules is crucial. One exception to the first matching rule wins is the default policy rule any default policy rule, as in this example: /sbin/iptables -P input DENY /sbin/iptables -A input -t filter -s j ACCEPT /sbin/iptables -A input -t filter -s /24 -j DROP Here the very first rule denies all packets but since it is the default policy (denoted by the -P option) it still allows other rules to be examined. In other words, the position of a policy rule does not prohibit other rules from being evaluated. You can write chain names in upper case or lower case. For example, INPUT and input are both acceptable. Listing the rules To list all the rules in a chain, simply run /sbin/iptables -L chain_name. For example, /sbin/iptables -L input lists all the rules in the input chain of the default filter table.

10 500 Part V: Firewalls Deleting a rule To delete a rule from a chain, run /sbin/iptables -D chain_name rule_number. For example, /sbin/iptables -D input 1 deletes the first rule in the input chain of the default filter table. To delete all the rules from a given chain, run /sbin/iptables -F chain_name. For example, /sbin/iptables -F input flushes (that is, empties) all the rules in the input chain. You can also delete a rule by replacing the -A (append) option with -D (delete) option in your rule specification. For example, say that you have added the following rule: /sbin/iptables -A input -t filter -s /24 -j DROP Now if you want to delete it without listing all rules and determining the rule number as discussed earlier, simply do the following: /sbin/iptables -D input -t filter -s /24 -j DROP This deletes this rule. Inserting a new rule within a chain To insert a new rule in a specific chain at a specific position, the syntax is /sbin/iptables -I chain_name rule_number rule_parameters -j target For example: /sbin/iptables -I input 1 -s j ACCEPT This inserts the rule in the number one position in the input chain of the default filter table. Replacing a rule within a chain To replacing an existing rule in a specific chain at a specific position, the syntax is /sbin/iptables -R chain_name rule_number rule_parameters -j target For example: /sbin/iptables -R input 1 -s j ACCEPT

11 Chapter 20: Firewalls, VPNs, and SSL Tunnels 501 This replaces the rule in the number one position in the input chain of the default filter table with the new rule. You can use the iptables program to create/modify/delete rules and policies in packet-filtering firewalls. Creating SOHO Packet-Filtering Firewalls The Small Office/Home Office (SOHO) is a common phenomenon in a working world that has more small-business owners and telecommuters than ever before. The emergence of Digital Subscriber Line (DSL) and cable based Internet connections in recent years have made it possible for a full-time Internet connection for even the smallest home office. The drop in PC hardware price has given many SOHO owners a real chance at creating multinode networks. In this section I discuss how a SOHO can create a simple firewall system to take protective measures against the outside world of people with way too much time for hacking. Suppose that there are three machines on the network and all three of them have real, static IP addresses as shown. Here each machine has an IP address that can be routed on the Internet. Suppose also that you as the SOHO administrator decide to turn the Linux box into a firewall, as shown in Figure Internet DSL Router Hub Linux PC Win PC Mac Figure 20-1: A SOHO network Here the Linux PC has been set up with two Ethernet interfaces (eth0 and eth1). The eth0 is connected to the DSL router and it has a real IP address. The internal, private LAN interface of the Linux PC (eth1) has a private IP ( ) and the two other systems in this LAN also have private IP addresses.

12 502 Part V: Firewalls In this configuration, all outgoing packets from the private network flow through the Linux firewall machine to the outside world; similarly, all incoming packets from the Internet come to the private network via the firewall machine. This Linux PC must implement the following: IP forwarding to enable packet movement between eth0 and eth1 IP masquerading to dynamically alter the private IP addresses of the private LAN to its own external interface (eth0) address for the outside world Packet-filtering rules to protect access to the private LAN Enabling IP forwarding is quite easy. You can simply add the following command in the /etc/rc.d/rc.local script to enable IP forwarding when you boot up your Linux system. /sbin/sysctl -w net.ipv4.conf.all.forwarding=1 You can also execute it from the shell to turn on IP forwarding at any time. Since you have already enabled the netfilter support in the kernel as discussed in the previous section, you can enable the masquerading and packet filtering using iptables, as shown in the script called soho-firewall.sh, Listing Listing 20-1: soho-firewall.sh #!/bin/sh # Path of the iptables program IPTABLES=/sbin/iptables # Private LAN address INTERNAL_LAN= /24 # Private LAN Interface INTERNAL_LAN_INTERFACE= eth1 # Private LAN interface address INTERNAL_LAN_INTERFACE_ADDR= # External LAN Interface EXTERNAL_LAN_INTERFACE= eth0 # External LAN interface address EXTERNAL_LAN_INTERFACE_ADDR= # Flush all the current packet filtering rules $IPTABLES -F # Set default policy to deny everything $IPTABLES -P input DENY $IPTABLES -P output REJECT $IPTABLES -P forward REJECT # Enable local (loopback) interface

13 Chapter 20: Firewalls, VPNs, and SSL Tunnels 503 $IPTABLES -A input -i lo -j ACCEPT $IPTABLES -A output -i lo -j ACCEPT # Enable internal LAN access to the firewall s # internal interface $IPTABLES -A input -i $INTERNAL_LAN_INTERFACE \ -s $INTERNAL_LAN -j ACCEPT # Enable firewall generated packets destined for # the internal LAN $IPTABLES -A output -i $INTERNAL_LAN_INTERFACE \ -d $INTERNAL_LAN -j ACCEPT # Setup masquerading for everything not destined to # the internal LAN $IPTABLES -t nat -A POSTROUTING -o $ EXTERNAL_LAN_INTERFACE \ -d! $INTERNAL_LAN \ -j MASQUERADE # Only forward packets from internal LAN $IPTABLES -A FORWARD -s $INTERNAL_LAN -j ACCEPT $IPTABLES -A FORWARD -d $INTERNAL_LAN -j ACCEPT This script allows you to change the necessary variables to make it work in a similar, real-world environment. When the script is executed as shown in Listing 20-1, it effectively creates the following packet-filtering rules. /sbin/iptables -F /sbin/iptables -P input DENY /sbin/iptables -P output REJECT /sbin/iptables -P forward REJECT /sbin/iptables -A input -i lo -j ACCEPT /sbin/iptables -A output -i lo -j ACCEPT /sbin/iptables -A input -i eth1 -s /24 -j ACCEPT /sbin/iptables -A output -i eth1 -d /24 -j ACCEPT /sbin/iptables -t nat -A POSTROUTING -o eth0 -d! /24 -j MASQUERADE /sbin/iptables -A FORWARD -s /24 -j ACCEPT /sbin/iptables -A FORWARD -d /24 -j ACCEPT The script has these rules: The very first rule flushes all the existing rules in the filter table. The next three rules should be familiar to you since they are the default policy rules. These rules state that no packet can enter, leave, or be forwarded to/from this system. Basically, these three rules lock up the IP traffic completely.

14 504 Part V: Firewalls The next two rules enable traffic to and from the local loopback interface (lo) so that you can access other systems when logged onto the firewall machine itself. The next rule specifies that any packet with source IP residing in the /24 network be accepted on the eth1 interface. Remember that the eth1 interface in Figure 20-2 is the internal, private network interface of the firewall system. We want this interface to accept packets from other nodes (that is, hosts) in the private network. The next rule specifies that packets generated (that is, output) by the firewall itself for the /24 network be allowed. The next rule is the masquerading rule. It uses the nat table and the POSTROUTING chain. This rule states that all packets not destined for the /24 network be masqueraded. For example, if a packet from the Windows PC ( ) system destined for an external system with IP address is detected by the firewall machine, it changes the source address of this packet such that the sees (eth0) address as the source address. When response packet from arrives at , the NAT facility retranslates the destination address to be At this point, what you have is a firewall system that forwards masqueraded IP traffic to the external interface (eth0) but no inbound packet can be seen from the outside world by the internal, private network. You need to now categorically open connectivity from external interface to the internal network. Allowing users at private network access to external Web servers In this case you want to do the following: Outbound traffic rule Create a rule that allows the external interface of the firewall to send (that is, output) HTTP requests using the standard port 80. Inbound traffic rule Create a rule that allows the external interface of the firewall to receive (that is, input) HTTP responses from outside Web servers. Here is a rule that you can add to the soho-firewall.sh script to implement the outbound traffic rule: $IPTABLES -A output -i $EXTERNAL_LAN_INTERFACE -p tcp \ -s $EXTERNAL_LAN_INTERFACE_ADDR \ -d 0/0 80 -j ACCEPT

15 Chapter 20: Firewalls, VPNs, and SSL Tunnels 505 This rule looks as follows when shell script variables are substituted for appropriate values: /sbin/iptables -A output -i eth0 -p tcp \ -s \ -d 0/0 80 -j ACCEPT This rule allows the firewall to output HTTP packets on port 80 destined to any IP address using the external interface. The range specifies that the Web browser can use any of the non-privileged ports (that is, ports greater than ) in the connection and, therefore, the firewall will not block packets with such a source port number. Similarly, you need the following line in the script to accept HTTP response traffic destined for the external interface. $IPTABLES -A input -i $EXTERNAL_LAN_INTERFACE -p tcp! -y \ -s 0/0 80 \ -d $EXTERNAL_LAN_INTERFACE_ADDR \ -j ACCEPT In this case, packets sent by outside Web servers to the external interface of the firewall via the external IP address of the firewall as the destination are accepted for any unprivileged port as long as the source port is HTTP (80). As you can see, opening bi-directional connection requires that you know which port a particular service runs on. For example, suppose you want to allow the outside world access to your Web server in the private network. Allowing external Web browsers access to a Web server on your firewall Running a Web server on a firewall is not a good idea but might be necessary (resource wise) for a SOHO. In such case, you want to do the following: Create a rule that allows any IP address to connect to the HTTP port (80) on your firewall machine s external interface. Create a rule that allows the firewall/web server to respond to unprivileged ports (which Web clients use for client-side connection) when source IP address is any IP and source port is HTTP (80). The following lines can be added to the soho-firewall.sh script to implement these rules. # Allow any IP to connect to firewall s external # interface to send a HTTP request for the

16 506 Part V: Firewalls # internal network $IPTABLES -A input -i $EXTERNAL_LAN_INTERFACE -p tcp! -y \ -s 0/ \ -d $EXTERNAL_LAN_INTERFACE_ADDR 80 \ -j ACCEPT # Allow internal HTTP response to go out to the # world via the external interface of the firewall $IPTABLES -A output -i $EXTERNAL_LAN_INTERFACE -p tcp \ -s $EXTERNAL_LAN_INTERFACE_ADDR 80 \ -d 0/ \ -j ACCEPT If you want to enable HTTPS (Secure HTTP) connections, add the following lines: # Enable incoming HTTPS connections $IPTABLES -A input -i $EXTERNAL_LAN_INTERFACE -p tcp! -y \ -s 0/0 443 \ -d $EXTERNAL_LAN_INTERFACE_ADDR \ -j ACCEPT # Enable outgoing HTTPS connections $IPTABLES -A output -i $EXTERNAL_LAN_INTERFACE -p tcp \ -s $EXTERNAL_LAN_INTERFACE_ADDR \ -d 0/0 443 \ -j ACCEPT In order to interact with the Internet, you are most likely to need a few other services enabled, such as DNS, SMTP, POP3, and SSH. In the following sections, I show you how. DNS client and cache-only services In a SOHO environment you are likely to use your ISP s name server for resolving DNS queries or you can use a caching only, local name server to boost your overall DNS related performance. First, suppose that you only want to enable access to the remote DNS server at your ISP network. Suppose that you have set up the following variable in the soho-firewall.sh script to point to the IP address of the name server. NAMED_ADDR=

17 Chapter 20: Firewalls, VPNs, and SSL Tunnels 507 Now, to allow your private network to access the name server, you should add the following lines in the script. # Allow packets from external interface of the # firewall to access an outside named server $IPTABLES -A output -i $EXTERNAL_LAN_INTERFACE -p udp \ -s $EXTERNAL_LAN_INTERFACE_ADDR \ -d $NAMED_ADDR 53 \ -j ACCEPT # Allow an external named to respond to internal # request by delivering query response packets # to external interface of the firewall $IPTABLES -A input -i $EXTERNAL_LAN_INTERFACE -p udp \ -s $NAMED_ADDR 53 \ -d $EXTERNAL_LAN_INTERFACE_ADDR \ -j ACCEPT The very first rule ensures that the firewall allows outputting of DNS query packets on port 53 via the UDP protocol. The second rule ensures that the firewall allows DNS query response packets originating from the name server to be accepted. Sometimes, when the DNS response is too large to fit in a UDP packet, a name server uses a TCP packet to respond.this occurs rarely unless you have systems in your internal network that want to perform DNS zone transfers, which are often large. If you want to ensure that rare large DNS responses are handled properly, add two more of the same rules as shown above except replace the -p udp protocol to -p tcp. Also use the! -y option for the input rule. Now if you run a DNS server internally on the private LAN or even on the firewall machine (not recommended), then you need to allow the caching server to perform DNS queries to your ISP s DNS server when it cannot resolve an internal request from the cache. In such case, add the following lines to the same script. # Allow DNS resolver to connect to external # name server on port 53 $IPTABLES -A output -i $EXTERNAL_LAN_INTERFACE -p udp \ -s $EXTERNAL_LAN_INTERFACE_ADDR 53 \ -d $NAMED_ADDR 53 \

18 508 Part V: Firewalls -j ACCEPT # Allow external name server to connect to firewall # system s external interface in response to a # resolver query $IPTABLES -A input -i $EXTERNAL_LAN_INTERFACE -p udp \ -s $NAMED_ADDR 53 \ -d $EXTERNAL_LAN_INTERFACE_ADDR 53 \ -j ACCEPT SMTP client service To access SMTP mail server from the internal network, add the following lines in the soho-firewall.sh script # Change the SMTP server IP address as needed SMTP_SERVER_ADDR= # Enable outgoing SMTP connections $IPTABLES -A output -i $EXTERNAL_LAN_INTERFACE -p tcp \ -s $EXTERNAL_LAN_INTERFACE_ADDR \ -d $SMTP_SERVER_ADDR 25 \ -j ACCEPT # Enable incoming SMTP responses from external SMTP # server $IPTABLES -A input -i $EXTERNAL_LAN_INTERFACE -p tcp! -y \ -s $SMTP_SERVER_ADDR 25 \ -d $EXTERNAL_LAN_INTERFACE_ADDR \ -j ACCEPT POP3 client service To access POP3 mail server from the internal network, add the following lines in the soho-firewall.sh script. # Change the POP3 server IP address as needed POP_SERVER_ADDR= # Enable outgoing POP3 connections $IPTABLES -A output -i $EXTERNAL_LAN_INTERFACE -p tcp! -y \ -s $EXTERNAL_LAN_INTERFACE_ADDR \ -d $POP_SERVER_ADDR 110 \ -j ACCEPT

19 Chapter 20: Firewalls, VPNs, and SSL Tunnels 509 # Enable incoming POP3 responses from external POP3 # server $IPTABLES -A input -i $EXTERNAL_LAN_INTERFACE -p tcp! -y \ -s $POP_SERVER_ADDR 110 \ -d $EXTERNAL_LAN_INTERFACE_ADDR \ -j ACCEPT Passive-mode FTP client service To access FTP server from the internal network, add the following lines in the soho-firewall.sh script. # Change the FTP server IP address as needed FTP_SERVER_ADDR= # Enable outgoing FTP connections $IPTABLES -A output -i $EXTERNAL_LAN_INTERFACE -p tcp! -y \ -s $EXTERNAL_LAN_INTERFACE_ADDR \ -d $POP_SERVER_ADDR 21 \ -j ACCEPT # Enable incoming FTP command responses from # external FTP server $IPTABLES -A input -i $EXTERNAL_LAN_INTERFACE -p tcp! -y \ -s $FTP_SERVER_ADDR 21 \ -d $EXTERNAL_LAN_INTERFACE_ADDR \ -j ACCEPT # Enable passive mode data connections $IPTABLES -A output -i $EXTERNAL_LAN_INTERFACE -p tcp! -y \ -s $EXTERNAL_LAN_INTERFACE_ADDR \ -d $POP_SERVER_ADDR \ -j ACCEPT # Enable passive mode data response $IPTABLES -A input -i $EXTERNAL_LAN_INTERFACE -p tcp! -y \ -s $FTP_SERVER_ADDR \ -d $EXTERNAL_LAN_INTERFACE_ADDR \ -j ACCEPT

20 510 Part V: Firewalls SSH client service If you want to allow SSH client connection to an external SSH server, add the following lines in the soho-firewall.sh script. # Set the IP address of your external SSH server # here. A random IP address is used in this example # EXTERNAL_SSH_SERVER_ADDR= # Allow the firewall to connect to SSH server # for the masquerading nodes behind it that want # to connect to the SSH server $IPTABLES -A output -i $EXTERNAL_LAN_INTERFACE -p tcp \ -s $EXTERNAL_LAN_INTERFACE_ADDR \ -d $ EXTERNAL_SSH_SERVER_ADDR 22 \ -j ACCEPT # Allow an external SSH server to deliver SSH packets # to the external interface of the firewall $IPTABLES -A input -i $EXTERNAL_LAN_INTERFACE -p tcp! -y \ -s $EXTERNAL_SSH_SERVER_ADDR 22 \ -d $EXTERNAL_LAN_INTERFACE_ADDR \ -j ACCEPT Note that SSH clients use 1020 or higher ports and, therefore, you need to use range. Other new client service Once you have identified a new service that you want to control using the firewall, do the following: 1. Determine what server (SERVER_ADDR) you want to access from the internal network. 2. Determine what ports are going to be used in such connectivity. Most likely the service uses a port defined in /etc/services file. Find that port (ASSIGNED_PORT). 3. Determine what ports the client software uses for the client-side of the connection. Typically, the unassigned ports ( ) are used. 4. Determine what protocol is being used, TCP or UDP. For TCP protocol, use the -t tcp and! -y options for UDP, use -t udp option.

21 Chapter 20: Firewalls, VPNs, and SSL Tunnels Create an output rule that allows the external interface of the firewall to send packets to the server. Internal clients can access the internal interface of the firewall and their requests for the external service is automatically forwarded to the external interface. And this is why we create the output rule for the external interface. This rule appears as follows: /sbin/iptables -A output -i external_interface \ -p protocol_name \ -s external_interface_address UNASSIGNED_PORTS \ -d external_server_address ASSIGNED_PORT \ -j ACCEPT 6. Create an input rule that allows the external server to respond with packets. The rule looks like this: /sbin/iptables -A input -i external_interface \ -p protocol_name [! -y ] \ -s external_server_address ASSIGNED_PORT \ -d external_interface_address UNASSIGNED_PORTS \ -j ACCEPT Creating a Simple Firewall There are times when I am asked to create a simple firewall. Yes, there are people who ask such questions. They want security, complete flexibility in everything, which reminds me of the phrase have your cake and eat it too. In such cases, I simply create the following rules in a script called /etc/rc.d/firewalldummy.sh: #!/bin/sh # # Packet filtering firewall for dummies # IPTABLES=/sbin/iptables # Drop all rules in the filter table $IPTABLES -F FORWARD $IPTABLES -F INPUT $IPTABLES -F OUTPUT # Create default drop-and-reject-everything policy $IPTABLES -P input DENY

22 512 Part V: Firewalls $IPTABLES -P output REJECT $IPTABLES -P forward REJECT # Enable loopback $IPTABLES -A INPUT -i lo -p all -j ACCEPT # Enable ICMP. Yes, even a dummy knows # how to use ping these days! $IPTABLES -A INPUT -p icmp -j ACCEPT # Enable caching DNS $IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT $IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT # We do not want to allow new connection so # accept only those incoming packets that do # not have the SYN flag set. In other words, # these packets are not new connection requests $IPTABLES -A INPUT -p tcp! --syn \ --dport :1023 -j ACCEPT \ -- syn -- dport :1023 -j ACCEPT # Most everything that a Internet dummy does # need unprivileged port access for both TCP and UDP # so enable them $IPTABLES -A INPUT -p tcp --dport 1024: -j ACCEPT $IPTABLES -A INPUT -p udp --dport 1024: -j ACCEPT Creating Transparent, proxy-arp Firewalls Suppose that you have a small office where several Linux/Windows 9x/2K/NT machines are connected to the internet using a modem or DSL/cable/ISDN router. You want to allow the world access to the Web server in your network and also want to implement some of the packet-filtering rules you learned earlier. Suppose your ISP provided you with an Internet connection via the network X.Y.Z.32/27. You have each machine on the network use the X.Y.Z.35 address as its Internet gateway address which allows each machine to send and receive packets to and from the outside world. Now you have two choices for your firewall: Set up a firewall machine between your LAN and the Internet feed (which is the typical place for a firewall).

23 Chapter 20: Firewalls, VPNs, and SSL Tunnels 513 The problem with the typical placement of a firewall is that if the firewall machine is down, the entire LAN is disconnected from the Internet. If Internet access is a big part of your business, that spells trouble especially for a small company. Use a transparent proxy-arp firewall. In this case, the firewall machine is less of a potential obstacle to your company s Internet connection. If the firewall machine is down, you can simply take out the network cable connected to eth0 on the firewall and reconnect it to the hub on the other side (eth1 side) and you should have full Internet connectivity. You might need to have your ISP refresh the arp cache and/or reboot some of your machines, but your network regains Internet access in a very short time. The idea behind this setup is as follows: the Linux firewall machine has two network interfaces eth0 and eth1 set to the same IP address (X.Y.Z.50) and has APR proxying and IP forwarding turned on. This allows the machine to see all the packets that are either originated from your LAN or that are coming to your LAN from the outside world via the ISP feed. Therefore, you can use packet filtering on such packets like a regular firewall system. The only real advantage is that if the firewall is down for upgrade, or other uncontrollable reasons, you can recover your connectivity in a much shorter time than if you had a regular firewall configuration where you had private IP addresses for your LAN and all the hosts were pointing to the firewall as their gateway to the Internet. In this configuration, the host machines don t even know that their packets are being scanned, forwarded by the man-in-the-middle type of transparent proxy-arp based firewall system. Assuming that you have a Linux system with two Ethernet network cards (eth0, eth1) installed, here is how you can create such as a setup. 1. As root, you need to create a custom kernel that supports netfilters. You can use the make menuconfig command to set this option from the /usr/src/linux directory. Select the [ ] Network packet filtering (replaces ipchains) from the Networking options submenu from the main menu and compile, install, and test your new kernel. For help in compiling, installing, and booting a new kernel, see Chapter Download and install the iproute package using RPM. For example, I installed the iproute rpm package, which I downloaded from a RPM mirror site called

24 514 Part V: Firewalls 3. Set up both of the /etc/sysconfig/network-scripts/ifcfg-eth0 and /etc/sysconfig/network-scripts/ifcfg-eth1 to have the same IP address Network address Network mask 4. Add the following lines in your /etc/rc.d/rc.local script to enable the proxy_arp feature for both of your Linux network interfaces. /sbin/sysctl net.ipv4.conf.eth0.proxy_arp=1 /sbin/sysctl net.ipv4.conf.eth1.proxy_arp=1 5. Add the following line in /etc/rc.d/rc.local script to enable IP forwarding between the eth0 and eth1 interfaces. /sbin/sysctl -w net.ipv4.conf.all.forwarding=1 6. Add the following lines in your /etc/rc.d/rc.local script. Don t forget to replace the X.Y.Z.32/27, X.Y.Z.35 with appropriate network addresses. /sbin/ip route del X.Y.Z.32/27 dev eth0 /sbin/ip route add X.Y.Z.35 dev eth0 /sbin/ip route add X.Y.Z.32/27 dev eth1 This tells the kernel that packets for the X.Y.Z.35 address (that is, the address of the router) is routed on eth0 and the rest of the network is available on eth1. Since you have enabled IP forwarding between the interfaces, any outside packet destined for an internal LAN host are seen by eth0 and forwarded onto eth1. At this point, either you can wait awhile for the arp caches to expire or restart your router. At that point you should be able to get back and forth between the router and the other servers on the network. If you look at your arp cache on a server, it will show the mac address of the router as the mac address of eth1 on your Linux firewall. After you have this layer working, you can add your rules. Creating Corporate Firewalls A corporation that has a lot of day-to-day Internet interaction is likely to spend quite a bit of resource in building a secure infrastructure. Here, I explore one such infrastructure that you can build with a set of Linux-based packet-filtering firewalls. Note that a packet-filtering firewall is only one of the important components in a high-grade security solution. As a rule of thumb, multiple (and redundant) security measures ensure a higher degree of security. This section focuses only on

25 Chapter 20: Firewalls, VPNs, and SSL Tunnels 515 the packet-filtering aspect of the solution; later sections cover other security components that you can integrate with packet filtering to build a robust, well-secured environment for your organization. A multiple-firewall environment, known as a Demilitarized Zone (DMZ), keeps the corporate public servers such as the Web server (Apache server), FTP server, mail server, and DNS server (if any) behind the primary firewall. The internal network (consisting of employee workstations, and possibly internal-only servers) resides behind another, separate firewall. Each of these firewalls has a distinct purpose; an examination of each purpose follows. Purpose of the internal firewall The internal firewall protects the internal network from outside access. It forwards non-local traffic to the DMZ and restricts incoming traffic. This firewall should be configured to do the following: Implement the default deny-all-packets policy. Masquerade the internal traffic meant for the DMZ services or for the outside world. Allow only incoming traffic that has been generated in response to internal requests. Incoming packets to this firewall must not have SYN bit set. Limit the internal network s access to outside services Purpose of the primary firewall The external (primary) firewall protects the entire corporate network, but its main task is to do the following: Implement the default deny all packets policy. Allow access to the DMZ servers from the outside world. Masquerade the packets that are generated by the internal firewall (on behalf of internal nodes) to the outside world to make the packets appear to be coming from the primary firewall s external interface. When the firewall is doing its job correctly, a typical scenario looks like this: 1. A user at a workstation in the internal LAN initiates a HTTP request for an outside domain via her Web browser. 2. The internal firewall masquerades her requests to its own external interface (the DMZ site).

26 516 Part V: Firewalls 3. The primary firewall sees this outgoing packet, masquerades it, and forwards to the outside world. 4. The Web server on the outside knows only that the external IP address of the primary firewall has requested access to an outside domain. Accordingly, the Web server sends response packets to the DMZ site, which ensures that outside systems do not know who the real user is and (more importantly) can t get hold of the user-account information for unauthorized uses. Note that you can decide to not masquerade outgoing packets on the internal firewall the external firewall masquerades them anyway but if you masquerade outgoing packets on the internal firewall, you can use simpler packet-filtering rules on the external (primary) firewall. When implemented consistently, such an arrangement can enhance performance without harming security. Because the primary firewall sees all packets from the internal network as coming from one address that of the internal firewall s external interface that one IP is the only one you have to deal with when you create access rules on the primary firewall. In this example, I use a DMZ network /24 (actually a private network) but in the real world, you cannot access a non-routable, private network from the Internet. You have to use an Internet-routable, non-private network for your real-world DMZ. Ask your ISP to allocate a subnet to your company s use and to route all packets addressed to the subnet to your firewall s external interface address instead. Then assign each server in your DMZ a real IP address to make them accessible from the outside world via the firewall. Note also that the external network address for the primary firewall is also assigned by your ISP; the example uses a random number that is routable on the Internet. Implementing these firewalls for the given scenario is a distinct process. Note that when you follw the instructions in the next two subsections, you must change IP addresses to match those on your own network environment. Setting up the internal firewall To set up your internal firewall, follow these steps: 1. Create an sh script (called internal-firewall.sh) that defines the settings of the internal network as follows: #!/bin/sh IPTABLES=/sbin/iptables INTERNAL_LAN= /24

27 Chapter 20: Firewalls, VPNs, and SSL Tunnels 517 INTERNAL_LAN_INTERFACE= eth1 INTERNAL_LAN_INTERFACE_ADDR= EXTERNAL_INTERFACE= eth0 EXTERNAL_INTERFACE_ADDR= Flush out all the rules in the filter table by appending the following lines to the script: # Drop all rules in the filter table $IPTABLES -F FORWARD $IPTABLES -F INPUT $IPTABLES -F OUTPUT 3. Implement the default policy by appending the following lines to the script: # Create default drop and reject everything policy $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT ACCEPT $IPTABLES -P INPUT DROP 4. Enable the local loopback interface by appending these lines: # Enable loopback $IPTABLES -A INPUT -i lo -p all -j ACCEPT 5. Enable the Internet Control Message Protocol (ICMP) packets used by ping and other services: $IPTABLES -A INPUT -p icmp -j ACCEPT 6. Allow internal LAN access to the firewall s internal interface by appending these lines: $IPTABLES -A input -i $INTERNAL_LAN_INTERFACE \ -s $INTERNAL_LAN -j ACCEPT 7. Allow access to firewall-generated packets destined for the internal LAN: $IPTABLES -A output -i $INTERNAL_LAN_INTERFACE \ -d $INTERNAL_LAN -j ACCEPT 8. Set up masquerading for everything not destined for the internal LAN: $IPTABLES -t nat -A POSTROUTING -o $EXTERNAL_LAN_INTERFACE \ -d! $INTERNAL_LAN \ -j MASQUERADE 9. Forward only those packets that come from the internal LAN by appending these lines: $IPTABLES -A FORWARD -s $INTERNAL_LAN -j ACCEPT $IPTABLES -A FORWARD -d $INTERNAL_LAN -j ACCEPT

28 518 Part V: Firewalls At this point, you have a firewall that can masquerade internal traffic meant for outside servers. Now you have to decide what types of services your internal users may access for example, HTTP, SMTP, POP3, DNS, and AUTH (part of identd) and create specific firewall rules for each service. Setting up the primary firewall To set up your external (primary) firewall, create an sh script called firewallprimary.sh script, as shown in Listing Listing 20-2: Firewall-primary.sh #!/bin/sh IPTABLES=/sbin/iptables DMZ_LAN= /24 DMZ_INTERFACE= eth1 DMZ_INTERFACE_ADDR= WORLD_INTERFACE= eth0 WORLD_INTERFACE_ADDR= INTERNAL_LAN= /24 DMZ_FTP_SERVER_ADDR= DMZ_APACHE_SERVER_ADDR= DMZ_MAIL_SERVER_ADDR= DMZ_DNS_SERVER_ADDR= # Drop all rules in the filter table $IPTABLES -F FORWARD $IPTABLES -F INPUT $IPTABLES -F OUTPUT # Create default drop and reject everything policy $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT ACCEPT $IPTABLES -P INPUT DROP # Enable loopback $IPTABLES -A INPUT -i lo -p all -j ACCEPT # Enable the Internet Control Message Protocol (ICMP) # packets that are used by ping and others $IPTABLES -A INPUT -p icmp -j ACCEPT # Enable DMZ LAN access to the firewall s # internal interface $IPTABLES -A input -i $DMZ_LAN_INTERFACE \ -s $DMZ_LAN -j ACCEPT # Enable firewall generated packets destined for # the DMZ LAN $IPTABLES -A output -i $DMZ_LAN_INTERFACE \

29 Chapter 20: Firewalls, VPNs, and SSL Tunnels 519 -d $DMZ_LAN -j ACCEPT # Setup masquerading for packets generated by the # internal private LAN that is not meant for itself $IPTABLES -t nat -A POSTROUTING -o $EXTERNAL_LAN_INTERFACE \ -s $INTERNAL_LAN \ -d! $INTERNAL_LAN \ -j MASQUERADE # Forward packets from DMZ LAN $IPTABLES -A FORWARD -s $DMZ_LAN -j ACCEPT $IPTABLES -A FORWARD -d $DMZ_LAN -j ACCEPT The next step is to add rules to enable the services offered in the DMZ. ACCESSING FTP SERVERS IN YOUR DMZ You want to allow FTP server access from the outside world, but you also want to regulate it to prevent FTP from becoming a security risk. The following code lays the foundation for such a policy: # Enable incoming FTP connections from # outside world $IPTABLES -A input -i $WORLD_INTERFACE -p tcp \ -s 0/ \ -d $DMZ_FTP_SERVER_ADDR 21\ -j ACCEPT # Enable outgoing FTP connections $IPTABLES -A output -i $WORLD_INTERFACE -p tcp! -y \ -s $DMZ_FTP_SERVER_ADDR 21 \ -d 0/ \ -j ACCEPT # Enable incoming FTP data channel connection from # outside world $IPTABLES -A input -i $WORLD_INTERFACE -p tcp \ -s 0/ \ -d $DMZ_FTP_SERVER_ADDR \ -j ACCEPT # Enable outgoing FTP data connections $IPTABLES -A output -i $WORLD_INTERFACE -p tcp! -y \ -s $DMZ_FTP_SERVER_ADDR \ -d 0/ \ -j ACCEPT

30 520 Part V: Firewalls ACCESSING APACHE SERVERS IN DMZ You want to allow Apache server access from the outside world. Here is the script: # Enable incoming HTTP requests from # outside world $IPTABLES -A input -i $WORLD_INTERFACE -p tcp \ -s 0/ \ -d $DMZ_APACHE_SERVER_ADDR 80\ -j ACCEPT # Enable outgoing HTTP responses $IPTABLES -A output -i $WORLD_INTERFACE -p tcp! -y \ -s $DMZ_APACHE_SERVER_ADDR 80 \ -d 0/ \ -j ACCEPT ACCESSING DNS SERVERS IN DMZ You want to allow DNS server access from the outside world. Here is the script: # Enable incoming client/server DNS requests from # outside world $IPTABLES -A input -i $WORLD_INTERFACE -p udp \ -s 0/ \ -d $DMZ_DNS_SERVER_ADDR 53\ -j ACCEPT # Enable outgoing client/server DNS responses $IPTABLES -A output -i $WORLD_INTERFACE -p udp \ -s $DMZ_DNS_SERVER_ADDR 53 \ -d 0/ \ -j ACCEPT # Enable incoming server/server DNS requests from # outside world $IPTABLES -A input -i $WORLD_INTERFACE -p udp \ -s 0/0 53 \ -d $DMZ_DNS_SERVER_ADDR 53\ -j ACCEPT # Enable outgoing server/server DNS responses $IPTABLES -A output -i $WORLD_INTERFACE -p udp \ -s $DMZ_DNS_SERVER_ADDR 53 \ -d 0/0 53 \ -j ACCEPT