Block UDP port 53 towards customer IP's Bryce D NETAGO NOT sent from an iPhone!
----- Reply message ----- From: "TJ Trout" <[email protected]> To: "Mikrotik Users" <[email protected]> Subject: [Mikrotik Users] Fwd: Open recursive resolver used for an attack: 162.251.127.65 Date: Thu, Dec 18, 2014 14:06 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
