im remote now - but thinking a quick script may help for those who need it - anyone want to jump in - if not - i will try to get to it this weekend
On Thu, Dec 18, 2014 at 4:18 PM, Sam Tetherow <[email protected]> wrote: > 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]> > Date: Dec 18, 2014 1:00 PM > Subject: Open recursive resolver used for an attack: 162.251.127.65 > To: <[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. 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. 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. 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].) > > > _______________________________________________ > Mikrotik-users mailing > [email protected]http://lists.wispa.org/mailman/listinfo/mikrotik-users > > > > _______________________________________________ > 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
