Lecture
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.
| Keyword | Description |
|---|---|
| ip | All IP packets. |
| tcp | TCP packets. |
| udp | UDP packets. |
| icmp | ICMP packets. |
| service name or number | A packet destined for one of the services described in /etc/services. |
| src IP address range | A packet with a source address that matches IP address. See below for the interpretation of IP address range. |
| dst IP address range | A packet with a destination address that matches IP address. |
| via interface | All packets going by the specified interface. interface may be an interface name or an IP address associated with only one interface. |
| recv interface | All packets arriving by the specified interface. interface may be an interface name or an IP address associated with only one interface. |
| xmit interface | All packets going out by the specified interface. interface may be an interface name or an IP address associated with only one interface. |
| IP address | This is an IP address. It specifies a match for exactly this address. |
| IP address/bits | bits is a value between 0 and 32. This form matches the first bits bits of IP address. |
| IP address: mask | mask is a 32-bit value. This form matches those bits of IP address specified in mask. This is the same concept as a net mask—see "Networks and the Internet" , page 290, for a description of net masks. |
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.