Re: denied NS/IN
In message f4058b15-888b-4cbd-b682-2ea2e1889...@stupendous.net, Nathan Ollerenshaw writes: On 21/01/2009, at 10:40 AM, Scott Haneda wrote: Hello, looking at my logs today, I am getting hammered with these: 20-Jan-2009 15:39:06.284 security: info: client 66.230.160.1#48517: query (cache) './NS/IN' denied 20-Jan-2009 15:39:06.790 security: info: client 66.230.128.15#31593: query (cache) './NS/IN' denied Repeated over and over, how do I tell what they are, and if they are bad, what is the best way to block them? -- Scott Scott, As you know, these are spoofed queries, created in the hope that you will reflect traffic back to these IPs to assist in DDoSing them. Patrik Rak posted to my blog an iptables rule, which is useful for those of us running linux, that drops this specific type of recursive query; namely IN NS queries against '.'. iptables -A INPUT -j DROP -p udp --dport domain -m u32 --u32 \ 0220...@1216=10220...@2024=00220...@21=0x00020001 I've tested it, and it appears effective. I now have blessed silence in my logfiles. You you don't also have blessed silence on the counters on this rule there is still a problem and you should be complaining to whoever is sending the packets to you. This just stops the amplification it doesn't clear up the problem. Ideally it'd be great to be able to track back through the internet and get every single network operator to implement BCP 38, but while that's getting done (and good luck with that), you at least have a workaround. At least until the kiddies change what kind of query they use ... god forbid they work out what names an authoritative nameserver WILL respond to and query that. Hope this helps, Nathan. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: denied NS/IN
On 24/01/2009, at 9:57 AM, Mark Andrews wrote: You you don't also have blessed silence on the counters on this rule there is still a problem and you should be complaining to whoever is sending the packets to you. This just stops the amplification it doesn't clear up the problem. Not every operator out there gives a damn. Getting the entire planet to implement ingress filtering is an admirable goal, but much like every other 'recommendation' out there, there are huge chunks of the internet that won't ever implement it out of ignorance and we'll be stuck with spoofed traffic. Conversation I had with one of the guys in our networking team: So, we're not under attack? We're just reflecting a small amount of traffic back to a victim? correct, it is negligible load for us Ok, it's not severity 1 then, none of our customers are affected and its not affecting us. I'll look at it when I get time. Which means, of course, never. Nathan. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: denied NS/IN
On Thu, 2009-01-22 at 10:25 +1100, Mark Andrews wrote: One way to test is to have a test box that sends spoofed traffic to a machine you control. Thanks, Mark. That tells me pretty well what I needed to know, but hoped not to hear: I have to build my own bot-net. 8-) /Niall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: denied NS/IN
In article gl61mf$9h...@sf1.isc.org, Mark Andrews mark_andr...@isc.org wrote: In message fb979b33-df83-4460-a3e4-040cd165e...@newgeo.com, Scott Haneda writ es: Is BCP 38 really as solid and plug and play as it sounds? In a shared, or colo'd environment, can that ISP really deploy something like this, without it causing trouble for those that assume unfettered inbound and outbound traffic to their servers? Yes it is. Everyone in a colo should be able to tell you which source address (prefixes) they should be emitting. You filter everything else. The closer to the edge that you do this the easier it is to do. Just a niggle (because we've been bitten by this): if you have multihomed hosts you need to be careful. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: denied NS/IN
On 20.01.09 17:52, Frank Bulk wrote:
That's being discussed on NANOG, here's one thread:
http://markmail.org/message/ydiqnztzmz5qmusf
See here for more details in blocking them:
http://www.cymru.com/Documents/secure-bind-template.html
specifically:
blackhole {
// Deny anything from the bogon networks as
// detailed in the bogon ACL.
bogon;
};
Note that isprime is suggesting an ACL on your firewall or router.
Especially when in the article above they ask for NOT blackholing them :)
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: Let God Debug It!.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: denied NS/IN
On Wed, 2009-01-21 at 12:44 +1100, Mark Andrews wrote: You should talk to your ISP to chase the traffic back to its source and get BCP 38 implemented there. BCP 38 is ~10 years old now. There is no excuse for not filtering spoofed traffic. Absolutely. Putting myself at the other end of the telescope, I'm wondering what tools (if any) are available for verifying that the ingress filtering actually in place is indeed compliant with BCP 38. I try to be conscientious, but drawing valid conclusions from visual inspection of the ACLs is already a challenge for my domestic network (3 LANs and an upstream). Enterprise (even with only one upstream) or ISP networks are likely more difficult to verify. Pointers for my next RTFM binge are welcome. Further discussion is probably off-topic for the bind-users list. /Niall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: denied NS/IN
In message 1232561124.6369.187.ca...@d410-heron, Niall O'Reilly writes: On Wed, 2009-01-21 at 12:44 +1100, Mark Andrews wrote: You should talk to your ISP to chase the traffic back to its source and get BCP 38 implemented there. BCP 38 is ~10 years old now. There is no excuse for not filtering spoofed traffic. Absolutely. Putting myself at the other end of the telescope, I'm wondering what tools (if any) are available for verifying that the ingress filtering actually in place is indeed compliant with BCP 38. I try to be conscientious, but drawing valid conclusions from visual inspection of the ACLs is already a challenge for my domestic network (3 LANs and an upstream). Enterprise (even with only one upstream) or ISP networks are likely more difficult to verify. Pointers for my next RTFM binge are welcome. Further discussion is probably off-topic for the bind-users list. /Niall One way to test is to have a test box that sends spoofed traffic to a machine you control. You should be able to detect acl or other hits. Checking the acls regularly is also a way to detect compromised machines that could be used for a different badness. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: denied NS/IN
That's being discussed on NANOG, here's one thread:
http://markmail.org/message/ydiqnztzmz5qmusf
See here for more details in blocking them:
http://www.cymru.com/Documents/secure-bind-template.html
specifically:
blackhole {
// Deny anything from the bogon networks as
// detailed in the bogon ACL.
bogon;
};
Note that isprime is suggesting an ACL on your firewall or router.
Frank
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Scott Haneda
Sent: Tuesday, January 20, 2009 5:41 PM
To: BIND Users Mailing List
Subject: denied NS/IN
Hello, looking at my logs today, I am getting hammered with these:
20-Jan-2009 15:39:06.284 security: info: client 66.230.160.1#48517:
query (cache) './NS/IN' denied
20-Jan-2009 15:39:06.790 security: info: client 66.230.128.15#31593:
query (cache) './NS/IN' denied
Repeated over and over, how do I tell what they are, and if they are
bad, what is the best way to block them?
--
Scott
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: denied NS/IN
On Jan 20, 2009, at 3:52 PM, Frank Bulk wrote:
That's being discussed on NANOG, here's one thread:
http://markmail.org/message/ydiqnztzmz5qmusf
See here for more details in blocking them:
http://www.cymru.com/Documents/secure-bind-template.html
specifically:
blackhole {
// Deny anything from the bogon networks as
// detailed in the bogon ACL.
bogon;
};
Note that isprime is suggesting an ACL on your firewall or router.
Thank you, curious, why does it say block all but 53, isnt that
exactly what we want to block?
--
Scott
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: denied NS/IN
According to ISPrime, 66.230.128.15 and 66.230.160.1 are authoritative DNS
servers, but do not make outbound requests. As such, they only *receive*
queries from remote DNS servers (or clients). So all UDP or TCP-based DNS
requests to those two DNS servers are made *to* port 53. And those two DNS
servers respond to those requests on port 53. The spoofers are sourcing
their queries from non-port 53 ports, so it's easy to tell what is spoofed
and what's not.
Frank
-Original Message-
From: Scott Haneda [mailto:talkli...@newgeo.com]
Sent: Tuesday, January 20, 2009 6:12 PM
To: frnk...@iname.com
Cc: BIND Users Mailing List
Subject: Re: denied NS/IN
On Jan 20, 2009, at 3:52 PM, Frank Bulk wrote:
That's being discussed on NANOG, here's one thread:
http://markmail.org/message/ydiqnztzmz5qmusf
See here for more details in blocking them:
http://www.cymru.com/Documents/secure-bind-template.html
specifically:
blackhole {
// Deny anything from the bogon networks as
// detailed in the bogon ACL.
bogon;
};
Note that isprime is suggesting an ACL on your firewall or router.
Thank you, curious, why does it say block all but 53, isnt that
exactly what we want to block?
--
Scott
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: denied NS/IN
In message 232b45f8-acd3-427a-95e9-bc3ca5fc9...@newgeo.com, Scott Haneda writ es: Hello, looking at my logs today, I am getting hammered with these: 20-Jan-2009 15:39:06.284 security: info: client 66.230.160.1#48517: query (cache) './NS/IN' denied 20-Jan-2009 15:39:06.790 security: info: client 66.230.128.15#31593: query (cache) './NS/IN' denied Repeated over and over, how do I tell what they are, and if they are bad, what is the best way to block them? -- Scott You should talk to your ISP to chase the traffic back to its source and get BCP 38 implemented there. BCP 38 is ~10 years old now. There is no excuse for not filtering spoofed traffic. If the source doesn't want to implement BCP 38 then de-peering the source should be considered. Mark http://www.ietf.org/rfc/rfc2267.txt January 1998 http://www.ietf.org/rfc/rfc2827.txt May 2000 (BCP 38) http://www.ietf.org/rfc/rfc3704.txt March 2004 (BCP 84) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: denied NS/IN
On Jan 20, 2009, at 5:44 PM, Mark Andrews wrote: In message 232b45f8-acd3-427a-95e9-bc3ca5fc9...@newgeo.com, Scott Haneda writ es: Hello, looking at my logs today, I am getting hammered with these: 20-Jan-2009 15:39:06.284 security: info: client 66.230.160.1#48517: query (cache) './NS/IN' denied 20-Jan-2009 15:39:06.790 security: info: client 66.230.128.15#31593: query (cache) './NS/IN' denied Repeated over and over, how do I tell what they are, and if they are bad, what is the best way to block them? -- Scott You should talk to your ISP to chase the traffic back to its source and get BCP 38 implemented there. BCP 38 is ~10 years old now. There is no excuse for not filtering spoofed traffic. If the source doesn't want to implement BCP 38 then de-peering the source should be considered. Is BCP 38 really as solid and plug and play as it sounds? In a shared, or colo'd environment, can that ISP really deploy something like this, without it causing trouble for those that assume unfettered inbound and outbound traffic to their servers? -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: denied NS/IN
In message fb979b33-df83-4460-a3e4-040cd165e...@newgeo.com, Scott Haneda writ es: On Jan 20, 2009, at 5:44 PM, Mark Andrews wrote: In message 232b45f8-acd3-427a-95e9-bc3ca5fc9...@newgeo.com, Scott Haneda writ es: Hello, looking at my logs today, I am getting hammered with these: 20-Jan-2009 15:39:06.284 security: info: client 66.230.160.1#48517: query (cache) './NS/IN' denied 20-Jan-2009 15:39:06.790 security: info: client 66.230.128.15#31593: query (cache) './NS/IN' denied Repeated over and over, how do I tell what they are, and if they are bad, what is the best way to block them? -- Scott You should talk to your ISP to chase the traffic back to its source and get BCP 38 implemented there. BCP 38 is ~10 years old now. There is no excuse for not filtering spoofed traffic. If the source doesn't want to implement BCP 38 then de-peering the source should be considered. Is BCP 38 really as solid and plug and play as it sounds? In a shared, or colo'd environment, can that ISP really deploy something like this, without it causing trouble for those that assume unfettered inbound and outbound traffic to their servers? Yes it is. Everyone in a colo should be able to tell you which source address (prefixes) they should be emitting. You filter everything else. The closer to the edge that you do this the easier it is to do. Mark -- Scott -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
