1. I am an Internet Service Provider which also offers shared hosting services for clients. I am concerned about security issues that might arise due to running multiple applications on the server. I do not want application of one customer to access data & sensitive application information of another customer.
2. I run a single application pool & run all my applications under this pool. I am sick n tied of trouble shooting the problem application because many a times problem one of the application [may be due to poor design, memory leaks etc] is affecting all my other good applications. Down time issues & affect on the good applications due to this is really a pain. I am losing my customers due to this. Can i get stability & reliability ?
Common Qs - How can you ensure that individual applications will not affect one another at run time? How can you prevent a single, poorly designed application from consuming critical system-level resources on the server that are necessary to keep other applications running properly? How can you ensure that one application from one company cannot access sensitive data contained in another company's application?______________________
Lets look at a Scenario
Bob has bought a shared hosting from one of the providers & he discovers that his application is running under the application pool configured with a built in default account called "Network Service" account. Bob has been a smart developer, although files requested by the applications are typically opened or accessed using the context of the user making the request, Bob re-writes his application in a such a way that the files are not opened in the context of the account under which the worker process is running. In this case it is the network service account which is used to run the application pool under which bob’s app is running.
To explain this further, let’s suppose your application is configured for anonymous access, when an anonymous user requests a file from your application, typically the IUSR_ComputerName account is used to access the file requested. Provided this account has sufficient access rights on the file requested it is severed to the user.
Now bob is feeling a bit malicious today, & he invoked the win32API RevertToSelf() Function & checks his identity. Guess what......? yes it is Network Service account. Voliaaaaaaaa Now all subsequent file accesses are being made from the application as network service account.
What are the implications for this from a security point of view? It means that if there are multiple applications running in the same application pool, you can write malicious code to access other applications sensitive data. e.g think of a case where network service account is ACL’ed on the downstream database server for one of the sensitive applications, now you can write code in your application as well to access the data which belongs to other applications.
Or think of a web.config which might contain clear text username and passwords. Possibilities are endless so I won’t get in much of exploitation techniques here. Let’s talk about what can be done to mitigate this problem.
Here are some Solutions
You need to have an effective application isolation strategy to counter the above issues.
* Separate sensitive or problem applications in to different application pools
* Create unique custom service account to run the different application pools
* Use separate processes for each application. On Windows Server 2003 and IIS 6.0, run each application in its own application pool that is configured to run under a unique identity. This enables you to use Windows auditing to audit the activity of each application separately, and it allows you to configure Windows access control lists (ACLs) independently for each application. This would also help in isolating application such that problem in one application will not affect other applications running on the server. This will immensely help trouble shooting from operational perspective.
* For highly isolated applications, it is best to create a unique user account to be used for anonymous access for the application, and then assign this user as the anonymous user in the Directory Security tab of the properties for the Web site. This allows you to configure authorization so that applications launched by the anonymous user are constrained to appropriate resources. Configuring one unique anonymous user per site adds a security layer by ensuring that users cannot access content on sites to which they are not permitted access.
The above solution does comes at a cost though :),it's high over head on managing multiple custom service accounts. What I recommend is a balanced solution. You can achieve a balance in this approach by determining application isolation needs for your server. Also considering priority in your context, if security is your first concern or ease of maintenance.
The applications that you deploy on a server might fit into several categories, based on your assessment of their sensitivity, technologies, their demand for server resources, or their history of instability. Group your applications according to the following categories, or make up your own set of application categories, before assigning your applications to application pools. e.g High Demand/performance apps, Critical/Sensitive apps, low risk apps, etc. You can also think of grouping application pools according to business groups you might have within your company. e.g a business group X might have 10 line of business applications, you can group them together in one application pool. Again this solution has its own pros n cons.
Here are some additional resources on application isolation:
- Isolating Applications : http://technet2.microsoft.com/WindowsServer/en/Library/0867131b-8e66-4166-8f3d-1b5b6515cf701033.mspx
- Best Practices for application consolidation using IIS 6.0: http://download.microsoft.com/download/1/A/8/1A8689E2-4313-46B1-8655-C62E0389B46A/Web_App_Con_BP.doc
Windows Vista has some cool new security features which can help services isolation problem. More on this later......Stay tuned.........