|
setting up a Linux firewall
by Juan Matus
Juan Matus gave up being a Yaqui sorcerer to work as a system
administrator because the work is more challenging. He now manages a
small mixed network of Linux and Microsoft systems.
My target audience is people with small networks and a full-time (non-dialup) direct link to an ISP. (For a reasonable cost, you can have a directional antenna on the roof giving 2 megabits per second.) The network topology is very simple. The firewall is a PC with two network interface cards (NICs). One card connects to your local network, and the other connects to your ISP. All packets from the Internet have to pass through the firewall to get to your local network. A firewall is only one component in your overall security plan. Gray[1] has a good general discussion of security, and there are also the classic firewall books (Cheswick[6] and Chapman[7]) for a deeper understanding of the issues. Getting Started When installing your firewall, load only the software you understand and disable any software that you don't understand. If you don't have time to understand all the details, then install open systems where the design has been reviewed and critiqued by many people worldwide. If you are forced to use Microsoft's black boxes, then beware. To sum it up, the KISS principle applies: Keep It Simple, Stupid! Although OpenBSD or FreeBSD may be more secure, Linux works well. Linux has also got enough mindshare among technical managers that justifying its use has become routine. You will want to use a newer version of Linux, such as Red Hat 6.0 on CD. This kernel has built-in support for ipchains. You may need to download and build ipchains, a package that includes the administrative commands with some other versions of Linux. (The HOWTO URL[3] has pointers for finding source.) For instructions on installing Linux, start browsing at <https://www.linux.org/>, or just boot from the CD and give it a whirl. The firewall PC can be a surplus Pentium 200 or similar box with whatever network interface cards are available. Linux will work with many network card types, but not all. You will have best luck with newer 3COM cards or those based on the DEC Tulip chipset. PCI cards are preferred because you don't have to assign IRQs (generally). Your hard disk should be large enough for the log files, at least 1 or 2 GB. My examples assume that your local network has the address 192.168.0.0, because this is reserved for networks that are not connected to the Internet. If a packet from your local network gets out onto the Internet, routers will drop any responses back to your network. Also, no one can route a packet to you from the Internet (although someone located at your ISP can certainly attempt to route a packet to your internal network). As you install Linux, let's assume you put in 192.168.0.15 for the IP address and 255.255.255.0 for the netmask for the internal interface, and the address and netmask assigned by your ISP for the external interface. Viewed from the back (or top in the case of a tower) the first network PCI card will be on the left (top). When Linux has been installed, the kernel should detect the network cards at boot time. The kernel will write some details to the screen. This information also goes to /var/log/messages. Use ifconfig -a to check that the cards are up, and check the activity lights on the cards. The interfaces will be called eth0 and eth1. I will assume that you have eth0 on your LAN and eth1 connected to the ISP. OS Configuration Log in as root with the X11 window system (if you installed it). Shut down all unneeded services by editing /etc/inetd.conf and commenting out most lines in the file. You might consider commenting everything out, then disabling inetd itself. Go into the /etc/rc.d/ directory tree and disable any unneeded processes and anything that you don't understand. You can disable processes using the GUI-based "Runlevel Editor," or you can go into rc5.d and change the links by hand. Then reboot and try things out. If you have disabled too much (for example, S10network), X11 won't work anymore, but you can still use the alternate consoles (Alt and function keys) to log in. You will need networking, but not S15netfs or S11portmap. You can use the ps command to list running processes, or use netstat to list listening Internet services: [root@firewall]# netstat -aep --inet ...
There will be some processes associated with the LISTEN state on a port. Are there any that you did not expect? The DNS process is named, and it is probably okay. However, you probably want to disable the ftp server. The sunrpc portmap process is mostly needed by NFS, and you disabled that, so let's make sure you disable portmap too. You might want to disable sendmail until you understand it better. sendmail is much more secure now than it was in the past, and maybe it could be left enabled. If you have the time, you can install an alternate mail package such as exim (<https://www.exim.org/>), qmail (<https://www.qmail.org/>), or postfix (<https://www.porcupine.org/postfix-mirror/start.html>). For our example, we have disabled sendmail on the firewall because we will use port forwarding to direct SMTP connections to an internal server. There is a new window system called GNOME running on top of X11. GNOME components open sockets, and in the spirit of disabling anything you don't understand, you will want to shut down GNOME. The window-manager menus will let you select the alternative FVWM. (I can imagine the GNOME developers getting steamed up at this point, as they have put much work into a really impressive desktop. Sorry, we are setting up a firewall, not a workstation.) In the menus you will find a simple GUI tool called "Network Configurator" to help assign IP addresses and netmasks. It just changes the text file /etc/sysconfig/network, and any changes take effect on a reboot. You need to enable IPV4 forwarding and set the IP address for eth1 (if you didn't do this during installation). Let's assume that your ISP has assigned you the 223.56.222.4 network with a netmask of 255.255.255.252. Let's assume that your eth1 address must be set to 223.56.222.6. Your ISP has set the Domain Name System to point yourcorp.com to the latter IP address. With such a restrictive netmask, that box that connects to the rooftop antenna must respond to 223.56.222.5. The latter number must be put in the Gateway field of the Sysconfig tool. If you have a direct connection, you will use the address of the router at your ISP's end of the connection. Outgoing Connections There are two approaches to firewalling. You can filter at the packet level or at the application level. In the latter case, you set up a proxy server on the firewall, and all connections are made via this server. The proxy server can take better control of the connections, and you can set up user-authentication mechanisms if desired. However, the server can be more trouble to set up than a simple packet filter, and performance will suffer slightly. For connection speeds less than 10MBs and small networks, performance should never be a problem. Both approaches, packet filtering and proxy server, will be discussed below. For outgoing HTTP and FTP connections, we can run a socks proxy server on the firewall. All the hosts on the local network will connect to port 1080 (socks) on the firewall, and the socks daemon will make the appropriate connection across the Internet. The (hidden) local hosts will appear on the Internet as if they were at 223.56.222.6. You can get socks5-v1.0r9.tar.gz from <https://www.socks.nec.com/cgi-bin/download.pl> and build it. You will need a startup file in /etc/rc.d/init.d/socks:
#!/bin/bash
exit 0 The SOCKS5_V4SUPPORT=1 flag is needed because the currently available Netscape and Internet Explorer browsers support only version 4 of the protocol. Go to rc3.d and link S25socks to /etc/rc.d/init.d/socks. Do the same in rc4.d and rc5.d. Now edit the /etc/socks5.conf file:
# A socks5 Config file for a dual homed server
The dashes are wildcards, so they will accept any value. Now go to each host on the local network and set the browser options so it uses the socks proxy server (port 1080 on host 192.168.0.15). Also set each host to use DNS on your firewall. Now you should be able to use your browser to access HTTP and FTP sites. Note that a standalone FTP client program will not work unless it knows about the socks proxy. There is a kernel module that can support FTP clients through the use of ipchains (see Russell's IPCHAINS-HOWTO[3]). You can also get also socksified telnet, finger, ping, traceroute, and archie. Incoming Connections You will want to permit machines on the Internet to connect to some services on hosts on the local network. For example, you might permit SMTP connections to a mail host on the local network. However, you want to block connections to most services. When connections are permitted, they will be to the firewall's externally visible IP address (223.56.222.6), and the firewall will rewrite each incoming packet with the address of a host on the local network. Packets flowing in the return direction will be rewritten to appear to come from the firewall. In the RFCs, this is known as Network Address Translation (NAT). In the Linux world, it is known as Masquerading with Port Forwarding. Performance will be excellent because the packet processing is done by networking code in the kernel. The Red Hat 6.0 kernel is already configured correctly for our purposes, with the exception of the following patch. You will need to build and install ipmasqadm-0.4.2.tar.gz from <https://juanjox.kernelnotes.org/>. This includes some tools used in port forwarding, which is explained below. The ipchains command has three chains, one named input for packets destined to the firewall, one named output for packets originating at the firewall, and one named forward for packets being transferred across the firewall (as if the system were a router, forwarding packets between networks). Let's add some lines to /etc/rc.d/rc.local. The syntax of the ipchains command is complex, so I hope the following working example helps you.
# clear the forward chain
The -F flags flush existing rules from the named chains. The DENY rule will drop packets silently. For debugging, you might want to temporarily replace it with a REJECT rule, which will return a RESET instead of silently dropping packets.
#for debugging:
The -P flag establishes a policy, that is, REJECT any forwarded packets by default. Now, let's add lines to set up forwarding to an internal email server in /etc/rc.d/rc.local:
# forward incoming packets to the mail server with masq
The -A flag appends this rule to the forward chain. The arguments set up the protocol (-p tcp), server name/address (-s $server), and port address (25 for sendmail), and enable masquerading (-j MASQ). This rule is needed for the port forwarding below.
# allow outgoing e-mail
This rule allows outgoing connections from the mail server at 192.168.0.27 to port 25 of any host on the Internet. Connections will appear to come from the firewall.
# log anything which does not match the above rules
This rule causes ipchains to write to the log when an unwanted packet is about to be dropped. This can help you debug your rules. When you have the rules right, any log entries could show rogue packets. This sort of logging is a mixed blessing. If you don't check /var/log/messages regularly, an attempted break-in can easily be overlooked. You can add more ipchains rules as desired, perhaps rules to log any unwelcome port scanning. Now, the port-forwarding rules:
# flush any existing rules
The -L internet must match a line in the /etc/hosts file defining internet as the IP address of the eth1 interface, 223.56.222.6. The portfw rules work with a previous MASQ rule to permit incoming connections to the mail host at 192.168.0.27. Normally, the MASQ rule causes an outgoing connection to be rewritten for masquerading. The portfw rule turns the MASQ rule around so that the connection can be incoming. You should test this from a host somewhere on the Internet. Do something like telnet yourcorp.com 25 You should now see SMTP responses from your mail host. Incoming mail should now get through, assuming that your mailhost is configured correctly. Resources [1] First, read Bob Gray's article on security. <https://boulderlabs.com/7.security> [2] Firewall and Proxy Server HOWTO by Mark Grennan. <https://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html> [3] Linux IPCHAINS-HOWTO by Paul Russell. <https://www.rustcorp.com/linux/ipchains/HOWTO.html> [4] The Linux IP Masquerade Resource. <https://members.home.net/ipmasq/> [5] The X/OS Linux firewall site. <https://www.xos.nl/linux/ipfwadm/paper/linuxfw2.html> [6] Bill Cheswick and Steven Bellovin, Firewalls and Internet Security. Reading, MA: Addison-Wesley, 1994. (Contains an extensive bibliography.) [7] Brent Chapman and Elizabeth Zwicky, Building Internet Firewalls. Sebastopol: O'Reilly & Associates, 1996. [8] socks5 configuration samples. <https://www.socks.nec.com/s5examples.html> There are many Linux Web sites for firewalling and security. You can spend many hours following links from the sites mentioned above.
|
 Need help? Use our Contacts page.
Last changed: 8 Dec. 1999 mc |
|
Issue index