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.
J.A. Coutts
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.
J.A. Coutts