security problem: cpanel allows DNS zonetransfers for everyone!

[chirpy]

Looks like views is the only realistic way to prevent cache lookups. The only realist way to implement them, though, would be to ask cPanel in a bugzilla enhancement for the feature because of the nature of its implementation as kemis highlighted.

If you're being bombarded from specific IP addresses, you can of of course either stick their IP's in your firewall or add them to a named.conf blackhole list.

I don't quite understand dyndns's conclusion that using only an ACL is almost as bad as no limitations since the fact that recursive lookups don't work, only cached ones, makes for a pretty useless recursive DNS resolver. It does still, of course, keep you open to DOS attacks, but that's often going to be the case on any protocol port. Since the DNS server won't perform recursive lookups for disallowed queries (only cached ones) the performance hits of those particular ones should be minimal I would have thought.

Whether you include 127.0.0.1 is probably a moot issue as long as you don't list it in /etc/resolv.conf

 

[fred123123]

I don't quite understand dyndns's conclusion that using only an ACL is almost as bad as no limitations since the fact that recursive lookups don't work, only cached ones, makes for a pretty useless recursive DNS resolver. It does still, of course, keep you open to DOS attacks, but that's often going to be the case on any protocol port. Since the DNS server won't perform recursive lookups for disallowed queries (only cached ones) the performance hits of those particular ones should be minimal I would have thought.

So by adding those lines in the named.conf, is this okay ? Or should i add something else ?

allow-transfer {
my_backup_dns_ip;
};

allow-recursion {
my_backup_dns_ip;
};


I'm a bit confused about this thread

 

[fred123123]

oops, i forgot to add the local ip... My server was unable to resolve domain name for 5 minutes.

I added my local ip and locahost in allow-recursion section...

 

[dwh2]

How to

Well, I've read and reread this thread and am still not confident that I know what to do so what better than to systematically go through this and write a How-To to see if I got it right or not.
===========
Subject: How to close CPanel security hole of Open DNS Zonetransfers

Message:
1. Determine if you are vulnerable to this exploit. Go to
http://www.dnsreport.com/

Run a test on your domain(s). If you see a huge RED entry that says "Open DNS Servers", then you are vulnerable and this How To applies to you.

2. Get a list of your ip addresses. To do that, open WHM, scroll down almost to the bottom left pane until you see "IP Functions". Then click on IP Address usage. On a separate notepad, mark down all IP Addresses that have a domain (or multiple domains) attached to it. In my case, I have a database server attached and it has an IP Address starting with 192.168, which indicates it an internal IP Address. Do NOT mark that IP Address if you are in a similar situation to me. (I'm not saying that it will hurt you, but I don't think it will help you.)

Let's assume for the sake of argument that the following are your IP Addresses:

123.123.123.4
123.123.123.5
123.123.123.6

I will use those IP Addresses as an EXAMPLE later on. Make sure to replace the above EXAMPLES with your actual IP Addresses.
3. SSH as root into your server.
4. cd /etc
5. cp named.conf named.backup
6. Using your favored editor, edit named.conf.
7. Right on top of the page you should see

controls {
inet 127.0.0.1 allow { localhost; } keys { "rndckey"; };
};

DIRECTLY BELOW that line, type this

// Restrict Zones transfer
allow-transfer {
123.123.123.4
123.123.123.5
123.123.123.6
};

// Restrict Recursion

allow-recursion {
123.123.123.4
123.123.123.5
123.123.123.6
};

8. Go back to http://www.dnsreport.com/ and run another test. If the red section is gone, you have correctly fixed this problem. Well, hopefully your domains will continue to resolve too

===============
Are there are any errors in this How To? Can I post it like this?

 

[kemis]

Sounds right, except that I would include some sort of note regarding the fact your server will still perform reverse DNS lookups from your cache, thus not *fully* eliminating the problem... As Chirpy pointed out a couple of posts ago, though, aside from a bugzilla fix, this can't be helped right now.

Also, I personally like to use the "trusted" ACL concept to eliminate the need of editing IP addresses in multiple places. That's just me, though, and your instructions as written look correct for making DNSstuff.com happy.

-- Matt

 

[dwh2]

Sounds right, except that I would include some sort of note regarding the fact your server will still perform reverse DNS lookups from your cache, thus not *fully* eliminating the problem... As Chirpy pointed out a couple of posts ago, though, aside from a bugzilla fix, this can't be helped right now.

Thanks Matt. OK, I will modify as follows:

===========
Subject: How to close CPanel security hole of Open DNS Zonetransfers

Message:
1. Determine if you are vulnerable to this exploit. Go to
http://www.dnsreport.com/

Run a test on your domain(s). If you see a huge RED entry that says "Open DNS Servers", then you are vulnerable and this How To applies to you.

2. Get a list of your ip addresses. To do that, open WHM, scroll down almost to the bottom left pane until you see "IP Functions". Then click on IP Address usage. On a separate notepad, mark down all IP Addresses that have a domain (or multiple domains) attached to it. In my case, I have a database server attached and it has an IP Address starting with 192.168, which indicates it an internal IP Address. Do NOT mark that IP Address if you are in a similar situation to me. (I'm not saying that it will hurt you, but I don't think it will help you.)

Let's assume for the sake of argument that the following are your IP Addresses:

123.123.123.4
123.123.123.5
123.123.123.6

I will use those IP Addresses as an EXAMPLE later on. Make sure to replace the above EXAMPLES with your actual IP Addresses.
3. SSH as root into your server.
4. cd /etc
5. cp named.conf named.backup
6. Using your favored editor, edit named.conf.
7. Right on top of the page you should see

controls {
inet 127.0.0.1 allow { localhost; } keys { "rndckey"; };
};

DIRECTLY BELOW that line, type this

// Restrict Zones transfer
allow-transfer {
123.123.123.4
123.123.123.5
123.123.123.6
};

// Restrict Recursion

allow-recursion {
123.123.123.4
123.123.123.5
123.123.123.6
};

8. Go back to http://www.dnsreport.com/ and run another test. If the red section is gone, you have correctly fixed this problem. Well, hopefully your domains will continue to resolve too

*NOTE: Your server will still perform reverse DNS lookups from your cache, thus not *fully* eliminating the problem... Aside from a bugzilla fix, this can't be helped right now. (I have no idea what I just said but Matt suggested this note so if you understood it, you know better than me )
===============

Also, I personally like to use the "trusted" ACL concept to eliminate the need of editing IP addresses in multiple places.
-- Matt

I agree. Editing multiple IP Addresses sucks. But I didn't understand how to make the "trusted" ACL concept works. If you tell me which item number to modify and what it should say, I will either change it, or make both versions available and post the How To.

Again, your help was much appreciated as I felt lost and out of my league

 

[kemis]

Refer to Post #32 in this thread by CoolMike for example code of using the ACL concept. Basically, you create an ACL named "trusted" (this could be named anything you like) that then lists the IP addresses that you trust. From then on, anywhere you want to throw in all those IP addresses (such as in the allow-transfer & allow-recursion) option statements, you simply call the ACL instead of all the individual IP addresses.

As mentioned before, the code has already been posted in this thread, but let me know if you need any clarification.

-- Matt

 

[dwh2]

Hmm... What does ACL stand for?

And if you need to enter the IP Addresses in that trusted ACL, then what's the difference?

Oh wait, I think I get it. You're saying it eliminates the need to place the IP Addresses in:

// Restrict Zones transfer

AND

// Restrict Recursion

correct?

If so, then it's not a big deal for me, I only have a few IP's. But I guess it's a little more of a hassle if you have tons.

I'll make the modifications once I get confirmation of the above questions...

 

[kemis]

ACL stands for Access Control List, as far as I know. Anyone else can feel free to correct me on that.

Yes, you're right. It simply eliminates the need to enter all IP addresses multiple times. Although you're only including allow-transfer and allow-recursion in your instructions, other options (such as allow-notify) can also use that common ACL, so depending on the number of options you're using with the ACL it really cuts down on the number of edits to make when it comes time to update your IP addresses. By only having to update IP addresses in one place instead of multiple places, this cuts down on the likelihood of a syntax error or other edit that can cause problems/confusion to ensue.

-- Matt

 

[dwh2]

OK, looks like I'm about good to go then. But I did think of one more thing. Bind needs to be restarted, correct? What's the command for that? Or actually I think there's a link to do it from WHM.

 

[kemis]

Two ways to have changes take effect (someone please correct me if I'm wrong!):

1) rndc reload
2) service bind restart

Those commands are off the top of my head, so please research/test them before implementing into the guide. I believe rndc is the preferred method, since it does not take down the bind service, but simply refreshes its configuration. (Whereas, the service restart command will actually take down bind for a moment while it restarts.)

Yes, you can also restart bind from WHM by clicking on "DNS Server (BIND)" under the "Restart Services" section.

Good luck!
Matt

 

[dwh2]

Well.. I tried it out and named failed for me. The domain still seemed to be resolving but doing a new test on that dnstools site gave me several red errors. So I switched back and those errors got fixed...so I'm not going to fool around with it anymore and won't post the How To because frankly I'm not sure what went wrong... Hopefully cpanel will address this issue soon...

 

[kemis]

Don't give up!

Here is the beginning of my named.conf file (before all the zones) that works great. Please compare to yours:

include "/etc/rndc.key";

controls {
	inet 127.0.0.1 allow { localhost; } keys { "rndckey"; };
};

// Blackhole any IPs for which my server still attempts to resolve cached queries
// This list can grow indefinitely until cPanel begins supporting views
acl "untrusted" {
	66.163.169.xxx;
	66.218.71.xx;
	63.250.206.xxx;
	216.109.116.xx;
	217.12.4.xx;
	66.218.71.xxx;
	216.109.116.xx;
	216.117.186.xxx;
	208.234.1.xx;
};

acl "trusted" {
	xx.xxx.xx.229;
	xxx.xx.xxx.242;
	127.0.0.1;
};

options {
	directory "/var/named";
	version "Later babe, I'm tired right now...";
	blackhole { untrusted; };
	allow-recursion { trusted; };
	allow-transfer { trusted; };
};

Be absolutely sure you get the semi-colons and spaces correct! The version of vi I use through ssh uses color which really helps me see when my syntax becomes incorrect as I'm editing.

-- Matt

P.S. -- Duh, it's not "service bind restart", it's "service named restart". Not sure what I was thinking when I wrote that in my last post. I guess I wasn't thinking!

 

[dwh2]

// Restrict Zones transfer
allow-transfer {
123.123.123.4
123.123.123.5
123.123.123.6
};

// Restrict Recursion

allow-recursion {
123.123.123.4
123.123.123.5
123.123.123.6
};

So there needs to be semicolons after the IPs?
Maybe that was my mistake.

// Restrict Zones transfer
allow-transfer {
123.123.123.4;
123.123.123.5;
123.123.123.6;
};

// Restrict Recursion

allow-recursion {
123.123.123.4;
123.123.123.5;
123.123.123.6;
};

 

[dwh2]

options {
	directory "/var/named";
	version "Later babe, I'm tired right now...";
	blackhole { untrusted; };
	allow-recursion { trusted; };
	allow-transfer { trusted; };
};

By the way, what does blackhole { untrusted; }; do?

 

[kemis]

Yes, you need semicolons after each individual IP.

As indicated in my code (above the untrusted ACL), you can blackhole IPs to prevent them from querying your DNS server at all. This is useful, because even with allow-recursive set to only your trusted IP addresses, BIND will still attempt to respond to recursive queries out of its cache (thus not fully solving the recursive DDOS attack issue).

If you ever look at your /var/log/messages log and see "lame server resolving" messages (even after only allowing recursive DNS queries from your trusted IPs), you will then understand why I'm frustrated by cPanel's current inability to fully resolve this issue!

If you see a ton of "lame server resolving" messages originating from the same IP, though, you can blackhole that IP to stop the attack from happening. It'll only be a matter of time, though, before a different IP strikes. Thus, your blackhole list could grow to be quite large until someone figures out how to get "views" working with cPanel zones and we can finally put all this to rest.

To understand more about this whole "recursive DNS DDoS attack" thing, you really should read the following two documents:

http://www.dyndns.com/about/company/notify/archives/the_dangers_of_open_recursive_dns.html
http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf

In a nutshell, with recursive DNS attacks, your server isn't the one being attacked, but rather your server is being USED to attack another server by helping to flood the other server with DNS queries. Thus this is a *distributed* denial of service (DDoS) attack we're trying to eliminate here.

IMHO, the only good way to truly eliminate this problem is to set up an internal view (where your servers can do what they want with DNS) and an external view (where anybody else is completely denied access to your DNS server). In this way, ALL recursive DNS queries from outside IPs are eliminated. Contrast this with the "allow-recursion { trusted; };" option, which denies most recursive DNS queries, but still attempts to answer some out of your DNS server's own cache. Do you see the difference and the problem?

So far, I feel like the only one in this entire forum on this quest. Everyone else seems to be happy with just setting up the allow-recursion option and being done with it. Even with this set, though, I still see quite a few "lame server resolving" messages in my log (red flag for a recursive DNS attack), so that's why I'm still on my mission! Unfortunately, cPanel doesn't yet support views, so there's not much you can do but set up allow-recursion for trusted and begin blackholing IPs that are still trying to use you.

I know I've repeated myself a bit, but wording all this concisely is sort of difficult for me, especially since I'm not sure what all you currently understand. Furthermore, I'm new to all this, too, so my opinions and advice should be tested and commented on before writing in stone!

Hopefully this will help you to understand 1) how to successfully get done what you want done, 2) why you're doing it in the first place, and 3) why seeing the red disappear from DNSStuff.com's report doesn't mean everything is now A-OK.

Read those two links I gave, think it all over, experiment, and let me know what you think!

-- Matt

 

[dwh2]

Thanks. Your post is very informative and I think you are on the right quest.

Unfortunately, the How To still does not work for me. I believe my DNS is set up incorrectly. It's not the first time. I've paid people to do it. Had many days of downtime while trying to fix it and since it's working now, I guess I shouldn't look for trouble....had too much heartache over dns in the past...

I feel out of my league...and since I thought I could trust the people I paid to do this and they've screwed up...I guess I'm just scared to do much of anything....so I'm even more frustrated than you.

I do hope cpanel fixes this though...and pays attention to your mission. Spammers would have less room if everyone were as vigilant as you. Amazing that you are new to this.

 

[Lescar2]

Hi,

Forgive me for being confused.

This thread started on 10-15-2003, 07:22 PM and as of 04-11-2006 it is still an issue with cpanel servers?

I have the problem sort of. My server DNS is using the name servers where it is located. I did this incase my server went off line my mail would still be cached. Seems to work. My main server domain looks ducky in DNS reports also. However, all my other domains are using my my main domain as their name server and they all have the open concern.

Am I making sense on this to anyone? If so, can I correct the open dns concern by following the instructions in this thread.

Kind Regards,

Les

 

[sawbuck]

Am I making sense on this to anyone?

Not really.

If so, can I correct the open dns concern by following the instructions in this thread.

Yes

 

[chirpy]

This thread started on 10-15-2003, 07:22 PM and as of 04-11-2006 it is still an issue with cpanel servers?

It's not an issue with cPanel. It's an issue with BIND and its default configuration and how you secure your own server.