Maintenance:Security Considerations
From Cerberus Helpdesk Wiki
Contents |
Directory Security
Securing Cerb4 Subdirectories
If you look at the .htaccess (or .htaccess-dist) file in your /cerb4 directory, you’ll notice the following lines:
This file sets up some basic rules, based on URLs and paths, to tell the web server that we don’t want anyone snooping around our private directories. You don’t want shady visitors poking around your /storage directory (which holds incoming e-mail sources and attachments), or your /storage/tmp directory (which holds caches that could be used to peek at your helpdesk data or crack your worker logins).
In a perfect world, we’d be creating these directories completely outside the web-accessible path. It’s a fairly easy tweak for those so inclined (who have proper server access); but for the average shared-hosting installation such a setup is often not possible. Our default installation needs to remove as many obstacles as we can without compromising too much. The beauty of Cerb4’s new design is that you can start customizing your installation from our simple, working baseline without losing your ability to easily upgrade.
If your web server isn’t capable of parsing .htaccess files (e.g. they’re disabled, you use IIS, etc) then you need to block the list of paths above using something like “directory security”. Practically every web server will give you this ability, and most control panels in shared hosting environments will as well (e.g. cPanel, Plesk).
Go ahead and test your helpdesk URL to make sure you have something in place to protect these directories.
For example, here's what our online demo shows:
The absolute worst result you can get is a directory listing that shows all the folders in these directories. If you see that, make sure you get some administrator help immediately (you can send them to this URL).
Securing the Entire Root Cerb4 Directory
It’s possible to set up directory security on your entire helpdesk URL (/cerb4/*), but there are a few important things you need to keep in mind if you want to do this:
- You’ll need to allow your community tools to connect to your helpdesk URL. At the moment our reverse proxy script doesn’t have the ability to do HTTP authentication. In an advanced configuration you could allow the IP of your community tool web server to bypass the authentication. I’ve gone ahead and opened up a development task to add HTTP authentication awareness to community tools: http://wgmdev.com/jira/browse/CHD-679
- Your cronjobs or scheduled tasks will need to do HTTP authentication to talk to /cerb4/cron or /cerb4/update. This is easier because command-line tools like wget support this already.
- If you use our Web-API plugin, you’ll need to add some extra code to your application to deal with HTTP authentication.
Bottom Line
You should be fine with directory security on specific subdirectories without locking down your entire site.
IP Security
A more practical approach to securing your entire helpdesk path or domain would be to lock it down by IPs rather than passwords. However, this can be very cumbersome — to the point of not being worth doing — if you have a lot of helpdesk staff. You can do this from the web server or from your firewall. You’ll still need to permit your scheduled tasks, Web-API users and community tools (from your public web servers) to connect to the helpdesk.
Obscurity
While “security through obscurity” is nothing you should critically depend on, some simple common sense can go a long way too:
- Use SSL.
- Rename your /cerb4 subdirectory to something less predictable. If you’re using a subdomain for your private helpdesk (not your public tools), you should try to make it something harder to guess than “helpdesk”.
- Don’t make public links to your helpdesk URL. To the degree possible to avoid, this also includes e-mail, bug reports and forum posts. If Google has indexed your helpdesk URL, then you’re already more immediately vulnerable to every published exploit.
- You could use a non-standard port for your helpdesk web server, if possible. If you control your own server it’s pretty straightforward to set up a separate Apache instance on a port like 9999. The downside is being slightly inconvenient to your helpdesk staff if they have an aversion to browser bookmarks or shortcuts. Get used to people going “the helpdesk disappeared!”.
- You could also host your helpdesk on your office intranet, using a domain like “http://helpdesk/” instead of a web-accessible IP. This won’t impact scheduled tasks that access your URL as long as they run from inside your network. You could permit your public community tools, or Web-API users, to access specific paths of your intranet helpdesk by opening up a non-standard port on your router and filtering traffic for specific URLs from specific IPs.
I wouldn’t really go as far as even calling most of these notes ‘recommendations’. These are simply options available to you.
However, make sure that you can’t access the URLs listed at the top of this post on your helpdesk from your web browser. That should be the very least that you do to lock things down.
Article adapted from [1] by Jeff Standen
