BSD Firewalls: Fine-Tuning Rulesets
06/01/2001In 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";
fixed-address 24.141.119.162;
option subnet-mask 255.255.252.0;
option time-offset -18000;
option routers 24.141.116.1;
option domain-name-servers 24.226.1.90,24.226.1.20,24.2.9.34;
option host-name "my_hostname";
option domain-name "my_domainname";
option broadcast-address 255.255.255.255;
option dhcp-lease-time 604800;
option dhcp-message-type 5;
option dhcp-server-identifier 24.226.1.41;
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: |
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 24.226.1.41, 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 255.255.255.255 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 255.255.255.255.
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.