December 17, 2009 at 00:42VBulletin Forum Protection Tips
If you are holding your forum, sooner or later you have to think about protecting your forum - after all, the attackers are not asleep! In this topic, I (with the help of the ReaM habrayuzer ) have compiled a list of tips for increasing the security of your forum. Interested in? Welcome to habrakat :)
So ... Let's start:
Description: No comment
Why ?: Jelsoft constantly closes pop-up vulnerabilities. Nobody wants to work at last year's leaky forum, right?
Description: Rename the admin panel, but in the configuration, in no case write the path to our renamed admin panel. We also rename modernization, but it can already be written in the configuration (although it is also undesirable), since it is less vulnerable. See for yourself :)
Why ?: If you rename the admin panel and do not specify the path in the configuration, it will be much more difficult to find it and therefore apply XSS or even worse. There are minuses: - editing a profile and adding moderators will stop working without manually editing links.
Description:
a) if ip is static, then b) we also set an additional password : Follow the link: _http: //vbsupport.org/htaccess.php, fill out the fields and add instructions to our htaccess file. Why ?: Additional password protection admin never hurts.
Description:
a) Delete the files:
/validator.php ( if available)
/checksum.md5
( if available) b) Delete the folders:
/ install /
Why ?: Unsafe files from zero versions may allow you to view the list of files, as well as the install folder very harmful =)
Description:
Go to the admin panel, then:
a) Attachments -> Method for storing attachments
Attachments should be stored in the database
b) Avatars -> Type of storage for user images
Avatars should be stored in the database
Why? : Line 3.5, if my memory serves me, gave direct links to pictures - which, if the hosting configuration was incorrect, made it possible to fill the shell.
Description: If step 5 is fulfilled, now we safely set the rights to the custom_ * 644 folders, since we no longer need them (or you can delete them). Further, if you installed vBulletin according to the instructions, you should have 644 permissions for all the folders in / (root). Check this, if not, then set the permissions to 644.
Why ?: We make it difficult for the hacker to fill in the shell.
Description: No comment. Why would anyone need HTML?
Why ?: The possibility of XSS attacks when the function is enabled.
Description : Put .htaccess on the includes folder of the following content: Why ?:
Description: Why ?: Scripts with the specified extensions can no longer be used within the directory with such htaccess.
Description: /includes/config.php. Just enter the administrators id after you have made all the necessary changes to the profile.
Why ?: There’s no reason for someone to change the profiles of administrators, even for themselves. It will be required - remove the ID from the file, change it, return it back. Safety comes first! :)
Description: No comment
Why ?: Why do you need extra files on the server? No reason ...
Description: No comments
Why ?: They will be available for download to anyone who finds out the name of the backup. Of course, you can screw htaccess, but all the same, for security's sake, take backups beyond the reach of the web server.
Description (quote):
Download from vbsupport.org
Why ?: An irreplaceable thing in the search for shells on the site, but you need to install it in advance.
Getting access to the admin panel is quite difficult - therefore, fill the shell through the admin panel too. You can fill the shell through vB vulnerabilities, but if you upload to / includes (there are files for some hacks that require 777), then we have deny from all on the includes folder - the shell will simply not be accessible from the outside!
You can put 644 permissions on other folders, if you have done all the points, then it will be quite difficult to fill in, especially if the chroot is configured correctly. And finally, we added protection from the admins themselves, who climb where they don’t get, thereby putting ourselves on XSSs and trojans.
Actually, that’s all ... This is my first topic on the hub, so please do not kick much :)
UPD: Transferred to "Information Security".
So ... Let's start:
1) Update to the very end of our lineup (3.5.x, 3.6.x, 3.7.x)
Description: No comment
Why ?: Jelsoft constantly closes pop-up vulnerabilities. Nobody wants to work at last year's leaky forum, right?
2) Rename the admin and modern
Description: Rename the admin panel, but in the configuration, in no case write the path to our renamed admin panel. We also rename modernization, but it can already be written in the configuration (although it is also undesirable), since it is less vulnerable. See for yourself :)
Why ?: If you rename the admin panel and do not specify the path in the configuration, it will be much more difficult to find it and therefore apply XSS or even worse. There are minuses: - editing a profile and adding moderators will stop working without manually editing links.
3) Put .htaccess on the admin panel:
Description:
a) if ip is static, then b) we also set an additional password : Follow the link: _http: //vbsupport.org/htaccess.php, fill out the fields and add instructions to our htaccess file. Why ?: Additional password protection admin never hurts.
order allow, deny
deny from all
allow from %ваш_IP%
4) Delete files and folders:
Description:
a) Delete the files:
/validator.php ( if available)
/checksum.md5
( if available) b) Delete the folders:
/ install /
Why ?: Unsafe files from zero versions may allow you to view the list of files, as well as the install folder very harmful =)
5) Move attachments and avatars
Description:
Go to the admin panel, then:
a) Attachments -> Method for storing attachments
Attachments should be stored in the database
b) Avatars -> Type of storage for user images
Avatars should be stored in the database
Why? : Line 3.5, if my memory serves me, gave direct links to pictures - which, if the hosting configuration was incorrect, made it possible to fill the shell.
6) We expose the rights to folders
Description: If step 5 is fulfilled, now we safely set the rights to the custom_ * 644 folders, since we no longer need them (or you can delete them). Further, if you installed vBulletin according to the instructions, you should have 644 permissions for all the folders in / (root). Check this, if not, then set the permissions to 644.
Why ?: We make it difficult for the hacker to fill in the shell.
7) Nowhere, never, do we turn on the 'Allow html' option for anyone.
Description: No comment. Why would anyone need HTML?
Why ?: The possibility of XSS attacks when the function is enabled.
8) Put .htaccess on the includes folder
Description : Put .htaccess on the includes folder of the following content: Why ?:
order allow, deny
deny from all- if the shell is poured in any way there, then they will not be able to enter it.
- if you are dodged, then this option is possible when the php interpreter falls off and only the Apache remains - and the Apache allows you to read php files already - therefore, you can read all the files from the / includes / folder - the same config.php, which is not very good.
9) Shove in a directory with files on which attributes 0777 such .htaccess stand:
© kerk _http: //vbsupport.org/forum/member.php? U = 30
Description: Why ?: Scripts with the specified extensions can no longer be used within the directory with such htaccess.
RemoveHandler .phtml
RemoveHandler .php
RemoveHandler .php3
RemoveHandler .php4
RemoveHandler .php5
RemoveHandler .cgi
RemoveHandler .exe
RemoveHandler .pl
RemoveHandler .asp
RemoveHandler .aspx
RemoveHandler .shtml
Order allow,deny
Deny from all
10) Edit config.php, enter the administrators id in the undeletable user field (undeletable / unchangeable users).
Description: /includes/config.php. Just enter the administrators id after you have made all the necessary changes to the profile.
Why ?: There’s no reason for someone to change the profiles of administrators, even for themselves. It will be required - remove the ID from the file, change it, return it back. Safety comes first! :)
11) After removing mods / hacks, do not forget to delete the files that you uploaded with them.
Description: No comment
Why ?: Why do you need extra files on the server? No reason ...
12) Never save backups within the reach of the web server.
Description: No comments
Why ?: They will be available for download to anyone who finds out the name of the backup. Of course, you can screw htaccess, but all the same, for security's sake, take backups beyond the reach of the web server.
13) Install the “File Inspector” plugin.
Posted by Ghost (http://www.vbsupport.org/forum/member.php?u=38422)
Description (quote):
Climbing my old scripts, I ran into this product - File Inspector. These are several modules for vBulletin, with which you can save a list of existing files in the database and check from time to time if any of them have changed (size, owner and access rights are saved for each file) - the built-in cron task will notify the administrator by mail About inconsistencies found. You can save several different copies (revisions) of file lists for comparison in the database (automatic verification with email notification is only verified with the latest revision). Appearance and available settings can be seen in the screenshots.
INSTALL: To install, you need to upload two PHP-files from the archive to the server and import the product from the file "product-gfi.xml".
UPDATE: Version upgrade is not provided, so to install a new one, it is recommended that you first delete the previous version.
Z.Y. The product successfully worked on all versions from 3.6.8 to 3.8.1 inclusive. True, a link to the drop-down menu in the navigation panel was added to different places, but this is a trifle.
Download from vbsupport.org
Why ?: An irreplaceable thing in the search for shells on the site, but you need to install it in advance.
Total:
Getting access to the admin panel is quite difficult - therefore, fill the shell through the admin panel too. You can fill the shell through vB vulnerabilities, but if you upload to / includes (there are files for some hacks that require 777), then we have deny from all on the includes folder - the shell will simply not be accessible from the outside!
You can put 644 permissions on other folders, if you have done all the points, then it will be quite difficult to fill in, especially if the chroot is configured correctly. And finally, we added protection from the admins themselves, who climb where they don’t get, thereby putting ourselves on XSSs and trojans.
Actually, that’s all ... This is my first topic on the hub, so please do not kick much :)
UPD: Transferred to "Information Security".