BSD DevCenter
oreilly.comSafari Books Online.Conferences.


FreeBSD Basics

BSD Firewalls: Fine-Tuning Rulesets


In the last article, I created a ruleset that told ipfw to allow responses to the connection requests I had made to the Internet and to also allow for DNS name resolution. In this article, I'd like to start fine-tuning this ruleset and begin to test its behavior by using the built-in logging facilities available to ipfw.

As my ruleset now stands, I'll enjoy my Internet connection until my DHCP lease runs out. At that point, everything will stop as I haven't created any rules that will allow me to receive a new DHCP lease. To know which rules will accomplish this, it is helpful to have a basic understanding of how DHCP works.

DHCP uses UDP packets, meaning I can't rely on my dynamic rules and the state table; instead, I will have to explicitly allow UDP packets between my machine and my provider's DHCP server. DHCP also uses two port numbers: My DHCP client uses port 68 and my provider's DHCP server uses port 67.

To see how the DHCP process actually works, let's take a look at my current DHCP lease:

more /var/db/dhclient.leases

lease {
  interface "ed0";
  option subnet-mask;
  option time-offset -18000;
  option routers;
  option domain-name-servers,,;
  option host-name "my_hostname";
  option domain-name "my_domainname";
  option broadcast-address;
  option dhcp-lease-time 604800;
  option dhcp-message-type 5;
  option dhcp-server-identifier;
  renew 2 2001/5/15 13:12:11;
  rebind 5 2001/5/18 04:12:11;
  expire 6 2001/5/19 01:12:11;

Note that the DHCP server has provided an IP address, subnet mask, default gateway address, the IP addresses of three DNS servers, my hostname, and the IP address of the DHCP server that provided this lease. Since a DHCP lease is indeed a "lease," meaning I can't keep this information indefinitely, the last three lines deal with how my DHCP client will renew this lease information.

Also in FreeBSD Basics:

Fun with Xorg

Sharing Internet Connections

Building a Desktop Firewall

Using DesktopBSD

Using PC-BSD

The "renew" line tells my DHCP client when it should go out and try to renew its lease. Note that this time is well before the actual expiration date listed on the "expire" line. On 2001/5/15 at 13:12:11, my computer will attempt to send out UDP packets to port 67 on the DHCP server, so I should add a rule that will allow these packets to go out. Assuming the DHCP server receives my packets, it should respond that it is willing to renew my lease, and will send this information in UDP packets to port 68 on my computer. Accordingly, I'll also want to add a rule so that ipfw will allow in the response packets.

If I don't add these rules to my ipfw ruleset, or if for some reason the DHCP server does not respond to my renewal request, the "rebind" line will kick in on 2001/5/18 at 04:12:11. At this point my DHCP client is starting to get a bit worried about its upcoming lease expiration and will send out some more UDP packets destined for port 67. However, this time they will not be addressed to a particular DHCP server, but will instead be sent to the broadcast address of in the hope that any DHCP server will respond.

If no DHCP server responds, my lease will expire on 2001/5/19 at 01:12:11, meaning my DCHP client is no longer sure that it is allowed to continue to use its lease information. At this point, several things may occur. The client will still try to contact a DHCP server, so will continue to send out broadcasts to UDP port 67. It will also try pinging the default gateway address to see if its IP address is still valid, meaning it will be sending out ICMP type 8 code 0 packets and hoping to receive back ICMP type 0 code 0 packets. If worst comes to worst, and my client actually ends up with an invalid IP address, any responses that come back from a DHCP server will have to be received as broadcasts, that is, be addressed to port 68 on

Now, knowing all this, what should I add to my ruleset? Before I add anything, I should first double-check what rules I currently have as order is starting to become increasingly important. The more rules I add to my ruleset, the greater the possibility that an earlier rule will override my new rule. Also, the trick to a good ruleset is to only allow the traffic you wish using as few rules as possible. Your firewall may still work if you add too many rules, but you will end up putting an unnecessary burden on ipfw as it has to read more rules before it finds the one that applies to a packet, and you will also create more confusion for yourself when you can't figure out which of your many rules is preventing the behavior you expect.

Pages: 1, 2, 3

Next Pagearrow

Sponsored by: