Protect your Config.php from Hackers

[MaryTheG(r)eek]

Hello all,



Here is a very easy way to protect your config.php (and thus your valuable database):

1. Copy your config.php from /includes/ directory, over the public area so nobody can access it with the browser.
2. Open the config.php that still exists in /includes/ directory and remove all the code.
3. Add only the following code:

<?php
require_once("/home/**username**/config.php");
?>

Ofcourse you need to replace **username** with your FTP username. Maybe you need to change the path. This example is from cPanel configuartions.

That's all. Connection details to your database are now hidden to hackers.

Maria
PS- I did a search before posting the advice, but I didn't found anything. If a similar article exists, then my apologies, but is well hidden

[TheLastSuperman]

Originally Posted by MaryTheG(r)eek

Hello all,



Here is a very easy way to protect your config.php (and thus your valuable database):

1. Copy your config.php from /includes/ directory, over the public area so nobody can access it with the browser.
2. Open the config.php that still exists in /includes/ directory and remove all the code.
3. Add only the following code:

<?php
require_once("/home/**username**/config.php");
?>

Ofcourse you need to replace **username** with your FTP username. Maybe you need to change the path. This example is from cPanel configuartions.

That's all. Connection details to your database are now hidden to hackers.

Maria
PS- I did a search before posting the advice, but I didn't found anything. If a similar article exists, then my apologies, but is well hidden

https://vborg.vbsupport.ru/showthread.php?t=198856

I prefer the above as many simply do not know about this and not to mention your telling a hacker where config.php is within the old config.php when/if they have a copy although they may not think to look for the edit within class_core (if you do not preserve timestamp info when editing or uploading the modified file) . The only drawback is vB4 does not like it to be renamed when upgrading, vB3 did not care - that's simple to bypass though, before upgrading change it all back then redo the changes again once you've upgraded and your good. You can then leave a cloned config.php in place within includes and fill it w/ all sorts of false information.

[Adrian Schneider]

Sorry if I'm missing something, but how does this stop hackers?

1. Hackers do not try to view config.php directly from the browser
2. Hackers usually end up hacking plugins / templates / template cache, which means it runs in PHP, which means they could easily find and have access to your config.php no matter where it is (as long as vBulletin can read it, so can they)
3. Hackers often get in from other web applications / vulnerabilities on your server.
4. Your credentials are stored in plaintext in memory with vBulletin, so a simple var_dump will show them.

This sort of thing is a little security by obscurity at best, but is by no means where you should be focusing your attention.

Not trying to be negative, but I also don't want people thinking that moving their config.php is going to protect them from hackers. At best it'll just cause some minor problems when they go upgrade.

[TheLastSuperman]

Originally Posted by Adrian Schneider

Sorry if I'm missing something, but how does this stop hackers?

1. Hackers do not try to view config.php directly from the browser
2. Hackers usually end up hacking plugins / templates / template cache, which means it runs in PHP, which means they could easily find and have access to your config.php no matter where it is (as long as vBulletin can read it, so can they)
3. Hackers often get in from other web applications / vulnerabilities on your server.
4. Your credentials are stored in plaintext in memory with vBulletin, so a simple var_dump will show them.

This sort of thing is a little security by obscurity at best, but is by no means where you should be focusing your attention.

Not trying to be negative, but I also don't want people thinking that moving their config.php is going to protect them from hackers. At best it'll just cause some minor problems when they go upgrade.

Stopped a professional at CrowdGather from moving one of my clients forums after they purchased (lol), so perhaps we should say hide instead of protect and "script kiddies" instead of hackers as many of them don't even know how to do all the above Adrian but valid points you have there.

[MaryTheG(r)eek]

Come on. Be ...serious. You know that nothing can stop hackers. While even CIA (as I've read) can't stop them, do you think that just a file move can stop them?

In any case I was talking in general. And is well known from the early days of PHP that configuration files is better to not being stored in the public area.

An daily example. There are many site owners who are giving FTP access at the public area to someone to fix something. Why to have the login to database details available to him?

Maria

--------------- Added [DATE]1310151314[/DATE] at [TIME]1310151314[/TIME] ---------------



By the way. Nice to see you back Sir Adrian. Even if we never talked, I've read carefully some of your articles when I started coding for vB. Especially that one for creating more secure addons.

Maria

[Adrian Schneider]

If they have FTP access, all they need to do is add var_dump($vbulletin->config) anywhere after global.php to see the password being used. Or they can look in init.php / class_core.php to see where the config.php is located. Even if they can't use FTP to view that directory, they can use file_get_contents() or similar to read the file.

There are lots things you can do to stop hackers, this may slow someone down for 3-4 minutes but I don't' think that 3-4 minutes is worth botching upgrades for. That's not my call, of course, people are free to do what they want.

Thanks I'm not trying to be a ++++ here, but I am trying to help educate people who may not understand the pros/cons of doing stuff like this. Hopefully it's not coming across that way.

Cheers

[MaryTheG(r)eek]

Originally Posted by Adrian Schneider

... but I am trying to help educate people
Cheers

At least for me, you helped me a lot and I'm greatful for it. Even coding since 1984, I'm selfteached. Lots of money for a Greek to study in US 35 years ago. My first 2 mods gone to Graveyard for security holes. After reading your article, I fixed them, and since that time, the only reason that my mods are there, is because I'm removing the files.

Again thank you
Maria

[Jeff Ledger]

If they have FTP access, all they need to do is add var_dump($vbulletin->config) anywhere after global.php to see the password being used. Or they can look in init.php / class_core.php to see where the config.php is located. Even if they can't use FTP to view that directory, they can use file_get_contents() or similar to read the file.

There are lots things you can do to stop hackers, this may slow someone down for 3-4 minutes but I don't' think that 3-4 minutes is worth botching upgrades for. That's not my call, of course, people are free to do what they want.

Thanks I'm not trying to be a ++++ here, but I am trying to help educate people who may not understand the pros/cons of doing stuff like this. Hopefully it's not coming across that way.

Cheers

You are my favorite guy, since the day I read your review about vbulletin 4. I coudn't say it better.

keep up the good work Adrian.

Jeff

[Angel-Wings]

And what's the different between this and a simple yet working:

<Files ..../includes/config.inc.php">
Order deny,allow
Deny from all
</Files>

???

Doesn't require any modification of core files and result is the same.
Because moving the file out, still no problem to use LFI to get it because you've to change your open_basedir value to the corresponding path.

Moving the file around doesn't add much protection - just a difference for an user getting either a 403 or a 404.

Specially - dunno but I don't like the idea adding something in $HOME to open_basedir

[MaryTheG(r)eek]

Originally Posted by Angel-Wings

And what's the different between this and a simple yet working:



???

First of all, and please correct me if I'm wrong you're talking for editing htaccess file right? In this case, just keep in mind that not all users know how to use such files, and most important, not all server configurations can use htaccess (eg win/iis). At least so easy as *nix servers.

Second, but this is just my opinion, I believe that anything outside the public area is "more" secure. Not that is totally secure, but it has a greater security level.

Thirda and last. I didn't wrote that my method is the best, or the only one available. I wrote something from my experiance as you did with yours. Sure should be other ways too.

Maria