Re: blockhole'd IP receiving referral?
On 19 Dec 2009, at 16:11, Fr34k wrote: Hello, Chris, I believe you are correct. That is, blackhole applies to the sending of queries in addition to the receiving of queries. Let me explain. I discovered this the hard way. I had a /24 in the blackhole because it contained abusive clients. Within this /24 sat two legitimate authoritative name servers (ANS). Our clients could not get responses from these ANS servers because they were within the /24 blackhole. The solution was to make an exception for these two ANS servers. This is fine in that the blackhole function is doing its job well! However, we have a few /16s among our blackhole networks and to manage an exception list of legitimate ANS servers contained within will be unmanageable. So, how to stop the abuse without impacting legitimate client queries? I think the solution here would be to permit allow-recursion ( mynets;) clients to query and get responses from blackhole ( badnets; } networks in some way. Does such a solution, or equivalent, exist? If so, can someone share? I haven't tested this, but I think this might do what you ask for: Remove the blackhole-statements from the config; instead add these rules to iptables, ipfw or equivalent: * Allow related or established packets to the DNS port * Drop incomming DNS-requests from the blackhole nets This will basically allow replies, but drop requests. Greets, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: blockhole'd IP receiving referral?
allow-recursion { internaldns; externaldns; };
blackhole { blackhats; };
Works for me.
The acls internaldns and externaldns are specific networks/IPs we allow
to do recursion. (Everyone can do lookups for domains for which we are
authoritative but not recursion.) The acl blackhats is IPs/networks
we've seen hitting us over and over and impacted CPU load.
However, even though BIND dropped the queries rather than responding and
the above blackhole worked tcpdump showed they continue to try so I went
ahead and added DROP statements for those to my iptables config just to
drop them at the kernel level.
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
Of Chris Buxton
Sent: Friday, December 18, 2009 5:33 PM
To: lcon...@go2france.com
Cc: bind-users@lists.isc.org
Subject: Re: blockhole'd IP receiving referral?
On Dec 18, 2009, at 12:33 PM, Len Conrad wrote:
bind 9.6.1-P1
named-checkconf /etc/namedb/named.conf
... ok
(in global options)
options {
allow-recursion { mynets; };
blackhole { !mynets; };
};
I could be wrong, but wouldn't that be:
blackhole { ! mynets; any; };
? To my understanding, without the any item, the ACL doesn't match
anything at all - no IP is blackholed.
Of course, if you blackhole anything not local, your server will not be
able to recurse out to the Internet - blackhole applies to the sending
of queries in addition to the receiving of queries. I believe you will
need to settle for allow-query instead of blackhole. Something like
this:
options {
allow-query { mynets; };
};
Again, I could be wrong, but I don't think allow-recursion is needed in
this case.
Chris Buxton
Professional Services
Men Mice
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: blockhole'd IP receiving referral?
Hello,
Chris, I believe you are correct. That is, blackhole applies to the sending of
queries in addition to the receiving of queries.
Let me explain.
I discovered this the hard way. I had a /24 in the blackhole because it
contained abusive clients. Within this /24 sat two legitimate authoritative
name servers (ANS). Our clients could not get responses from these ANS servers
because they were within the /24 blackhole.
The solution was to make an exception for these two ANS servers. This is fine
in that the blackhole function is doing its job well!
However, we have a few /16s among our blackhole networks and to manage an
exception list of legitimate ANS servers contained within will be unmanageable.
So, how to stop the abuse without impacting legitimate client queries?
I think the solution here would be to permit allow-recursion ( mynets;)
clients to query and get responses from blackhole ( badnets; } networks in
some way.
Does such a solution, or equivalent, exist? If so, can someone share?
Otherwise, I'll buy a case of beer for the BIND developer that builds this
functionality into 9.6.x, or greater.
NOTE: I would prefer that a new type of ACL be greated for this solution. Say,
call it greyhole, because blackhole does such a great job of dumping ALL
traffic when needed.
Thanks.
- Original Message
From: Chris Buxton cbux...@menandmice.com
To: lcon...@go2france.com
Cc: bind-users@lists.isc.org
Sent: Fri, December 18, 2009 5:33:22 PM
Subject: Re: blockhole'd IP receiving referral?
On Dec 18, 2009, at 12:33 PM, Len Conrad wrote:
bind 9.6.1-P1
named-checkconf /etc/namedb/named.conf
... ok
(in global options)
options {
allow-recursion { mynets; };
blackhole { !mynets; };
};
I could be wrong, but wouldn't that be:
blackhole{ ! mynets; any; };
? To my understanding, without the any item, the ACL doesn't match anything
at all - no IP is blackholed.
Of course, if you blackhole anything not local, your server will not be able to
recurse out to the Internet - blackhole applies to the sending of queries in
addition to the receiving of queries. I believe you will need to settle for
allow-query instead of blackhole. Something like this:
options {
allow-query { mynets; };
};
Again, I could be wrong, but I don't think allow-recursion is needed in this
case.
Chris Buxton
Professional Services
Men Mice
___
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
blockhole'd IP receiving referral?
bind 9.6.1-P1
named-checkconf /etc/namedb/named.conf
... ok
(in global options)
options {
allow-recursion { mynets; };
blackhole { !mynets; };
};
dig'ging from a !mynets IP receives a referral to rather than time-out/silence.
dig'ging from a mynets IP receives an answer.
Len
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: blockhole'd IP receiving referral?
On Fri, 18 Dec 2009, Len Conrad wrote: dig'ging from a !mynets IP receives a referral to rather than time-out/silence. Please show us. Does dig and tcpdump (or other packet trace) show where the response actually comes from? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: blockhole'd IP receiving referral?
On Dec 18, 2009, at 12:33 PM, Len Conrad wrote:
bind 9.6.1-P1
named-checkconf /etc/namedb/named.conf
... ok
(in global options)
options {
allow-recursion { mynets; };
blackhole { !mynets; };
};
I could be wrong, but wouldn't that be:
blackhole { ! mynets; any; };
? To my understanding, without the any item, the ACL doesn't match anything
at all - no IP is blackholed.
Of course, if you blackhole anything not local, your server will not be able to
recurse out to the Internet - blackhole applies to the sending of queries in
addition to the receiving of queries. I believe you will need to settle for
allow-query instead of blackhole. Something like this:
options {
allow-query { mynets; };
};
Again, I could be wrong, but I don't think allow-recursion is needed in this
case.
Chris Buxton
Professional Services
Men Mice
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
