1. Restrict your recursive DNS to answer only your IP space.
2. Run separate authoritative servers.
3. Drop all traffic going out your external interfaces that are not from
your IP space.
4. Drop all traffic coming in your external interfaces that is from your
IP space.
5. Drop all incoming port 53 (UDP and TCP) except to your DNS servers
(and an approved list of DNS servers on your network)
On 12/18/2014 03:06 PM, TJ Trout wrote:
Anything that can be done at the edge/core to block this type of
attack in the firewall? Would be easier than trying to get customers
to disable remote requests. ..
---------- Forwarded message ----------
From: "NFOservers.com DDoS notifier" <[email protected]
<mailto:[email protected]>>
Date: Dec 18, 2014 1:00 PM
Subject: Open recursive resolver used for an attack: 162.251.127.65
To: <[email protected] <mailto:[email protected]>>
Cc:
You appear to be running an open recursive resolver at IP address
162.251.127.65 that participated in an attack against a customer of
ours, generating large UDP responses to spoofed queries, with those
responses becoming fragmented because of their size.
Please consider reconfiguring your resolver in one or more of these ways:
- To only serve your customers and not respond to outside IP addresses
(in BIND, this is done by defining a limited set of hosts in
"allow-query"; with a Windows DNS server, you would need to use
firewall rules to block external access to UDP port 53)
- To only serve domains that it is authoritative for (in BIND, this is
done by defining a limited set of hosts in "allow-query" for the
server overall but setting "allow-query" to "any" for each zone)
- To rate-limit responses to individual source IP addresses (such as
by using DNS Response Rate Limiting or iptables rules)
More information on this type of attack and what each party can do to
mitigate it can be found here:
http://www.us-cert.gov/ncas/alerts/TA13-088A
If you are an ISP, please also look at your network configuration and
make sure that you do not allow spoofed traffic (that pretends to be
from external IP addresses) to leave the network. Hosts that allow
spoofed traffic make possible this type of attack.
Example DNS responses from your resolver during this attack are given
below.
Date/timestamps (far left) are UTC.
2014-12-18 20:09:42.765086 IP (tos 0x0, ttl 54, id 36277, offset 0,
flags [+], proto UDP (17), length 1500) 162.251.127.65.53 >
31.186.250.x.21218: 23398 26/6/0 doleta.gov <http://doleta.gov>.
RRSIG[|domain]
0x0000: 4500 05dc 8db5 2000 3611 9494 a2fb 7f41 E.......6......A
0x0010: 1fba fad0 0035 52e2 0a1b 6cd2 5b66 8180 .....5R...l.[f..
0x0020: 0001 001a 0006 0000 0664 6f6c 6574 6103 .........doleta.
0x0030: 676f 7600 00ff 0001 c00c 002e 0001 0000 gov.............
0x0040: 02f7 009e 0033 0702 0000 0384 549b 7deb .....3......T.}.
0x0050: 5492 T.
2014-12-18 20:09:42.765653 IP (tos 0x0, ttl 54, id 36278, offset 0,
flags [+], proto UDP (17), length 1500) 162.251.127.65.53 >
31.186.250.x.21218: 23398 26/6/0 doleta.gov <http://doleta.gov>.
RRSIG[|domain]
0x0000: 4500 05dc 8db6 2000 3611 9493 a2fb 7f41 E.......6......A
0x0010: 1fba fad0 0035 52e2 0a1b 5047 5b66 8180 .....5R...PG[f..
0x0020: 0001 001a 0006 0000 0664 6f6c 6574 6103 .........doleta.
0x0030: 676f 7600 00ff 0001 c00c 002e 0001 0000 gov.............
0x0040: 02f7 009e 0006 0702 0000 0384 549b 7deb ............T.}.
0x0050: 5492 T.
2014-12-18 20:09:42.766223 IP (tos 0x0, ttl 54, id 36279, offset 0,
flags [+], proto UDP (17), length 1500) 162.251.127.65.53 >
31.186.250.x.21218: 23398 26/6/0 doleta.gov <http://doleta.gov>.
RRSIG[|domain]
0x0000: 4500 05dc 8db7 2000 3611 9492 a2fb 7f41 E.......6......A
0x0010: 1fba fad0 0035 52e2 0a1b 608f 5b66 8180 .....5R...`.[f..
0x0020: 0001 001a 0006 0000 0664 6f6c 6574 6103 .........doleta.
0x0030: 676f 7600 00ff 0001 c00c 002e 0001 0000 gov.............
0x0040: 02f7 011e 0030 0702 0000 0384 549b 7deb .....0......T.}.
0x0050: 5492 T.
(The final octet of our customer's IP address is masked in the above
output because some automatic parsers become confused when multiple IP
addresses are included. The value of that octet is "208".)
-John
President
Nuclearfallout, Enterprises, Inc. (NFOservers.com)
(We're sending out so many of these notices, and seeing so many
auto-responses, that we can't go through this email inbox effectively.
If you have follow-up questions, please contact us at [email protected]
<mailto:[email protected]>.)
_______________________________________________
Mikrotik-users mailing list
[email protected]
http://lists.wispa.org/mailman/listinfo/mikrotik-users
_______________________________________________
Mikrotik-users mailing list
[email protected]
http://lists.wispa.org/mailman/listinfo/mikrotik-users
