Building Firewalls With OpenBSD And PF, 2nd Edition (2003)

sary, rename it, create an empty /var/log/p•og, and compress the old /var/log/p•og with gzip(1). The name of the archived log begins with the original log Œlename and ends with the 0.gz sufŒx. So, /var/log/p•og becomes /var/log/p•og.0.gz and syslogd(8) can begin Œlling up /var/log/p•og again. The whole cycle repeats every hour, and when newsyslog(8) decides that /var/log/p•og is ready to be archived again, it will rename

/var/log/p•og.0.gz to /var/log/p•og.1.gz and repeat the steps described earlier.

At any given point in time, your Œrewall will store up to four p•og archives. When a new archive is created, the archive with the highest number (p•og.3.gz) is overwritten with the younger archive, (p•og.2.gz). You can check the times when they were created in the following way:

On Œrewalls servicing busy networks, the best we can hope for is a fourhour snapshot of the trafŒc. If we want to extend that time, we have two choices: either modify the newsyslog entry in crontab, or edit the

/etc/newsyslog.conf entry for p•og.

Editing crontab allows us to only change the delay between consecutive newsyslog runs; the longer the delay, the larger the logs and their archives will be. The procedure is quite simple. Do (as root):

# crontab -e -u root

and change:

# rotate log files every hour, if necessary

0 * * * * /usr/bin/newsyslog

to:

# rotate log files every two hours, if necessary

0-23/2 * * * /usr/bin/newsyslog

Then press Esc and type :x followed by a hit on the Enter/Return key on your keyboard. Cron(8) will run newsyslog(8) every two hours, keeping an eight-hour snapshot of the trafŒc. (Changing the value of the hour Œeld to 0-23/6 would give us a 24-hour snapshot of the trafŒc. For additional information on cron read man cron, man crontab, and man 5 crontab.) The Œles will be larger, but there will still be a limit on the number of p•og archives kept in /var/log.

If you want to change the number of archives newsyslog keeps in /var/log, or increase their size without affecting all other logs, you need to get familiar with /etc/newsyslog.conf, the conŒguration Œle for newsyslog(8). Open /etc/newsyslog.conf in a text editor (vi(1) will do nicely) and locate the following lines:

# logfilename owner.group mode ngen size time [ZB] /var/log/pflog 600 3 250 * ZB /var/run/pflogd.pid

As you can see, the owner.group Œeld is empty, which means that the archives of p•og will be owned by the user running newsyslog(8) (typically root). You could consider changing the owner and the group to a different user, if you have plans to automate the downloading of p•ogs to another workstation for later analysis. Why not just log in as root and download the archives? Because you cannot be sure that your network is internally secure unless you have control over all machines on it. And even then, there is (however remote) a possibility that you may download rogue code that snoops on your network. But it is better to leave that setting alone and write a script that copies the archives to another place, changing its owner and permissions.

The mode Œeld speciŒes the write, read, and execute privileges. The default 600 (owner can read and write) is a good choice and should be left alone. The highest number a log archive can have is set in the ngen Œeld. The default value is 3, which tells newsyslog(8) to keep at most 4 (0 - 3) p•og archives. If you wanted to keep more, say 24 archives, you'd need to set it to 23. This increases the time required to complete the whole procedure of log rotation, so do not go overboard.

The size Œeld deŒnes the minimum size (in kilobytes) of the log Œle that qualiŒes it for archiving. The default setting is 250 kilobytes. Increasing its value will result in longer delays between log rotations; decreasing it

So, if you wanted to compute the amount of space needed to store logs arriving on a 100Mbps interface on the monitoring station over a period of 24 hours, you'd need a rather large partition or disk (note that 1MB is assumed to be 1024KB, not 1000KB):

100 ´ 24 ´ 3600 = 1080000MB = 1055GB = 1. 1TB 8

Wow! That's a lot of data to play with! You might have a problem, because you cannot buy a 1.1 TB disk today although there are news of 200GB disks, so that day may be nearer than one might think. But don't worry. If you absolutely need that kind of capacity, you can build or buy a RAID array to handle it. Another problem is disk subsystem bandwidth. If your disk cannot write information fast enough, the performance of the Œrewall and the network connection suffers. Suddenly, the performance of the I/O subsystem begins to affect the performance of an otherwise very capable Œrewall machine.

In practice, you are unlikely to saturate such link, at least on a small or medium sized network, because (a) the Œrewall machine probably cannot send data fast enough, (b) the monitoring station cannot receive data at that rate, and (c) the trafŒc on your network does not reach the 100Mbps limit.

But even if it was nearer 600GB, we'd still have a problem. We can solve it in several ways:

ƒUse a RAID array to store data. A pure brute force hardware/software solution. May be necessary on high-risk sites or when logs are monitored in real-time by NIDS software, which can take some automated actions.

ƒKeep less data on the disk by moving it to a tape, CD-R or CD-RW. Requires fast and automated backup hardware. Expensive.

ƒLog less data. Not possible in all cases.

ƒUse separate logging stations for each subnet. Spreads the load, increases complexity.

The Œrst solution is based on a hardware, simply buy enough disks to hold as much data as you need and conŒgure them in a way that suits your needs (man raidctl for more information or look it up in [Artymiak, 2000]).

The second solution still requires a large disk, but not as large as 1.1TB. If your Œrewall was really receiving 1.1TB of data in a day, it would require a

modest 44GB of data in an hour. A 100GB disk could, therefore, hold the current log plus data from the last hour. That old log ought to be written to an external storage device before the current log closes and is rotated. That should not be a problem, if you own a fast tape streamer capable of recording up to 44GB of data per hour. Other storage media, such as CD-R, CD-RW, DVD-R, or optical disks are just not fast enough or cannot hold enough data. But this is theory and one cannot realistically expect a small or medium sized network to have such resources. And they probably do not have to, because the amount of trafŒc logged will be much lower. How much? Well, the answer to that question has to be found by the administrator who will watch the amount of trafŒc on the monitoring station's interface over a period of a few weeks.

A far less expensive, and much saner, solution for those networks that do not need to log all trafŒc, is optimization of the pf(4) logging setup. Instead of logging all trafŒc on all interfaces, you can only log trafŒc entering and leaving the external interface. That should be good enough for catching most of the interesting trafŒc and will make log analysis and storage more manageable.

To see how much storage space we'll need this time, we'll use our magic formula again, using a fast ADSL modem as an example. Suppose it is a 7 (downlink) / 3 (uplink) Mbps model:

7 ´ 24 ´ 3600 = 75600MB = 74GB 8

Now, 74GB of data per day is certainly more manageable than 1.1TB. Furthermore, the external interface is never working at 100% of its maximum transfer rate, and we can safely assume that we need a paltry 40GB (or less) of space to store uncompressed trafŒc logged over a period of 24 hours. A 100GB disk will hold two days worth of data plus enough space for another 12 hours. That is enough data to get a very good view of suspicious activities. Also, 40GB is well within capacity of inexpensive modern DDS/DAT streamers.

What's more, if we tell pf(4) to log only incoming packets, we further decrease the amount of space needed to log trafŒc. Just how much of a saving it will be depends on the patterns of usage of our network. If the amount of outbound trafŒc passing though the external interface is a signiŒcant

portion of the overall trafŒc on that interface, the savings might be substantial; otherwise, they might not be noticeable.

1.6 Logging on a Bridge (Span Ports)

When you run your OpenBSD box, you can easily log trafŒc passing through it to an external machine with span ports, a feature of bridge(4), which lets you conŒgure one of the interfaces to transmit a copy of every packet received by the bridge.

You can conŒgure an interface as a span port with the following command added to the appropriate /etc/bridgename.if Œle:

addspan rl2

For more information, consult brconŒg(8) and bridgename.if(5), and Chapter 4, ConŒguring OpenBSD.

Chapter 12

Using authpf

In this chapter we'll discuss authpf(8), the authenticating gateway shell that offers an elegant solution to the problem of making sure that the users behind the Œrewall really are who say they are.

The problem of user authentication is a complex one, not only because it is a technological challenge, but also because it must be done in a way that will cause the least user rebellion against the system.

One-time user authentication on the computer he or she is working at is not good enough, especially when users are mobile and often disable password protection or use weak passwords. If you write a ruleset that is based solely on IP addresses or port numbers, your Œrewall may fail quickly when one of the machines it is protecting falls into wrong hands or is otherwise broken into. One of the methods for making sure this doesn't happen is user authentication done on the Œrewall implemented with pf(4) and authpf(8). It is quite simple, each user who wants to connect to the Œrewall, must log on the Œrewall via ssh(1). When the authentication is successful, the Œrewall loads a ruleset (via anchors) that allows that user access to the network. Every user can have a separate ruleset, limiting them in what they can do. This solution is used to secure wireless networks, which are particularly vulnerable to host identity theft, but it is also being used increasingly often on `wired' networks to add another layer of defense.

Every user whom you want to authenticate must have an account on the Œrewall and a copy of an SSH client on its computer before they can log on.

12.1 ConŒguring authpf

ƒ/etc/authpf/authpf.conf Š the authpf(8) conŒguration Œle. Contains the name of the anchors where redirection and Œltering rules are loaded into.

Add user joe to /etc/authpf/authpf.allow:

# echo "joe" >> /etc/authpf/authpf.allow

Create a welcome message:

# echo "Where are you going with that NIC in your hand?" >

/etc/authpf/authpf.message

Create a message displayed when there are problems with authentication:

# echo "I'm sorry Dave ..." > /etc/authpf/authpf.problem

ConŒgure sshd(8) (see section 12.2).

ConŒgure login shell (see section 12.3).

Clear pf(4) ruleset:

# pftcl -F all

Create a directory for joe's ruleset:

# mkdir -p /etc/authpf/users/joe

Create a new ruleset for joe. We add only add a Œltering rule, you can create as many rules as you like, just remember to not use the quick keyword. Read Chapter 5, /etc/pf.conf and Chapter 9, Dynamic Rulesets for more information about limits of anchor rulesets:

The /etc/pf.conf ruleset will contain the following rules:

ext_if = "ne1" int_if = "ne2"

nat-anchor authpf rdr-anchor authpf binat-anchor authpf block in on $ext_if all block out on $ext_if all