Sunday, September 25, 2011

Web Security – IIS


Introduction

With the sharp increase of hacking attacks over the last couple of years, and the introduction of a number of regulatory compliance guidelines to follow, web application security has become a key concern for many online businesses, and also a common expense in a company’s budget.  Although many businesses are focusing on securing their web applications, unfortunately they are not looking at the whole picture.  A vital part of securing a business’s whole web infrastructure also includes having a secure web server configuration.  Securing a web server’s configuration is as important as securing the web application itself.

What is Web Security?

Web Security is defined as protecting web site assets in order to ensure user confidence by maintaining the integrity of customer data and defending the company name.

Web Server Security and Database Server Security

Various high-profile hacking attacks have proven that web security remains the most critical issue to any business that conducts its operations online.  Web servers are one of the most targeted public faces of an organization, because of the sensitive data they usually host.  Securing a web server is as important as securing the website or web application itself and the network around it.  If you have a secure web application and an insecure web server, or vice versa, it still puts your business at a huge risk.  Your company’s security is as strong as its weakest point.

Although securing a web server can be a daunting operation and requires specialist expertise, it is not an impossible task. Irrelevant of what web server software and operating system you are running, an out of the box configuration is usually insecure.  Therefore one must take some necessary steps in order to increase web server security.  Below is a list of tasks one should follow when securing a web server.


1. Remove unnecessary services


Default operating system installations and configurations, are not secure.  In a typical default installation, many network services which won’t be used in a web server configuration are installed, such as remote registry services, print server service, RAS etc.  The more services running on an operating system, the more ports will be left open, thus leaving more open doors for malicious users to abuse.  Switch off all unnecessary services and disable them, so next time the server is rebooted, they are not started automatically.  Switching off unnecessary services will also give an extra boost to your server performances, by freeing some hardware resources.

2. Remote access

Although nowadays it is not practical, when possible, server administrators should login to web servers locally.  If remote access is needed, one must make sure that the remote connection is secured properly, by using tunneling and encryption protocols.  Using security tokens and other single sign on equipment and software, is a very good security practice.  Remote access should also be restricted to a specific number of IP’s and to specific accounts only.  It is also very important not to use public computers or public networks to access corporate servers remotely, such as in internet cafĂ©’s or public wireless networks.

3. Separate development / testing / production environment

Since it is easier and faster for a developer to develop a newer version of a web application on a production server, it is quite common that development and testing of web applications are done directly on the production servers itself.  It is a common occurrence on the internet to find newer versions of a specific website, or some content which should not be available to the public in directories such as /test/, /new/ or other similar sub directories.  Because such web applications are in their early development stages, they tend to have a number of vulnerabilities, lack input validation and do not handle exceptions appropriately.   Such applications could easily be discovered and exploited by a malicious user, by using free available tools on the internet.
To ease more the development and testing of web applications, developers tend to develop specific internal applications that give them privileged access to the web application, databases and other web server resources, which a normal anonymous user would not have.  Such applications usually do not have any kind of restriction, since they are just test applications accessed that should be accessed from the developers only.  Unfortunately, if development and testing is done on a production server, such applications can easily be discovered from a malicious user, which could help him compromise and gain access on the production server.
Ideally, development and testing of web applications should always be done on servers isolated from the internet, and should never use or connect to real life data and databases.

4 .Web application content and server-side scripting

The web application or website files and scripts should always be on a separate partition or drive other than that of the operating system, logs and any other system files.  Through experience we’ve learnt that hackers who gained access to the web root directory, were able to exploit other vulnerabilities, and were able to go a step further and escalate their privileges to gain access to the data on the whole disc, including the operating system and other system files.  From there onwards, the malicious users have access to execute any operating system command, resulting in complete control of the web server.

5. Permissions and privileges:

File and network services permissions play a vital role in web server security.  If a web server engine is compromised via network service software, the malicious user can use the account on which the network service is running to carry out tasks, such as execute specific files.  Therefore it is very important to always assign the least privileges needed for a specific network service to run, such as web server software.  It is also very important to assign minimum privileges to the anonymous user which is needed to access the website, web application files and also backend data and databases.

6. Install all security patches on time

Although having fully patched software does not necessarily mean your server is fully secure, it is still very important to update your operating system and any other software running on it with the latest security patches.  Up until this day, hacking incidents still occur because hackers took advantage and exploited un-patched servers and software.

7. Monitor and audit the server

All the logs present in a web server, should ideally be stored in a segregated area.  All network services logs, website access logs, database server logs (e.g. Microsoft SQL Server, MySQL) and operating system logs should be monitored and checked frequently.  One should always be on the lookout for strange log entries.  Log files tend to give all the information about an attempt of an attack, and even of a successful attack, but most of the times these are ignored.  If one notices strange activity from the logs, this should immediately be escalated so the issue can be investigated to see what is happening.

8. User accounts

Unused default user accounts created during an operating system install should be disabled.  There is also a long list of software that when installed, user accounts are created on the operating system.  Such accounts should also be checked properly and permissions need to be changed required.  The built in administrator account should be renamed and is not to be used. Every administrator accessing the web server should have his own user account, with the correct privileges needed.  It is also a good security practice not to share each others’ user accounts. 

9. Remove all unused modules and application extensions

By default, IIS is configured to serve a large number of application types, e.g. ASP, ASP.NET and more.  The list of application extensions should only contain a list of extensions the website or web application will be using.  Every application extension should also be restricted to use specific HTTP verbs only, where possible.

10. Use security tools provided with web server software

Microsoft released a number of tools to help administrators secure IIS web server installations, such as URL scan.

11. Stay informed

Nowadays, information and tips on the software and operating system being used can be found freely on the internet.  It is very important to stay informed and learn about new attacks and tools, by reading security related magazines and subscribing to newsletters, forums or any other type of community.

12. Use Scanners

Scanners are handy tools that help you automate and ease the process of securing a web server and web applications, which when enabled will port scan the web server hosting the web application being scanned.   

A brief introduction to Microsoft IIS

Microsoft Internet Information Services, better known as IIS, is Microsoft’s set of internet based services for servers, which runs on Microsoft Windows operating systems.  The internet services provided with IIS are a SMTP (simple mail transport protocol) Server, FTP (file transfer protocol) Server, NNTP (network news transfer protocol) server and WWW (World Wide Web) server.  Until version 5.1 (~ year 2000), IIS was hit with a number of vulnerabilities, which also lead to a number of infamous worms on the internet. Most of such incidents happened because both the design of the application itself and the permissions it used to run were flawed.  An out of the box installation of IIS version 5.1 published on the internet in 2000, could get hacked in a matter of minutes.  From version 6 onwards, when internet hacking was causing a huge financial problem to major online businesses, Microsoft re-designed IIS.  The way IIS 6 and more recent versions work and use resources, are more secure, and help in reducing the attack surface.  Microsoft also removed the SMTP server and the NNTP server in more recent versions of IIS.  Still, an out of the box IIS installation, with a default configuration may still lead to a number of problems.

Securing Microsoft IIS web server

1. To start off with, all web related documents, such as web application files and other files which are typically shared over the internet, should be stored in a different drive from the operating system drive.  Because of vulnerability, a malicious user can gain access to the web root directory, and then escalate his permissions and gain access to the whole drive where the web root is.  If the malicious user gains access to the whole drive, at least he cannot tamper your operating system installation, thus making it easier to trace his activity.

2. When creating a new web root directory, where all the files to be shared on the web will be stored, grant the appropriate (least possible) NTFS permissions to the anonymous user being used from the IIS web server to access the web content.  Ideally, deny write access to any file or directory in the web root directory to the anonymous user.  If need be, create a new user to be used as an anonymous user and grant the appropriate permissions, and disable the built-in IIS anonymous user.  Always avoid giving write NTFS permissions to the anonymous user.

3. If a database server, such as Microsoft SQL Server is to be used as a backend database, install it on a separate server.  If the budget permits, other network services should be installed on separate servers.  If one of such network services is compromised, it makes it more difficult for a malicious user to gain access over the other servers, thus compromising the whole web farm infrastructure.  Also, if possible, avoid mapping virtual directories between two different servers, or over a network.

4. If IIS FTP service is needed, do not install the FTP service shipped with latest windows editions.  Apart from not being a very practical FTP server, its configuration has to be accessed from a IIS 6 management console.  Microsoft released a new FTP server which integrates better with IIS 7 and its configuration, and is more practical. One should also follow good FTP server configuration practices, such as to always isolate the ftp user in his home directory, use secure FTP (over SSL), and also allow the least possible privileges to the users.  Even though FTP user permissions can be controlled from the IIS 7 MMC, make sure that such permissions are also enforced via NTFS permissions

5. Monitor servers, web applications and network services activity frequently.  By analyzing the log files, you can determine if a web server or network service is being attacked.  Studying such activity, you can also learn what type of attacks your server is undergoing, thus helping you understand the attacker and will also help you adapt to such attacks and increase the level of security of the whole web farm infrastructure.

6. Like every other software vendor, Microsoft periodically releases a number of software updates and security patches.  These patches should be applied at the earliest possible to reduce the risk of someone finding the security hole before it is patched.  Once vulnerabilities are made public, within a couple of hours, malicious users would already have automated scripts and scanners that crawl the internet and identify vulnerable server.  Once a new security patch or software update is applied, you should also thoroughly test the web applications’ functionalities, to confirm they were not affected by such security patch or software update.

7. Microsoft provides a number of tools to help you secure your web server.  It is imperative to invest time in learning how to use such tools, since in the long run they can save you from a more time consuming activity, such as restoring a server after it was hacked, or tracing a malicious user’s activity.  Such tools are; IIS Security “What if” tool, which helps you troubleshoot security issues with IIS, IIS Security Planning Tool which helps you deploy IIS with security that is appropriate for the server’s role, and IIS Lockdown tool, which provides built-in secure IIS configuration templates.  There are many other tools provided from Microsoft for free, which can be downloaded from their website.  Also, Microsoft frequently publishes documents and security guidelines on how to secure your web server, which one should follow.  After using such tools, or applying changes which you’ve learnt about from Microsoft’s documentation, test the web application’s functionality, to confirm that such changes did not affect or block any of the web application’s functionality.  Ideally you should also use other third party security tools.

8. If Pre-Built PHP applications are host on IIS, Please make sure that they must be update to the latest versions to avoid the loophole in IIS’s Security as PHP Applications are more vulnerable and prone to hacking.



Web Security Scanning

Web security, therefore, contains two important components: web and database server security, and web application security. Addressing web application security is as critical as addressing server security.

Firewalls and similar intrusion detection mechanisms provide little defense against full-scale web attacks. Since website needs to be public, security mechanisms will allow public web traffic to communicate with your web and databases servers (generally over port 80).

Scanning the security of these web assets on the network for possible vulnerabilities is paramount. For example, all modern database systems (e.g. Microsoft SQL Server, Oracle and MySQL) may be accessed through specific ports and anyone can attempt direct connections to the databases effectively bypassing the security mechanisms used by the operating system. These ports remain open to allow communication with legitimate traffic and therefore constitute a major vulnerability. Other weaknesses relate to the actual database application itself and the use of weak or default passwords by administrators. Vendors patch their products regularly; however, hackers always find new ways of attack.

Some hackers, for example, may maliciously inject code within vulnerable web applications to trick users and redirect them towards phishing sites. This technique is called Cross-Site Scripting (XSS) and may be used even though the web and database servers contain no vulnerability themselves.

Sunday, September 18, 2011

FSMO Roles



 This article includes the FSMO Roles of Domain Controller.


Schema Master:

The schema master domain controller controls all updates and modifications to the schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the whole forest.

Domain naming master:

The domain naming master domain controller controls the addition or removal of domains in the forest. This DC is the only one that can add or remove a domain from the directory. It can also add or remove cross references to domains in external directories. There can be only one domain naming master in the whole forest.

Infrastructure Master:

When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object's SID and distinguished name in a cross-domain object reference. At any one time, there can be only one domain controller acting as the infrastructure master in each domain.
Note: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server (GC). If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not be updated and a warning to that effect will be logged on that DC's event log. If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which domain controller holds the infrastructure master role.

Relative ID (RID) Master:

The RID master is responsible for processing RID pool requests from all domain controllers in a particular domain. When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain.  Each DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC. At any one time, there can be only one domain controller acting as the RID master in the domain.

PDC Emulator:
 
The PDC emulator is necessary to synchronize time in an enterprise. Windows 2000/2003 includes the W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows 2000/2003-based computers within an enterprise use a common time. The purpose of the time service is to ensure that the Windows Time service uses a hierarchical relationship that controls authority and does not permit loops to ensure appropriate common time usage.
The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source. All PDC FSMO role holders follow the hierarchy of domains in the selection of their in-bound time partner.
In a Windows 2000/2003 domain, the PDC emulator role holder retains the following functions:
  • Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.
  • Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password failure message is reported to the user.
  • Account lockout is processed on the PDC emulator.
  • Editing or creation of Group Policy Objects (GPO) is always done from the GPO copy found in the PDC Emulator's SYSVOL share, unless configured not to do so by the administrator.
  • The PDC emulator performs all of the functionality that a Microsoft Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows NT 4.0-based or earlier clients.
This part of the PDC emulator role becomes unnecessary when all workstations, member servers, and domain controllers that are running Windows NT 4.0 or earlier are all upgraded to Windows 2000/2003. The PDC emulator still performs the other functions as described in a Windows 2000/2003 environment.
At any one time, there can be only one domain controller acting as the PDC emulator master in each domain in the forest.