Upcoming Events

Where the Cloud Touches Down: Simplifying Data Center Infrastructure Management

Thursday, July 25, 2013
10:00 AM PT/1:00 PM ET

In most data centers, DCIM rests on a shaky foundation of manual record keeping and scattered documentation. OpManager replaces data center documentation with a single repository for data, QRCodes for asset tracking, accurate 3D mapping of asset locations, and a configuration management database (CMDB). In this webcast, sponsored by ManageEngine, you will see how a real-world datacenter mapping stored in racktables gets imported into OpManager, which then provides a 3D visualization of where assets actually are. You'll also see how the QR Code generator helps you make the link between real assets and the monitoring world, and how the layered CMDB provides a single point of view for all your configuration data.

Register Now!

A Network Computing Webinar:
SDN First Steps

Thursday, August 8, 2013
11:00 AM PT / 2:00 PM ET

This webinar will help attendees understand the overall concept of SDN and its benefits, describe the different conceptual approaches to SDN, and examine the various technologies, both proprietary and open source, that are emerging. It will also help users decide whether SDN makes sense in their environment, and outline the first steps IT can take for testing SDN technologies.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up


Linux gobbles
Microsoft


Tutorial: Linux Internet Server: Set Up a Firewall Part 2

By Paul Dunne

This article examines how to set up a Linux box to provide routing services between the local network and the Internet, and to address the security issues raised by such a connection by having the Linux box act as a firewall. This article deals with setting up a Linux PC for use as a firewall between the Internet and a local network. It is a tutorial that takes the reader through installing, configuring and administering a L inux firewall. Some knowledge of TCP/IP networking and Linux is assumed, as well as a basic acquaintance with firewalls.

Questions regarding this article should be directed to the author at paul@tiny1.demon.co.uk

Other installments of this Linux Internet server tutorial series include:

Introduction

It is assumed that you are familiar with the theory behind firewalls. If not, a bit of background readin g might help. There is a good collection of papers at AT&T's Research site . The set of papers at the TIS site is also worth a read.

Routing

As it stands, our Linux box is connected to the Internet and to the local network, but our local network is still unable to talk to the Internet, and vice versa. For this, we must enable routing on the Linux box, so that packets from one network interface destined for addresses outside the local network are sent on through the other network interface.

There are two different ways to provide routing, depending on whether or not the local network has been allocated IP addresses by InterNIC, or whether it uses the ``private'' addresses allowed by RFC 1597 .

For the purpose of this article, we will assume that the local network has not had Internet addresses allocated to it, and must thus be kept hidden from the Internet. Our firewall set-up will serve the dual purpose of providing the routing services for the hidden network, and also acting as a security barrier.

Types of Firewalls

There are two types of firewalls. The first is a filtering firewall, where packets are allowed or denied routing according to a rule-set. The other type is the proxy firewall, which blocks off the internal network from the external network entirely, and provides proxy services as requested by the internal network. Further, there are two types of proxy firewall: firstly, the application proxy gateway, secondly, the circuit-level relay.

In this article, we will be setting up a basic filtering firewall. For more information about the other kinds, see the Firewalling and Proxy Server HOWTO .

Hardware Requirements

Any PC capable of running Linux can be used as a firewall. There are certain features that a firewall relies on more than others. A filtering firewall needs a decent amount of RAM, if only to hold the routing tables in memory; a proxy firewall's hardware needs are determined by the requirements of the services for which it provides proxy support. For example, providing WWW proxy support can demand plenty of RAM and high-performance hard disk space, depending on how much caching is done.

Configuration

Using a Linux box as a firewall can be done either by using the built-in firewall capability, or by installing additional packages. This article looks specifically at turning a Linux machine into a packet-filtering router, using no additional packaged software.

The Kernel

The Linux kernel needs to be compiled with certain options enabled in order to use the firewall code. Most generic kernels -- that type usually supplied with a distribution -- will have these options turned off, so that it is nece ssary to recompile the kernel. This is a simple task, and we will quickly run through the steps here. For more details, see the Linux Kernel HOWTO .

I should also point out that it is a good idea to take this opportunity to upgrade your kernel to the latest stable release. At time of writing, this is 2.0.30. The kernel is brought up to date in one of two ways: either by downloading the latest source tree en masse, or by applying all the patch files released between your version, and the current stable release. The former is easier, the latter cheaper if you pay for telephone calls to your ISP, or are billed for usage. Either way, many sites carry both. See the Linux v2 Information HQ for details.

Configuring The Kernel

The Linux kernel is configured by the ``make config'' command. The following options must be switched on.

CONFIG_FIREWALL=y
CONFIG_INET=y
CONFIG_IP_FORWAR
D=y
CONFIG_SYN_COOKIES=y  
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_VERBOSE=y
CONFIG_IP_MASQUERADE=y
CONFIG_IP_ACCT=y


Recompiling The Kernel

The following command sequence will re-compile the kernel:


make dep && make clean && make zImage

Installing the New Kernel

The following sequence of commands copies the new kernel image and its associated symbol table to the root directory, and reruns LILO so that the boot loader knows about the new kernel:


cp /usr/src/linux/arch/i386/boot/zImage /
cp /usr/src/linux/System.map /
/sbin/lilo

It's not a bad idea to put the new kernel on a floppy only at first, and reboot using that diskette, just to make sure everything is working right. You can then install the new kernel on the hard disk as shown above when this has been done. You can use a simple copy operation, like:


cp /usr/src/linux/arch/i386/boot/zImage /dev/fd0

Getti ng ipfwadm

The ipfwadm(8) utility is used to administer the IP accounting and IP firewall services offered by the Linux kernel. You can get this utility from the X/OS site in source and binary form . It is very easy to compile the source and install.

Filtering Rule-Sets

The core of firewall functionality is contained in the rule-sets that determine what happens to packets. There are four types of rule-sets: those governing input, those governing output, those in charge of forwarding, and those controlling accounting. Rule-sets are maintained by ipfwadm(8) .

Rather than bludgeoning you with a great list of options and arguments that ipfwadm can take, we will introduce the most important gradually through examples. The manual page provides more details on the more esoteric arguments.

In the examples that follow, we shall construct a firewall machine tha t is connected to the local network via interface 192.168.1.1, and to the Internet via 192.168.20.1. Please note that the 192.168.0.0 net is a non-routed net address block set aside specifically for use on networks that are not connected to the Internet, or are screened from contact with the Internet by a firewall of the type we are building. They should NOT be used on any network which will be directly connected to the Net. The system acts as a mail relay hub for the local network, as a router for the local network, provides local DNS services, and provides HTTP and FTP services.

Note that in the rules that follow are taken from an ``rc script'' on my machine, where the following variables are defined at the head of the file to simplify maintenance:

LOCALHOST=`hostname`
IFEXTERN="158.152.37.217"
IFINTERN="192.168.1.1"
LOCALNET="192.168.1.0/24"
ANYWHERE="0.0.0.0/0"
UNPRIVPORTS="1024:65535"

Blocking

The blocking rules control going directly to or fro m the firewall itself. In what follows, I will build up step by step a set of blocking rules for our basic firewall. With ipfwadm , blocking rules are controlled by two parameters: -I for input rules and -O for output rules.

Firstly, we block everything! The idea here is that we deny access wherever we do not explicitly permit it.


# Sure we're paranoid, but are we paranoid enough?
ipfwadm -I -p deny
ipfwadm -O -p deny
ipfwadm -F -p deny

The -b option specifies that the rule is bidirectional, that is, will match IP packets in both directions. The -p option sets the default policy, which will be used when no matching rule is found. So, as it stands, our firewall will reject all packets coming in or going out. Obviously, this won't do! So, we will add some rules to selectively allow traffic to and from the firewall. First though, we need a way of protecting ourselves from packet spoofing. The fol lowing two rules will ensure that we do not fall victim to such attacks:


# Handle spoofed packets.
ipfwadm -I -a deny -V $IFEXTERN -S $LOCALNET -D $ANYWHERE
ipfwadm -I -a deny -V $IFEXTERN -S $IFEXTERN -D $ANYWHERE

For a start, we can allow packets between the firewall and our local network:


# Unlimited traffic within the local network.
ipfwadm -I -a accept -V 192.168.1.1 -S 0.0.0.0/0 -D 0.0.0.0/0
ipfwadm -O -a accept -V 192.168.1.1 -S 0.0.0.0/0 -D 0.0.0.0/0

# Unlimited traffic to localhost
ipfwadm -I -a accept -V 127.0.0.1 -S 127.0.0.1 -D 127.0.0.1
ipfwadm -O -a accept -V 127.0.0.1 -S 127.0.0.1 -D 127.0.0.1

Here, we see the use of the input ( -I and output ( -O ) categories, to control what direction of traffic our rule will be applied to. The -V option states that only traffic originating from that interface will be checked by this rule. In this example, I have assumed that the network card c onnecting our firewall to the local network has the address 192.168.1.1.

Now, in one fell swoop, we add SMTP, FTP, WWW and DNS access:


# SMTP
ipfwadm -I -a accept -P tcp -S $ANYWHERE -D $LOCALHOST smtp
ipfwadm -O -a accept -P tcp -S $LOCALHOST $UNPRIVPORTS -D $ANYWHERE
ipfwadm -O -a accept -P tcp -S $LOCALHOST smtp -D $ANYWHERE
ipfwadm -I -a accept -P tcp -S $ANYWHERE -D $LOCALHOST $UNPRIVPORTS

# DNS
ipfwadm -I -a accept -P tcp -S $ANYWHERE -D $LOCALHOST domain
ipfwadm -I -a accept -P udp -S $ANYWHERE -D $LOCALHOST domain
ipfwadm -O -a accept -P udp -S $LOCALHOST domain -D $ANYWHERE

# FTP
ipfwadm -I -a accept -P tcp -S $ANYWHERE -D $LOCALHOST ftp
ipfwadm -I -a accept -k -P tcp -S $ANYWHERE -D $LOCALHOST ftp-data
ipfwadm -O -a accept -P tcp -S $LOCALHOST ftp -D $ANYWHERE

# WWW
ipfwadm -I -a accept -P tcp -S $ANYWHERE -D $LOCALHOST www
ipfwadm -O -a accept -P tcp -S $LOCALHOST www -D $ANYWHERE

Because we intend to allow traffic to be forwarded to and from the in ternal network, we must also add some input and output rules to allow for this, in addition to the forwarding rules in the next section:


# Outgoing packets.
ipfwadm -O -a accept -P tcp -S $LOCALNET $UNPRIVPORTS \
  -D $ANYWHERE smtp ftp ftp-data www telnet domain
ipfwadm -O -a accept -P tcp -S $IFEXTERN $UNPRIVPORTS \
  -D $ANYWHERE smtp ftp ftp-data www telnet domain
ipfwadm -O -a accept -P udp -S $LOCALHOST $UNPRIVPORTS \
  -D $ANYWHERE  domain

# Incoming packets.
ipfwadm -I -a accept -k -P tcp -S $ANYWHERE ftp www telnet domain \
  -D $LOCALNET $UNPRIVPORTS
ipfwadm -I -a accept -k -P tcp -S $ANYWHERE ftp www telnet domain \
  -D $IFEXTERN $UNPRIVPORTS
ipfwadm -I -a accept -P tcp -S $ANYWHERE ftp-data -D $LOCALNET $UNPRIVPORTS
ipfwadm -I -a accept -P tcp -S $ANYWHERE ftp-data -D $IFEXTERN $UNPRIVPORTS
ipfwadm -I -a accept -P udp -S $ANYWHERE domain -D $LOCALHOST $UNPRIVPORTS


Firstly, we allow input TCP packets from anywhere into our local network, provided they are f rom our allowed services. We also allow UDP packets to the name server. The -k option says to only allow packets with the ACK bit set. Then, we have two output rules, again, one for TCP, one for UDP. These should be easy to understand now, as they are but the mirror-image of the input rules.

Forwarding

The forwarding rules control which packets will be forwarded by the firewall. In addition, our forwarding rules must take care of masquerading. As mentioned above in the section on routing, we are using ``private'' IP numbers for our network, and we cannot allow packets with source addresses set to these numbers out onto the Internet. Therefore, our firewall will ``masquerade'' as our other machines for the purposes of sending packets to and from the Internet.

Once again, we start by denying everything, before explicitly allowing some sorts of traffic.


ipfwadm -F -p deny

Here, the -F option specif ies a forwarding rule. And, -p deny as we have seen before, sets the default policy to deny everything, then we explicitly allow the services we wish to permit:


ipfwadm -F -m -a accept -P tcp -S $LOCALNET $UNPRIVPORTS \
  -D $ANYWHERE ftp ftp-data www telnet
ipfwadm -F -m -a accept -k -P tcp -S $ANYWHERE ftp www telnet \
  -D $LOCALNET $UN PRIVPORTS
ipfwadm -F -m -a accept -P tcp -S $ANYWHERE ftp-data \
  -D $LOCALNET $UNPRIVPORTS

Here, the -m option enables masquerading, and -P specifies the protocol involved. The numeric argument after the network/port source is the range of non-privileged ports this operation is permitted to use. The destination is set to ``any''.

Accounting

The accounting rules are used to build up packet and byte counts for selected traffic. There is a single set, used for both incoming and outgoing traffic. Every packet is checked against each rule, and the counts of ea ch matching rule incremented.

Now, ipfwadm controls accounting with the -A option. A direction can be specified (in, out, or both; default both) indicating whether only packets in the specified direction should be counted. For example, the following keeps track of all traffic to and from the local Web server:


ipfwadm -A -a -b -P tcp -S 0.0.0.0/0 -D 192.168.1.2 www

Where we assume that a machine on the local network with address 192.168.1.2 hosts the Web server.

The rule I use is rather more simple, just:


ipfwadm -A -a -b

Conclusion

This article has shown you how to set up a Linux box as a combined router and firewall, using the network capabilities built in to the Linux kernel. It does not attempt to provide a complete, robust firewalling solution; but it will prove sufficient for sites without grave security concerns. For further information, a good starting p oint is Linux Journal Firewall Resources

Author Biography

Paul Dunne is a writer and consultant who specialises in Linux. He has a home page that describes in more detail what he does.

Print This Page


e-mail Send as e-mail
Vendor Comparisons
Network Computing’s Vendor Comparisons provide extensive details on products and services, including downloadable feature matrices. Our categories include:

Research and Reports

Network Computing: April 2013



TechWeb Careers