Firewalls, IP aliasing and proxies

The Internet was developed by a relatively small community of computer scientists, who were for the most part responsible people who often did not take security issues very seriously. Since the Internet has been opened to the general public, three problems have become evident:

• A large number of people have sought to abuse its relatively lax security.
• The address space is no longer adequate for the number of machines connecting to the network.
• Much bandwidth is used by people downloading the same web pages multiple times.

What do these problems have to do with each other? Nothing much, but the solutions are related, so we'll look at them together. More specifically, we'll consider:

• How to set up an Internet firewall to keep intruders out of your network.
• Security tools that ensure that nobody can steal your password from a node through which it passes.
• Tools for IP aliasing, which translate IP addresses to make them appear to come from the gateway machine. The way this is done makes it impossible to set up connections from outside, so they also represent a kind of security device.
• Caching proxy servers, which both address the multiple download issues and provide some additional security.

Security and firewalls

Recall from "Networks and the Internet" that incoming packets need to connect to an IP port, and that some process on the machine must accept them. By default, this process is inetd. You can limit the vulnerability of your machine by limiting the number of services it supports. Do you need to supply telnet and rlogin services? If not, don't enable the service. By default, /etc/inetd.conf no longer enables any services, so this should not be a problem. Obviously, careful system configuration can minimize your vulnerability, but it also reduces your accessibility: intruders can't get in, but neither can the people who need to access the machine.

A better solution is a tool that passes authorized data and refuses to pass unauthorized data. Such a tool is called a firewall. In this section, we'll look at packet filtering firewalls: the firewall examines each incoming packet and uses a set of predefined walls to decide whether to pass it unchanged, change it, or simply discard it. An alternative approach is a proxy firewall, which analyzes each packet and creates new requests based on its content. On page 396 we'll look at squid, a caching proxy server that provides some of this functionality.

FreeBSD supports three different firewalls, ipf, ipfilter and ipfw. We consider ipfw here; you can find details about ipf and ipfilter and in the respective man pages.

The DEFAULT FreeBSD kernel does not include firewall support. If you wish, you can build a kernel with firewall support—see the file /usr/src/sys/conf/NOTES for a list of parameters—but you don't need to build a new kernel. You can load the KLD /boot/kernel/ipfw.ko instead:

# kldload ipfw
ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled

Before you do so, make sure you have direct local connection to the system. If you start this command remotely, you will instantly lose access to the system. Read the following section before loading the firewall.

ipfw: defining access rules

The program ipfw processes access rules for the firewall. Each rule relates to specific kinds of packet and describes what to do with them. On receiving a packet, ipfw examines each rule in a predetermined order until it finds one which matches the packet. It then performs the action that the rule specifies. In most cases, the rule accepts or denies the packet, so ipfw does not need to continue processing the remaining rules, though sometimes processing can continue after a match. If no rule matches, the default is to allow no traffic.

Table 22-1 shows the keywords you can use to define the packets and the forms that the IP address range can take:

These options can be combined with a few restrictions:

• The recv interface can be tested on either incoming or outgoing packets, while the xmit interface can be tested only on outgoing packets. This means that you must specify the keyword out (and you may not specify in) when you use xmit. You can't specify via together with xmit or recv.
• A packet that originates from the local host does not have a receive interface. A packet destined for the local host has no transmit interface.

Actions

When ipfw finds a rule which matches a packet, it performs the specified action. Table 22-2 shows the possibilities.