Docstoc

Securing IIS 6.0 Web Server on Windows 2003

Document Sample
Securing IIS 6.0 Web Server on Windows 2003 Powered By Docstoc
					Securing IIS 6.0 Web Server on Windows 2003
Hacking a Web Server
With the advent of Windows 2003 and IIS 6.0 there was a sharp turn in the
way hosting services were being provided on Windows platform few years
back. Today, web servers running on Internet Information Services 6.0
(IIS 6.0) are highly popular worldwide - thanks to the .NET and AJAX
revolution for designing web applications. Unfortunately, this also makes
IIS web servers a popular target amongst hacking groups and almost every
day we read about the new exploits being traced out and patched. That
does not mean that Windows is not as secured as Linux. In fact, it's good
that we see so many patches being released for Windows platform as it
clearly shows that the vulnerabilities have been identified and blocked.
Many server administrators have a hard time coping up with patch
management on multiple servers thus making it easy for hackers to find a
vulnerable web server on the Internet. One good way I have found to
ensure servers are patched is to use Nagios to run an external script on
a remote host, in turn alerting on the big screen which servers need
patches and a reboot after the patch has been applied. In other words, it
is not a difficult task for an intruder to gain access to a vulnerable
server if the web server is not secured and then compromise it further to
an extent that there is no option left for the administrator but to do a
fresh OS install and restore from backups.
Many tools are available on the Internet which allows an experienced or a
beginner hacker to identify an exploit and gain access to a web server.
The most common of them are:
IPP (Internet Printing Protocol) - which makes use of the IPP buffer
overflow. The hacking application sends out an actual string that
overflows the stack and opens up a window to execute custom shell code.
It connects the CMD.EXE file to a specified port on the attacker's side
and the hacker is provided with a command shell and system access.
UNICODE and CGI-Decode - where the hacker uses the browser on his or her
computer to run malicious scripts on the targeted server. The script is
executed using the IUSR_ account also called the "anonymous account" in
IIS. Using this type of scripts a directory transversal attack can be
performed to gain further access to the system.
Over these years, I've seen that most of the time, attacks on a IIS web
server result due to poor server administration, lack of patch
management, bad configuration of security, etc. It is not the OS or the
application to blame but the basic configuration of the server is the
main culprit. I've outlined below a checklist with an explanation to each
item. These if followed correctly would help prevent lot of web attacks
on an IIS web server.
Secure the Operating System
The first step is to secure the operating system which runs the web
server. Ensure that the Windows 2003 Server is running the latest service
pack which includes a number of key security enhancements.
Always use NTFS File System
NTFS file system provides granular control over user permissions and lets
you give users only access to what they absolutely need on a file or
inside a folder.
Remove Unwanted Applications and Services
The more applications and services that you run on a server, the larger
the attack surface for a potential intruder. For example, if you do not
need File and Printer sharing capabilities on your shared hosting
platform, disable that service.
Use Least Privileged Accounts for Service
Always use the local system account for starting services. By default
Windows Server 2003 has reduced the need for service accounts in many
instances, but they are still necessary for some third-party
applications. Use local system accounts in this case rather than using a
domain account. Using a local system account means you are containing a
breach to a single server.
Rename Administrator and Disable Guest
Ensure that the default account called Guest is disabled even though this
is a less privileged account. Moreover, the Administrator account is the
favorite targets for hackers and most of the malicious scripts out there
use this to exploit and vulnerable server. Rename the administrator
account to something else so that the scripts or programs that have a
check for these accounts hard-coded fail.
Disable NetBIOS over TCP/IP and SMB
NetBIOS is a broadcast-based, non-routable and insecure protocol, and it
scales poorly mostly because it was designed with a flat namespace. Web
servers and Domain Name System (DNS) servers do 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 facing
the Internet and select Properties. Open the Advanced TCP/IP settings and
go to the WINS tab. The option for disabling NetBIOS TCP/IP should be
visible now.
To disable SMB, simply uncheck the File and Print Sharing for Microsoft
Networks and Client for Microsoft Networks. A word of caution though - if
you are using network shares to store content skip this. Only perform
this if you are sure that your Web Server is a stand-alone server.
Schedule Patch Management
Make a plan for patch management 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 your server's Automatic Update to notify you on availability of
new patches if you would like to review them before installation.
Run MBSA Scan
This is one of the best way to identify security issues on your servers.
Download the Microsoft Base Line Security tool and run it on the server.
It will give you details of security issues with user accounts,
permissions, missing patches and updates and much more.
That's it to the basic of securing the operating system. There are more
fixes which can be performed for further securing the server but they are
beyond the scope of this article. Let's now move on to securing the IIS
web server.
IIS 6.0 when setup is secured by default. When we say this, it means that
when a fresh installation of IIS is done, it prevents scripts from
running on the web server unless specified. When IIS is first installed,
it serves 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 that is not what a web server is meant to do,
the default configuration is changed to allow these extensions. Listed
below are some basic points that guide you to securing the web server
further:
Latest Patches and Updates
Ensure that the latest patches, updates and service packs have been
installed for .NET Framework. These patches and updates fix lot of issues
which enhances the security of the web server.
Isolate Operating System
Do not run your web server from the default InetPub folder. If you have
the option to partition your hard disks then use the C: drive for
Operating System files and store all your client web sites on another
partition. Relocate web root directories and virtual directories to a
non-system partition to help protect against directory traversal attacks.
IISLockDown Tool
There are some benefits to this tool and there are some drawbacks,
however, so use it cautiously. If your web server interacts with other
servers, test the lockdown tool to make sure it is configured so that
connectivity to backend services is not lost.
Permissions for Web Content
Ensure that Script Source Access is never enabled under a web site's
property. If this option is enabled, users can access source files. If
Read is selected, source can be read; if Write is selected, source can be
written to. To ensure that it is disabled, open IIS, right click the
Websites folder and select Properties. Clear the check box if it is
enabled and propagate it to all child websites.
Enable Only Required Web Server Extensions
IIS 6.0 by default does not allow any dynamic content to be parsed. To
allow a dynamic page to be executed, you need to enable the relevant
extension from the Web Service Extensions property page. Always ensure
that "All Unknown CGI Extensions" and "All Unknown ISAPI Extensions" are
disabled all the time. If WebDAV and Internet Data Connector are not
required, disable that too.
Disable Parent Paths
This is the worst of all and thanks to Microsoft, it is disabled in IIS
6.0 by default. The Parent Paths option permits programmers to use ".."
in calls to functions by 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 critical or
confidential files outside the root directory of the application. Since
most of the programmers and third-party readymade applications use this
notation, I leave it up to you to decide if this needs to be enabled or
disabled. The workaround to Parent Paths is to use the Server.MapPath
option in your dynamic scripts.
Disable Default Web Site
If not required, stop the Default Web Site which is created when IIS 6.0
is installed or change the property of Default Web Site to run on a
specific IP address along with a Host Header. Never keep it running on
All Unassigned as most of the ready-made hacking packages identify a
vulnerable web server from IP address rather than a domain name. If your
Default Web Site is running on All Unassigned, it means that it can serve
content over an IP address in the URL rather than the domain name.
Use Application Isolation
I like this feature in IIS 6.0 which allows you to isolate applications
in application pools. By creating new application pools and assigning web
sites and applications to them, you can make your server more efficient
and reliable as it ensures that other applications or sites do not get
affected due to a faulty application running under that pool.
Summary
All of the aforementioned IIS tips and tools are natively available in
Windows. Don't forget to try just one at a time before you test your Web
accessibility. It could be disastrous if all of these were implemented at
the same time making you wonder what is causing a problem in case you
start having issues.
Final tip: Go to your Web server and Run "netstat -an" (without quotes)
at the command line. Observe how many different IP addresses are trying
to gain connectivity to your machine, mostly via port 80. If you see that
you have IP addresses established at a number of higher ports, then
you've already got a bit of investigating to do.
Remote Server Administration and Web Hosting Support

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:4
posted:10/15/2010
language:English
pages:4