[#328562] Open recursive resolver used for an attack: 209.191.185.66

[Zachary West]

named has been disabled on our servers 209.191.185.65 and 209.191.185.66.
Thanks for the heads up.

On Sat, Jul 26, 2014 at 6:44 AM, <support at networkredux.com> wrote:

> Hello Team,
>
> We received following abuse report for your server
>
>
> ===========================================================================================
> You appear to be running an open recursive resolver at IP address
> 209.191.185.66
> that participated in an attack against a customer of ours today, 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.
> Timestamps (far left) are PDT (UTC-7), and the date is 2014-07-20.
>
> 22:57:22.690040 IP (tos 0x0, ttl 53, id 42948, offset 0, flags [+], proto
> UDP
> (17), length 1500) 209.191.185.66.53 > 192.223.27.x.36996: 3361| 9/0/1
> webpanel.sk. RRSIG[|domain]
>     0x0000:  4500 05dc a7c4 2000 3511 510d d1bf b942  E.......5.Q....B
>     0x0010:  c0df 1b5e 0035 9084 0f97 581f 0d21 8380  ...^.5....X..!..
>     0x0020:  0001 0009 0000 0001 0877 6562 7061 6e65  .........webpane
>     0x0030:  6c02 736b 0000 ff00 01c0 0c00 2e00 0100  l.sk............
>     0x0040:  00e7 7802 1f00 3007 0200 0151 8053 db3a  ..x...0....Q.S.:
>     0x0050:  5351                                    SQ
> 22:57:22.693345 IP (tos 0x0, ttl 53, id 42949, offset 0, flags [+], proto
> UDP
> (17), length 1500) 209.191.185.66.53 > 192.223.27.x.36996: 3361| 9/0/1
> webpanel.sk. RRSIG[|domain]
>     0x0000:  4500 05dc a7c5 2000 3511 510c d1bf b942  E.......5.Q....B
>     0x0010:  c0df 1b5e 0035 9084 0f97 a6d0 0d21 8380  ...^.5.......!..
>     0x0020:  0001 0009 0000 0001 0877 6562 7061 6e65  .........webpane
>     0x0030:  6c02 736b 0000 ff00 01c0 0c00 2e00 0100  l.sk............
>     0x0040:  00e7 7802 1f00 3007 0200 0151 8053 db3a  ..x...0....Q.S.:
>     0x0050:  5351                                    SQ
> 22:57:22.696631 IP (tos 0x0, ttl 53, id 42950, offset 0, flags [+], proto
> UDP
> (17), length 1500) 209.191.185.66.53 > 192.223.27.x.36996: 3361| 9/0/1
> webpanel.sk. RRSIG[|domain]
>     0x0000:  4500 05dc a7c6 2000 3511 510b d1bf b942  E.......5.Q....B
>     0x0010:  c0df 1b5e 0035 9084 0f97 581f 0d21 8380  ...^.5....X..!..
>     0x0020:  0001 0009 0000 0001 0877 6562 7061 6e65  .........webpane
>     0x0030:  6c02 736b 0000 ff00 01c0 0c00 2e00 0100  l.sk............
>     0x0040:  00e7 7802 1f00 3007 0200 0151 8053 db3a  ..x...0....Q.S.:
>     0x0050:  5351                                    SQ
>
> (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 "94".)
>
> -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 noc at nfoe.net.)
>
> ===========================================================================================
> --
> Sujith Paily
> System Architect | Global RTAC
> Network Redux, LLC
>
> Common Answers:  http://www.networkredux.com/answers
> How am I doing?   Email my management team at
> rtac.escalation at networkredux.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20140812/e23cf323/attachment-0002.html>