PART III: BETTER THAN NOTHING SECURITY

Shamlessly grep’d from the http://www.hackerfactor.com/blog/ There be good stuff here…

Security is a measurement of risk. Nothing is ever secure, but things can be made secure enough. Most of the time, online network attacks are not personal. The attacker does not want “your site” as much as they want “a” site and yours just happened to be handy. In this regard, the typical web site does not need to be hardened like Fort Knox. It just needs to be more difficult to compromise than your neighbor. (In Colorado we have a saying: I don’t have to run faster than the bear. I just need to run faster than you.)

In my previous blog entries about minimal web server security, I discussed security by obscurity methods to deter a blind attacker.

Security in Layers

The most secure systems do not employ one security precaution. Instead, they implement layers of secure methods. The idea is that an attacker may be able to get past one level of security, but the more layers you have, the more difficult it is to break in.

For example, a secure house does not just have a lock on the door. It also has a deadbolt (a second lock). Inside are motion detectors, floor sensors, fire alarms, glass sensors, and a big dog named Hooch. But you don’t stop there… you also have a safe, and large valuables are locked down and may even have their own alarms. And even with all of this, a secure home usually employs security by obscurity: you stop mail before you leave, you have a friend pick up newspapers and packages, you leave a light on a timer and a radio playing some talk-radio show so it sounds like someone is home. Security happens in layers.

With SbO, (Security By Obscurity) you lower your threat profile by not advertising your potential risks. SbO does not block known attacks and offers nothing to patch a vulnerable system. But it does offer a layer of security. Just as you should not hang a sign on your front door that says “Out of town until next Tuesday, we have no alarm, and the backdoor is unlocked”, you shouldn’t have your web site that advertises its version and potential weaknesses.

Along with SbO, blind attackers test known vulnerabilities. By patching systems and moving default access points, the blind attacker will be unable to gain a foothold. (Kind of like the thief who places a pizza coupon on your front door. If you don’t remove the pizza offer, then he knows you are not home. But if you remove the doorknob, then he’s got no place to hang his sign.)

Looking Around

If your site does not make it easy to identify your vulnerabilities, then the only option for an attacker is to look around. Most likely, they will start with open directories. These are easy enough to find, since every web page on your site identifies the server directories.

The fastest way to find open directories comes from the images on your site. Select any image on your web site. Right-click the mouse in your browser and view the image. The image will contain the full URL. If you remove the image name from the URL, then you will access the directory. And if you can see the directory, then you are vulnerable.

For example:
The Japan Asia Financial Services Co. Ltd. is at the URL http://www.ja-fs.jp/
Their web site has an image with the URL: http://www.ja-fs.jp/img/asia_logo.gif
If you look at http://www.ja-fs.jp/img/, then you will see an open directory.

Open directories tell a lot about the site. It identifies when the files were last updated, the web server version, and suggests that other directories on the site are equally vulnerable. For example, http://www.ja-fs.jp/news/ is open. It contains temp directories and files that are not linked from anywhere else. In this case, there is even a backdoor admin page for changing their site’s content. (Ouch!)

Viewing an open directory is not hacking — because they made it public to the world. (I actually found the JA-FS open news directory from Google. I was just looking for sites that publish data and wanted to see something before it was published…)

Staying Hidden

There are two ways to deter someone from sniffing around your site. First, you can create an index file in every directory. Something as simple as an empty index.html file will block someone from finding files that should be hidden. Anyone browsing your site’s directories will simply see a blank web page. (This is what the Iranian news agencies implemented a while ago after people found hidden files and read stories before they were made public.)

A better solution is to block it in the web server. Most web servers run Apache. The default Apache installation includes a line similar to Options Indexes. (There may be multiple options listed on the line.) The Indexes parameter turns on open directory listings. If you change this to -Indexes (with a hyphen), then you will disable open directory listings on the entire server. (The Indexes option will appear in lots of places in the server configuration file. Be sure to disable it everywhere.)

If you don’t have administrative access to the web server, then it is very likely that the administrator permits you to have a .htaccess file. Put one in your top directory (or in each directory) and make sure to give it the line Options -Indexes. This will disable open directories for your account.

For the really cleaver people, you can take the next step. Disable indexes and create a static index.html file that looks like an open directory. Remember: misinformation is far more damaging to an attacker than providing no information.

Without an ability to see potential footholds, most attackers will never make progress and will eventually give up.

Better Than Nothing

Whether it is your web server, blog software, public forum, or other web-based system, the default installation is almost never very secure. Systems disclose version information, offer known footholds for blind attacks, and readily provide sensitive insight into how to best compromise your system.

With a few simple steps, you can make your system much more difficult to compromise. While this won’t make your system impervious to attack, it will make most sites secure enough. Part IV, covers more types of filtering with .htaccess files.

g33kadmin

I am a g33k, Linux blogger, developer, student and Tech Writer for Liquidweb.com/kb. My passion for all things tech drives my hunt for all the coolz. I often need a vacation after I get back from vacation....

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.