31 march and root servers

2012-03-30 Thread Ivo 
Hello,


During the research on dns/dnssec amplification attacks against root
servers and evaluation of anonymous operation global blackout (we still
don't know if this is a hoax...), we came up with idea which would limit
one additional attack.

Lets imagine query source spoofed as one of the root servers IP and now
if sending query to DNS cache server, which does all the name resolving
process and finally sends reply to spoofed IP which in this case is one
of the root servers. So this may be additional network traffic during
the attack.

The idea is to filter these outgoing replies with IP matching any of the
root server IP and source port :53 on DNS cache servers, so we will
avoid loading root servers with this spoofed reply.
I hope this does not drop legitimate traffic so let me know if this is a
bad idea. :)


best regards,

Ivo

___
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: Bind vs flood

2014-02-27 Thread Ivo 
Hi Dmitry,

We observed that similar requests are landing on our cache resolver
mostly from various home routers running dns server as open resolver and
that also masquerades the original request source.
We have a collection of ~60 domains involved and most of them are
related to China. The problem is that attacker selects few domains and
generates queries with random hostnames which therefore are not in the
cache and server has to perform recursion for each query. So each query
will consume one udp or tcp socket for at least 10 seconds because
remote DNS server is responding slowly or is down and based on a query
volume it can effectively overload the cache server.

Initially we thought we could fix it with " resolver-query-timeout", but
after bind code analysis it seems that everything less that 10 seconds
would be ignored, it would be great to mention this in the documentation.
So one solution is to change MINIMUM_QUERY_TIMEOUT in resolver.c and
recompile named, but  it would be nice to understand why 10 seconds as
minimum value were selected in the first place, see /lib/dns/resolver.c

#define MAX_SINGLE_QUERY_TIMEOUT 9U
#define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U) 

snip

void
dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int seconds) {
REQUIRE(VALID_RESOLVER(resolver));
if (seconds == 0)
seconds = DEFAULT_QUERY_TIMEOUT;
if (seconds > MAXIMUM_QUERY_TIMEOUT)
seconds = MAXIMUM_QUERY_TIMEOUT;
if (seconds < MINIMUM_QUERY_TIMEOUT)
seconds =  MINIMUM_QUERY_TIMEOUT;
resolver->query_timeout = seconds;
}

We also tried to create local dummy zones for all these domains but
since domains change frequently we started to block most active open
resolvers and coordinate with local CERT.

It would be nice to have some kind of rate limits for query volume of
different hosts inside a single zone.

Best regards,

Ivo


On 2/27/14 7:59 AM, Dmitry Rybin wrote:
> Over 2 weeks ago begins flood. A lot of queries:
>
> niqcs.www.84822258.com
> vbhea.www.84822258.com
> abpqeftuijklm.www.84822258.com
> adcbefmzidmx.www.84822258.com
> and many others.
>
> Bind answers with "Server failure". On high load (4 qps) all normal
> client can get Servfail on good query. Or query can execute more 2-3
> second.
>
> Recursion clients via "rnds status" 300-500.
>
> I can try to use rate limit:
> rate-limit {
> nxdomains-per-second 10;
> errors-per-second 10;
> nodata-per-second 10;
> };
> I do not see an any improvement.
>
> Found one exit in this situation, add flood zones local.
>
> What can we do in this situation?
> ___
> 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: Bind vs flood

2014-02-27 Thread Ivo 
Ben,

No, our server is not an open resolver,  we have a large user community
and the problem is that users install their own wifi box like Zyxel or
similar which may have open resolver by default.

Ivo

On 2/27/14 5:18 PM, Ben Croswell wrote:
>
> I guess I am missing why anyone on the internet should be able to open
> queries against your caching resolver. 
>
> Why would in bound queries be allowed to servers that are for your
> people to get out?
>
> On Feb 27, 2014 10:13 AM, "Ivo" mailto:i...@nic.lv>> wrote:
>
> Hi Dmitry,
>
> We observed that similar requests are landing on our cache
> resolver mostly from various home routers running dns server as
> open resolver and that also masquerades the original request source.
> We have a collection of ~60 domains involved and most of them are
> related to China. The problem is that attacker selects few domains
> and generates queries with random hostnames which therefore are
> not in the cache and server has to perform recursion for each
> query. So each query will consume one udp or tcp socket for at
> least 10 seconds because remote DNS server is responding slowly or
> is down and based on a query volume it can effectively overload
> the cache server.
>
> Initially we thought we could fix it with "
> resolver-query-timeout", but after bind code analysis it seems
> that everything less that 10 seconds would be ignored, it would be
> great to mention this in the documentation.
> So one solution is to change MINIMUM_QUERY_TIMEOUT in resolver.c
> and recompile named, but  it would be nice to understand why 10
> seconds as minimum value were selected in the first place, see
> /lib/dns/resolver.c
>
> #define MAX_SINGLE_QUERY_TIMEOUT 9U
> #define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U) 
>
> snip
>
> void
> dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int
> seconds) {
> REQUIRE(VALID_RESOLVER(resolver));
> if (seconds == 0)
> seconds = DEFAULT_QUERY_TIMEOUT;
> if (seconds > MAXIMUM_QUERY_TIMEOUT)
> seconds = MAXIMUM_QUERY_TIMEOUT;
> if (seconds < MINIMUM_QUERY_TIMEOUT)
> seconds =  MINIMUM_QUERY_TIMEOUT;
> resolver->query_timeout = seconds;
> }
>
> We also tried to create local dummy zones for all these domains
> but since domains change frequently we started to block most
> active open resolvers and coordinate with local CERT.
>
> It would be nice to have some kind of rate limits for query volume
> of different hosts inside a single zone.
>
> Best regards,
>
> Ivo
>
>
> On 2/27/14 7:59 AM, Dmitry Rybin wrote:
>> Over 2 weeks ago begins flood. A lot of queries:
>>
>> niqcs.www.84822258.com <http://niqcs.www.84822258.com>
>> vbhea.www.84822258.com <http://vbhea.www.84822258.com>
>> abpqeftuijklm.www.84822258.com
>> <http://abpqeftuijklm.www.84822258.com>
>> adcbefmzidmx.www.84822258.com <http://adcbefmzidmx.www.84822258.com>
>> and many others.
>>
>> Bind answers with "Server failure". On high load (4 qps) all
>> normal client can get Servfail on good query. Or query can
>> execute more 2-3 second.
>>
>> Recursion clients via "rnds status" 300-500.
>>
>> I can try to use rate limit:
>> rate-limit {
>> nxdomains-per-second 10;
>> errors-per-second 10;
>> nodata-per-second 10;
>> };
>> I do not see an any improvement.
>>
>> Found one exit in this situation, add flood zones local.
>>
>> What can we do in this situation?
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org <mailto: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 <mailto: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: Bind vs flood

2014-02-28 Thread Ivo 
RPZ cannot rewrite servfail, it is designed to replace a valid response.

On 2/28/14 11:42 AM, Jason Brown wrote:
>
> Isn't this where RPZ comes in? Using RPZ means it is quicker and
> easier to null amplification, also easier to remove if you do all this
> with nsupdate, you can also create a webpage for TS to query any fault
> against.
>
>  
>
> *From:*bind-users-bounces+jason.brown=kcom@lists.isc.org
> [mailto:bind-users-bounces+jason.brown=kcom@lists.isc.org] *On
> Behalf Of *Peter Andreev
> *Sent:* 28 February 2014 09:36
> *To:* Dmitry Rybin
> *Cc:* BIND Users Mailing List
> *Subject:* Re: Bind vs flood
>
>  
>
> Well, at first glance it looks like malicious activity, so the best
> action is to call all users, suspected in sending such requests, and
> warn them.
> The fast and very (very-very-very) dirty solution is to set up zone
> 84822258.com  on your resolver. This
> should supress outgoing queries and thus minimize resolving time.
>
>  
>
> 2014-02-28 12:06 GMT+04:00 Dmitry Rybin  >:
>
> On 27.02.2014 09:59, Dmitry Rybin wrote:
>
> Bind answers with "Server failure". On high load (4 qps) all normal
> client can get Servfail on good query. Or query can execute more 2-3
> second.
>
>  
>
> I have an a mistake, 4'000 QPS.
>
>
> ___
> 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
>
>
>
>
> -- 
> Is there any problem Exterminatus cannot solve? I have not found one yet.
>
>
>
>
>
> This email has been scanned for all viruses.
>
> Please consider the environment before printing this email.
>
> The content of this email and any attachment is private and may be
> privileged. If you are not the intended recipient, any use,
> disclosure, copying or forwarding of this email and/or its attachments
> is unauthorised. If you have received this email in error please
> notify the sender by email and delete this message and any attachments
> immediately. Nothing in this email shall bind the Company or any of
> its subsidiaries or businesses in any contract or obligation, unless
> we have specifically agreed to be bound.
>
> KCOM Group PLC is a public limited company incorporated in England and
> Wales, company number 02150618 and whose registered office is at 37
> Carr Lane, Hull, HU1 3RE.
>
> 118288 - KCOM Group UK Directory Enquiries. Calls will cost no more
> than £2.58 connection + £1.79p per minute following the first 60
> seconds, including VAT from a KC or BT landline. Call charges from
> mobiles and other networks may vary. If you are calling from a mobile
> you will now receive your requested number via text message. You will
> not be charged for the text message.
>
>
>
> ___
> 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

dnssec-signzone: fatal: cannot sign zone with non-private dnskey

2011-03-22 Thread Ivo 
Hello,

I am trying to sign a zone(domain.nx) using Bind-9.7.3 with
PCKS11/OpenSC, I am able to generate key on smartcard using
(pkcs11-keygen) and export a meta-description info with
dnssec-keyfromlabel, however dnssec-signzone seem to have problem
finding a private key.

#./dnssec-signzone -E pkcs11  -N unixtime  -r /dev/urandom  -v 5   -o 
domain.nx  -a -A  -H 2 -3 12345678 -t  -k Kdomain.nx.+008+61097
domain.nx Kdomain.nx.+008+61096

dnssec-signzone: fatal: cannot sign zone with non-private dnskey
Kdomain.nx.+008+61096

---

This is how I exported key information from smarcard, slot 1 : keyID

# ./dnssec-keyfromlabel -l 1:2fbe3c50f0b7fd76f86b9efe6a6bb933547ce58c -a
RSASHA256 -f KSK domain.nx
Kdomain.nx.+008+61097
#./dnssec-keyfromlabel -l 1:2fbe3c50f0b7fd76f86b9efe6a6bb933547ce58c -a
RSASHA256  domain.nx
Kdomain.nx.+008+61096

#pkcs15-tool -D

Private RSA Key [test]
Object Flags   : [0x3], private, modifiable
Usage  : [0xC], sign, signRecover
Access Flags   : [0x0]
ModLength  : 1024
Key ref: 1
Native : yes
Path   : 3f005015
Auth ID: 01
ID : 2fbe3c50f0b7fd76f86b9efe6a6bb933547ce58c

Public RSA Key [test]
Object Flags   : [0x2], modifiable
Usage  : [0xC0], verify, verifyRecover
Access Flags   : [0x0]
ModLength  : 1024
Key ref: 0
Native : no
Path   : 3f0050153000
ID : 2fbe3c50f0b7fd76f86b9efe6a6bb933547ce58c


Base64 encoded Label seem to match slot:keyID of the key on smartcard -

# more Kdomain.nx.+008+61096.private
Private-key-format: v1.3
Algorithm: 8 (RSASHA256)
Modulus:
rQTT+TTT+UZ5bHDgSXD9NYC7uuVm1VY8S1ssDgWnoM72xD1SHaKDcaF3YtDZ7FyvNGPwUC4nxIzCwJvhNEKbTqFvhTl1bovzMPdSZ/BfcQjYDJpDe8aF94woIIo
q5ryDPGx9ymo6qQ9hhOzN0IWMbUp9q0JgTC8QnJ9Vc+Rlsf0=
PublicExponent: AQAB
Engine: cGtjczExAA==
Label: MToyZmJlM2M1MGYwYjdmZDc2Zjg2YjllZmU2YTZiYjkzMzU0N2NlNThjAA==
Created: 20110322140421
Publish: 20110322140421
Activate: 20110322140421

#more Kdomain.nx.+008+61096.key
; This is a zone-signing key, keyid 61096, for domain.nx.
; Created: 20110322140421 (Tue Mar 22 16:04:21 2011)
; Publish: 20110322140421 (Tue Mar 22 16:04:21 2011)
; Activate: 20110322140421 (Tue Mar 22 16:04:21 2011)
domain.nx. IN DNSKEY 256 3 8
AwEAAa0E0/k00/lGeWxw4Elw/TWAu7rlZtVWPEtbLA4Fp6DO9sQ9Uh2i
g3Ghd2LQ2excrzRj8FAuJ8SMwsCb4TRCm06hb4U5dW6L8zD3UmfwX3EI
2AyaQ3vGhfeMKCCKKua8gzxsfcpqOqkPYYTszdCFjG1KfatCYEwvEJyf VXPkZbH9

Has anyone else had a similar problem with the signing tool?

Thanks,

Ivo

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