denied NS/IN
Scott Haneda
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-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Frank Bulk
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
Scott Haneda
> 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?
Frank Bulk
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
Mark Andrews
In message <232B45F8-ACD3-427A...@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-...@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_A...@isc.org
Scott Haneda
> In message <232B45F8-ACD3-427A...@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
Mark Andrews
In message <FB979B33-DF83-4460...@newgeo.com>, Scott Haneda writ
es:
> On Jan 20, 2009, at 5:44 PM, Mark Andrews wrote:
>
> > In message <232B45F8-ACD3-427A...@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_A...@isc.org
Matus UHLAR - fantomas
> 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!".
Niall O'Reilly
> 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
Mark Andrews
In message <1232561124.6369.187.camel@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_A...@isc.org
Niall O'Reilly
> 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
Sam Wilson
Mark Andrews <Mark_A...@isc.org> wrote:
> In message <FB979B33-DF83-4460...@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
Nathan Ollerenshaw
> 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 \
"0>>22&0x3C@12>>16=1&&0>>22&0x3C@20>>24=0&&0>>22&0x3C@21=0x00020001"
I've tested it, and it appears effective. I now have blessed silence
in my logfiles.
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.
Mark Andrews
In message <F4058B15-888B-4CBD...@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 \
> "0>>22&0x3C@12>>16=1&&0>>22&0x3C@20>>24=0&&0>>22&0x3C@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-...@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_A...@isc.org
Nathan Ollerenshaw
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.