Configuring Your Server for IE 8

Originally posted on Web Pro World.

Microsoft Internet Explorer 8 is designed to be more standards compliant than previous versions. As a result, certain hacks in web sites can cause those sites to display incorrectly in Internet Explorer 8. This can be addressed by forcing browsers to render your site in what is called "compatibility mode". The following instructions detail how to enable compatibility mode site wide, if your site is hosted on an Apache server.

Setting Compatibility Mode for all visitors on Apache

Enabling compatibility mode on an Apache server requires the ability to create and edit .htaccess files, and mod_headers must be installed on the server. Most shared and dedicated hosting plans should allow this.

Simply add the following line to your .htaccess file.
Code:

Header set X-UA-Compatible "IE=EmulateIE7"

Setting Compatibility Mode for everyone but the webmaster

If you will be testing your site, and want your own browser to work without compatibility mode, you can specify certain IP addresses that will not be shown the header.

First, create a list of IP addresses that should not have compatibility mode. Add the following line to the .htaccess file, changing 1.2.3.4 to the appropriate address. Each IP address would require a seperate line.

SetEnvIf Remote_Addr 1.2.3.4 webmaster

This assigns the code "webmaster" to each specified IP address. Now, you would add the compatability header, telling it to display if the visitor has not been given the "webmaster" code. This is done by adding the following line to the .htaccess file after the lines you added above.

Header set X-UA-Compatible "IE=EmulateIE7" env=!webmaster

Everyone not from the specified IP address will be put in compatibility mode by default. Those visiting the site from the specified IP address(es) can enable compatibility if they want, but it will be disabled by default.

Setting Compatibility Mode on IIS 7

If you have administrative access to your IIS server, you can add new headers by following the instructions here: IIS 7.0: Add a Custom HTTP Response Header

The name you need to specify is "X-UA-Compatible" and the value is "IE=EmulateIE7" (without the quotes).

Setting Compatibility Mode on other platforms

If you can not use the above method for any reason, you can add compatibility mode to each page by adding the following meta tag:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

Hiding Server Version Information

The less information an attacker has about a system, the more work that attacker has to do to find possible exploits, and the more chances Intrusion Detection Systems, firewalls and administrators have to detect the attack and stop it.

Given the version numbers of services running on a Web server, an attacker has an advantage in that the attacker can simply look up known vulnerabilities for that software and immediately attack them, without tipping off defensive systems with unsuccessful attempts. If the version numbers are hidden, the attacker has to guess, and try a variety of attacks, any of which might activate defensive systems running on the server. The following steps will allow webmasters to remove certain identifying information from Linux based servers. Some of these steps may not work on shared web hosts.

How the Information is Found

Before we go into hiding the information, it may be helpful to briefly discuss how an attacker finds the information in question. When a file is requested from a web server, the server attaches information about the document, called "headers", to the file. These headers contain information about the server software and the communication protocols involved in transmitting the document. This information is hidden from most web users, but can be viewed using various browser plugins, such as Live HTTP Headers for Firefox. The following are some sample headers that a web site might send when serving a page to a user:

1. HTTP/1.1 200 OK
2. Date: Tue, 24 Mar 2009 14:44:38 GMT
3. Server: Apache/2.0.55 (FreeBSD) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
4. X-Powered-By: PHP/5.1.2
5. Expires: Thu, 19 Nov 1981 08:52:00 GMT
6. Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
7. Pragma: no-cache
8. Connection: close
9. Transfer-Encoding: chunked
10. Content-Type: text/html; charset=ISO-8859-1
11. Content-Language: en-us

The important lines are 3 and 4, which contain the server and PHP version numbers. These give a potential attacker information about the Apache server, PHP engine and operating system.

Hiding the Information

The first step is to hide the Operating System information and Apache version numbers. This is very easy to do, and only requires the addition of a single line to the server configuration file or .htaccess file:

ServerTokens Prod

That simple line will change line 3 above into the following:

3. Server: Apache

That's it.

The next step is to hide the information about PHP. That is slightly more difficult. The following line in the server configuration file or .htaccess file will remove line 4 in the above example completely:

Header unset X-Powered-By

Using this directive requires that the mod_headers package be installed and enabled in Apache. In most systems, the module will be available.

Of course, if you really wanted to get tricky, you could add some fun headers as well.

Header set X-AspNet-Version "2.0.50727"
Header set X-Powered-By "ASP.NET"

This would make the server look to an attacker as though it were running ASP on a Linux system (which is not very likely).

Protect Your Site By Hacking It

I frequently see comments on various security forums from webmasters after a compromise wondering how their sites could possibly have been attacked. In discussions with some of the webmasters that have been affected with some of these issues, I have found that most are unaware of simple and free steps that can be taken to help protect a web site. This is purely preventative, but when it comes to web site security, prevention is the most important element.
DISCLAIMER: This information is for educational purposes only. Check with your hosting company before using ANY of the software I mention to ensure it is allowed under their policies. Any misuse of this information, and any damage resulting from your use of this information is solely your responsibility.
One of the simplest and most important things to do is make sure you are on the mailing list for every piece of third party software you use so you know about security patches as soon as they are released. It is important to keep the software on your site up to date.
The next thing to do is hack your server. There are a few tools that malicious users use to find ways of gaining access to a web server. By using these tools yourself, you can find many of the same problems before you are attacked. Nessus is the most commonly used tool for finding vulnerable software on the Internet. In fact, this program forms the basis of most commercial vulnerability scanners and is available for free. Nessus can be downloaded from http://www.nessus.org/ although you need to register (for free) to get the program and updates. You want to download these updates so that every time you use the scanner it looks for the most recently known vulnerabilities.
Finally, there is a range of attacks that are hand coded. In most cases, these attacks are done by editing the requests sent to your server. This can be accomplished in two ways. The easiest is to install a Firefox plug-in (if you use Firefox) called HackBar. This can be installed from the Firefox plug-in library or by searching Google. This software allows you to edit the requests you send to a web server to test how well the server and scripts validate incoming data, while bypassing any security features of the web browser and any JavaScript validation. The other method is to install a proxy program called Paros Proxy. This program enables you to change the data being sent between your browser and the remote server, as well as seeing the raw data. This tool is also useful for testing redirects. A few searches on the web for “cross site scripting,” “SQL injection” and “buffer overflow” should give you plenty of ideas of things to try. This is the best way to test scripts that you have created yourself to ensure that those scripts are as secure as possible.
One often overlooked element of web site security is the validation of input on web forms. Javascript is useless for validating input, as the previous paragraph shows two easy ways to get around it. Your scripts should follow a simple formula: trust nothing, validate everything.
Bear in mind, all of the technology I describe is intended to demonstrate possible problems. This will not fix any issues. However, you should be able to find where you are vulnerable and make the appropriate corrections. Obviously this is no replacement for a full security analysis, but this will give you a starting point. Also, note that these methods are less likely to find security issues in custom made scripts. For that, you should consult a security consultant or a programmer who has experience securing applications in whatever programming language you are using.

Securing a Server

The Problem

Simply put, the Internet is a dangerous place, and you (presumably) have a web server. Web servers, by default, are relatively insecure, presenting potential attackers with a variety of attack vectors (an "attack vector" is a way to attack a server or application). Fortunately, depending on your needs, it is usually easy to properly secure your server. For this example, we will be assuming you are using a Linux based server, and you are responsible for making sure that the server is as secure as possible.

The Attack

To understand how to secure your server, you have to have some understanding of how someone would perform the attack. This description is going to be based on someone who has located and targeted your server specifically, although most of what I talk about would also apply to a script kiddie doing general searches who happens to find your server.
The first step in attacking a server is to gather intelligence. The more you know about a server, the better able you are to find it's weaknesses and exploit them. The first step is to scan the ports on the server. Every application that allows external software to connect to it is called a service, and every service listens on a port for incoming connections. In this way, the operating system on the server can route incoming connections to the correct service/application. For example, if you have an Apache web server installed and listening for connections, it typically binds to port 80. When a browser requests a page from the server, the request goes to port 80.
A port scanner requests data from every port (or from selected ports) on the server. Based on the responses, an attacker can determine exactly what ports are listening for connections, and thus what services are installed on the server.
Once the services running on the server have been identified, the attacker then exploits known weaknesses in those services. Every service should be secured on it's own, and individual services are outside the scope of this article, but some important services are Telnet, FTP and HTTP. Your server will, under most configurations, allow connections to these ports, whether such access is needed or not, trusting the application's own security.

The Defense

The first step in protecting your server is with the firewall. A properly configured firewall will not allow incoming requests on any port that is not absolutely required. For example, a server being used to serve web sites typically only needs a few ports to be available to the public (80 and 443 for the web server, and 21 for FTP). Other ports may be required for administrative access, such as port 20 or 22 for remote command line functionality, or port 10000 for access to a web based control panel. The firewall should only allow traffic to these ports from IP addresses that are known to be trustworthy.
Next, if possible, an intrusion detection system should be installed. These applications detect suspicious behavior and block it at the firewall level. Hardware IDS devices are best, as they block the traffic before it ever reaches the server, but if that is not possible, software IDS systems can be very effective as well. The reporting functions can be invaluable if the server is ever successfully attacked, and most possible attacks will be thwarted before they ever threaten the security of the server.

Security in a Shared Space

The Problem

When your network is located in a facility where you are the only business, physical security is easy. You can be reasonably sure that the only way someone can compromise your network is by defeating your perimeter defenses. Frequent scans, effective antivirus and properly configured firewalls and IDS software should be sufficient to secure such a network.
When your network is in a shared location, such as an office building, it is more difficult to ensure that your wired network is fully secure. This is because in many shared spaces network cabling runs through the offices of other companies. In addition, network resources such as servers and routers may be located in shared server rooms.

The Attack

There are two different types of attacks that are unique to a shared space. The first is unauthorized access to a server located in a shared server room. This probably presents the greatest risk because the attacker is able to access all of the resources on the server and may be able to install backdoors or other malware on the server.
The second type of attack is tapping, where a network cable passing through another business's space is cut, and a router is installed on the line. This would allow additional computers to be connected to the network.

Detection

The only way to detect unauthorized access to a network device in a shared location is log analysis. For example, a script should be created that transfers the authentication log (which records login attempts) to another location. This exported log file should then be reviewed frequently for suspicious activity. The server should also be checked to ensure that only required users have the ability to log on, and unauthenticated or guest accounts are disabled.
Detection of tapping is more difficult. Periodic scans should be performed to look for unexpected devices. These scans should include thorough port scans that will scan the IP in question even if a ping is unsuccessful.

Prevention

The only way to prevent unauthorized access to a resource in a shared area is to lock the resource any time it is left unattended. The passwords should also be checked to ensure they are complex to protect against brute force attacks.
Tapping is impossible to prevent. However, the damage potential could be minimized or eliminated. First, routers and firewalls on the network should be, if possible, set to only allow traffic from devices with certain known mac addresses. This will prevent most attackers from accessing any resources on the network. Second, no resource on the network should be accessible to unauthenticated users, and all passwords on the network should be complex. Although an attacker would be able to use the network connection until a scan detects their access, they will not be able to gain access to the network's resources. Finally, regular scans should be run on outgoing traffic through the router. This will reveal the presence of any unauthorized devices.

What To Do if you have been Hacked or Infected

Although I am writing this primarily for home computer users, many of the same principles apply for business networks. However, in a business environment, your IT department should handle cleaning the infection and checking the network for additional problems.

The Symptoms

How do you know if your computer has been compromised? It may be obvious - your computer might be displaying the incorrect pages when you browse the web, or it may be more subtle - your computer may be running slowly. I have had some friends tell me recently that their web-based accounts were hacked, but had not been accessed from any computer other than their own (possible keylogger).

Cleansing

The first step is to remove any and all hostile software that may be on your computer. This includes viruses if you have been infected, and backdoors if you have been hacked. If your computer is compromised, assume that your antivirus software was compromised as well. Uninstall it. From a clean (unaffected) computer, download the latest version of Avast Antivirus, AVG, or whatever antivirus software you have a license for, and burn the software onto a CD. From the CD, install the software on the affected computer. Update the software, run a full scan, reboot, scan again, until you are clear.

Securing

Once your computer is clean, you will need to secure the computer so this does not happen again. Download and install a high end firewall application (if you are looking for something free, Zone Alarm is one of the best free firewalls). Also, find and install a quality anti-spyware application.

Mitigation

Now that your computer is cleaned up and secured, it is time to mitigate the damage that could have been caused by the compromise. The first step is to secure your network. If you have any computers on the same network as the compromised computer, uninstall and reinstall the antivirus software, and rescan those systems to make sure any viruses were not transferred between systems. Also, any external backup media you use MUST be scanned before it is reused.
Finally, change all of your passwords on the compromised system, as well as all passwords that you used while using that computer. This includes all web-based e-mail systems such as GMail, social networks like Facebook and MySpace, your bank if you use online banking, etc. If your PIN number for any of your credit cards was on the computer, change the pin number. If any of your credit card numbers were stored on the computer, notify the banks that issued the cards.

Onion Security

Onion Security is a methodology for securing a network in layers, like an onion. This type of security approach helps keep the network insulated against attacks.

The problem

You have a medium to large network, consisting of internal workstations and externally accessible servers. There are multiple vectors of attack available to a determined attacker.
Most networks rely on security measures such as perimeter firewalls to protect the entire network. In an environment where new vulnerabilities are being discovered daily, such an approach is ineffective. If you rely on a firewall, for example, and a network user visits a compromised web site, and is infected by a virus, the attacker now has a way around the perimeter defenses. Once the perimeter is breached, what protects the remaining resources on the network?

The Solution

Onion security is implemented by securing every resource on the network. This includes strong perimeter security measures as well as strong internal protection. Of course, every workstation and server should have effective and up to date anti-virus software, but in addition each workstation should have it’s own software based firewall. Most of the workstations on your network do not need to be able to communicate directly with one another. The firewalls should limit communication between workstations, and only allow communication with servers. This should help limit the spread of viruses and intrusions to the network.
Access to server resources such as shared files should also be limited. Financial information should only be accessible to users in the Finance department, for example, and marketing files should only be accessible to marketing personnel. In this way, a compromise can be further controlled. If a marketing computer is compromised, for example, the attacker cannot access anything from the finance department. This provides yet another layer of protection.