With CPanel 11 rolling out as stable, you’d be surprised to see the number of individuals I get with this response:
I can’t access CPanel/webmail/etc. When I try, I get the following error

The server was configured to not permit you access to the specified resource. If you believe this is in error or inadvertent, please contact the
system administrator and ask them to update the host access files.


There IS only one thing causing this through CPanel, a properly configured server, at least the way I set servers up there is. With a great deal of investigation (ok, it only took me about 3 hours, within the first week of using CP 11;)), I found the issue. The problem? It’s NOT a server issue, but an ISP DNS issue. Here’s what happened, why it’s happening now and not before, and what the ISPs are saying about it:

Firstly, what is happening, and why it’s happening now:
Servers should always be configured to deny host spoofing attacks, through any method available. One simple method? Adding

ALL: PARANOID

to /etc/hosts.deny

What does this do? Well, that’s actually quite simple:
This entry in hosts.deny will deny access to ANY program utilizing tcpwrapper security unless the DNS is properly setup. If it is not setup properly, the activity is denied. Simple, right? Still don’t understand? Ok, I’ll go a bit more in depth here:
Let’s take an ip I own, lease, etc, and use that as an example. This ip is 65.254.41.186
Now, doing a lookup on 65.254.41.186 shows the following:

nslookup 65.254.41.186
Server: 208.67.222.222
Address: 208.67.222.222#53
Non-authoritative answer:
186.41.254.65.in-addr.arpa name = jarlata.linux-tech.net.
Authoritative answers can be found from:

This is good. I have RDNS setup for this ip address to point to the hostname of jarlata.linux-tech.net . Now, according to RFC standards, I must ALSO have a SINGLE A entry in my dns configuration for jarlata.linux-tech.net, and it MUST point to the ip address 65.254.41.186. I do, and it does

nslookup jarlata
Server: 208.67.222.222
Address: 208.67.222.222#53

Non-authoritative answer:
Name: jarlata.linux-tech.net
Address: 65.254.41.186

So, by doing this, I’ve passed a basic security check, and first year networking classes.
The problem, however, comes when ips are NOT properly configured. For example, let’s take a very odd situation, let’s say I had 127.0.0.1 configured to point to unlocalhost as a reverse dns entry. Of course, we all know (those of us in the security game) that’s not right, and it’s wrong, but let’s say for the sake of argument that I did. If I did NOT have an unlocalhost entry in my FORWARD dns (the zone responsible for 127.0.0.1), then , well, I wouldn’t be doing things properly, now, would I? Of course not. Even better, if I had unlocalhost pointing to 127.0.0.1 and 127.0.0.2, it would be, again, an incorrect entry.

Now, what all affect does this have on servers, security, and the like? Believe it or not, a LOT!
In the first case (my host), the DNS is configured properly, so traffic walks in through tcpwrappers, no worries , walks out, and things are normal. They’re normal because they were setup properly!
In the second case (my unlocalhost), things are NOT configured properly, so traffic walks up to the tcpwrapper security guard, and gets booted out. WHY? Because it’s not possible to verify the authority of the host requesting traffic. What? Why SHOULD anyone leave a server open to traffic which can not be tracked back if need be? You SHOULDN’T!

The problem here is that without this check, it’s entirely possible to setup a fake sub.domain.com check and get into a server. I’ve seen it done enough times (not on my servers mind you) to know it IS entirely possible! For example, I could setup a server and ip with the hostname of suck.microsoft.com , ssh into a server, do my damage and leave. They, in turn would see that I came from suck.microsoft.com and think “hrrm, that’s odd”. Of course, they’d have NO way to know where the original attack came from, and NO way to pursue any sort of investigation.

So, that said, on to the LAST two questions:
Why is this just now taking effect on Cpanel related services? Truth be told, CPanel is just now getting in the game of increasing security and awareness of it., and they’re starting to be mroe and more open to using tcpwrappers which have been built into the Linux environment for ages now!

How to get this resolved?
That one is tricky. In order to get this issue resolved you will need to have your ISP setup PROPER dns for your ip and all of their ip addresses. If your ip is 1.2.3.4 and has an rdns entry of ip-4-3-2-1.provider.com , then there MUST be an Authoritative entry and ONLY one authoritative entry for ip-4-3-2-1.provider.com pointing to 1.2.3.4 . No other A entries may exist for ip-4-3-2-1.provider.com .

Your basic ISP tech will tell you that they can’t help you, because, guess what, they can’t. In fact they’ll try to tell you that you need to have a tech come out. Well, guess what, THAT isn’t going to solve anything either. This isn’t something that can be solved by some Joe Bloe in a cable (or ISP) truck (or van), it must be solved within their level 2 (or 3) network administration setup. You’ve got it, you need to talk to the bigwigs, and you probably won’t have much luck with them. Have them add an A entry for your IP, or FIX the A entry so that there’s only ONE in there.

In the past couple of months, I’ve had the unfortunate experience of dealing with ISP’s left and right about this issue. While MANY of them are co-operative, many just choose to be ignorant about proper RFCs, standards, and refuse to change their dns so that it is PROPERLY adherent to standards. Much like Microsoft trying to use IE to write their own standards, ISP’s are doing this left and right. More notably, the ISP’s who have repeatedly REFUSED to do things and correct their mistakes?

AT&T
ComCast
Hargray (1)

1 -

One of our support reps here at Hargray Communications forwarded my
group your e-mail. I help maintain our DNS servers, and hopefully I can
shed some light on this situation.You’re right, we don’t have A records for the names we have in our PTR
records. We consider this unnecessary, and would just add to clutter in
our nameservers’ configurations. The only RFC I can find that says this
is required is RFC 1912, which is not an “Internet Standard” RFC. If
you can point to an Internet Standard document which says this is
required, we would appreciate the opportunity to peruse it.

Yeah, it’s unnecessary to provide authentication of an IP, and password auth really isn’t necessary either. ALL authentication methods and security methods are valuable. An ISP claiming “it’s not necessary to provide A entries for DNS” is just wrong!! Clutter? Maybe, but if you don’t CHANGE it, and keep it all in one zone, that takes one guy an hour (MAYBE an hour) to edit a zone file for all ip address. Hire a flunky to do it! it’s simple text editing!