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

ƒdefault Š as its name says, it's the default optimization algorithm.

ƒnormal Š same as default.

ƒhigh-latency Š used for high-latency links, such as satellite links. Expires idle connections later than default.

ƒsatellite same as high-latency.

ƒaggressive Š expires idle connections earlier than default; using less memory and CPU time while possibly dropping some legitimate connections.

ƒconservative Š tries to avoid dropping any legitimate connections at the expense of increased memory usage and CPU utilization.

Don't forget to reload the new options after changing the optimization algorithm.

Before you rush to enable these optimization rules, you should know that these algorithms make a difference in special cases like high-latency connections, or very busy corporate, government, or education networks. Small networks and networks with low trafŒc will see no noticeable performance improvements.

The optimization rule is a shortcut for quickly setting a bunch of timeout rules. If none of them seem to work in your particular setup, consider adjusting the timeout values yourself, as described in Chapter 8,

Packet Filtering.

248

Chapter 15

Testing Your Firewall

Is you Œrewall working as it should, or are there some strange communication problems? Why that small change you made suddenly cut you off? In this chapter we'll learn how to test the Œrewall, how to monitor it, and where to look for information.

Testing your ruleset is a multi-stage process. It is never too early to begin testing your Œrewall, and it certainly is not a good idea to put an untested Œrewall straight into production use.

15.1 Pencil Test

The Œrst test of your Œrewall must be done before you start mucking around with hardware and pf(4). It should be done with a pen or a pencil and a piece of paper. Simply draw boxes (hosts) and connect them with arrows, each marked with service and protocol names or port numbers that are allowed to pass through the Œrewall, and think what rules need to be used. The picture doesn't have to be pretty, but it ought to be clear enough to be understood without ripping your head apart. Once you have your Œrewall diagram, write Œltering/NAT/ALTQ and other rules down on another piece of paper. You do not need to use pf(4) syntax, plain English will work just Œne. After you're done, try to read these rules and follow the paths on the diagram, checking if the rules you are using will actually work in your mind. It is even better to ask a colleague to do it for you, because he or she will have a fresh mind and will be able to spot design •aws quicker than yourself. When you Œnd something that doesn't quite work, revise your rules and repeat the process again. If you don't understand something, refer to other parts of this book, the pf.conf(5) man page, and the reference material listed in Bibliography.

After you are conŒdent you know what you want pf(4) to do, begin writing the ruleset, one rule at a time. Start with general rules with the broadest

scope and add more speciŒc ones after you get the general setup working.

Every time you want to make a change, make a copy of the old ruleset:

# cp /etc/pf.conf /etc/pf.conf.old

Make changes to /etc/pf.conf and save them. Then, •ush the old ruleset from memory and reload the new one. To make sure that you don't get cut off, when you are testing your new ruleset without physical access to the Œrewall machine, use the following command:

#pfctl -F all

#pfctl -f /etc/pf.conf ; sleep 10 ; pfctl -f /etc/pf.conf-old

Then, check if the new rules are working Œne. When they are, add a new rule and repeat that procedure again. (If you need more time to perform checks, increase the value of the sleep(1) argument from 10 seconds to 20 or 30.) Should things go wrong, the previously working version of the ruleset will be loaded automatically and you will be saved the inconvenience of having to walk or drive to the machine to make changes from the console.

When all is working Œne, commit the new ruleset to CVS (for a short course in CVS, see Chapter 5, /etc/pf.conf):

# cvs ci -m 'Added spamd rules' /etc/pf.conf

OK, but how do you know that the rules are working as they should? Read on.

15.2 Checking Host Availability

The simplest, yet one of the more effective testing tools is the humble ping(8). Provided you conŒgured pf(4) to pass ping requests and replies (see Appendix B), you should be able to use ping(8) to perform the following checks:

ƒIs the Œrewall host up and running? Simply ping the Œrewall, e.g. when the Œrewall is located at 192.168.15.7 (the address assigned to the interface it connects to the LAN segment you are sending pings with), do:

$ ping 192.168.15.7

If you want to send tst packets through a speciŒc interface, give ping(8) the address of that interface:

$ ping -I 192.168.15.1 192.168.15.7

Let it run for a few seconds, press Ctrl+C, and read statistics printed on screen, have a look at the percentage of packet loss. When that value is 0%, you have a perfect connection, when it is equal to 100% there is no connection to the Œrewall or all packets are being dropped. Values in-be- tween indicate that the network or the Œrewall is heavily loaded and some packets are being lost, but the Œrewall is up and running.

ƒAre hosts on the other side of the Œrewall running? When the Œrewall is conŒgured to let responses to ping datagrams pass back to the sender, you can send pings to check other hosts, on other LAN segments, in the DMZ, or on the outside of the Œrewall. Results are interpreted in the same way as the results of sending pings to the Œrewall, but a 100% loss of packets does not necessarily indicate that the Œrewall is down. It may be dropping packets because that's how the pf(4) is conŒgured. Therefore, another check is required in such cases, because the Œrewall may pass responses to pings sent from the Œrewall itself, but not from the hosts protected by that Œrewall. To do it, log on the Œrewall and ping the same hosts again. The interpretation of results is the same as for the Œrewall test, but again, a 100% packet loss may be simply a conŒrmation that pings are not being let through the Œrewall, because that's how pf(4) has been conŒgured and it's just doing its job. Yet another possibility could be that the hosts you are trying to ping is dropping the packets you send it on purpose, to prevent DoS attacks. In such case, you need to check if other hosts on the outside respond to pings. When they don't there may be a problem with your connection to the Internet.

Be careful with sending pings to external hosts. If you swamp them with requests, you may trigger their NIDS and someone might be thinking they caught a dangerous villain. A couple of pings sent their way will not get you in trouble, but if you start ping(8) and go to make a coffee, don't be surprised to get a call from the other side's administrator. Should you have really bad luck, you might get legal action started against you, so use

ping(8) sparingly. (The same goes for traceroute(8), mtr(8), or other similar tools.)

15.2.1 When Ping Cannot Help

When ping(8) says that the host you are trying to reach is down, there is a possibility that it is conŒgured to ignore your pings. In such case, try connecting to one of the ports on that server with telnet(1).

For example, to check if the remote server is up and running, try:

$ telnet www.example.com 80

You can replace the hostname with an IP address and you can replace the port number with the service name (see /etc/services):

$ telnet 10.5.45.2 http

When these attempts are unsuccessful, you may assume that:

ƒPf(4) may be blocking packets. Try connecting to other hosts with pf(4) turned off. When that helps, check /etc/pf.conf for offending rules.

ƒThe routing is not set up properly. Assuming that pf(4) is conŒgured to let all packets pass and that NAT is conŒgured correctly, if used at all, it is possible that the routing information is not correct. Check if the gateway address on the local hosts points to the internal interface on the Œrewall, or when the Œrewall is working as an invisible Œltering bridgeŠto the host that acts as the gateway for the local LAN segment. Another thing to check is the gateway address on the Œrewall or the gateway host. See Chapter 4, ConŒguring OpenBSD for more information.

ƒThe target host is down. In that case, restart the host, if you have the right to do so and can do it, or wait until its administrators do it. Depending on your circumstances, it may be appropriate to let them know there is trouble.

ƒYou are blocked by a Œrewall on the other side. Do they have a reason to block you? Get in touch with their administrator and ask.

ƒThere is a problem with the network equipment. Check cables, hubs, switches, routers, power plugs.

15.3 Discovering Open Ports on Remote Hosts

When you are at a loss and cannot connect to a server over a network, there is a tool that can help, but you need to be very careful with it. It is called nmap, and can be found in OpenBSD packages.

Nmap is, among other things, a port scanner. It uses clever tricks to discover which ports are open on a target machine, does Œngerprinting (discovers which version and which operating system the remote host is running) and can be your last chance of Œnding out, if the host you are trying to check does allow some kind of connections, without going there and checking it yourself.

Do not forget that it is possible to have more than one IP address assigned to a single interface (with the ifconŒg(8) alias option). In that case, run nmap on every IP address you are interested in!

Because nmap is so powerful, it is an ideal tool for network administrators and security specialists. Unfortunately, it is also used by people with less friendly intentions, who use it to learn about remote hosts they wish to break into. Therefore, it is very important that you do not scan hosts that you do not manage or do not have the permission to scan. If you let nmap loose on other people's hosts you will get yourself in serious legal trouble.

15.4 Testing Network Performance

When the network is slowing down, the reasons for that could be numerous and you will have to do some detective work to get to the source of the problem.

ƒThe local network is overloaded. To test that hypothesis, ping various hosts on the local network and see what time values they return. If they are in hundreds of milliseconds, you may have a problem with your local network segment. Somewhere, something's wrong. The target hosts could be overloaded, the cabling may be damaged, someone might be downloading huge Œles (put them on a diet, use ALTQ to limit bandwidth). Or, someone might be messing with your network. Monitor the situation, and if the problems don't disappear, get to work.

column b is greater than 0, there is probably a problem with the I/O subsystem (the disk are too slow, happens when you do extensive logging); and when w is greater than 0 your machine is short of memory and has to swap to disk. In all cases, the network connections will be affected. Pay particular attention to swapping, as it severely degrades the Œrewall performance. Often adding more memory will have a much better effect than a faster processor, disk, RAID, or a faster network card.

Yet another performance indicator reported by vmstat(8) is the amount of time the processor is idle (cpu id). The higher that value, the better, but it cannot be 100% idle all the time, of course. There are two schools of thinking about that indicator. Some say that a 10%‰20% reserve is OK, while others say that it ought to be at most 50%. When the load is applied evenly, it is OK for the processor to be quite busy (10% idle), but when the load is bursty, the CPU ought to be idle at 50% or more. Another popular system performance measuring tool is top(1), which has its critics, who claim that it places additional load on the system and blurs the overall picture of system performance. While it is true, it displays a lot of useful information about the system. It can be run in interactive mode:

$ top

or in batch mode:

$ top -b

(If you long for a simple, visual interface in text mode, try systat(1).)

Another important tool for monitoring performance is netstat(1), used to check parameters of the network connections, interfaces, and so on. To use it, type:

$ netstat

Watch out for high values of the Recv-Q queue and the Send-Q queue. When Recv-Q is constantly high, your host may be having problems with processing packets it receives. High values of Send-Q may indicate that the external hosts may be having problems processing packets fast enough. To make netstat(1) work faster disable name lookups, with: