Posts Tagged ‘server security’

Securing eXtplorer

Friday, March 11th, 2011

As mentioned in my previous blog post, Cool Web-Based Software- eXtplorer, eXtplorer is an excellent online file manager solution that has a great set of features. While I was examining eXtplorer’s potential to be used in an Offsite Linux Server Backup service, I did find several drawbacks to the software. In particular, two features needed to be disabled, in order for eXtplorer to be used in a shared environment.

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

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 disable about page

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.







extplorer's new file/directory button disabled

New File/Directory (Disabled)

Once we have made these modifications, we now need to tell our users that these two features no longer work. We can do this a few ways- my favorite is to edit the images for the buttons on the menu (located in the images directory). The image that controls the New File/Directory image is named ” _filenew.png”, and the image that controls the About image is named ” _help.png”. By the time that you are done, you should have a navigational bar that appears close to the image on the left.

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.

The Importance of a Linux Server Security Audit

Tuesday, May 4th, 2010

A security audit is probably one of the least requested services that I perform, and for a good reason.  Truth be told, most of my clients don’t think about security when it comes to their Linux server.  After all, Linux is an extremely stable and secure Operating System.  Assuming that some sort of basic Linux server maintenance is being performed, the server should be safe from most types of root compromises.  However, server maintenance usually won’t protect your server from the more popular web application attacks.

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.

New Tutorial- Six Steps to a More Secure Linux Server

Monday, June 15th, 2009

I wrote a new tutorial on my website about how to easily secure your Linux server today.  The article is designed to point out the more common security flaws present in most of the servers that I work on (all of them easily fixed), in the hopes that more “administrators” and “consultants” will advise their clients to implement them.

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