Thread

I think the single most important thing is the choice of host. Having a car with a state of the art alarm system, bullet proof and unopenable windows, and unpickable locks means nothing if you hand your keys to the valet who hires an irresponsible teen with a criminal record and pays him minimum wage to “watch” your car.

Well put, Mr. Allard.  I couldn’t agree more.

Can we locate trustworthy data that compares the security histories of hosting vendors or are we stuck with anecdotal reports?

I think the single most important thing is the choice of host. Having a car with a state of the art alarm system, bullet proof and unopenable windows, and unpickable locks means nothing if you hand your keys to the valet who hires an irresponsible teen with a criminal record and pays him minimum wage to “watch” your car.

Amen to that.

The basics do a great job of making EE access secure. Change /system directory name. Choose good login IDs and passwords. Password protect directories. And use a host that takes the business of security, dependability, stability seriously. Generally speaking, those sites that get hacked regularly are the cheapo sites.

Except for the expensive credit card databases, of course.

😉

Markus,

I agree with encrypting the files, if it’s gone that far… it’s time to start checking your backups! Also, I have tried several different methods to grab the config.php with no luck. The last thing I am going to try next is using a program, I used to use this along time ago, that had a feature to pull files from a remote server. I just need to install it on windows 7 (if it works).

Derek,

To be redundant, well said. Going off topic since most of us are Mac fans… I’m waiting for the MT (xv) VPS to be released. Really excited to test it out using EE on a Mac platform.

Last thing: Has anyone considered a “semi-annual” system directory move like McGehee mentioned?

Okay, let’s get paranoid…

- Always use SFTP to transfer files.

- Always log into the CP via HTTPS... use .htaccess to enforce this.

- Move your MySQL password out of config.php and replace it with a $variable. Then create a file in a directory ABOVE your public_html directory, and store it there. Then require that file in config.php. Now even if PHP crashes no one can read your MySQL password.

Caveat: you’ll have to CHMOD config.php to 644 or 444 to prevent EE from overwriting it, and then make all changes in the file manually (i.e. not through the CP).

--> in /home/user/includes/mysql_password_include.php

<?php $MySqlVar = 'your_mysql_password'; ?>


--> and in /home/user/public_html/system/config.php

<?php 

require("/home/user/includes/mysql_password_include.php");

...

$conf['db_password'] = "$MySqlVar";

?>

- Call /system/ something ridiculous, like a random 20 digit string. Then set up an .htaccess redirect from something easier to remember. You can change the .htaccess redirect url every month, or week, or day depending on your paranoia level, without having to make any changes in your EE settings. Even if someone sees the real URL they won’t be able to remember it.

redirect 301 /tHiS-wEEkz-URL-52678/ <a href="https://mysite.com/system-1yshorIj3Duio7iLZmqo6apA7rgdL86G3/">https://mysite.com/system-1yshorIj3Duio7iLZmqo6apA7rgdL86G3/</a>

- Limit CP login attempts to certain IP addresses, like your office and your home. In /system/index.php do…

<?php

if ($_SERVER['REMOTE_ADDR'] != 'my.off.ice.ip' && $_SERVER['REMOTE_ADDR'] != 'my.hom.e.ip'){
    echo "<meta http-equiv='refresh' content='0; url=../'>";
}else{
    error_reporting(0);
    $pathinfo = pathinfo(__FILE__);
    $ext = '.'.$pathinfo['extension'];
    require './core/core.system'.$ext;
}
?>

- If you’re not using the Members features, change your member profile triggering word to .member (i.e. member with a period before it). That will block access to all the member templates (credit to the person who posted this trick here on the forums).

- And the thing we should all do more then we do do—change your password frequently!

Okay, back to the bunker…
- i

Pure brilliance!! I am going to have to start implementing these methods!

Not sure about the IP Address thing, I am always on the road. I think for me it would kind of turn into a pain in the butt. However, this is still excellent material!

Thanks WTHIGO?!

Not sure about the IP Address thing…

Yeah, that one can bite you if you’re at a client’s office or something… doesn’t look too good when the developer can’t log in to his own back end!

- i!

- Limit CP login attempts to certain IP addresses, like your office and your home. In /system/index.php do…

Or, we can create.htaccess in system folder with the content below

order deny,allow
deny from all
allow from 255.255.255.255

Amazing no one mentioned the most overlooked, and constantly the largest source of all compromises.  Though in the case of web hosting places that provide lackluster security between hosting clients you have no control over your neighbors…

UPGRADE YOUR SCRIPTS! I mean on a regular basis, shortly after the authors release new versions, and of course more so after the authors tell you the upgrade includes fixes for known/actively abused, or theoretical security concerns!

Along this same line of thought…

Remove all old scripts you no longer use! This includes 3rd party additions to your other, in use scripts.  If you upgrade a script don’t simply move the old version into a directory called scriptname-old, download it as a backup and remove it from the server.

Did you try out 3 GUI editors to use in EE for example and are no longer using any of them?  Why are they still installed in your hosting account if you are not using them? and you tested them 2 years ago?!? 😊

In every instance of us helping hosting clients with a compromise of their site, I can not think of a single instance it was not caused by either really outdated scripts, in most cases ones no longer even actively used on the site, or simply ignoring security related update notices by the authors of their active scripts.

Think about it, all the paranoid changing of passwords, encryption of settings files, use of SSL for logins, etc. will not help you if a) your hosting company’s server setup allows for cross-client security issues, or b) your own scripts installed in your account are the cause of the security breach.

So in the end, and with safety in mind, clean up your unused scripts, and update the ones you do use frequently!

Last thing: Has anyone considered a “semi-annual” system directory move like McGehee mentioned?

Heh. Even I’m not considering doing it again, if I can help it.

UPGRADE YOUR SCRIPTS! I mean on a regular basis, shortly after the authors release new versions, and of course more so after the authors tell you the upgrade includes fixes for known/actively abused, or theoretical security concerns!

Spoken like a true sys admin; one who’s cleaned up after a few customer messes.

Along those same lines, what kinds of security issues have other EE developers had on their sites?

Spoken like a true sys admin; one who’s cleaned up after a few customer messes.

Actually we deal with fewer compromised web sites then you may think, can chalk a lot of that up to the software that a majority of our clients select to run though too 😉

The thing that actually amazes me though are the companies, large and small, that have a web presence, but will outright say “Oh we can’t upgrade because we did not budget for that, so it will have to wait”.  This is like saying you built a brick and mortar building, but did not budget at all for building maintenance or physical security of your new building.  But one of the first pre-sales questions from most of these same companies is about what we have in place to protect their sites.  So we do remind pre-sales and clients that security is in their (and their web developers) court as much as it is in ours, neither will work well without the other.

I agree with iseem - I’ve never liked storing passwords within the docroot of a site, far better to move it out. (I’ve tended to move the entire config file contents out of docroot and require() the file in my real config.php, but I like the simple idea of iseem and just replacing with variables)

Another *silly* tip is after renaming your admin area actually create a folder called ‘admin’ & ‘administrator’ then use Basic Authentication to password protect them. Any scripts searching for admin areas will expend their efforts on fake directories.

Perhaps this thread is a candidate for the wiki.

jfp

I agree with iseem - I’ve never liked storing passwords within the docroot of a site, far better to move it out.

Being in the public html folder is not the issue, as unless you are storing passwords in HTML or text files, they aren’t going to be able to view it with a direct HTTP request.  And if a directory traversal hack occurs on the server, the ultimate location of your files is immaterial, as the attacker will go where they want to.

So if the concept of removing the update.php file exists, should removing modules that you don’t use apply? Modules such as Moblog, Wiki and etc?