HOME
In Our Opinion
Writing Code
How To
The Command Line
Hack It Yourself
Security Everything
Linux Distributions
Mr-Oss's Store
News Feeds
News
Links
Blog
HOME
Taking Away Tools PDF Print E-mail
Written by Mr-Oss   
Sunday, 18 January 2009

Image

Taking Away Tools

When it comes to your production systems security is a constantly evolving beast that keeps system administrators awake at night.  Though the only way to truly secure a computer system is to unplug it and put it in a locked room, there are other things you can do to help protect your systems from unauthorized access.

Image

There is an unlimited  number of things that a system administrator can do to help secure the systems they are employed to defend.  Port scanning, application testing, & vulnerability analysis are just a few activities which can be performed on systems to help protect them from potential covert access channels.  Others might include user access controls, firewall restrictions, and even disk encryption.  There are other tricks which sys admins can use to help lower the impact of threats before the are exploited into elevated system level account access.

Taking tools away on production systems is a simple way to make unwanted hackers lives a little more difficult.  The so called tools that I am referring to in this instance would be things like compilers.  On production systems it is good practice to NOT install C compilers.  The reason for doing this is to make the life of a would be hacker that much harder when it comes to accessing your systems.  

For example, say you have an apache server with php and someone figures out how to send simple commands to your server.  These commands would then get executed with the level of access that was allocated to your webserver user that Apache is running as.  So if you have an httpd user who started apache somehow php is letting commands through into your system.  The XSS hacker then proceeds with telling your system to download the latest exploit code for a local user buffer overflow.  The code is pulled down onto your system via php XSS exploit and parked in /tmp because /tmp is typically writable for everyone and is a working path. 

Next, the hacker uncompresses the source code and attempts to compile the overflow.  At this point, they are presented with a new challenge.  Compiling exploit code on a system without a compiler.  Sometimes, this can be enough to thwart the fumbling attempts of script kiddies or even deter other hackers from caring enough to keep trying.  They might pass over your system and on to the next.  This technique does not however protect you completely.  If a hacker is truly skilled and is out to get you then the use of the STATIC flag when compiling the exploit on their local machine could be utilized.  Then once they have statically linked and compiled the application, they download the binary as opposed to the source code.  The exploit could then still be used against your system.

 Taking away tools should not be your final answer to system protection but you might want to put it on your list.  If you need to compile something from source, simply install the compiler and compile your program.  Once you are finished, remove the compiler again from your server.  This will only slow down a determined individual but it might be just enough of a headache that nobody wants to mess with it.  It's hard to build a house without the proper tools and the same is true when it comes to rooting a server.  Enough little headaches like these and hackers get more than they bargained for.  Taking away tools for others to use against you is good practice and I would encourage anyone with a production system to take the tools away.

 

 
< Prev   Next >