Overview
This article describes how writing kernel STREAMS module could solve DoS various issues faced by user-space DHCP server application that acts in heavy traffic condition. This software was tested on ORACLE Solaris 10 x64 and sparc platform. You can download source code. It ought to be used in conjunction with Internet System Consortium DHCP server. Patches for ISC DHCP software can be downloaded.
Abstract
Hosts in IP networks must be configured before it can communicate between them. Historically this task is solved by manual configuration of each host or via DHCP protocol.
DHCP protocol provides hosts automatically with the most essential configuration (but not limited to!) which is obtained from one or more DHCP servers: IP address, IP network mask, IP of default gateway, cache DNS servers etc.
The well-known scenario is the following : DHCP-aware clients send requests message to the DHCP server. After receiving valid request DHCP server, that manages a pool of IP addresses and other client-related information, assigns IP configuration parameters which is accepted by client via DHCP reply. DHCP traffic uses UDP broadcast or unicast.
Typical DHCP server implementation (ex. ISC DHCP) is single-threaded process that handles incoming DHCP requests and provides the reply packets if needed. Since it uses UDP, it can be easy compromised by sending a large amount of traffic. This leads packets not to be processed and getting dropped on high input load. Moreover the existence of bad implemented DHCP clients in modern IP networks significantly increases the probability of such situation. It is impossible to control which kind of devices are connected to the network.
The common approach to the high load issue has at least two ways:
- More threads are processing more traffic
Solaris bundled DHCP server is multi-threaded application, and so load of ingress traffic is redistributed between its threads thus reducing the negative effects of attacks if not solving it completely.
As to single-threaded DHCP software products (such as ISC DHCP), significant effort on re-writing of DHCP server software is required in order to have multhread support. Also to process all traffic a vast part of it could be a mess, can't be considered a suitable option.
- Localize attacker sources and drop before it reach DHCP serverStandard IP firewalls are of little use, because packets to be filtered all come from small number of DHCP relays. DHCP packets passed through DHCP relay has a common source - IP address of relay. In order to archive the goal more detail about DHCP will be discussed.
Known practices against DHCP DoS
Many modern ISPs often use DHCP relaying for serving many IP subnets on centralized DHCP servers. In that case DHCP relay agent software installed on low-end edge equipment assumes control on traffic retransmission of their network segment. Some vendors (but not all) have already implemented DHCP snooping feature which takes measures against some types of attacks including DHCP DoS. This feature has an disadvantage that it is error prone, because it is required all DSLAMs/FTTH switches configured. The configuration can be more burdensome if VLAN trunking is used, because it must be configured per each VLAN. However the worst disadvantage is that feature cannot prevent flood from an already authorized DHCP client which can send a huge amount of completely justified (and indispensable) DHCP client traffic.
Some vendors have implemented a feature which addresses flood issue. It is so called DHCP sending rate (or rate-limit) feature which places client port state in administratively down for a reasonable period of time if the number of DHCP packets originated from a single port exceeds configured limit. But this prevents that customer from functioning properly until the attack is finished. So technical support will be involved in problem solving even if the port is unblocked automatically after some time.
Discussed techniques help to stop excess of traffic at access equipment edge, but requires special implementation efforts on the hardware vendor side, which isn't suitable in multivendor environments.
Modern ISPs requires more robust, centralized, vendor independent and free of human factor solution.
Module dhcpmod topology scheme
It is proposed to stop traffic at DHCP server before it enters into DHCP server software. That option means to move a part of packet processing into the kernel.
For accessing traffic ISC DHCP under Solaris uses Data Link Provider Interface (DLPI). DLPI V2 enables a data link service user (DHCP) to access and uses any of a variety of conforming data link service providers. ISC DHCP uses Data Link Service (DLS) provider V2. It opens a Ethernet-capable device, creates a stream between DLS provider and DLS user and then registers the desired Physical Point of Attachment (PPA).
New software is a multi-threaded STREAMS module (named as dhcpmod).
Fig. 1 presents module insertion scheme.
For filtering DHCP traffic if you have Solaris zones with DHCP installed in, another technology was choosed – Solaris Packet Filtering HOOK. It will be discussed later in the upcoming article. Why we cannot use it for DLPI-enabled DHCP? Because DLPI acts at lower level than PF HOOK interception entry points and so packet discarding for DLPI-aware clients is impossible.
Processing DHCP packets as STREAMS mblk
STREAMS reading queue delivers it with IP header (8 bytes long), followed by UDP header (20 bytes long). Start of packet is pointed by b_rptr and end of packet respectively by b_wptr.
Module dhcpmod firstly checks for IP version and headers length. All packets are discarded silently if are not directed to UDP port 67 or contains positive values of IP fragmentation offset, or IP flag is non-zero and not equal to IP_DF (don't fragment). Bit alignment checks are included too.
DHCP packet is composed of two parts:
- BOOTP headerwhich is constantly in size and has predetermined number of BOOTP parameters
- DHCP Options which are not limited by the length of the value. Each option has a specific opcode that represents the type. The length specifies the length of the value. The length field is followed by the value. The set of options are appended to the DHCP packet after the BOOTP part of the packet. The options can be present in any order.
Workflow within kernel module dhcpmod
The reading queue (RQ) is the core element. The basic logic is to extract the most interesting parameters such as source IP address (in DHCP relay environment it helps to distinguish between IP subnets), Client-Ethernet-Address which represents MAC address of DHCP client equipment, DHCP Option 82 parameter (usually used for binding of IP address to physical port on low-end). Last parameter contains so called Agent Remote ID and Agent Circuit ID (at least one of them).
These parameters approximates packet information by using CRC32 algorithm incorporated in Solaris kernel.
Next action is to store calculated combined parameter in a HASH table and packet rating counters as well.
Fig. 2 shows the workflow briefly
For periodic cleanups of HASH table, special callback routine is installed. It is scheduled twice a second via qtimeout(). HASH table size is auto-adjusted (step is the power of two) while it grows to keep its effectiveness.
Management policies in dhcpmod
The module is configured using custom IOCTLS passed to a writing queue (WR). Accepted IOCTL argument is a pointer to uint_t variable. All policies can be set for the current queue instance.
The following traffic policies are supported:
/*
* Ioctls.
*/
#define DHCPIOC ('D' << 8)
/* dropping rate per min */
#define DHCPIOCSDROPANYPPM (DHCPIOC|1)
/* dropping policy if no DHCP Option 82 info */
#define DHCPIOCSDROPPOLIFNORA (DHCPIOC|2)
/* dropping rate per min if no DHCP Option 82 info */
#define DHCPIOCSDROPNORAPPM (DHCPIOC|3)
/* dropping policy for all packets if no DHCP Option 82 info */
#define DHCPIOCSDROPPOLALLNORA (DHCPIOC|4)
/* dropping policy by rate */
#define DHCPIOCSDROPPOLBYPPM (DHCPIOC|5)
DHCPIOCSDROPANYPPM Allowed number of packets for discard packets by rate
DHCPIOCSDROPPOLIFNORA Turning off/on discard packets by rate policy if no DHCP Option 82 information
DHCPIOCSDROPNORAPPM Allowed number of packets if no DHCP Option 82 information
DHCPIOCSDROPPOLALLNORA Turning off/on discard all packets policy with no DHCP Option 82
DHCPIOCSDROPPOLBYPPM Turning off/on discard packets by rate policy
Conclusion
In this article an effort was presented towards implementing new DHCPv4 filtering software to run as a STREAMS module in the Solaris kernel. This software automatically prevents DoS on DHCP server without wasting CPU cycles of DHCP server process.
Hence this solution will add some processing delay. It is supposed that DHCP server application uses DLPI and some filtering work is already done in the kernel space: after attaching to PPA it filters only destination UDP port 67. So an inserting of new module will increase the processing delay imperceptibly.
Also this opens a new room for further enhancements: discarding packets without certain DHCP options etc.
Note that this solution is centralized, vendor independent and can be treated as a part of protecting solution for DHCP large network scheme. It was built for use in conjunction with DHCP snooping and DHCP Option 82 features.
No comments:
Post a Comment