The first feature in eXtlplorer that needed to be disabled was the “New File/Directory” button. This button allows the creation of symlinks, which can override the specified user’s directory. As you can imagine, this would allow a user to view any files that the webserver owner would be able to view. In most circumstances, the user running under the webserver process will be able to view well over 90% of the files on a server (some of which are sensitive). We can easily disable this feature, by editing a few files.

To disable this feature, edit the file include/mkitem.php. In that file, you should see code similar to the following:
/**
* Allows to create dirs, files and symlinks on a server
*
*/
class ext_Mkitem extends ext_Action {


New File/Directory disabled, on eXtplorer

To properly disable this feature, you can either comment out the function, or simply rename the function. This results in a screen similar to the one on the left, when a user attempts to create a new file or directory. As you can see, the screen is completely blank, and does not allow the user to upload new files, or create a symlink to another directory.



 

The other weakness in eXtplorer’s design was the creation of an “About” page, which contains (among other items) a way to view the phpinfo() function. This function reveals sensitive information about the webserver (the version of PHP running, OS, PHP configuration, etc). Fortunately, disabling this feature is rather easy.

To disable the “About” page, edit the file admin.extplorer.php, and look for the line that is similar to:

case'get_about':
require_once( _EXT_PATH . "/include/system_info.php" );
system_info();
break;


And change this to:


case'get_about':
echo "This feature has been disabled by your administrator.";
// require_once( _EXT_PATH . "/include/system_info.php" );
// system_info();
break;


eXtplorer's About page, properly disabled

What we are effectively doing here is commenting out loading the script that reveals the phpinfo() information, and instead we create a line that tells the user that this feature is disabled. This way, the dialog now looks similar to the dialog on the left.

New File/Directory (Disabled)

Finally, we need to edit the language file, and edit the “New File/Directory” and “About” descriptions. These help our users to understand that when they hover their mouse over an option, they can read that the features have been disabled. In order to do this, edit the file languages/english.php (or whatever language is the default), and edit the variables “aboutlink”, and “newlink”. You can edit these variables to display whatever message you choose, my personal favorite is just to use the text “Disabled” after the feature, to let the user know that the feature is disabled on purpose.

Once you have performed these modifications, eXtplorer will happily run in a multi-user environment securely. If you have any further questions about eXtplorer, feel free to contact me by posting a reply, or using the contact form on this website.

A good security audit will test your server for:

• XSS vulnerabilities
• Operating System vulnerabilities
• Weak user names and passwords
• SQL Injection vulnerabilities
• Server application vulnerabilities
• Insecure configurations
• Information disclosure vulnerabilities

Using advanced scanning tools, you can test for all of these potential vulnerabilities on your server.  Tools such as nmap allow for advanced port scanning, and the tests the ability of an attacker to detect possible sensitive information about your server.  Tools such as Nikto scan a server for web application vulnerabilities, and reveal information disclosure vulnerabilities.

If you hire someone to run a security audit on your server, ask questions beforehand, such as what scanning suites will be used,  and ask for references.  Any professional should have quite a few references, and should be able to identify the scanners that will be used against your Linux server.  In addition, ask them if after hours scanning is available, so that your business is not adversely affected by these scans.

If you have any further questions about security audits for your Linux servers, please feel free to contact me.

I’m not trying to be “that guy” that makes it seem like most admins are lazy- but most admins do overlook basic or moderate security steps.  They usually also cry out against strict security guidelines by saying that security breaks applications.  While this is true for a novice, most seasoned administrators know what to not do when securing a server.

I can’t complain too much though I guess, since admins like this give me great job security!

Here is the article:

http://linuxconsultant.info/tutorials/6-steps-to-a-more-secure-linux-server.html