Keeping a site safe from malicious users (often referred to as “hackers”) depends on a great number of variables. All of our staff have faced these questions and concerns from clients at one time or another, or have responded to questions posed on a news group or forum community. Here, we’d like to outline some of the things users can do to in an effort to help protect themselves from such problems, with the below summary.

Firstly, it is a misconception that “nothing is 100% secure”. While it is true that very few services or scripts people often use are known to have a history of no known security issues, some things have a proven track record of being secure, such as Dan Bernstein’s Qmail MTA mail software and his dbjdns (tinyDNS) DNS services software. While we don’t claim there is no way to exploit his software, no one to date has been able to, with years of public challenges and a prize of money and credit for anyone that can.

Similarly, many of us being programmers ourselves and having written thousands of programs with thousands of lines of code each for popular web sites that have people very intend on breaking into them, we also have a track record of no exploits against our own developed scripts and programs. This is not to claim perfection, or say that it’s not possible, especially in light of API’s and wrappers the scripts run through, the environment they run in, the interpreter engines they use for languages such as Perl, PHP, Ruby and Python, but to simply point out that it’s not an issue to view as fatalistic, hopeless or to come to accept it as inevitable.

I know that programs I have written, and those of my coworkers, would be quite comfortable putting up a challenge or standing by them with the claim that they are, in fact, 100% secure. Coding securely is not a difficult task, if you are an experienced and knowledgeable programmer. Anticipating potentials and taking measures to prevent aspects you didn’t anticipate are a key role. Such as denying all functionality and input by default, and then build the functions to accept specific input, and to do so in a controlled manner. Selecting the proper environment and how it will run, the privileges it has, and above all, sanity and security checks, will go a long way. Of course, many scripts out there weren’t coded with these things in mind and many do suffer from exploits, which we’ll attempt to cover a little way down this blog.

The same thing can be said of account security itself. While there may me a lot to it, and thousands of specific incidents and potential security holes in a lot of software floating around out there, a few general things can help to prevent a lot of these, without specific targeted solutions for every type of software and its known or potential exploits. A few simple things can go a long way for a good basis, and some suggestions along the way can help as well. Should you follow such advise, truly, then combined with even only a reasonably secure server, you should not find you experience any of the site compromises that a very high percentage of the causes are (literally, 99% of the time).

If you use our services, then you already can rest assured that we take all reasonable and custom measures available to prevent a high level security issue, but ultimately your own account and script security will dictate how secure your site is — no matter how well we secure our services, if you host a script that acts as a gateway into your account, there’s only so much we can do to protect your site. We do offer some services that are unique to BurlyHost.com, Inc., which will help you to protect your site, even if you happen to be lazy about your site’s security, but, as our CEO says, “if you create a security hole in your site by how you use and store your own passwords, or what scripts you choose to run that might be insecure, then all bets are off”. While you shouldn’t worry, you should take the matter seriously. The below suggestions will help, and should you follow them, it would be unlikely that your site would ever be compromised.

#1: Keep up to date on all scripts. First, consider if you want to run certain types of scripts. Some are almost specifically asking for trouble, though most common one’s are safe in general. Subscribe to common security alert announcements and mailing lists, and especially keep up to date on any security issues that are posted on the script author’s site of the software you use. They will often be the first to release security patches you can apply to your current installs, or offer a new version that you can either install in place or your current one, or more likely, to allow you a means to upgrade. Of course, you will want to make a safe backup of the scripts, data and databases you are going to patch, replace, or upgrade, but be sure that backup isn’t publicly accessible, else you might forgot about it and have both a newer secure version running along side of an older version with a known security issue. The unfortunate drawbacks of this, is that is can be time consuming, especially if you use a large number of scripts, and even more so if you use a lot of scripts from a lot of different authors, for a lot of different interfaces. However, it is an absolute necessity. A major reason for sites being compromised, is that a lot of people install a script and leave it for years without ever updating it. Remember, just because it works, still, doesn’t mean it doesn’t suffer from a bug or security issue suddenly being introduced. Don’t be lazy about this. If you don’t have time, hire someone that does, or partner with someone to help you with your site that can help keep watch for updates and security notices related to your software/scripts.

#2: Don’t leave install/test scripts. Don’t start something and not finish it, this can spell disaster. Don’t ever install scripts as a test and leave it enabled, or any vital portion or extension of it. Many people will try out software, scripts or some new module or extension for a script they are either trying out, or one that they actively use, and then forgot about it, either not revisiting the install or idea or the extension on the programs they do actively run, and they can be left as sitting time bombs. Should someone access it and guess a URL location, they could use that against you and your site. Additionally to this fact, is that new installs often, until the setup is complete, will allow control over certain aspects of your site, so if someone accessed it before setup was complete, or if you kept the default password/login or set up an easy one because you weren’t sure if you wanted to use the script, then an attacker would still have access to run an install/setup script, which can allow for a lot of methods that most scripts won’t naturally allow due to the security ramifications.

#3: Passwords. This is a major factor as well. Always use secure, strong and unique passwords. Never use dictionary words. Never use the same password for your scripts, forum logins (including admin logins), databases or anything else, that you use for something else. In other words, if you use a password for your main email, FTP, control panel or other login, do not use this same password when setting up a database or when setting the admin login for a script, even just for the install steps. Never use the same database passwords for different databases. Never use the same password for a forum account that you use somewhere else. Clearly, this can start to become a hassle if you have a lot of scripts, databases, logins, etc., but once the database passwords are set, you shouldn’t have to remember them. They are going to be set in your script’s configuration files, and you can write it down elsewhere.

People far too often prefer to simply ignore the problem and instead go for the ease of using the same password across all of the dozens of web sites they visit online. If someone were to guess or obtain your password from one of those services online or otherwise, imagine how much data they could have access to. Some people use the same passwords for a web forum online somewhere, as they do for their hosting account, or for their online bank account, or for their paypal account, ebay account or even for their own forum admin login. Someone could log into your forum admin area and abuse that script to do things to read other passwords you have and then try those at the other sites you might visit. Always chose to go through the hassle instead of making it easy for a malicious user. Remember, if you’re using the same password to make it easy for you, all you’re doing is ensuring that you’re an easy target.

Also consider other than just where you use the password(s), but how you store them. The best method to store them, is to have a master password and use some method to have a local text file or database on your system, and that master password unlocks it. If you have a lot of passwords, consider having a file containing them, if you can’t remember them all, and putting an abbreviation of the site or service, without actually saying what site or service it’s for (that only you would know), and then consider encrypting that file with something like PGP, and make it so that difficult to remember, single password, is strong (only you know it). We also recommend against ever using a birth date, zip code, pet’s name, child’s name or birthday, favorite band, video game character, nickname, etc., even for a password reminder. That sort of information is far too easy to locate online, especially with how willing people are with the information they reveal about their lives in forums, blogs and their bio pages and so on.

#4: Script and program configurations. Pay attention to what information you supply when configuring a new program or script. Some settings will be more secure to not enable, and some will help the security of the install, even if from fraudulent signups, orders or memberships or posts on your site and script. Enabling login attempts and failures, if available in the script, is helpful, as are captcha (image code verifications) and so on. If given the option, try not to install the script at a common location, especially if it’s a popular script, and even more so if it’s an admin directory for the script. Should any exploits be known and you’ve not been keeping up on updates (let’s face it, most people just don’t do it), then an automated exploit “bot” can hit your site and submit and auto-compromise the exploitable feature in the script. Another good tip, is to disable access by adding password protection for a sub directory (such as an admin directory) that not everyone in the world should have a reason to access. Other options are to do such things as using a deny/allow rule and deny all IPs from access to the admin directory except from your IP or IPs (or IP ranges) known by yourself or staff you want to allow access to.

#5: Permissions and Ownership: One important thing, is permissions of your files and directories. Our servers are set up so you can execute scripts through the web server over http (and secure https) with lower permissions than a lot of script’s install instructions tell you to use. Instead of using a world writable permission (777, 666, etc.), you can set scripts to run with chmod 700, so only your user had read, write and execute permission. “group” and “other” don’t need even read permission, so only your user can view and run the script. Since your user is the user that actually executes CGI and PHP scripts on our services, you can ignore any instructions to set world read/write or execute on your script installs. In fact, world writable scripts will error and not run, for your protection. Any files that are intended to be world readable, and are non executable (not scripts), should be chmod 644 (allowing only your user read and (re)write permission, and the web server only read). Directories should be chmod 755 for allowing directory listing to show the files located within it to web users, or chmod 711 to allow files to be accessed within it, but not allow people to see all of the files located within it. Chmod 700 can be used for directories that will hold data that’s only intended to be read from and written to a PHP or CGI script and not be directly publicly accessible, though you can also consider putting the non-directly publicly accessible files outside of your web root directory path. This (the lower permissions) prevents web users, as well as any other users on a shared server from viewing or running or modifying your files, as well as prevents them from seeing your script’s source code or passwords on the server.

#6: Secure connections (SSL/TLS, etc.) Another important factor, is to ensure that, when possible, you use SSL for connections for sending sensitive data. Ultimately, SSL, tunneling, TLS, sftp, ssh, etc. are not really at risk, as someone would need super user access on the server or your network (or the remote network) to control and listen to data being passed over the network, to “sniff” out passwords or other data, but if you have an office where there’s a LAN/WAN or you connect out to the WWW (Internet/Web) over a connection where someone can have a listening device, or if someone did take control of the remote server or network, that they could at least not likely obtain your data, such as the password you use. Unfortunately, if someone has root access on a server, even sending data over SSL still results in plain text data being submitted to the server, if someone with that access modified the script or service on the remote end to capture the data sent over SSL, but that would only be the server side — it wouldn’t work on the network side and all bets are off at that point anyway (but it would still help to protect you in such situations so there aren’t multiple points of failure in a security sense and what data is able to be obtained for all services, if someone did compromise one). This is mainly just good security practice and behavior, since “just in case”, you want to take every measure to prevent a third party from being able to obtain the sensitive data you send and receive, so it’s a good thing to do as a personal policy. We don’t intend to get into the gory details about all of it, and where it really does any good or not and in what situation, but there’s never any reason not to practice this, so always use a secure connection when its available, be it for web, ftp, ssh, imap, pop3, smtp, or anything else.

#7: Site structure/design and miscellaneous: Never use a browser-side check for security or anything that can impose a security issue on your site. Always do all checks server-side with a script (using a PHP, CGI script, rewrite rules, .htaccess env var checks, allow/deny rules, SSI tags calling a script or environment variable, etc.) Be sure that any data you allow users to add or submit to your site or database is properly checked. Do simple checking to ensure there can’t be any injections into the database, any data added to the site or a file that could be executed (such as someone adding an SSI tag or some type of PHP scripting within the site, or any JavaScript or anything that could cause other views, or you as the admin, to have your information obtained or crash your browser. Things such as stealing cookies or guessing sessions, etc. via an exploitable weakness or some type of cross site scripting attack). Also, keeping in mind the files you have, any loose files, old files, and their contents, can sometimes be a problem and provide information malicious users can use against you, especially if they are executable scripts, database dumps stored in the web root and things where files are renamed as copies or backups, such as mysqdata.sql or myscript.php.back (it will no longer be executable and people can view the file as a text file, for example). Also, other things such as upload scripts, where people can bypass the file extensions you try and limit it to, or upload a non image file (script) and execute it by uploading an .htaccess file to make all files executable, and image.gif is now a script or compiled binary they can run.

Other things to consider, such as your robots.txt file, and what directories you disallow search engines to access. Anyone can view that file (though you could disallow it for non valid search spiders, someone can fake the user agent), and that person could then see all of the directories or files you are hiding from search engine indexing. That is not an appropriate method to hide anything, and in fact, if you don’t have any links to that area that are able to be indexed (followed) or seen, you shouldn’t have to worry about a search engine indexing it anyway (it doesn’t know what files you have on your site, unless there’s a link in the public area or page for it to follow, like any browser would — and legitimate spiders don’t guess at file names). Also, if you suspect anything, watch the error and access logs for your site (but don’t get too worried when you see the very common exploit attempt request by exploit and spam bots that randomly go across the Internet trying every IP and domain for attempted, generic and usually very old exploits).

Conclusion and further options: These are just a few very simple and common things, which, if followed, should greatly reduce the chances of an account/script being exploited or defaced. It ultimately comes down to how secure the script is that you decide to run. For further protection of your site and reducing the chances of an exploitable script you might run on your account from causing damage to your files, please feel free to contact us, as we offer a very unique file locking service GUI for our users, which allows you great control over the files on your site. Stay tuned for an announcement about this service in the next few days.

Here is a quick run down of a few of about 100 things we implement on our servers, and how they benefit our clients from a reliability and security stand point.

SuEXEC CGI Wrapper: All CGI scripts use the Apache SuEXEC CGI wrapper. This allows processes to run as your own user, rather than the global web server user. When CGI scripts run in the Apache web server, without the SuEXEC wrapper, it fails to perform security checks and all scripts on any account will be running as the same global user (world). This means, any script that the web server can (or has to) read, execute, write to, or otherwise has access or modify rights to, can be seen from other user’s CGI scripts.

To combat this, we implement the SuEXEC CGI wrapper on all servers by default, and have practiced this policy for many years. The advantages are that any files created by your script are owned by your own user, and not a different (web server) user, allowing you to control, remove, add, and edit them via FTP, the control panel, File Manager, web page editor, SSH/shell, email piping, etc. The checks it does ensures that you can’t set the permissions so other users script’s can access/write to your files. You can therefore set lower permissions to protect any read access, even, yet the web server itself can still execute the scripts. This prevents any other scripts from being exploited or intentionally coded to view files and such things as database passwords, script passwords or private information you store in databases and files, etc.

We automatically protect your site in this way, so no other users or processes can possibly access the files anywhere, and allows you to set real, beneficial permissions, whereby you can make directories that can store and retrieve data/content only through a script in a controlled manner, and make it so no web access can be allowed outside of your script. You can, of course, store those files outside of the web root path, so they are automatically outside of the web accessible areas, as well as password protect and set .htaccess rules to deny access to browsers, while your script still has control and access. This allows for the ultimate security regarding CGI scripts, so your site can be dynamic using them, but still remain secure.

The wrapper in question has the best benefit, where any abuses, spam, attacks, illicit processes, etc. are easier and more immediately tracked and controlled. This allows us to impose limits on the CGI script’s memory usage, CPU time usage, number of concurrent processes and the total time a process can run. We can white list specific users, processes, paths, and set different hard limits and soft limits for these resource restrictions. This allows us control, and you the security, and offers the ability for the server to automatically prevent any user’s script from going out of control (intentionally or not), so the server is never overloaded and negatively affects your site because of another user’s poor coding or if you happen to use a resource intensive script that would otherwise create a problem. We believe in preventative measures to keep things stable and clients happy, rather than only being proactive once a problem exists.

All CGI scripts run through this wrapper and can be coded in Perl, PHP, Python, Ruby, C, C++, shell scripts, and many more. CGI is only the protocol (or API) in question, and unlike what many people believe, CGI and Perl are two different things. CGI is the interface (Common Gateway Interface), and Perl is a language, so Perl is no more relevant to CGI than PHP or Ruby or C. Therefore, regardless of the language of choice, any of your CGI scripts automatically take advantage of all of the security, processing, ownership and permissive benefits that SuEXEC offers. This is not a new technology and has been widely used with great success for over a decade, so rest assured that these are only pros and there are absolutely no cons to the SuEXEC CGI wrapper.

Therefore, you should always ignore ANY script installation that instructs you to set world read, write and execute (chmod 0777) permissions on a file or directory, or that instructs you to set read and write to “world” as well (chmod 0666). Instead, CGI scripts themselves should be set to chmod 0700 (read, write and execute for your OWN user, only), or chmod 0500 for execute for only your user). The CGI wrapper will do the rest of the work. Chmod 0750 or 755 are fine, too, but you don’t ever need to allow “world” any read, or write, or execute permissions. This (world read access) is only needed for regular, non script/non executable files, such as text, HTML, images, and similar files, which aren’t executable or written to from their own http processes (since they aren’t a script/executable from the web server).

Directories that need to store data, can be set to chmod 0700 as well, or if you need to allow web access to that directory and the files within it, set it to chmod 0711 or 0755 or 0751. Any files that need read only access for the script, should be set to chmod 0400, and read/write access 0600. The first 0 is a sticky bit you can ignore on the permissions (it’s just for a full example). The second number of your user, this is where the SuEXEC wrapper cares about permissions. The third number is for your user’s group. This is a value you can ignore, really and don’t need to set. The final value is world (or other), which means all of the users but your user, so you needn’t set permissions on it or CGI scripts to run, read or write to. In fact, SuEXEC will cause your script to error and not run, if it sees anything wrong with the permissions or ownership, and it does this to protect you from running a script with too open of permissions (which protects you from allowing other users to modify a script that would have its process actually run as your own user) or ownership issues, where it detects the script isn’t owned by your user and isn’t in your account’s web root path, and thus, rightfully, and luckliy, fails. This is a good thing.

suPHP: Similar to the above, is suPHP, which is almost exactly as outlined above with the SuEXEC wrapper. They key differences is that it works off of the PHP file extension and will execute normal PHP scripts with normal permissions (even chmod 0644, for example). The point is for it to run more safely, and in a more controlled way, allowing you better security, and without you needing to make any changes to your scripts. Few people ever notice unless they are doing specific tasks, and even then it shouldn’t require any modifications to the code. Some key things are different for suPHP in how it sees PHP flag/value settings in, for example, an .htaccess control file. Instead of adding them there, you’d simply put them in the (more appropriate) php.ini file, just as the main PHP install uses globally.

suPHP is a replacement for an older idea of a SuEXEC (see above) source hack called “phpsuexec”. While it worked well in its time for the purpose and intent, it was not a very good implementation, so suPHP was the official recommended replacement as of about 5+ years ago now. Therefore, you can rest assured that suPHP is a well tested, stable, and mature implementation, where you can seamlessly run PHP scripts as your own user, without having to modify them (even if only slightly) if you wanted them to run in CGI (to take advantage of the SuEXEC CGI wrapper). This uses a similar method, but still protects your scripts and your site from the fundamental drawbacks of running mod_php (Apache web server API) as a global web server user, where the need for world writable files existed and memory leaks were more prevalent with php processes embedded in the Apache httpd server process. While the benefit of using the Apache API was the speed increase due to the lack of CGI overhead (when a CGI script is ran, it spawns a new process, instead of using the already existing httpd process for the web request), the increase was very negligible and had too many security drawbacks on sites that weren’t hosted on their own dedicated server. Essentially, it’s win-win for you and us.

mod_security: The mod_security Apache module is an addon that allows us to globally, or individually, control certain elements of requests that are sent to our web servers that host your site(s). We can filter out a lot of known and common exploit attempts, spam bot spiders that harvest email addresses, and many wide spread or unique actions that are nefarious or our of malice, be it from a human or, more likely, a scan/attack bot from some person’s infected system. This covers all types of request methods (GET, POST, TRACE, HEAD, etc.) and can check the header, body and URI, USER_AGENT, IP, etc. of the person, browser or system making the request. This helps to protect from common exploit attempts on common scripts, which are bound to host some out of date/unpatched script with all of the clients running all of the various scripts that have been out for the last 5, 10 or 15 years on their sites. This allows us to add one more of a dozen additional steps to help protect our clients, even if they ultimately uploaded a vulnerable script. If detected, we’ll contact a client and help/advise them to get it updated or replaced with a more secure, equally feature-rich alternative, which are almost always open source (no charge to use the scripts).

Iptables & Software Firewalls: While we implement various methods of limiting and blocking and controlling traffic and when sites need protecting, we can use route rejects, iptables (software) firewall rules, hardware firewalls with our upstream provider, null routing, deny from directives for the web server, blocking and controlling access with tcpwrappers, deny rules for email, SSH and FTP, etc., the one major factor that allows a server to be incredibly dynamic and automate protections, is to use iptables. Iptables is a very mature software firewall, which allows us to control and limit and prevent issues on both incoming, outgoing, forwarding, etc. as well as tallying transfer usage with greater accuracy.

With iptables, we can prevent abuse from denying any ports to be bound to/listened on, unless approved, which prevents a great deal of backdoor exploits on scripts and servers, rate limit how many times an IP can make a request to a site or server in a specified amount of time to prevent attacks dynamically without having to specify a specific block on an IP or IP range, block or limit or break down packets by IP requested, source IP or the service/port and protocol used, block or limit per port or service, log all requests without it actually hitting the service/making the request, save bandwidth, fight attacks and control the type of connections both in and out, to prevent a great variety of issues. We implement complex, but well tested and proven firewall policies that we have modified and perfected over the last decade or more and are always careful to ensure that client’s sites can function without problems or restrictions based on these policies/rules, but add an extra layer of protection.

Kernels, grsecurity, policies: We always use the most stable, secure and efficient kernel versions, patches and configuration options. Everything from ensuring it’s a stripped down kernel with only secure features needed and no unnecessary protocols, drivers, etc., to ensuring we add specific and custom addons, including things like the grsecurity patch, which allow us to perform everything from process listing protection, including paths, chrooting, jailing, and mounting issues, to such things as process ID randomization, time randomization on encryption and session routines, to controlling memory heap and storage to prevent zero day exploits if there’s an exploit discovered in a kernel version before the new version comes out and before the public is notified on security lists, right down to standard things such as (real) partition mounting policies, segmentation, to the kernel being static without LKM (Loadable Kernel Module) support, to protect from lkm exploits.

We really would make this blog entry result in a 100 page long post with just describing the kernel compile options and customizations alone, but we go to great lengths to ensure the best security and reliability, from the bottom (from the kernel) to the most top level protocol and services. This is only a short run down of a few things, out of probably 100+ actions we take based on over 250 years of combined experience with our staff members, as they each have over a decade or more of high level, hands on experience working on every level and aspect of systems administration, security engineers, developers and even getting heavily involved in the support aspects, keeping in touch with and providing satisfaction to the customers. There’s more to come, stay tuned.