Re: allow-query does not seem to be working

2016-08-08 Thread Ray Bellis 
On 08/08/2016 20:59, Frank Even wrote:
> Thanks for the info.  Also I'll have to note that I completely missed
> that the "offending IP" is one of the .uk root servers so the next
> logical conclusion is I've probably got a box in one of my environments
> driving an amplification attack of some sort or something at those IPs
> that I need to figure out.  Sorry for the bother and thanks for the
> feedback.  Much appreciated.

The host in question (156.154.100.3) is nsa.nic.uk, but is actually
operated by UltraDNS / Neustar.

However to me it looks like _you're_ the one sending the queries, as
evidenced by the 'A?' in your tcpdump log (where the ? indicates query,
and 'A' on its own would be the response) and also the destination port
of 53.

Ray

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-query does not seem to be working

2016-08-08 Thread Frank Even 
Thanks for the info.  Also I'll have to note that I completely missed that
the "offending IP" is one of the .uk root servers so the next logical
conclusion is I've probably got a box in one of my environments driving an
amplification attack of some sort or something at those IPs that I need to
figure out.  Sorry for the bother and thanks for the feedback.  Much
appreciated.

On Mon, Aug 8, 2016 at 10:51 AM, Ray Bellis  wrote:

> On 08/08/2016 18:43, Darcy Kevin (FCA) wrote:
> > As already noted, allow-query will cause you to send back a REFUSED
> > response. That’s sort of the whole point of the REFUSED RCODE.
> >
> >
> >
> > If you want to not send back any response **whatsoever**, then take a
> > look at the “blackhole” statement, but, honestly, this kind of “drop”
> > function may, depending on network topology, be more efficiently
> > performed in your firewall or IDS/IPS.
> >
> >
> >
> > Be aware that a client that doesn’t get a response may retry the query,
> > so simply “dropping” queries may ultimately prove counter-productive.
>
> and also see Mark Andrew's Internet Draft on this very topic:
>
> https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-03
>
> Ray
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-query does not seem to be working

2016-08-08 Thread Ray Bellis 
On 08/08/2016 18:43, Darcy Kevin (FCA) wrote:
> As already noted, allow-query will cause you to send back a REFUSED
> response. That’s sort of the whole point of the REFUSED RCODE.
> 
>  
> 
> If you want to not send back any response **whatsoever**, then take a
> look at the “blackhole” statement, but, honestly, this kind of “drop”
> function may, depending on network topology, be more efficiently
> performed in your firewall or IDS/IPS.
> 
>  
> 
> Be aware that a client that doesn’t get a response may retry the query,
> so simply “dropping” queries may ultimately prove counter-productive.

and also see Mark Andrew's Internet Draft on this very topic:

https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-03

Ray

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: allow-query does not seem to be working

2016-08-08 Thread Darcy Kevin (FCA) 
As already noted, allow-query will cause you to send back a REFUSED response. 
That’s sort of the whole point of the REFUSED RCODE.

If you want to not send back any response *whatsoever*, then take a look at the 
“blackhole” statement, but, honestly, this kind of “drop” function may, 
depending on network topology, be more efficiently performed in your firewall 
or IDS/IPS.

Be aware that a client that doesn’t get a response may retry the query, so 
simply “dropping” queries may ultimately prove counter-productive.


- Kevin

[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Frank 
Even
Sent: Saturday, August 06, 2016 4:42 PM
To: bind-users
Subject: allow-query does not seem to be working

I have a group of servers serving out multiple addresses via anycast.  I've 
been made aware that an IP outside of our network is hitting the boxes with 
queries, and we're returning data to the client.

With allow-query and allow-recursion locked to our subnets, this outside host 
is still getting responses, and I'm trying to figure out why.

named.conf snippet:

allow-query { mynets; };
allow-recursion { mynets; };

Yet in response to a host not from one of the subnets allowed, we're getting 
requests and returning some kind of response:

# tcpdump -i any -nvv src $myhost and dst 156.154.100.3
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 
65535 bytes
13:37:30.578020 IP (tos 0x0, ttl 64, id 5059, offset 0, flags [none], proto UDP 
(17), length 81)
$myhost.33941 > 156.154.100.3.domain: [bad udp cksum f39c!] 54976 [1au] A? 
www.sparknewspaper.co.uk. ar: . OPT 
UDPsize=4096 OK (53)
13:37:30.578025 IP (tos 0x0, ttl 64, id 5059, offset 0, flags [none], proto UDP 
(17), length 81)
$myhost.33941 > 156.154.100.3.domain: [bad udp cksum f39c!] 54976 [1au] A? 
www.sparknewspaper.co.uk. ar: . OPT 
UDPsize=4096 OK (53)
13:37:30.644502 IP (tos 0x0, ttl 64, id 5060, offset 0, flags [none], proto UDP 
(17), length 79)
$myhost.61737 > 156.154.100.3.domain: [bad udp cksum fef9!] 7832 [1au] A? 
silverstonepaint.co.uk. ar: . OPT UDPsize=4096 
OK (51)
13:37:30.644505 IP (tos 0x0, ttl 64, id 5060, offset 0, flags [none], proto UDP 
(17), length 79)
$myhost.61737 > 156.154.100.3.domain: [bad udp cksum fef9!] 7832 [1au] A? 
silverstonepaint.co.uk. ar: . OPT UDPsize=4096 
OK (51)
13:37:30.722628 IP (tos 0x0, ttl 64, id 5061, offset 0, flags [none], proto UDP 
(17), length 68)


If an IP is not allowed as part of an "allow-query" statement, should the name 
server still be returning any responses?

BIND version - BIND 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: forcing clients to TCP

2016-08-08 Thread Tony Finch 
Fima Leshinsky  wrote:
>
> It seems like setting the TC flag is what I'm after but curious if there's
> a way to do this via configuration rather than a patch.

You can do this by setting the rate-limit slip parameter to 1. This might
be the right answer if you want to use an ACL to identify when to apply
the policy.

Or you can use RPZ with a tcp-only policy, if you want to apply it based
on client IP address or query name (etc.)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Biscay: Northerly or northeasterly 4 or 5, occasionally 6 later in south.
Moderate, occasionally rough at first in north. Showers. Good, occasionally
moderate.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users