I've seen a web application running by Classic App Pool with Network Service identity. What should be the reason behind? what issue we face if use Local System/Local Service or other.
Please share your knowledge if anyone knows.
IIS 4.x/5.x used to use Local System/Local Service as default identity for IIS processes, which became a system-wide risk, as web servers like IIS can be hacked. Once hacked, malicious code would be executed under those powerful accounts to hack the whole Windows machine, and possible other resources in the same domain.
Thus, when Microsoft designed IIS 6, they switched to Network Service, which has significantly less permissions than the old options. Further on in IIS 7 and above, Microsoft introduced Application Pool Identities accounts to reduce more permissions. That's what #mason commented as "the principle of least privilege".
However, the whole IIS security story does not end here. Concepts such as DMZ and so on would bring more security to your web environment, which you should spend some time learning via specific materials (IIS security books and so on), not simply via a web forum.
Related
My ASP MVC web site effected from URL redirect malware recently.There are several web site hosted in IIS in azure server and only one web site opens unwanted popups and redirecting. I have checked same site within local IIS by hosting and it also gave the same result . This is not happening always but it happens suddenly.Any body has idea how I can figure out what is the reason and how I can prevent these issue ?
Since the issue occurs locally and also an Azure VM evidently not an Azure issue. As Adyson rightly mentioned “the site is infected and you need to restore a non-infected version from a backup or re-deploy from the correct version of the source.
In an IaaS deployment, you are still responsible for the management of the systems that you deploy, just like any other server or workstation in your environment. Patching, hardening, rights assignments, and any other activity related to the maintenance of your system are still your responsibility. For systems that are tightly integrated with your on-premises resources, you might want to use the same tools and procedures that you're using on-premises for things like antivirus, antimalware, patching, and backup.
Check the document Security best practices for IaaS workloads in Azure for more details: https://learn.microsoft.com/en-us/azure/security/azure-security-iaas
IIS security: At the level of Internet Information Services (IIS), you set content permissions, authentication controls, and operator privileges. Refer Managing Web Server Security (https://msdn.microsoft.com/en-us/library/bb727096.aspx?f=255&MSPPError=-2147217396) for more details.
I am not clear that what is the purpose of running asp.net application in IIS. Why we go for IIS. Any difference amoung running in VS and IIS?
Please suggest me.
Simply because you won't run asp.net in VS on production !
IIS Express and the VS Development Server are designed to emulate IIS, but they are configured differently and may fail to reveal errors that can occur when you deploy to a production version of IIS.
Visual Studio Development Server, also known as Cassini, is very limited. It does not have all IIS features and we will have a few problems when resolving References to Root-Level Resources or on security.
For example, when you run a page using IIS Express/VS Development Server, the page runs in the context of your current user account (often Admin). In IIS 7, by default ASP.NET runs in an account that has limited privileges (know as AppPool Identity, see here). This difference can be a source of problems when you deploy on production a web application.
A complete list of Hosting options is available here.
Internet Information Services (IIS) for Windows® Server is a flexible, secure and manageable Web server for hosting anything on the Web. From media streaming to web applications, IIS's scalable and open architecture is ready to handle the most demanding tasks.
Application pools allow you to isolate your applications from one another, even if they are running on the same server. This way, if there is an error in one app, it won't take down other applications.
Additionally, applications pools allow you to seperate different apps which require different levels of security.
Here's a good resource: http://www.advancedinstaller.com/user-guide/tutorial-iis.html
http://www.iis.net/learn
I'm upgrading an ASP.NET 4.0 app from:
Windows Server 2003 and IIS 6
to:
Windows Server 2008 and IIS 7.5
This app is based on ASP.NET Web Forms and not MVC. I currently use SQL authentication, but I would like to follow best practices in the new environment.
Both the IIS 7.5 machine and the SQL Server 2008 machine will reside in a DMZ with its own domain controller. It would be nice if we could use similar connection strings for Dev, Test and Prod environments. What's the best practice for this situation? I've read about three options.
ApplicationPoolIdentity
Create your own service account on the domain
SQL authentication
Here are links to questions that discussed related issues, but nothing seemed to answer my specific question.
User ASP.NET Runs Under
Assign Permissions to ApplicationPoolIdentity Account
I recommend AD account for running the app pool. Then, permissions can be created at SQL server for that same account. The conn string used by the app will then not have to contain account info at all (trusted connection), and you will have one less thing to worry about related to security. As additional precaution, remove that AD account from all user groups, and don't use it for anything else but for this one thing (the app pool). Give that user read access to website files, and write access only to folders that it needs to write to (e.g. to dump log files).
As far as best practices is concerned, I don't think any of the 3 options you listed is better over the other one; all of them can do the job securely and efficiently if used correctly. Your decision should be based on which of those offers advantages to you considering your particular environment, company policies, etc., but again, none of them are bad practice.
I have ASP.NET applications deployed on a number of different environments (AppHarbor, Azure, DiscountASP.NET, GoDaddy, etc...) and one thing that bothers me with my deployments on Azure is that my low-traffic websites get JIT-compliled if there hasn't been a request for more than a couple of hours.
Obviously I could solve this by increasing the amount of traffic to my site (I'm being facetious) or by trying to do some hacky things with precompilation, but I'd rather understand why the site needs to be compiled constantly in Azure. I've never noticed this issue on other providers (even GoDaddy) for low-traffic sites - is there some reason for this, and is there anything I can do in the Azure config files to stop this?
Bump your app pool timeout settings with a web role startup task. Steve Marx has a post on how to do this in Azure. You can login with remote desktop to change this to verify - but that setting would get blown away next time you deploy.
On other environments, the app pool settings are probably configured differently. This bugged me for a while when I first set up my Azure site.
I have a windows service that hosts the main WCF service. The clients for this service are both hosted in IIS 7, the first one is an IIS hosted WCF service and the second is a standard Asp.Net application. Both of the IIS hosted clients communicate with the windows service over named pipes.
The IIS hosted WCF service can communicate with the windows hosted WCF service perfectly, but the Asp.Net service fails with this error:
The pipe name could not be obtained from the pipe URI: Access is denied.
My first reaction is that this is a permissions issue somewhere, but I dont know where. And second, why would the IIS hosted WCF service be able to communicate without issue, but the Asp.Net application fail?
Ok, I solved it, or rather I figured out where the permission issue was.
It turns out the Anonymous Authentication setting was using some weird user created by our client (the physical person, not our WCF client), and not the NetworkService user (the identity the app pool was using).
But this almost begets another question: Why were even newly created sites defaulting to this IUSR and not the system defaults? In anycase, I just hope this gets indexed in google as, there were virtually no articles relating to it.
Check the Identity of the Application Pools that the WCF and ASP.NET services resides in.
Maybe the WCF service's AppPool has an identity that has different rights than the other AppPool?
Also, you might want to note that IUSR is the default IIS7 account for Anonymous accessors. See Understanding the Built-In User and Group Accounts in IIS 7.0 for an explanation of the default accounts.
Hope this is helpful.