Version 2.5 of DNSFilSvc utilizes version 3.2 of WinpkFilter from NT Kernel Resources. This version of WinpkFilter is not compatible with older versions because it supports both IPv4 and IPv6. The driver has been signed with a Microsoft approved certificate, so it now loads on all versions of Windows. Although the driver supports IPv6, DNSFilSvc does not. It uses long words (4 bytes) to store IPv4 addresses, whereas IPv6 requires 16 bytes for each address.
Like Version 2, DNSFilSvc consists of 2 programs; the actual service, and a management program to load and manage the service. Although the service can install itself, the management program is needed to store a couple of parameters. Because the Service runs in Session 0, the Registry values must be placed in the Registry in a location that allows System access. Because the management program runs in Session 1 or more, it has no actual interaction with the service. It deals entirely with the Service Manager (services.msc), and because it accesses restricted parts of the Registry, the management program must be "Run as Administrator".
Why would you need this kind of filter? If you operate a DNS Server, hackers can use that server to launch DoS (Denial of Service) attacks against other networks. Because DNS uses UDP packets on port 53, the advertized IP addresses where responses are sent, is not necessarily where the requests originated from. They can be spoofed. How do we know this? Here is just one example:
21:23:25 Request from 99.239.40.201 for any record for isc.org.
Doing an online port scan on this address:
Domain: CPE6c198ff33353-CM00fc8db88650.cpe.net.cable.rogers.com
IP Address: 99.239.40.201
City: Barrie
Region: ON
Country Name: Canada
Country Code: CA CA
Port Type Status
53 domain Closed
This machine does not even offer DNS service (at least not to the outside world).
DNSFilSvc filters out the excess requests. However, hackers figured out that they could get around the filter by slightly modifying each request. In this example:
00:19:11 Request from 183.56.172.145 for A-record for 6483220-0-3073944721-3608005795.ns.183-56-172-145-ns.dns-spider.myxns.cn.
the first number (6483220) was incremented for each request. So I added a DropList feature, where addresses for abusers could be manually added. The DropList file will be created in the same directory as the service the first time the service is activated. After adding an address to the file, the service must be restarted. The first 3 addresses I added to my own file were for a German provider that refused to address the over 13,000 requests per day that their servers were sending to our server (and those were just the ones that made it past the filter). All 3 servers had been blocked twice by our DNS server for sending over 20 requests per second, and after twice warning them, they are now permanently blocked. Any requests from these 3 servers are simply dropped by the filter.
This filter would not be suitable for a high volume server. For that kind of server, direct use of the Kernel Mode driver would be more appropriate.
Note: DNSFilSvc was designed to be run in Development mode as well as a Service. To compile the service, change the IsService flag to True.
The requests like this:
00:19:11 Request from 183.56.172.145 for A-record for 6483220-0-3073944721-3608005795.ns.183-56-172-145-ns.dns-spider.myxns.cn.
appear to be all targeted to a Chinese network, whereas the requests like:
21:23:25 Request from 99.239.40.201 for any record for isc.org.
all seem to be targeted to various networks around the world. These may have something to do with the recent DoS attacks against the Root Servers, but I am just guessing.
The first type of request is being handled by the IsDuplicated function. The long sequences of repeated requests appear as a single request only. The second type of request is being handled by the maximum requests accepted by the server. After exceeding the maximum, all further requests are blocked.
Sooner or later, the hackers will figure out what is happening in the latter case, and adjust accordingly. So I have prepared a follow-up version of "DNSFilSvc" for when they do. I do not want to publish this version in advance, but if you are interested, send me a PM and I will send it to you directly.
They finally figured it out, so I had to upgrade to Version 2.5.1. During the 74 seconds that it took to shut down the filter service and upgrade it, we received 35 requests from 5 IP addresses for isc.org. In all likelihood, the requests all came from the same source using spoofed IP addresses. This version will only provide extra functionality for those using a DNS server that does not support Recursion. That is to say that the server is only being used to host Domain Names. Requests for unsupported Domains will simply be dropped. Normally, our server will return the appropriate root servers and their respective IP addresses for unsupported domains.
We ran into another problem with one ISP from Indonesia that the filter could not address. They were using 62 different IP addresses for DNS service (118.98.115.1 - 118.98.115.62). There is no earthly reason that any ISP needs that many DNS servers, so I manually blocked all but the first 7 using the built-in blocking function in our DNS server.
J.A. Coutts
Updated: 01/16/2017
Last edited by couttsj; Jan 16th, 2017 at 11:13 AM.
I have no idea why, but for the last couple of weeks our DNS server has been bombarded by requests for a Type 99 record for our domain. A type 99 request is the former SPF record that was obsoleted by RFC 7208 in April 2014. The biggest offenders are:
Google
Amazon
Yahoo
AOL
This morning for example, we received 3100 requests from Amazon alone using dozens of different servers. So I modified DNSFil251.zip to block all Type 99 requests.
After supposedly blocking type 99 requests, we continued to receive many such requests. So I logged every request that came in and compared that to what was passed onto our DNS server. What showed up in our server as a type 99 was actually a type 32,768. This is not a valid type, but an experimental DNSSec record. As well, there were numerous type 0, which got interpreted as a type "A" in the DNS. So I have once again modified the DNS Filter Service to only accept valid types. After modifying the filter, the statistics for Sun. Jan 15, 2017 were:
Requests received by filter - 49,905
Requests passed onto DNS - 6,075
Requests dropped by filter - 43,830 or 88%
The percentage is actually higher than that, as the hackers were also using type 28, which is a valid type "AAAA" and I could not block those.
The situation has deteriorated further. Yesterday, we got these results.
Requests received by filter - 103,390
Requests passed on to DNS - 1,095
Requests dropped by filter - 102,295 or 99%
This is after modifying the filter once again. The Drop List was changed from a static Drop List to a dynamic Drop List. After analyzing the incoming requests, we determined a commonality to the spoofed requests, and used that criteria to add IP addresses to the Drop List. Because it is conceivable that a legitimate server may be requesting the experimental type that we are triggering on, we clear the Block List every 4 hours.
The question might arise as to how we know these are spoofed requests. The first clue is that on Jan. 05, we recorded a DNS volume about 4 times normal. It then fell back to normal volumes for 3 days, before climbing steadily every day thereafter. This is a common hacker technique. You test your code for a brief period of time to prevent the target from recognizing it as an attack and adjusting to it. The second clue is the fact that they are requesting DNS translations for record types that do not exist or are experimental. The third clue is the fact that the IP addresses seem to be added to the Drop List in groups over a very short period of time (less than a minute).
So why are the hackers still continuing the attack using our DNS server when it obviously isn't working? When you spoof an IP address using UDP, you never know that the target is not responding, because the responses would normally go to the spoofed address.
In the attached code, we make 4 different checks on the query question.
1. Is the IP address on the Drop List? If so, drop it.
2. Is the query of the trigger type? If so, add it to the Drop List.
3. Is the query for a domain that we do not host? If so, drop it.
4. Is the query a duplicate of one already requested? If so, drop it.
You can adjust the code to suit your own purposes. We also added a couple of counters to the code to give us an idea of how bad the situation is. The previous days statistics are reported at the beginning of the new log file.
Total queries processed - 103390
Queries forwarded to DNS - 1095
00:00:59|Drop List Cleared!
J.A. Coutts
Updated Stats 02/22/2017;
Requests received by filter - 240,771
Requests passed on to DNS - 601
Requests dropped by filter - 240,170 or 99.8%\
Updated Stats 02/23/2017;
Requests received by filter - 669,611
Requests passed on to DNS - 1,111
Requests dropped by filter - 668,500 or 99.8%
Updated Stats 05/08/2017
Total queries processed -8472
Queries forwarded to DNS - 2151 (25.4%)
Unsupported Domain Queries - 849 (10.0%)
Unsupported Type Queries - 2755 (32.5%)
Duplicate Queries - 2717 (32.1%)
Last edited by couttsj; May 9th, 2017 at 01:40 AM.
Some new information has surfaced that indicates these queries originate from hacked sources rather than having the source addresses spoofed.
Following up on a suggestion that analyzing the TTL could help to determine which requests are coming from spoofed addresses, I started to log the TTL on IP addresses as they are added to the block list. The TTL is decremented by one as it passes through each router, but not all operating systems use the same starting TTL by default. Unix/Linux systems default to 64, Windows systems default to 128, and Solaris systems default to 255. Most of the start values used seemed to be either 64 or 192, with a high percentage of the 64 based queries belonging to Level3, and a high percentage of the 192 based queries belonging to Amazon. There did not appear to be any that defaulted to 128. This fact, coupled with the fact that none of the filtered addresses belong to Microsoft, would suggest that Windows systems are not involved. I was able to verify the hop count using a ping on some of the 64 based queries, but I could not find any of the 192 based addresses that would respond to a ping. As none of the 192 based addresses appear to have any listening ports, I am unaware of any other method of determining hop count.
The number of queries has tapered off to 100,000-200,000 with the latest stats being:
04/01/2017
Total queries processed - 184745
Queries forwarded to DNS - 1093
Even though the number of queries has tapered off, the number of addresses blocked by the filter has not. It has actually increased slightly.
The only conclusion I can draw is that the source address on most of these queries has NOT been spoofed, and they represent the actual source. What this suggests is that the Linux devices on the other end have been compromised, and I am at a loss to explain what is happening here. I also find it difficult to believe I am the only one experiencing this issue, but I can find no information to the contrary.
It turns out the problem originates with EDNS. I logged the entire request packets for a brief period, and analyzed the results. The extra length of the OPT record (11 bytes), caused a miscalculation of the Question Length. It was not a problem for the question itself because the Name string ended in a null character, but the Question Length was also used to locate the Question Type. The extra length resulted in the DO flag being detected as the Question Type (32768).
This change brought DNS volumes back to near normal, but with the lack of IP addresses being added to the Drop List, I lost the ability to log daily packet counts. The other 3 criteria used to ignore query requests (Unsupported Domain Queries, Unsupported Type Queries, & Duplicate Queries), were still in play, so I added counters for these, and triggered a logfile entry when the day of the month changed. The latest download has been updated to reflect these changes.
EDNS (Extended Domain Name Service) was implemented in order to support DNSSEC. I personally do not intend to support EDNS, but that does not stop others from asking for it. Parts of the early Internet had limited packet size, so the UDP query message size was restricted to 512 bytes. The modern Internet no longer has this restriction, but changing the standards would have been a very difficult task. So they added an optional Pseudo Resource Record that advertised larger message size capabilities. Older responders would simply ignore the extra record, but the extra length could be used to pass the DNSSEC signature. But there are some downsides to EDNS. To keep the size capabilities up to date, it has to be periodically polled, increasing DNS traffic. And the increased size makes DNS amplification attacks more effective.
Reply With Quote