Last week we discussed why retail organizations must consider web application security when hosting an ecommerce site. Now I would like to provide some tips on how to provide secure access to web application servers.
Firewalls and IPS systems still have their place and can help guard against simple exploits and Denial of Service attacks. To properly protect valuable web application servers though, an actual Web Application Firewall should also be used. A WAF works by examining the application layer to protect against common web server attacks such as cross site scripting and SQL injection attacks. These types of attacks are not caught by standard firewalls and IPS solutions, and most WAF's also function as a reverse proxy. This has the added benefit of making sure traffic from the Internet is not just 'passed' through to your servers, but is instead stopped at the WAF where a new connection is made on its behalf. This has the additional benefit of allowing for other advanced features such as malware scanning, and SSL offloading. Note that if credit cards numbers are processed on your web server you probably fall under PCI regulations, and may be required to have either a Web Application Firewall, or a code review to ensure you're not susceptible to common exploits.
In addition to having a WAF you can also try to protect your web servers using a few other techniques such as:
Separation of resources
Install web application servers in a protected DMZ which has no access to the local LAN or internal users. This prevents opening up the entire organization to threats should a successful exploit occur.
Know your network and how it appears to others
Review what information is available to would be attackers. The less unintended information available, the better. Review public DNS records to ensure only valid corporate information is available and no personal employee information is listed. Attackers may use public information about an organization and its employees to help launch a socially engineered attack. Check web server responses to make sure information about Operating System, application used, etc. are not available. Review error pages to ensure no useful information is given out such as local machine name or directory structure.
Limit responses to probes/errors
Eliminate bad requests instead of just responding to them. This cuts down on the information provided, and helps to avoid filling up logs which could result in a resource issue or downed server.
Monitor logs and reports for signs of anomalies, attackers, etc... Are the same IP's constantly probing your system? Do you constantly see the IPS reporting ISS exploits? Knowing what others are doing is important so you can ensure your defenses are sufficient. It may also help you spot things you missed in your network review.
User NMAP and other tools ensure only allowed ports are available. Understanding what ports are open on web servers, and what IPs are visible via the internet is important in understanding your environment. Ideally you want to deny all traffic and only allow specific ports/applications to and from your servers.
Another tactic may be to use probing information to your advantage. Using decoy names and information in public records and for error messages are 2 examples. If you find someone trying to contact that fake name or attacks are launched based on that misleading info, it can confirm when someone is probing your defenses. Deploying a honey-pot is another method so that you can further analyze intrusion attempts. Be careful with this method though as it may invite more aggressive attacks when attackers find out they've been fooled.