Normally a netmask is used to define a network, but I ran into a problem that required the use of a mask. Let me explain.
For some time now, I have had a problem with excessive DNS queries theoretically originating from Amazon IP ranges. I say theoretical, because the origin of UDP requests can be spoofed. In this case however, I believe them to be real because sometimes a rash of UDP requests will end with TCP requests, and TCP requests are much harder to spoof. There was literally more than a hundred thousand requests per day from hundreds of different servers. All attempts to get Amazon to address the issue have failed.
02/14/2018
Total queries processed - 127900
Queries forwarded to DNS - 14528
Queries dropped by filter - 0
Unsupported Domain Queries - 1396
Unsupported Type Queries - 88820
Duplicate Queries - 23156
These are the stats reported by our firewall, and the bulk of those are from Amazon IP addresses. Of the 14,528 requests forwarded to the DNS for processing, 12,840 were from Amazon. Even with most of the address ranges blocked within the DNS server itself, it was struggling at times to keep up (it is an older multi-use server).
To relieve the pressure on the server, I decided to move the address blocks from the DNS server to the Firewall. That meant redesigning the Firewall software because it was only designed to block individual addresses, and there were hundreds that needed to be blocked. The only feasible approach was to block entire IP ranges, and that's where Netmasks come into the picture.
Unlike the DNS Server, the Firewall does not log individual attempts, so it was imperative that the blocks be accurate. Calculating them by hand was time consuming and error prone, so I wrote a program to do it for me.
For an explanation of how Netmasks work, see:
http://www.yellowhead.com/mask.htm
Our situation is a little more complex. IP ranges do not often get assigned in nice full class ranges. The sample program wants a starting IP number and an ending IP number, and that is how they are generally found in a Whois server. For example:
Amazon Technologies Inc. AT-88-Z (NET-18-144-0-0-1) 18.144.0.0 - 18.144.255.255
But it also reports:
Amazon Technologies Inc. AT-88-Z (NET-18-145-0-0-1) 18.145.0.0 - 18.145.255.255
The input should be 18.144.0.0 - 18.145.255.255 and this yields a Netmask of:
255.254.0.0
11111111.11111110.00000000.00000000
This verifies, but within the same class network we find 18.194.0.0 - 18.197.255.255. Calculating a Netmask for these numbers reveals:
255.248.0.0
11111111.11111000.00000000.00000000
but it does not verify. Why not? Lets look at the starting and ending addresses in binary.
00010010.11000010.00000000.00000000
00010010.11000101.00000000.00000000
The zeros in the Netmask for the 1,2,& 4 bits tells us that 11000110 & 11000111 are permissible, when in fact 198 & 199 are outside the defined range. To accomplish this one, we have to use 2 separate masks.
Address - 18.194.0.0
Netmask - 255.254.0.0
Address - 18.196.0.0
Netmask - 255.254.0.0
These will verify.
Netmasks pretty well have to be contiguous. In other words, no zeros between the ones. If we attempt to define the network 54.144.0.0 - 54.255.255.255, we get:
Netmask - 255.144.0.0
Binary - 11111111.10010000.00000000.00000000
with a warning that it probably will not pass the verify test. And indeed it doesn't. It has to be broken up into smaller blocks.
J.A. Coutts
For some time now, I have had a problem with excessive DNS queries theoretically originating from Amazon IP ranges. I say theoretical, because the origin of UDP requests can be spoofed. In this case however, I believe them to be real because sometimes a rash of UDP requests will end with TCP requests, and TCP requests are much harder to spoof. There was literally more than a hundred thousand requests per day from hundreds of different servers. All attempts to get Amazon to address the issue have failed.
02/14/2018
Total queries processed - 127900
Queries forwarded to DNS - 14528
Queries dropped by filter - 0
Unsupported Domain Queries - 1396
Unsupported Type Queries - 88820
Duplicate Queries - 23156
These are the stats reported by our firewall, and the bulk of those are from Amazon IP addresses. Of the 14,528 requests forwarded to the DNS for processing, 12,840 were from Amazon. Even with most of the address ranges blocked within the DNS server itself, it was struggling at times to keep up (it is an older multi-use server).
To relieve the pressure on the server, I decided to move the address blocks from the DNS server to the Firewall. That meant redesigning the Firewall software because it was only designed to block individual addresses, and there were hundreds that needed to be blocked. The only feasible approach was to block entire IP ranges, and that's where Netmasks come into the picture.
Unlike the DNS Server, the Firewall does not log individual attempts, so it was imperative that the blocks be accurate. Calculating them by hand was time consuming and error prone, so I wrote a program to do it for me.
For an explanation of how Netmasks work, see:
http://www.yellowhead.com/mask.htm
Our situation is a little more complex. IP ranges do not often get assigned in nice full class ranges. The sample program wants a starting IP number and an ending IP number, and that is how they are generally found in a Whois server. For example:
Amazon Technologies Inc. AT-88-Z (NET-18-144-0-0-1) 18.144.0.0 - 18.144.255.255
But it also reports:
Amazon Technologies Inc. AT-88-Z (NET-18-145-0-0-1) 18.145.0.0 - 18.145.255.255
The input should be 18.144.0.0 - 18.145.255.255 and this yields a Netmask of:
255.254.0.0
11111111.11111110.00000000.00000000
This verifies, but within the same class network we find 18.194.0.0 - 18.197.255.255. Calculating a Netmask for these numbers reveals:
255.248.0.0
11111111.11111000.00000000.00000000
but it does not verify. Why not? Lets look at the starting and ending addresses in binary.
00010010.11000010.00000000.00000000
00010010.11000101.00000000.00000000
The zeros in the Netmask for the 1,2,& 4 bits tells us that 11000110 & 11000111 are permissible, when in fact 198 & 199 are outside the defined range. To accomplish this one, we have to use 2 separate masks.
Address - 18.194.0.0
Netmask - 255.254.0.0
Address - 18.196.0.0
Netmask - 255.254.0.0
These will verify.
Netmasks pretty well have to be contiguous. In other words, no zeros between the ones. If we attempt to define the network 54.144.0.0 - 54.255.255.255, we get:
Netmask - 255.144.0.0
Binary - 11111111.10010000.00000000.00000000
with a warning that it probably will not pass the verify test. And indeed it doesn't. It has to be broken up into smaller blocks.
J.A. Coutts