By W.M. on

I have posted this question before. Some have said that it makes no difference to restrict IP addresses' access to Admin folder by a htaccess file. Is this true? Is it possible to rename the Admin folder to some really hard to guess name?! Is it possible to disallow access to Admin folder by query?! Is it possible to restrict logging into administration area to SSL connections only?!

How to make my site safe?! The only thing that I have done so far is to have real long password.

⋅ Categories: Drupal 6.x

Comments

styro’s picture

styro commented

The main things that matter:

* Keep up to date with all Drupal patches
* Don't add any custom code to your site without checking it over (yes this includes modules and themes)
* Don't use shared hosting
* Making sure the server you are running on is kept secure

Protecting logins (or the whole site) with SSL will add some protection from people intercepting the traffic or some types of DNS fiddling, but I get the impression that SSL can sometimes add some headaches. You'll need to try it out.

If you can't get SSL working how you want, one option to protect your own password might be to use OpenID, and only use providers that use SSL or two factor auth etc.

Note that password sniffing attacks are very rare compared to just exploiting vulnerable servers - and if you have vulnerable software on your server none of the minor restrictions you ask about will be any help.

W.M.’s picture

W.M. commented

Why shared hosting no good idea?!

styro’s picture

styro commented

involves a lot of security compromises.

You (ok the host) can use suexec to prevent other users (or the crackers that have compromised the other sites) on the server being able to read your files, but that involves allowing your own site write access to its files. You'd better keep your own site secure.

The alternative is having the web server run with the same account for everyone on the web server. This allows you to protect your code from being written by the web server, but you then have to trust that other users (or the crackers on their sites) won't read your your code and get DB passwords etc. If someone can log into your DB, then it makes no difference what IP restrictions etc you have on your admin urls.

The suexec is probably the preferred approach for shared hosting, but you need to be extra vigilant about keeping your own site up to date. You generally trust yourself more than the other users.

You can't get any real security on a shared host, and it makes all the things you asked about the equivalent of rearranging the deck chairs on the Titanic (ie futile). On a virtual or dedicated server, there are no other users on the server to worry about and the non suexec approach is probably the better one. But you still need to be vigilant in making/keeping the server itself secure.

dkeays’s picture

dkeays commented

Ok, we know that shared hosting is full of compromises and potential mistakes that can be leveraged into security vulnerabilities. But those mistakes are even more likely to be made by someone without extensive experience on the server-side. For those like me whose experience doesn't extend to the server, it is better to put up as many barriers possible and let the staff at the shared hosting site take care of the rest.

All security is a compromise and errors can be made anytime a human is involved or a robot created by a human. The concern isn't to try and eliminate the existence of compromises but to minimize them. You may be very capable of rolling your own server solution without exposing the site to even more flaws, but most of us are not.

Saying that you need to control your own hosting site because of potential errors in a shared site is like saying we must create our own crypto schemes because Debian/Ubuntu had weak keys for years.

styro’s picture

styro commented

Shared hosting is "good enough" for a lot of people - especially if a managed server is massive overkill for their site.

My (possibly badly worded) point wasn't that everyone needs dedicated hosting - just that freaking out over the kinds of things in the original question is pointless if far bigger and more common risks haven't been addressed. Someone who was legitimately paranoid enough to worry about those minor risks would freak out at shared hosting, but most people don't (and don't need to) care.

It's all a matter of putting each risk in perspective.

dkeays’s picture

dkeays commented

After that (April) fools worm, freaking-out doesn't seem very odd anymore. It almost makes you nostalgic about the days when nobody cared about security.

I use a risk-to-benefit analysis to keep my head straight-- looking at each piece of protection and decide if it will potentially hurt me more than it will potentially benefit me.

dkeays’s picture

dkeays commented

I would start with:

When designing a site:

  • Do not allow the PHP filter or fullHTML filter to be used by anybody you don't trust and never set it as the default input format. Somebody can use this to log into your administrator account with 1 line of PHP or and a few lines of JS.
  • Avoid allowing the anonymous user to comment or create content. I know it can't be helped in some cases, but make sure the above step is done.
  • Set your file/directory permissions so that /files is the only directory that users can write to.
  • Set-up a decent ACL with roles so that no user has more power than they absolutely need (ie article readers don't need to write articles, authors don't need to edit other users contents, editors don't need to change the menu, etc...)

When programming a module or a theme:

  • Use the database abstraction layer.
  • Use the Form API (FAPI).
  • Use t(), checkplain(), xss_filter(), xss_filter_admin(), and db_query() correctly. This would cut the majority of XSS, SQL-injection, and CDFR which are a significant number (if not the majority) of attacks.
  • Use the db_rewrite_sql() function to allow for the administrator to make proper node access decisions.
zirvap’s picture

zirvap commented

There's also http://drupal.org/security, http://drupal.org/security/secure-configuration, and http://drupal.org/writing-secure-code

dkeays’s picture

dkeays commented

I wish more people paid attention to those pages, especially the ones about file permissions and input filtering. But I'm afraid people will use it to justify only doing the 3rd (hiding info) hence, "security through obscurity". STO is dangerous in the wrong places.

myke’s picture

myke commented

Delete the CHANGELOG.txt, so people can't figure out what version of Drupal you're running so easily..

-Myke