[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:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

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:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

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

http://www.vbulletin.org/forum/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 08 Jul 2011 at 19:55 ---------------



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

[Disasterpiece]

if the hacker somehow got the chance to include your precious config.php file, there's something completely wrong nontheless. But then again, this is just fighting against phantoms and has no real security value. A colorful image file reading "please do not hack my server, k?" would have the same effect. But if it makes you sleep better...

[Kahraman_5222]

thank you...

[OwuFail]

This as you said can help you protect from the want to be hackers. The hackers who think they are good. I will use this since my forums will be small and hackers won`t try to hack it unless there desperate.

[Angel-Wings]

Originally Posted by MaryTheG(r)eek

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.

Well - doesn't matter if htaccess or not - IIS also supports restrictions. The problem is just that VB (and so PHP) need to read this file so it basically doesn't matter where it's put. By default the config file isn't remotely accessible anyways.
And remembering some VB bugs (like the FAQ one revealing the DB info) - then it doesn't matter where this file is because VB needs it to work at all.

Originally Posted by MaryTheG(r)eek

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.

That depends. Writeable directories like the attachments should be stored outside the webroot, without any doubt.
For readable files like configurations, there's for the webserver absolutely no difference having them placed in the "includes" directory and set that via "Deny from all" to only allow local access or moving them somewhere into a directory that has the same restrictions (like /etc).

It's maybe a bit more userfriendly to setup the "includes" directory to disallow access because you don't need to edit VB core files.

And - for the worst case - if it happens that VB has some kind of LFI or info revealing bug - then it doesn't matter where this file is.