Protecting Your Admin Site – Part 1
I saw this while browsing the web the other day.
Server: Apache/2.2.12 (Ubuntu)
X-Content-Encoded-By: Joomla! 1.5
I am not going to be too hard on them because I see this all the time, but it does make an excellent starting point on something that needs to be fixed. I’m going to ignore the fact that they are using an old version of Apache (which may be patched) and an old version of PHP and Ubuntu. What caught my eye was that they were using Joomla.
I’ve always wanted to play with that, so I pulled up http://www.joomla.org/ and a “demo” button. Clicking on that Demo button, I get a backend demo – which is cool to check out the product without having to install it.
However, I noticed that the admin interface is at /adminstrator, and I wondered how many sites have this on their public website. So if you went to somedomain.com/administrator, would it ask you to enter a username and password? So tell me why do I (as a guest to the site) need a prompt to the administration site? Do they want me to log in and change their website for them?
Quite frankly, the answer is usually:
- We installed this years ago when we were checking out multiple frameworks. The project had a tight deadline, and we never had time to go back and tighten it up.
- We have outside consultants helping us with content and layout, and we never know what their IP is from week to week.
- I do not know how to secure it.
That is as far as I went other than I informed the owner of the site and encouraged them to fix it. However, this reminded me that many sites are like this. Putting your admin site on your public website is a bad idea, and here’s why:
- Curious people will find it (like I did). It is not that hard to guess a few dozen directories where admin files usually are. In fact, there are tools like Dirbuster, designed to find unpublished directories. Assume people will find your admin site.
- Someone on your staff will almost always have a bad password or have reused it on another site. Other site gets hacked, and there are the password, email address, and your site name. Alternatively, how hard is to try “password”, “password1” and “password1?” Sounds like something that ‘could’ be automated.
- A new exploit is found in your favorite CMS – you wanted to run the update, but you are not sure if it would break that custom code you put in. Blast it all; they’re already in….
Here are some alternatives:
- Stick your admin tool on an internal site and then either have it publish static files to your public site or write to your external database.
- If you can’t do that, at least use a firewall rule or .htaccess rule to block the page from anyone not from an approved IP address.
- Cache your site with a tool like Varnish and disallow the admin directory. Use a concept like a Bastion host to give you access to the backend port the real server is running on.