Protecting Against Web Attacks
| < Day Day Up > |
| Protecting against web attacks can be a time-consuming task. You must protect all aspects of your system, from the operating system to the network architecture. Following are some of the areas that you need to secure:
Securing the Operating SystemInitial operating system selection for your web server is fairly important, and Linux and FreeBSD are some of the best and possibly the most secure after a base install. Like Microsoft servers, however, Linux and FreeBSD can remain unconfigured yet still be deployed to perform the task of a secure web server. This is a common problem with multipurpose operating systems today, where dozens of services and applications might be accidentally left on. A perfect web server system has only one application running on it: the web application itself, such as IIS or Apache. To demonstrate the problem, take a look using the netstat command on a standard Windows 2003 Server hosting IIS. Example 7-18 shows that several applications are running and listening on ports. Example 7-18. Netstat OutputC:\>netstat -a -n Active Connections Proto Local Address Foreign Address State TCP 0.0.0.0:23 0.0.0.0:0 LISTENING TCP 0.0.0.0:53 0.0.0.0:0 LISTENING TCP 0.0.0.0:135 0.0.0.0:0 LISTENING TCP 0.0.0.0:445 0.0.0.0:0 LISTENING TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING TCP 0.0.0.0:1029 0.0.0.0:0 LISTENING TCP 0.0.0.0:1031 0.0.0.0:0 LISTENING TCP 0.0.0.0:1433 0.0.0.0:0 LISTENING TCP 0.0.0.0:1434 0.0.0.0:0 LISTENING TCP 0.0.0.0:2382 0.0.0.0:0 LISTENING TCP 0.0.0.0:2383 0.0.0.0:0 LISTENING TCP 192.168.200.100:139 0.0.0.0:0 LISTENING TCP 192.168.200.100:139 192.168.200.21:1033 ESTABLISHED UDP 0.0.0.0:161 *:* UDP 0.0.0.0:445 *:* UDP 0.0.0.0:500 *:* UDP 0.0.0.0:514 *:* UDP 0.0.0.0:1028 *:* UDP 0.0.0.0:1030 *:* UDP 0.0.0.0:1032 *:* UDP 0.0.0.0:1434 *:* UDP 0.0.0.0:4500 *:* UDP 0.0.0.0:22102 *:* UDP 127.0.0.1:53 *:* UDP 127.0.0.1:123 *:* UDP 127.0.0.1:1027 *:* UDP 192.168.200.100:53 *:* UDP 192.168.200.100:67 *:* UDP 192.168.200.100:68 *:* UDP 192.168.200.100:123 *:* UDP 192.168.200.100:137 *:* UDP 192.168.200.100:138 *:* UDP 192.168.200.100:2535 *:* C:\>Following is a quick list of tasks to perform on your base operating system:
Securing the operating system is a never-ending battle as new exploits are uncovered on a day-by-day basis. However, you can get close to perfect security by researching the most current methods and ways to secure your operating system of choice at the website of the vendor. The following link takes you to an excellent guide to securing a Windows operating system from a company called Systems Experts:
Of course, you can also review the Microsoft offering. Securing Web Server ApplicationsEven if you have the most secure operating system in the world, it still needs to execute the programs used to your host web pages. If these programs are insecure, the whole server might still be at risk. For example, some of the IIS buffer overflow issues allow a remote command prompt access to a web server. These applications need to be secured, too. IIS and Apache have a large footprint on the Internet today, and both provide fantastic features and capabilities. Following are some of the generic steps to protecting your web server application:
IISIIS 6.0 (Microsoft 2003) has changed significantly from the previous version of IIS 5.0 in 2000. The 5.0 version installed plenty of demos and sample files to assist the developer in understanding the capabilities of IIS. However, this made an unconfigured IIS installation a powerful weapon for hackers every time a new exploit was discovered. The worms Nimda and Code Red took advantage of IIS exploits that Microsoft had already created patches for. It was only because IIS administrators did not apply those patches and security features that these worms became famous. IIS 2003, also known as 6.0, took a "secure by default" approach, basically installing only the necessary tools and service and disabling everything from the start. Administrators have to actually know how to enable features if they need them, and interestingly enough, this slight change of focus makes IIS more secure. Microsoft, in its wisdom, has published several articles and created dedicated tools to help secure IIS. For example:
IIS Lock DownMicrosoft created IIS Lock Down to aid the IIS 5.0 web server administrator in configuring a secure web server by creating a template that is applied to the application. You can download the tool from the Microsoft website. It performs the following functions:
This tool gets a mention on all the Windows 2000 IIS 5.0 security recommendations websites and should be applied if you have not already done so. For more details, see http://www.microsoft.com/technet/security/tools/locktool.mspx. UrlScanMicrosoft also has a tool called UrlScan that provides several features to validate what you request from the web server. For example:
IIS 6.0 has several of the same features as those built into UrlScan; however, you can still UrlScan and further enhance IIS 6.0 security. See http://www.microsoft.com/technet/security/tools/urlscan.mspx for more details. Note Microsoft has a plethora of articles on securing IIS that, if used, make a secure and well-protected web server. The only catch is that you have to do the work: General IIS: http://www.microsoft.com/iis Securing Your Web Server: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod112.asp ApacheYou can find Apache web server vulnerabilities and items of interest on either http://www.apache.org/ or http://www.apacheweek.com/. Although Apache is generally secure, an article by Security Focus takes a step-by-step approach detailing how to create a really secure installation. You can find this at http://www.securityfocus.com/infocus/1694. Securing Website DesignSecuring website design is a difficult topic to document easily because of all the possible issues that unaware developers can integrate into the website through ignorance. The security of web design in this context really refers to the implementations used to deploy technologies that create dynamic content. For example, an ASP developer might create a web page that allows an input form to take only 10 characters, but he does not implement checks to ensure that only 10 characters are coming into the server. Hackers can always send more data than expected to the web server. The result of this might be anything from nothing at all to bringing down the web server. When a developer fails to test for added SQL code to the input from a website, he leaves his application vulnerable to what is known as SQL injection (which is covered in Chapter 8, "Performing Database Attacks"). This might result in data being added, deleted, updated, or revealed from the underlying database. These and other common design flaws leave a web server and potentially the underlying network vulnerable to attack. To reduce the risk, the website designer should follow some basic practices:
Last, the designer should employ a web specialist penetration tester to probe test the website and highlight design vulnerabilities in the site. Securing Network ArchitectureYou should place all web servers in a separate secure network protected by a firewall, such as the Cisco PIX Firewall or the Cisco Adaptive Security Appliance, to prevent all traffic except for that traffic that is allowed by a created rule. In a web server environment, this typically is traffic on ports 80 and 443. Figure 7-37 displays the basic layout of a Demilitarized Zone (DMZ) and the recommended placement of the web server within it. The second firewall allows further protection. If someone does compromise the web server, he has to go through another firewall to gain access to the private office network. The IDS is placed within the DMZ to help monitor and detect potential attacks against the web server. You can further configure the Cisco 4200 Series IDS to integrate with the PIX firewall to help repel attacks when they are detected. Figure 7-37. Standard Staked Firewall Design For greater protection when you do not have anything but a web server in the DMZ and no internal private network, you should add an access control list (ACL) to the inside interface of the PIX firewall. This ACL should only allow traffic with a source port of port 80 to pass through. This provides a secure system such that even if a hacker compromises the web server, only the web server that is running on port 80 has access to the Internet. Figure 7-38 displays an example of a firewall configured in such a way. Figure 7-38. Firewall Blocking from Both Sides |
| < Day Day Up > |
EAN: 2147483647
Pages: 209