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.