Discuss mailing list

[Alex <coyo AT darkdna.net>]

Before I start responding to this email, i'd like to preface this with
an announcement.

Falk's name from here on will be Falker, for he has so richly earned it
with this email.

Before Falker or anyone else on this heavily populated mailing list
thinks I'm not grateful for the valuable input that Falker has provided,
I'd kindly suggest you read it again.

Thank you, Falker, for providing such a helpful and positive email, I
look forward to spending time on this mailing list with you.

On 5/2/2012 3:46 AM, Falk Husemann wrote:
> Hi Alex,
>
> I wrote a quite lengthy reply to your questions, but want to send some
> things ahead. If you want to improve security, you need a better
> understanding of what your problem is. Here, ask yourself:
>

That you did. Thank you for taking the consideration to respond to my
queries.

> What do you want to defend against whom for how long?
>
> Your post - to me - reads like: I want to defend everything against
> everybody for ever, which is impossible. I have a feeling you have lots
> of good questions, but lack the methodology to work out answers.
>
> If I were you, I'd start with profiling what you want to defend against
> and for how long. Write that down and post here, so we can work from
> there.
>

Obviously, the attacks in everyone's mind are those of powerful botnets,
and the legal takedown orders of ICE.

I should note that botnets, even if an attacker could lease a
considerable number of zombies, are not omnipotent, they can only
"snipe" a single IP address at a time, and are extremely expensive to
lease. It costs great amounts of money, time, and effort, so a fully
concerted attack against multiple IP addresses seems a waste of effort.

It's unlikely to happen, especially for an extended period of time,
since it's risky for the botherder, and expensive for the adversary
leasing the botnet.

That said, I'm more worried about more agile and subversive groups that
will attempt to use any means to takedown anything that threatens their
way of life.

For example, I personally doubt the US federal government would stop at
merely legal means to remove a threat such as WikiLeaks or ThePirateBay.

Though that may just be me. I would not try to defend against everything
EVAR, because that is impossible.

> Also keep in mind, that security provides no additional use to the
> OpenNIC community if there is no adversary in sight. If there were no
> burglars, you wouldn't need locks in your doors, would you? So dont
> expect too enthusiastic response when you propose security measures
> which involve lots of work (every single command has to be replicated to
> all servers, keep that in mind!) but provide no immediate benefit.
>

Okay, I'll keep that in mind.

I should make a note here, I could certainly contribute servers and
money to OpenNIC if that helps.

I'm not sure you guys would accept money if I offered it, though, so I
was thinking I'd learn everything I could about DNS and the protocol
used, how to configure BIND, etc. since you have to learn the basics
before you can secure the basics. Then I could get the valuable
engineering experience of running name servers.

> Am 02.05.2012 07:22, schrieb Alex:
> > Out of sheer curiosity, and a desire to protect my friend, Alex
> > Hanselka's pet project, I wanted to ask you all what all can be done to
> > mitigate the threat of attacks such as concerted DDOS attacks against
> > specific name servers, such as the IP address of the single
> > authoritative root name server of OpenNIC.
>
> There is exactly nothing you can do, to protect against a massive scale
> DDoS. But theres a lot that can be done against the normal threats a
> nameserver faces. Also drawing the picture of an omnipotent attacker is
> well, undefendable against. Most times though, the adversary is _not_
> omnipotent.
>

I am aware of this fact, even if it does not seem like it.

"Massive scale DDoS" is highly expensive, and cannot be sustained for
very long.

The only real thing to do is wait it out.

> > What attack countermeasures are possible, to mitigate attack, other than
> > the obvious anti-cracking things like making sure you have a strong
> > password, etc?
>
> There should be no passwords involved when running a nameserver. I guess
> you mean securing rndc access and access to remote shell services like
> OpenSSH. Well, standard advice: Dont use passwords for SSH and limit
> rndc to localhost.
>

Yay, valuable advice! I'll keep "no passwords" (assuming clientside
certificate?) in mind for SSH (because the name server has to be
maintained through something, amirite?

> > Is it wise to protect root name servers behind a VPN, or do the root
> > name servers HAVE to be publicly accessible?
>
> Read up on DNS and think again. If you dont understand the architecture
> of DNS, a debate on security is free of sense. I recommend reading
>
> The Concise Guide to DNS and BIND (by Nicolai Langfeldt), published by
> Que (ISDN 0-7897-2273-9). The book is quite a good read by the DNS-HowTo
> author.

Okay, I'll stop by Barnes and Noble, and see if they have it.

It might be a good read to curl up with.

"The Concise Guide to DNS and BIND" by Nicolai Langfeldt. Got it.

Thank you.

>
> > If the root name servers, and top-level domain name servers MUST be
> > publically addressible, do the authoritative name servers have to be
> > publically addressible, or can they hide behind name server proxies?
> > (application-layer proxies, for example, such as specialized name
> > servers which ONLY act to duplicate records, and are not actually
> > responsible for them?)
>
> What would be the benefit?
>
>
> > Maybe I'm betraying my lack of knowledge, maybe I'm ignorant, but if I
> > dont ask, I wont learn, and I rather like OpenNIC, and think the project
> > has a lot of potential.
>
> I agree.

OpenNIC FTW <3

>
> > That said, i worry that the project is completely open to attack, and
> > that if we are used for anything critical, the first DDOS would bring us
> > down, and it would be an embarrassing defeat.
>
> True, theres that. And then theres this:
>
> <SNIP>
> #!/bin/bash
>
> function axfrall()
> {
>         dig @${1} axfr geek
>         dig @${1} axfr neo
>         dig @${1} axfr fur
>         dig @${1} axfr ing
>         dig @${1} axfr micro
>         dig @${1} axfr bbs
>         dig @${1} axfr dyn
>         dig @${1} axfr gopher
>         dig @${1} axfr free
>         dig @${1} axfr geek
>         dig @${1} axfr indy
>         dig @${1} axfr null
> }
> TMPFILE=/tmp/onic$RANDOM
> axfrall 84.200.228.200 | grep -o
> '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq >
> ${TMPFILE}
> nmap -A -p 21,23,80,443 -iL ${TMPFILE} -oA opennic -vvv
> <SNAP>
what the carp is that?

(yes, i know it's a shell script, before you tell me it's a shell script!)

*gives Falker a wary look*

>
> > 1) What is the standard operating procedure for protecting name servers
> > against DOS attacks?
>
> Query rate limiting.
>

Does query rate limiting throttle requests, or simply stop responding to
requests, and how does it work, per ip address? what about socks or tor
proxies? Do you have to make manual exceptions for high volume proxies?
what about other name servers? does the protocol between name servers
differ from the protocol used by local caching proxies?

(You don't have to answer, Falker, if no one else answers, I'll just
read the book, and MAYBE I'll know what to search for on duckduckgo)

>
> > 2) How does one protect name servers from being targeted in the first
> > place?
> Not running one is the best protection.
>

Ha.

> > 3) What can be done to protect servers from taking the full brunt of
> > heavy loads?
>
> Scale. Instead of n nameservers, run n+x nameservers. Thats one of the
> things DNS does very good.
>

Maybe that'll be in that book you referred to.

> > 4) What load balancing techniques are standard practice for name
> servers?
>
> Anycast. Also keepalived can be a solution to increase availability in
> case of hardware failure, but is no help when this omnipotent attacker
> floods your bandwidth.
>

keepalived. *makes a note*

Thank you, I'll read up on that later today.

> > 5) What might be some novel techniques to protect name servers from
> > taking the full blow of sudden surges in user demand?
>
> Shut the overloaded nameserves off. This would be a very radical and new
> approach, though I dont recommend it ;-) See my answer to your point 3)
> for a useful hint.
>

Falker, your new name is Falker. Congratulations.

This response is particularly acidic, and I do not believe even the most
proficient of hackers deserves to behave in such a manner.

I may be green, you unlike 99.98% of the people out there, I'm willing
to learn, I just don't know where to start, so I think I deserve a
LITTLE more respect than when what I'm getting from you.

Rather than cry to Alex or one of the other moderators of the list, I'm
going to just say this: watch me. I am not known for being unintelligent.

> > 6) are there any P2P name server protocols to help distribute the load
> > and take the strain off authoritative TLD name servers?
>
> What exactly is wrong with DNS that needs fixing with P2P? It seems this
> is a solution looking for a problem.
>

Perhaps. Perhaps not.

> > 7) Is there such a thing as name server software that allows for DNSSEC
> > and DANE that makes it easy to rotate certificates?
>
> See 6).
>
> > 8) Is there such a thing as name server software that is easy to
> > configure, period?
>
> Yes. Bind.
>

My experience with BIND suggests that it makes DNS more complicated than
it really needs to be.

In the end, DNS is merely a hash table, key -> value, nothing more. the
only reason a DHT cannot do it, is because a DHT can be poisoned with
false or malicious information, and there's a need for authoritative data.

This authorization can be achieved with hash chains/hash trees, but
you're response would be, "See 6)" so i'm not including you as the
audience of this statement, Falker.

Anyway, I'm mostly thinking aloud, so don't mind me.

> > 9) Is there such a thing as name servers that serve as mirrors/proxies
> > for authoritative servers, and do nothing else?
>
> You need to buy this book, Alex. Really. The DNS was designed with this
> in mind, so there are caches and mirrors (called secondary nameservers).

Will do, Falker.

> You're just now using the DNS Cache your local router and/or your ISP
> provides.
>

I actually use Alex Hanselka's name server, just so you know. :3

I'm actually aware that every device on my local network has name
caches, I'm not a complete idiot.

> > 10) is it possible to have 30 powerful name servers located on distinct
> > networks all over the world sit behind a single IP address using a fast
> > iptables/proxychains proxy?
>
> I guess, using the REDIRECT target. But this is stupid. You've just
> introduced a new single point of failure this omnipotent adversary can
> target. Anycast would be the solution here. Or more simple: See 3).
>

Hmm. The idea would be to use the iptables redirect proxies (plural) to
span a tree of name servers, but obviously, this would be very
expensive, so probably not an optimal solution.

> > 11) Is it possible to have more than one name server delegation for a
> > given domain name? (just want this verified, clarified)
>
> Yes, you can have as many as you want.
>
> Greets,
> Falk

It's a pleasure to meet you, Falker.

I look forward to being chastised by you in the future.

Cheers,
Alex

Attachment: 0xC34ED745.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature