Our DNS server was being used as an attack vector against primarily Chinese servers. DNS by preference uses UDP packets instead of TCP packets. The UDP protocol is much faster than TCP, but unlike TCP it does not perform a handshake. It is essentially one way communication with no confirmation of receipt. Because of that, it is possible to fake the sender IP address, and this is what the attackers were doing. A 128 byte request was causing a 388 byte invalid response to be sent to the target server. By enlisting many hacked computers, the attackers could overwhelm the target. Because the hackers were sending false source information to legitimate DNS servers, it was difficult to track the actual source.
Our DNS server has the capability to block source addresses that send too many requests per second, but it was getting to be a pain to update the list, and the list itself was getting quite long. So I set about to design a filter. For this purpose I am using the Windows Packet Filter Kit from NT Kernel Resources. This high performance packet filtering framework hooks the NDIS (Network Driver Interface Specification) driver in your Windows Operating System. This allows me to inspect each packet and only target incoming Port 53 UDP packets for further processing. A 20 element cache is maintained with the Source IP Address, the Question Type, the Question, and a Timeout. When a DNS request is received, the program checks the cache and if does not exist or is timed out, it is added with the maximun timeout. If it already exists, the timeout is reset to the maximum and the record dropped. A timer decrements the timeout values every second.
I had considered building this progam some time ago because some abusive DNS servers were using brute force by sending multiple requests for the same thing. The worst offender was Yahoo, which not only sent multiple requests from the same server, but also used multiple servers for the same thing. These hackers only served to elevate the priority.
This program is a work in progress, and once it has proven itself, I will convert it to run as a Service. To run as a Service, I must ensure that the program makes no attempt to display to the Desktop, as this can cause the operating system to get into an endless loop when the user is logged off and the desktop is not available. All potential errors must be trapped, and logged to the Event or other log.
J.A. Coutts
Edit: When the filter was put into production, a bug was discovered that caused Overflow errors in the PacketRead routine. The problem was caused by Message Types greater than 32,767, which got interpreted as negative numbers. The problem was resolved by changed the data type to long integer from integer. To facilitate this resolution, Error Trapping and a logging function was added.
Our DNS server has the capability to block source addresses that send too many requests per second, but it was getting to be a pain to update the list, and the list itself was getting quite long. So I set about to design a filter. For this purpose I am using the Windows Packet Filter Kit from NT Kernel Resources. This high performance packet filtering framework hooks the NDIS (Network Driver Interface Specification) driver in your Windows Operating System. This allows me to inspect each packet and only target incoming Port 53 UDP packets for further processing. A 20 element cache is maintained with the Source IP Address, the Question Type, the Question, and a Timeout. When a DNS request is received, the program checks the cache and if does not exist or is timed out, it is added with the maximun timeout. If it already exists, the timeout is reset to the maximum and the record dropped. A timer decrements the timeout values every second.
I had considered building this progam some time ago because some abusive DNS servers were using brute force by sending multiple requests for the same thing. The worst offender was Yahoo, which not only sent multiple requests from the same server, but also used multiple servers for the same thing. These hackers only served to elevate the priority.
This program is a work in progress, and once it has proven itself, I will convert it to run as a Service. To run as a Service, I must ensure that the program makes no attempt to display to the Desktop, as this can cause the operating system to get into an endless loop when the user is logged off and the desktop is not available. All potential errors must be trapped, and logged to the Event or other log.
J.A. Coutts
Edit: When the filter was put into production, a bug was discovered that caused Overflow errors in the PacketRead routine. The problem was caused by Message Types greater than 32,767, which got interpreted as negative numbers. The problem was resolved by changed the data type to long integer from integer. To facilitate this resolution, Error Trapping and a logging function was added.