Contributed by &a.gpalmer;.4th of October 1995 Firewalls are an area of increasing interest for people who are connected to the Internet, and are even finding applications on private networks to provide enhanced security. This section will hopefully explain what firewalls are, how to use them, and how to use the facilities provided in the FreeBSD kernel to implement them. Note: People often think that having a firewall between your companies internal network and the ``Big Bad Internet'' will solve all your security problems. It may help, but a poorly setup firewall system is more of a security risk than not having one at all. A firewall can only add another layer of security to your systems, but they will not be able to stop a really determined hacker from penetrating your internal network. If you let internal security lapse because you believe your firewall to be impenetrable, you have just made the hackers job that bit easier. What is a firewall?

There are currently two distinct types of firewalls in common use on the Internet today. The first type is more properly called a packet filtering router, where the kernel on a multi-homed machine chooses whether to forward or block packets based on a set of rules. The second type, known as proxy servers, rely on daemons to provide authentication and to forward packets, possibly on a multi-homed machine which has kernel packet forwarding disabled.

Sometimes sites combine the two types of firewalls, so that only a certain machine (known as a bastion host) is allowed to send packets through a packet filtering router onto an internal network. Proxy services are run on the bastion host, which are generally more secure than normal authentication mechanisms.

FreeBSD comes with a kernel packet filter (known as IPFW), which is what the rest of this section will concentrate on. Proxy servers can be built on FreeBSD from third party software, but there is such a variety of proxy servers available that it would be impossible to cover them in this document. Packet filtering routers

A router is a machine which forwards packets between two or more networks. A packet filtering router has an extra piece of code in it's kernel, which compares each packet to a list of rules before deciding if it should be forwarded or not. Most modern IP routing software has packet filtering code in it, which defaults to forwarding all packets. To enable the filters, you need to define a set of rules for the filtering code, so that it can decide if the packet should be allowed to pass or not.

To decide if a packet should be passed on or not, the code looks through it's set of rules for a rule which matches the contents of this packets headers. Once a match is found, the rule action is obeyed. The rule action could be to drop the packet, to forward the packet, or even to send an ICMP message back to the originator. Only the first match counts, as the rules are searched in order. Hence, the list of rules can be referred to as a ``rule chain''.

The packet matching criteria varies depending on the software used, but typically you can specify rules which depend on the source IP address of the packet, the destination IP address, the source port number, the destination port number (for protocols which support ports), or even the packet type (UDP, TCP, ICMP, etc). Proxy servers

Proxy servers are machines which have had the normal system daemons (telnetd, ftpd, etc) replaced with special servers. These servers are called proxy servers as they normally only allow onward connections to be made. This enables you to run (for example) a proxy telnet server on your firewall host, and people can telnet in to your firewall from the outside, go through some authentication mechanism, and then gain access to the internal network (alternatively, proxy servers can be used for signals coming from the internal network and heading out).

Proxy servers are normally more secure than normal servers, and often have a wider variety of authentication mechanisms available, including ``one-shot'' password systems so that even if someone manages to discover what password you used, they will not be able to use it to gain access to your systems as the password instantly expires. As they do not actually give users access to the host machine, it becomes a lot more difficult for someone to install backdoors around your security system.

Proxy servers often have ways of restricting access further, so that only certain hosts can gain access to the servers, and often they can be set up so that you can limit which users can talk to which destination machine. Again, what facilities are available depends largely on what proxy software you choose. What does IPFW allow me to do?

IPFW, the software supplied with FreeBSD, is a packet filtering and accounting system which resides in the kernel, and has a user-land control utility, ipfw(8). Together, they allow you to define and query the rules currently used by the kernel in its routing decisions.

There are two related parts to IPFW. The firewall section allows you to perform packet filtering. There is also an IP accounting section which allows you to track usage of your router, based on similar rules to the firewall section. This allows you to see (for example) how much traffic your router is getting from a certain machine, or how much WWW (World Wide Web) traffic it is forwarding.

As a result of the way that IPFW is designed, you can use IPFW on non-router machines to perform packet filtering on incoming and outgoing connections. This is a special case of the more general use of IPFW, and the same commands and techniques should be used in this situation. Enabling IPFW on FreeBSD

As the main part of the IPFW system lives in the kernel, you will need to add one or more options to your kernel configuration file, depending on what facilities you want, and recompile your kernel. See for more details on how to recompile your kernel.

There are currently three kernel configuration options relevant to IPFW: syslogd(8). Without this option, even if you specify that packets should be logged in the filter rules, nothing will happen. Configuring IPFW

The configuration of the IPFW software is done through the ipfw(8) utility. The syntax for this command looks quite complicated, but it is relatively simple once you understand it's structure.

There are currently two different command line formats for the utility, depending on what you are doing. The first form is used when adding/deleting entries from the firewall or accounting chains, or when clearing the counters for an entry on the accounting chain. The second form is used for more general actions, such as flushing the rule chains, listing the rule chains or setting the default policy. Altering the IPFW rules

The syntax for this form of the command is: ipfw [-n] command action protocol addresses

There is one valid flag when using this form of the command: The command given can be shortened to the shortest unique form. The valid commands are: If no command is given, it will default addfirewall or addaccounting depending on the arguments given.

Currently, the firewall support in the kernel applies a set of weights to the rule being added. This means that the rules will not be evaluated in the order that they are given to the system. The weighting system is designed so that rules which are very specific are evaluated first, and rules which cover very large ranges are evaluated last. In other words, a rule which applies to a specific port on a specific host will have a higher priority than a rule which applies to that same port, but on a range of hosts, or that host on a range of ports.

The weighting system is not perfect, however, and can lead to problems. The best way to see what order it has put your rules in is to use the list command, as that command lists the rules in the order that they are evaluated, not the order that they were fed to the system.

The actions available depend on which rule chain the entry is destined for. For the firewall chain, valid actions are: reject, but also log the packet details. deny, but also log the packet details. accept. For the accounting chain, valid actions are:

Each action will be recognized by the shortest unambiguous prefix. The protocols which can be specified are:

The address specification is: [from <address/mask>[port]] [to <address/mask>[port]] [via <interface>]

You can only specify port in conjunction with protocols which support ports (UDP, TCP and SYN).

The order of the from, to, and via keywords is unimportant. Any of them can be omitted, in which case a default entry for that keyword will be supplied which matches everything.

The via is optional and may specify the IP address or domain name of a local IP interface, or an interface name (e.g. ed0) to match only packets coming through this interface. The keyword via can be substituted by on, for readability reasons.

The syntax used to specify an <address/mask> is: <address> or <address>/mask-bits or <address>:mask-pattern

A valid hostname may be specified in place of the IP address. mask-bits is a decimal number representing how many bits in the address mask should be set. e.g. specifying 192.216.222.1/24 will create a mask which will allow any address in a class C subnet (in this case, 192.216.222) to be matched. mask-pattern is an IP address which will be logically AND'ed with the address given. The keyword any may be used to specify ``any IP address''.

The port numbers to be blocked are specified as: port[,port[,port[...]]] to specify either a single port or a list of ports, or port:port to specify a range of ports. The name of a service (from /etc/services) can be used instead of a numeric port value. Listing/flushing the IPFW rules

The syntax for this form of the command is: ipfw [-ans] command [argument]

There are three valid flags when using this form of the command: -s. -a to see accounting counters. The short form listing is incompatible with the input syntax used by the ipfw(8) utility. The command given can be shortened to the shortest unique form. The valid commands are: -s flag is given, the format is compatible with the command line syntax. The list and flush commands may optionally be passed an argument to specify which chain to flush. Valid arguments are:

The policy command can be given one of two arguments: As usual, the arguments can be shortened to the shortest unique form (in this case, the first letter). Example commands for ipfw

This command will deny all packets from the host evil.hacker.org to the telnet port of the host nice.people.org by being forwarded by the router: ipfw addf deny tcp from evil.hacker.org to nice.people.org telnet

The next example denies and logs any TCP traffic from the entire hacker.org network (a class C) to the nice.people.org machine (any port). ipfw addf ldeny tcp from evil.hacker.org/24 to nice.people.org If you do not want people sending X sessions to your internal network (a subnet of a class C), the following command will do the necessary filtering: ipfw addf deny syn to my.org/28 6000 To allow access to the SUP server on sup.FreeBSD.ORG, use the following command: ipfw addf accept syn to sup.FreeBSD.ORG supfilesrv To see the accounting records: ipfw -sa list accounting or in the short form ipfw -sa l a Building a packet filtering firewall

Note: The following suggestions are just that: suggestions. The requirements of each firewall are different and I cannot tell you how to build a firewall to meet your particular requirements.

When initially setting up your firewall, unless you have a test bench setup where you can configure your firewall host in a controlled environment, I strongly recommend you use the logging version of the commands and enable logging in the kernel. This will allow you to quickly identify problem areas and cure them without too much disruption. Even after the initial setup phase is complete, I recommend using the logging for of `deny' as it allows tracing of possible attacks and also modification of the firewall rules if your requirements alter. Note: If you use the logging versions of the accept command, it can generate large amounts of log data as one log line will be generated for every packet that passes through the firewall, so large ftp/http transfers, etc, will really slow the system down. It also increases the latencies on those packets as it requires more work to be done by the kernel before the packet can be passed on. syslogd with also start using up a lot more processor time as it logs all the extra data to disk, and it could quite easily fill the partition /var/log is located on.

As currently supplied, FreeBSD does not have the ability to load firewall rules at boot time. My suggestion is to put a call to a shell script in the /etc/netstart script. Put the call early enough in the netstart file so that the firewall is configured before any of the IP interfaces are configured. This means that there is no window during which time your network is open.

The actual script used to load the rules is entirely up to you. There is currently no support in the ipfw utility for loading multiple rules in the one command. The system I use is to use the command: # ipfw list to write a list of the current rules out to a file, and then use a text editor to prepend ``ipfw '' before all the lines. This will allow the script to be fed into /bin/sh and reload the rules into the kernel. Perhaps not the most efficient way, but it works.

The next problem is what your firewall should actually DO! This is largely dependent on what access to your network you want to allow from the outside, and how much access to the outside world you want to allow from the inside. Some general rules are: Block all incoming access to ports below 1000 for TCP. This is where most of the security sensitive services are, like finger, SMTP (mail) and telnet. Block incoming SYN connections to ports between 1001 and 1024 (this will allow internal users to rsh/rlogin to the outside). If you do not want to allow rsh/rlogin connections from the inside to the outside, then extend the above suggestion to cover ports 1-1024. Block all incoming UDP traffic. There are very few useful services that travel over UDP, and what useful traffic there is is normally a security threat (e.g. Suns RPC and NFS protocols). This has its disadvantages also, since UDP is a connectionless protocol, denying incoming UDP traffic also blocks the replies to outgoing UDP traffic. This can cause a problem for people (on the inside) using external archie (prospero) servers. If you want to allow access to archie, you'll have to allow packets coming from ports 191 and 1525 to any internal UDP port through the firewall. ntp is another service you may consider allowing through, which comes from port 123. Block traffic to port 6000 from the outside. Port 6000 is the port used for access to X11 servers, and can be a security threat (especially if people are in the habit of doing xhost + on their workstations). X11 can actually use a range of ports starting at 6000, the upper limit being how many X displays you can run on the machine. The upper limit as defined by RFC 1700 (Assigned Numbers) is 6063. Check what ports any internal servers use (e.g. SQL servers, etc). It's probably a good idea to block those as well, as they normally fall outside the 1-1024 range specified above.

Of course, if you want to make sure that no un-authorized traffic gets through the firewall, change the default policy to ``deny''. This will mean that any traffic which is allowed through has to be specified explicitly in an ``accept'' or ``allow'' filter rule. Which ports you allow through is again something that you will have to decide for yourself. If you do set the default policy to be deny, you will probably want to install proxy servers, as no traffic will be able to get OUT either unless you allow TCP SYN connections going form the inside out.

As I said above, these are only guidelines. You will have to decide what filter rules you want to use on your firewall yourself. I cannot accept ANY responsibility if someone breaks into your network, even if you follow the advice given above.