Saturday, August 25, 2012

Protection IIS Web Server 6.0 on Windows 2003


Hacking a Web server
With the advent of Windows 2003 and IIS 6.0 there was an abrupt shift in how hosting services were awarded on Windows years ago. Today, the web server running Internet Information Services 6.0 (IIS 6.0) are very popular all over the world - thanks to the network and the AJAX revolution for designing web applications .. Unfortunately, this makes IIS web servers a popular target amongst hacking groups and almost every day we read the exploits of new tracks and patched. This does not mean that Windows is not as assured as Linux. In fact, it is good that we see so many patches being released for the Windows platform as demonstrated clearly that the vulnerabilities have been identified and blocked.

Many server administrators have difficulty coping with the patch management across multiple servers, making it easier for hackers to find a vulnerable web server on the Internet. I found a good way to ensure server patch is to use Nagios to run an external script on a remote host, in turn alert the big screen which servers need patches and a reboot after the patch was applied. In other words, it is difficult for an intruder to gain access to a vulnerable server if the web server is not protected and therefore further compromise to the point that there is no option left for the administrator, but to make a fresh OS installation and restoring from backup.
Many tools are available on the Internet that allows an expert or a novice hacker to identify an exploit and gain access to a web server. The most common of these are:

IPP (Internet Printing Protocol) - which uses the IPP buffer overflow. The application sends a string of hacking that actual stack overflow and opens a window to run shell custom code. It connects the CMD.EXE file to a specified port on the side of the attacker and the attacker has a command shell, and system access.

UNICODE and CGI-Decode - where the attacker uses the browser on your computer to run malicious scripts on the target server. The script runs under the IUSR_ also called "anonymous account" in IIS. Using this type of an attack script directory traversal can be performed to obtain further access to the system.

In these years, I saw that most of the time, a result of attacks on IIS web servers due to poor server administration, the lack of patch management, security misconfiguration, etc., is not the operating system or application to blame, but the basic configuration of the server is the main culprit. Are set out below a checklist and an explanation for each item. These, if followed properly would help prevent many attacks on a web server, IIS web.

Secure the operating system
The first step is to ensure the operating system that runs the web server. Make sure that the Windows Server 2003 is running the latest service pack that includes a number of important security enhancements.

Always use the NTFS file system
NTFS file system provides granular control over user permissions and allows users to access only what you absolutely need a file or inside a folder.

Remove unwanted applications and services
Applications and services that best run on a server, the greater the surface area of ​​attack for an intruder. For example, if you do not need file and printer sharing capabilities on your shared hosting platform, disable this service.

Use less privileged accounts for the service
Always use the local system account for starting services. By default Windows Server 2003 has reduced the need for a service account in many cases, but they are still necessary for some third-party applications. Use local system account, in this case rather than using a domain account. Using a local system account means that you are in violation contains a single server.

Rename Administrator and Guest off
Ensure that the default account called Guest is disabled even though this is an account with fewer privileges. In addition, the Administrator account is the preferred targets for hackers and most of the malicious scripts out there use to exploit and vulnerable server. Rename the Administrator account to something else so that scripts or programs that have a check account of these hard-coded safe.

Disable NetBIOS over TCP / IP and SMB
NetBIOS is a broadcast-based protocol, is not routable and insecure, and it scales slightly mainly because it was designed with a flat namespace. Web Server and Domain Name System (DNS) server does not require NetBIOS and Server Message Block (SMB). This protocol should be disabled to reduce the threat of user enumeration.

To disable NetBIOS over TCP / IP, right-click the network connection to the Internet and select Properties. Open the advanced TCP / IP and go to the WINS tab. The option to disable NetBIOS TCP / IP should be visible.

To disable SMB, simply uncheck the File and Printer Sharing for Microsoft Networks and Client for Microsoft Networks. A word of caution though - if you use network shares to store the contents skip this. Run this if you are sure that your Web Server is a stand-alone.

Patch management program
Make a plan for managing patches and stick to it. Subscribe to Microsoft Security Notification Service (http://www.microsoft.com/technet/security/bulletin/notify.asp) to stay updated on the latest release of patches and updates from Microsoft. Configure automatic updating of the server for the notification of the availability of new patches, if you want to review them prior to installation.

Run MBSA Scan
This is one of the best ways to identify security issues on the server. Download the tool Microsoft Baseline Security and run it on the server. It will give you details of security problems with user accounts, permissions, missing patches and updates, and much more.

This is the basis for fixing the operating system. There are other fixes that can be performed to further secure the server, but are beyond the scope of this article. Let us now turn to the security of the IIS web server.

IIS 6.0 when the setup is set by default. When you say this, it means that when a new installation of IIS is done, prevents the execution of scripts on the web server unless specified. When IIS is first installed, serving only HTML pages and all dynamic content is blocked by default. This means that the web server will not serve or parse dynamic pages like ASP, ASP.NET, etc. since it is not what a web server is designed to do, the default configuration is changed to allow these extensions. Here are some key points that guide the user to ensure the most popular web server:

Latest patches and updates
Make sure the latest patches, updates and service packs have been installed. NET Framework. This patch updates and fixes a lot of issues that enhances the security of web servers.

Isolate the operating system
Do not run the web server by default InetPub directory. If you have the opportunity to partition your hard drive then use the C: drive to the operating system files and store all your web client to another partition. Move Web root directories and virtual directories in a non-system partition to help protect against directory traversal attacks.

Tool IISLockdown
There are some advantages of this tool and there are some drawbacks, however, so use it with caution. If the web server interacts with other servers, test the lockdown tool to ensure it is configured so that connectivity to back-end is not lost.

Permissions for Web content
Ensure that the Script Source Access is enabled in the properties of a web site. If this option is enabled, users can access the source file. If the reading is selected, the source can be read, if Write is selected, the source can be written. To ensure that it is disabled, open IIS, right-click the Web Sites folder and select Properties. Clear the check box if it is activated and propagated to all the Web sites of children.

Enable only the Web server extensions
IIS 6.0 by default does not allow any dynamic content to be analyzed. To enable a dynamic page to be executed, you must turn on the extension from the Web page service properties Extensions. Always make sure that "All Unknown CGI Extensions" and "all unknown ISAPI extensions" are disabled for all the time. If WebDAV and Internet Data Connector are not needed, disable that too.

Turn off the main routes
This is the worst of all, thanks to Microsoft, it is disabled by default in IIS 6.0. The Parent Paths option allows programmers to use ".." in function calls, allowing paths that are relative to the current directory using the notation ... Setting this property to True may constitute a security risk because an include path can access important or confidential files outside the root directory. Since most of the programmers and third party applications ready to use this notation, I leave you to decide whether it should be enabled or disabled. The solution to the main paths is to use the Server.MapPath in your dynamic scripts.

Disable Default Web Site
Otherwise, stop the default Web site that is created when you install IIS 6.0 or change the default Web site properties to run on a particular IP address with a host header. Do not keep it running on All Unassigned as most of the packages prepared hacking identify a vulnerable web server by IP address instead of a domain name. If your default Web site is running on All Unassigned, which means it can serve content to an IP address in the URL instead of the domain name.

Use application isolation
I like this feature in IIS 6.0 that allows you to isolate applications into application pools. By creating new application pools and assigning Web sites and applications to them, you can make the server more efficient and reliable as it ensures that other applications or sites are not affected because of a bad application running in that pool.

Summary
All the above advice in IIS and tools are available natively in Windows. Do not forget to try one at a time before you test your Web accessibility. It could be disastrous if all these were implemented at the same time making you wonder what is causing a problem when you start having problems.

Final advice: Go to the Web server and Run "netstat-an" (without quotes) in the command line. Look at how many different IP addresses are trying to get connectivity to the machine, mostly through port 80. If you see that you have the IP addresses set to a higher number of ports, then you already have a little 'of investigating to do.

No comments:

Post a Comment