Shamlessly grep’d from the There be good stuff here…

I’ve started attending a social group of bloggers. It’s part of my mandated community outreach ordered by she-who-must-be-obeyed. (“You need to get out of the office more than once a week!”)

The group is primarily a bunch of people who are looking to use their blogs for generating revenue, advertising products, attracting customers, or building an authoritative reputation. In contrast, I’m just a hacker who uses his blog as a writing exercise.

A Different View

The group of 16-20 attendees each month consists of everyone from advertisers (one guy is a reformed mass mailer) to people who run SOHO companies, or have a particular agenda (one woman runs an autism education blog). While there are 1-2 programmers or system administrators present, I’m the only security specialist/hacker. So I always have a different take on things.

For example, one guy asked if anyone used a wiki for their content. He uses a wiki, but nobody participates. A programmer/admin suggested that wikis are frequently used in places where a forum would be better suited. Of course, I immediately jumped to security: public wiki’s are fun because you can impersonate anyone. Wikipedia knows this problem far too well.

Status Quo

Going around the room, we introduced ourselves and said if we had a blog. The advertisers and most SOHO people really had their 20-second intro down. “I am [name], my company is [company name], and my blog is http://[URL].” (My intro was nowhere near as smooth; I need to get out more often.)

As people mentioned their web sites, I brought them up on my netbook. And I was stunned. First, my web site is ugly and needs to be redesigned (I’m open to suggestions and feedback; watch for changes next year). But more importantly, a significant number of people were running default installations without any patches or hardening. While they spent a significant amount of time fine tuning their presentation, content, look, and feel, their blog software itself was simply a case of install-and-go.

(I owe K. an apology. I passed her a note saying that her blog had a security risk and was vulnerable. I didn’t mean to give her a heart attack.)

So I have decided to do a couple of blog entries on how to harden and secure your web site — regardless of whether you run a blog, wiki, forum or just have some static web pages.

Note: These tips only apply to people who installed and run their own web software. If you are using a hosted service, like Blogger and LiveJournal, then this does not apply since you are not responsible for software maintenance.

Security By Obscurity

Security by Obscurity is a term that describes security through secrecy. If you don’t tell anyone that you have a million dollars buried in your backyard, then it is “secure” because nobody will find it.

There’s a saying in the security field: Security by Obscurity (SbO) does not work. If you are vulnerable, then you are still vulnerable. You’re just hoping that nobody discovers the exploit.

In my opinion, SbO does work to a degree. While SbO should not be your only security option, it does deter pre-attack reconnaissance. For example, most automated scanners look for obvious signs that can be used to identify a vulnerable system. If the scanner finds something, then the attack will come later. However, if you remove these markings then the scanners won’t flag your site for an attack. SbO removes the “low hanging fruit”.

The first thing you want to remove is anything that denotes what software version you are running. For example, WordPress is a very popular blog software package. If the bottom of your blog says “Powered by WordPress”, then everyone knows what software you are running. Knowing “WordPress” isn’t that bad. However, WordPress also embeds the version in the HTML content. For example, the “We Love WP” site runs WordPress. If you “view source” of their web page, you will see at the top:

Now we know that they are running WordPress version 2.8.4. If you happen to know of a security vulnerability for version 2.8.4 (such as a XSS or Traceback denial-of-service), then you know that the “We Love WP” blog is vulnerable.

Similarly, the popular vBulletin web forum software includes the version at the bottom of the page and in the HTML meta data. Does the world really need to know that the Graphic Forums uses version 3.6.1?

So the first thing to do (regardless of whether you know of a vulnerability or not): remove all information about software and version from your site. This includes information embedded in your HTML pages and RSS feeds. Where to do the change depends on your software. With blogs, it is usually in the custom template, default template, or PHP/ASP pages. You probably don’t need to change every single web page — but you will probably need to change it in a few places.

This won’t stop someone from attacking you and does not close the security hole. What it does do: this prevents automatic scanners (and casual observers) from quickly determining that you are vulnerable. (Congratulations, you are no longer the lowest hanging fruit and most likely to be attacked.)

For the really creative types out there, don’t just remove it. Change it! Misinformation is far more damaging to an attacker than no information. Rather than removing the “Powered by WordPress”, change it to say “Powered by Serendipity” — a totally different blog package, or just lie: BlogProKit 9.8.1. Now if someone if going to attack you, then they will initially do so with the wrong set of exploits.


Shamlessly grep’d from the There be good stuff here…

I’m not an electrician. While I am pretty confident that I can change a light bulb or plug something into an outlet, adding a new electrical outlet or installing a new light into the ceiling of my office is beyond my skill set.

Much of the software on the Internet is like the ceiling light in my office. Regular users know how to push the install button, configure colors, edit blog entries, start new forum topics, and even add in plugins. However, your typical user cannot develop a new plugin or know how to do much more than use the software as it was intended. (They are users, after all.)

The problem is, default installations are usually not secure installations. Even if there are no known vulnerabilities, new ones are discovered every day. Software that is secure today may not be secure tomorrow.

In my previous blog entry I wrote about a really simple way to lower your threat profile. By hiding the software version, you deter automated systems that scan for vulnerable systems. However, hiding your version doesn’t stop blind attacks.

The Blind Attacker

When attacking a system, most people follow Sun Tzu’s The Art of War: Know your enemy. This means conducting reconnaissance before attacking. With a blind attacker, they forgo reconnaissance. A blind attacker will try an exploit and then check to see if it worked — without first looking to see what they are attacking.

On the Internet, most attacks are performed by automated software; they are not manual. Automated blind attacks are the most common type of attacks. At any given moment, hundreds of thousands of computers are infected with malware and slinging attacks blindly across the Internet. Usually you won’t notice because the attack wasn’t appropriate for your system, but every now and then a blind attack succeeds. (It’s the spaghetti test method: If you throw enough noodles against the wall, something might stick.)

Methods like hiding your software version won’t stop a blind attacker. So we need to do something more.


It might sound obvious, but you need to periodically patch and update your software. Unlike your PC, your blog, wiki, and online forum software probably does not have an auto-update feature. Patching and upgrading your web software is like changing the oil in your car. If you don’t do it periodically, then it isn’t a question of “if” it will fail; it will fail. The only question is “when”.

Most popular web software packages have lists of updates and changes. WordPress has their security and release information in blog format, as does Serendipity. Docuwiki keeps a list of changes, and MediaWiki uses a low-volume mailing list to actively keep users advised of changes.

How often to patch is up to you. If you change your car’s oil every three months, then that sounds like a good minimum effort. If you run a high-volume site, then monthly or weekly is probably good. And if you run a massive site, like Amazon or Wikipedia, or consider your site to be mission critical (or run a high target site, like a security geek who blogs about security tips), then daily checks with scheduled updates is definitely the way to go.

Finally, if you choose not to patch, then you should have a good reason beyond “it isn’t convenient”, “it’s too much work”, or “I don’t know how”. And frankly, there are not many good reasons. (If your wrote your own code, if you have undergone a government Orange Book (TCSEC) audit and have received an A1 rating, if your system is not on the Internet, or if you have enough security layers that a direct attack is improbable, then you can delay patching. Otherwise, you must remain vigilant.)

Moving Footholds

While patching will stop attacks that are known, it won’t stop an 0-day exploit. A zero-day (or oh-day) vulnerability is one in which there is no patch currently available. (The count refers to the number of days after the vendor starts working on a patch. No patch means day zero.) Patching also won’t help you during the time between when a patch exists and when you apply it.

Blind attackers succeed because they know about a vulnerability and how vulnerable systems are configured. To stop blind attackers, you just need to change the system enough that it looks different from the expected configuration. The attacker looks for a foothold, and fails to make contact.

Common footholds come from CGI scripts that process user input. If your PHP or ASP web page has a form on it, or allows users to select dynamic content (not a static HTML page), then that is a potential foothold. To make the system look different, we just need to remove the target.

As with other forms of Security by Obscurity (SbO), this doesn’t remove the vulnerability. However, this approach is great for stopping blind attackers.

Don’t Ask, Don’t Tell

One common type of attack is to go after login pages. If you can guess the login, then you can gain access to the system. Blogs, wikis, and other web software usually have login links on the page. This allows the administrator to get into the system and modify content.

The typical SbO approach is to hide the login link. This way, humans won’t stumble across it. Frankly, unless you expect lots of other people (“lots” meaning “all of your customers”) to login, there is no reason for this to be public. Copy the login URL to your web browser’s bookmarks, and then remove the login link from your page.

For example, the City of Albert Lea, Minnesota uses WordPress 2.8.4 (found in the the source of their HTML content). At the bottom of their web site is a Log in link. There is no reason for the general public to see this link. Having it present is an attractive nuisance.

If the bare minimum you can do is to remove the hyperlink, then the intermediate solution is to move the link. If your link is, then rename “wp-login.php” to something else (e.g., supersecret-login.php). Now attackers don’t see the link (because you took it off your page) and if they take a wild guess then they will guess wrong. For WordPress users, you can find a great writeup of files to rename at the blog Peter’s Useful Crap.

For the really advanced users who don’t have any/many remote users with login access, you’ll need to do a little programming. Keep a list of network addresses that are permitted to connect to the login page. Modify the login script to make sure that the user is coming from a permitted network address. This introduces two-part authentication: something you know (your password, the URL to the login page), and something you have (your network address). Even if some malware infects your computer and sends your password to Russia, the Russians won’t be able to login to your site from a remote location.

With this advanced tip, you begin to lock down your site. Even if an attacker knows the URL to the login page, they cannot login because they will be coming from the wrong network address. Of course, you won’t be able to login from a coffee shop, but I view this as a good thing — coffee shops are usually not secure network connections. (Which is more important: your company’s reputation and web site’s security, or your mocha latte frappachino grande?)

Remove Default Samples

Most software packages include sample scripts and templates that are used to illustrate various features or configuration options. Remove these examples. If you’re going to use the features, then use them in your customized templates or personalized pages. You don’t need the example files on a live (Internet accessible) server. The only thing these examples do: they provide potential footholds for blind attackers.

For example, currently has the default installation page for the Apache web server. This includes all of the manuals for Apache and some of the default CGI scripts. This server has not been configured, so if you happen to know an exploit for an unconfigured Apache server, then this is a good target. However, if the owner did configure the main web page, they might still forget to remove the default documentation and scripts. It only takes one exploit of a default file to take over a system.

For a couple of years, security guru Johnny Long maintained Google Hacking Database (GHDB). Using Google, he searched for standard files and default configurations that are vulnerable to everything from information leakage to cruel exploits. Although the GHDB is no longer maintained, it still serves as an excellent example for why you should not keep default sample scripts and templates sitting around on a publicly accessible server. (GHDB contained much more than exploits from default scripts, but we’ll get to system hardening in a bit.)

Next Up?

When I follow up with simple system hardening next Tuesday, I will dive into some lockdown options. Some of this information will also be covered at my up-coming “Fort Collins Internet Pros” presentation on the 16th — “Htaccess configurations and turning your htaccess file into an application firewall.”


Shamlessly grep’d from the 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
Their web site has an image with the URL:
If you look at, 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, 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.


Shamlessly grep’d from the There be good stuff here…

In my last three entries about minimal web server security, I covered security by obscurity methods to deter a blind attacker and very basic methods to prevent unintentional information disclosure by blocking open directory browsing.

The best solution to prevent open directory browsing is simply turn it off. Using a .htaccess file and setting Options -Indexes, you block undesirable directory browsing. However, the .htaccess file can do much more than just disabling directory indexing.

(The following examples are part of a presentation I gave earlier this week for the Fort Collins Internet Professional’s Technical Track.)

Redirecting Errors

When you use Options -Indexes, requests for the open directory will return a server error (403 Forbidden). However, you might want to return a nicer error code. Using your .htaccess file, you can catch and redirect errors to an HTML page or return simple HTML. For example:
ErrorDocument 403 /403.html

ErrorDocument 404 “That page was not found.”

ErrorDocument 401 /login/unauthorized.cgi

You can also redirect based on substring matches. For example:
RedirectMatch 301 (.*/secret.txt) /~user/block.cgi?$1
The extended regular expression “(.*/secret.txt)” is a little cryptic. It says to look for any substring in the URL that contains “/secret.txt”. It then redirects the user to a CGI web page and appends the offending URL to the query for the CGI.

Blocking Attacks

The .htaccess file allows you to define variables and then use the variables as conditionals. For example, my blog should not have any kind of quotes in the URL. If someone submits a quote, then they are likely trying to attack my site with an SQL or CGI injection attack. By defining a few environment variables, I can detect and block potential attacks long before they ever get to my blog software (and potentially compromise my site).

SetEnvIf Request_URI "'" bad_bot=1

SetEnvIf Request_URI '"' bad_bot=1

SetEnvIf Request_URI '`' bad_bot=1

SetEnvIf Request_URI '%22' bad_bot=1

SetEnvIf Request_URI '%27' bad_bot=1

SetEnvIf Request_URI '%60' bad_bot=1

Order Allow,Deny

Allow from all

Deny from env=bad_bot

The first part sets an environment variable called “bad_bot” if any kind of quote is seen in the URI. (The URI is the part of the URL that comes after the hostname and before any question mark.)

The second part limits who can access the web site. If you do a HEAD, GET, or POST request, and you include a quote in the URI, then you are blocked. Since casual/friendly users don’t include quotes in the URL, this is not a problem for regular visitors.

Other characters you might want to block include < , >, $, !, and the backslash (\).

Depending on your site, you might even want to block them from query strings (everything after the question mark). To do this requires the mod_rewrite engine.

RewriteEngine on

RewriteCond %{THE_REQUEST} .*['"`!$<>;].* [OR]

RewriteCond %{THE_REQUEST} .*%22.* [NC,OR]

RewriteCond %{THE_REQUEST} .*%27.* [NC,OR]

RewriteCond %{THE_REQUEST} .*%60.* [NC,OR]

RewriteCond %{THE_REQUEST} .*%3C.* [NC,OR]

RewriteCond %{THE_REQUEST} .*%3E.* [NC,OR]

RewriteCond %{THE_REQUEST} .*%3B.*

RewriteRule $ - [l,F]

This looks for any of the forbidden characters in the entire HTTP request and fails access if any are seen.

Stopping Undesirables

Attacks can be technical or political. For example, let’s say you don’t want people to hyperlink to images on your site. How do you stop them? The answer is to look for the referrer (spelled “referer”). If the referrer for the image does not come from your site, then someone is cross-linking to you. In this example, we look for any jpeg, gif, png, or bmp request that was not linked from my site. If one is found, then a CGI script is called. Ideally, the script will generate an image that is the correct size but contains a nasty message about cross-linking.

# Identify if a Referer is used

SetEnvIf Referer "^" from_me=1

SetEnvIf Referer "^" from_me=1

SetEnvIf Request_URI .jpg has_image=1

SetEnvIf Request_URI .gif has_image=1

SetEnvIf Request_URI .png has_image=1

SetEnvIf Request_URI .bmp has_image=1

RewriteEngine on

RewriteCond %{env:has_image} 1

RewriteCond %{env:from_me} !1

RewriteRule (.*) /block_image_theft.php [l]

Of course, the most annoying type of undesirable visitor are those spam-bots. If you are a web master, then you know what I am talking about. They find forms on your site and submit tons of spam. Since many of these bots don’t use a referer, we can block posts that lack a referrer.

# Identify if a Referer is used

SetEnvIf Referer "^$" no_referer=1

Order Allow,Deny

Allow from all

Deny from env=no_referer

Not Too Bad

With a little practice, your .htaccess file can block potential attacks against your web site. A well-configured .htaccess can deter undesirable visitors, protect you from potential exploits, and enhance your site’s usability by returning informative error messages.

Delete Files Older Than x Days on Linux

The find utility on linux allows you to pass in a bunch of interesting arguments, including one to execute another command on each file. We’ll use this in order to figure out what files are older than a certain number of days, and then use the rm command to delete them.

Command Syntax

find /path/to/files* -mtime +5 -exec rm {} \;

Note that there are spaces between rm, {}, and \;


The first argument is the path to the files. This can be a path, a directory, or a wildcard as in the example above. I would recommend using the full path, and make sure that you run the command without the exec rm to make sure you are getting the right results.
The second argument, -mtime, is used to specify the number of days old that the file is. If you enter +5, it will find files older than 5 days.
The third argument, -exec, allows you to pass in a command such as rm. The {} \; at the end is required to end the command.
This should work on Ubuntu, Suse, Redhat, or pretty much any version of linux.

Access MySQL remotely via SSH

From Yahoo answers
So you’ve got MySQL on your web server, but it’s only opened to local ports by default for security reasons. If you want to access your database from a client tool like the MySQL Query Browser, normally you’d have to open up access from your local IP address… but that’s not nearly as secure.

So instead, we’ll just use port-forwarding through an SSH tunnel, so your MySQL client thinks it’s connecting to your localhost machine, but it’s really connecting to the other server through the tunnel.

If you are using the command line ssh, the command would look like this. (You can do the same thing graphically in Putty or SecureCRT options if you need to)

ssh -L 3306:localhost:3306

The syntax is ssh -L hostname @. We’re using localhost as the hostname because we are directly accessing the remote mysql server through ssh. You could also use this technique to port-forward through one ssh server to another server.

If you already have mysql running on your local machine then you can use a different local port for the port-forwarding, and just set your client tools to access MySQL on a different port.

Once you’ve got the ssh tunnel going, you can open up MySQL Query Browser and enter in the details for your remote server, using localhost as the server host, and adjust the port to whatever you used.

Once you get used to this method, you’ll wonder why you ever used phpmyadmin or the command line version.

WHM Email Relayers issue

When you check the email relayers option within WHM then it shows empty. You can try the following change on your server. Using pico or vim

pico /etc/passwd

and search for the following entry.


Change it to


Restart the eximstats on the server,


The email relayers should now be visible within WHM.

Password protect a directory

If you would like to password protect a directory, create a .htaccess file in a directory which you wish to protect and insert the following parameters:

AuthUserFile /home/username/.htpasswd
AuthGroupFile /dev/null
AuthName “Private Area”
AuthType Basic

require valid-user


replace the “username” with the actual username. Create a .htpasswd file and place the username/password in the following format:


You can place as many users you wish in the .htpasswd file


What is “SSH: POSSIBLE BREAK-IN ATTEMPT!”? You may receive such a warning message when you SSH to a remote host. It is not as threatening as it sounds. When you SSH to a host, a series of checks are made to make sure you are connecting to the host you are expecting to connect to. SSH does a reverse mapping on the IP you are connecting to, to see if the hostname of that server is pointing to the same IP, if it isn’t, you will see the warning message “reverse mapping checking getaddrinfo for … POSSIBLE BREAK-IN ATTEMPT!”

For example, when you try to SSH to a host, you will enter something like:

ssh root@

and see something like:

Connecting to
reverse mapping checking getaddrinfo for failed - POSSIBLE BREAK-IN ATTEMPT!’s password:

You can see above that we are connecting to the IP whose hostname is, which isn’t pointing back to the IP resulting in a warning message. Same applies the other way round, if you try to SSH to the hostname i.e. “” who’s IP is, it check the reverse DNS of the IP and if it isn’t pointing back to “”, you will receive the warning message.

If you see the “POSSIBLE BREAK-IN ATTEMPT!” messages in your auth.log file it can mean someone may be trying to brute force in and you should take necessary steps to tighten the security of your server.

Kernel Support for 4GB+ RAM

If you have 4 GB or more RAM on a Linux server, it may not show up the in the server. In this case you need to install PAE kernel package. This kernel package will support upto 64GB of memory. The non-PAE kernel can only address up to 4GB of memory. You can install the kernel-PAE package if you have more than 4GB of RAM. Use the yum command to install the package:

yum install kernel-PAE

This will install the package and in order for the changes to take affect, you need to reboot your server with the following command:


Once the server is online, you can check the physical memory on your server using:

free -m