|
DHCP Packet Filtering
Stopping unwanted DHCP packets before they can damage performance
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: February 27, 2001
Note: Birds-Eye.Net offers a DHCP Stress Testing Suite [evaluation/buy]
as well as expert consulting help for the peskiest of DHCP configurations [consulting].
Overview:
Existing IP address provisioning DHCP*
servers geared for enterprise networking currently offer only minimum functionality need
by operators of a Multiple Subscriber Organizations (MSO) cable modem systems. The
following is a list of feature enhancements that could be made by DHCP vendors to enable
them to operate on broadband public networks:
1.
Variable
MAC address filter
2.
Variable
length packet filter
3.
RAS
Handling
* Use
of DHCP from here on out will also mean dynamic BOOTP
Each of these enhancements will be discussed
in detail. The object of this document is to describe the operational need as well as the
possible results of adding this functionality.
Variable MAC Address Filter
There are cases where one wants to filter
certain types of packets coming from specific MAC addresses. MAC addresses to be filtered
are either known by their exact MAC address or by some part of their MAC address
(typically their Vendor ID but sometimes a more exact match is required). For this reason,
the following filters MUST be supported on the DHCP server to filter packets from these
MAC addresses.
Exact Match
MAC String: |
Action: |
00:00:ca:03:12:57 |
Block |
00:00:ca:03:12:57 |
Pass |
Partial Match: (Vendor ID)
MAC String: |
Action: |
00:00:ca: |
Block |
00:00:ca: |
Pass |
Partial Match: (extended Vendor ID)
MAC String: |
Action: |
00:00:ca:06: |
Block |
00:00:ca:06 |
Pass |
MAC filtering can be set up in two steps.
The first is to configure the scope of MAC addresses that will be allowed to pass/block
(known as the global statement) then the scope of MAC addresses that will be allowed to
pass (which is known as the local statement).
Example #1:
xx:xx:xx:xx:xx:xx pass
00:00:ca
block
In this example (#1), all packets matching
the MAC addresses (xx:xx:xx:xx:xx:xx) will be allowed to enter the DHCP packet processing
logic – this is what the first statement tells the DHCP server. However, the second
statement stipulates that the DHCP server should ignore all DHCP packets that begin with
“00:00:ca:” – these will not be processed (or simply blocked). Both the
“x” as well as the “:” in these statements should be optional but
sometimes used as placeholders.
Example #2:
block
0000ca
pass
In this example (#2), all packets having the
MAC address “” will not be allowed to enter the DHCP packet processing logic. In
other words, all DHCP packets will be blocked. However, those packets that begin with
“0000ca” will be allowed to proceed into the DHCP server’s packet
processing. Additional comment lines should be supported like standard UNIX configuration
files (i.e. any line beginning with a pound “#” symbol should be ignored).
Likewise, any information beyond a pound symbol within a line should be ignored. Thus the
following are valid lines in the filtering file:
# Variable MAC filtering file
# Modified: 02/27/2001 bahlmann
block
#block everything
0000ca
pass
#only process 0000ca
This functionality is extremely powerful and
allows the DHCP server to be set up in virtually any type of mode and provide extremely
specialized service. These entries should be stored in a single external file that can be
hand edited for easy changes. Note the DHCP server should sense any changes to this file
so it can be made active on the server (i.e. the server should be able to sense a change
has been made and assimilate its current running state to the new configuration without
restarting – very important that these types of changes can be made on the fly). The
presence of the file implies filtering and the absence of the file means normal behavior
– as a result no configuration is required to activate/deactivate the
filtering.
Variable Length Packet Filter:
For a number of reasons, there are cases
where packets become garbled – and even malformed For these cases there is a need to
qualify DHCP packets in some way before they are allowed to pass into the processing
logic. A malformed or incomplete packet that is allowed to enter DHCP processing will need
to get dropped anyway or worst – it will not contain all the information required for
the DHCP server to return a valid packet back to the requesting client.
To address these cases a “minimum
packet size” server parameter should be supported. This parameter should be
configurable and apply to all packets received by the DHCP server. Usually a minimum size
of 200 would block a majority of bad packets yet allow some clients that send minimum
packet sizes (like Apple clients).
RAS Handling
Microsoft servers that run Remote Access
Service (RAS) can present significant problems to DHCP servers on public networks.
Essentially, RAS can work like a DHCP client requesting dynamic IP addresses for each of
its virtual interfaces. Any DHCP server set to doll out IP addresses freely is subject to
a RAS attack which can easily consume all available IP addresses in the DHCP server’s
address pool. Since many of these RAS servers can exist on a typical broadband network
this ability to consume IP addresses is compounded.
One can use variable length MAC address
filtering explained above to drop these packets but this method still requires the server
to open each DHCP packet. The other limitation of this handling is that it does not stop
the RAS attack – instead it simply drops these packets. However, in order to drop a
packet one needs to accept it, examine it, and discard it – by taking this approach
the server does not engage in further (expensive) processing of the packet but still
consumes some resources to discard it. A better way to handle RAS is to give them an offer
they can’t refuse – but a lease that will not work on the production network.
This offer should be of a specified private network address range (127.x.x.x is one likely
subnet). This range is used over and over again for each unique RAS client request. Each
of these leases provided to RAS clients should be of long lease duration (e.g. good for 50
years or something like that).
Once the RAS client gets this address it
will become isolated on the network and not work. Even better about this is that once it
becomes satisfied/isolated, the RAS requests from this client stop until their lease runs
out. To turn on this field one should be able to configure the private IP address range of
the “RAS handler” as well as the lease offset from current server time. In this way, one can toggle the RAS handler on/off
as well as dictate the IP range that it will doll out and the time offset it will apply to
the spoofed leases.
RAS_Handler
127.0.0.1-127.0.0.254
50yr
#activated 2/27/2001 bfb
#RAS_Handler
127.0.0.1-127.0.0.254
50yr
#deactivated 2/27/2001 bfb
The same use of UNIX like comments should be
supported as other features.
Check out these other Birds-Eye.Net papers/products regarding DHCP:
Products:
White Papers and Reading Material
Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white
papers hot off
the presses by adding our RSS feed to your reader.
|