We did it.
We released a HUGE .NET project, all crafted with C#, SQL Server and ASP.NET.
Problems? You bet... but nothing at all like releasing in ASP 3.0 - in fact, given the circumstances, it was a big success. Microsoft has gone out of their way to provide some really great tools and documentation to make the launch of your .NET application as smooth as possible. Given the history of DLL HELL and trying to get dynamic libraries registered and running in MTS Services... well, you get the point.
I'll let you in on some of the security strategies we followed when deploying our ASP.NET application and also some of the problems that we encountered on the final days of release.
Security has always been a 'problem' with IIS, mostly because of the lackadaisical work habits of system administrators or developers wearing two 'hats'. Earlier this year, Microsoft rededicated the work of many programmers to security. This was a good move - but I'm not waiting until .NET Servers to do my work for me. I'll walk you through some of the easiest ways to lock down a machine and fix some of the snags that you might encounter when deploying an ASP.NET application.
First Rule: If you don't know what you're doing, don't do it.
I can't stress this enough - it takes a special kind of person to admit that they don't know what they're doing. Most of the time a good slap upside the head and then a few late nights with the IIS manual will cure 'IISitis'. Take the time to really understand what IIS is about - what permissions are, what services are on your machine. The days of 'out of the box' functionality are long gone. Guessing if something is going to work has been the death knell of many an administrator.
There are many, many resources out there to help those of you who suffer from IISitis - don't be afraid to ask for help.
Get Rid of It
See that sample folder? Do you know what it does?
Well wipe it out of your
wwwroot - you don't need it. In fact, get rid of ANYTHING on your root you don't need. That includes files and folders that you're not currently using but could be exploited somehow, someway. It's not only good practice to release only files you'll actually be using; it also makes for good housekeeping on the server.
What's Script Mapping?
Say what? You've got to be kidding me... A script mapping is a 'shortcut' for IIS to interpret an extension on a requested file name, like .HTML or .XML. There are a lot of server mappings that you don't need. Avoid these like the plague.
Follow these instructions to remove some of the more commonly exploited server mappings - if you don't use the services....
- Open Internet Services Manager.
- Right-click the Web server, and choose Properties from the context menu.
- Master Properties
- Select WWW Service | Edit | HomeDirectory | Configuration
|Web-based password reset||.htr|
|Internet Database Connector||.idc|
|Server-side Includes||.stm, .shtm and .shtml|
|Index Server||.htw, .ida and .idq|
If you're using any of these, you've got problems. Just say 'NO'.
Windows Update Tool
Get it. Install it. Don't ignore it.
Although sometimes MS is sometimes a little late coming out of the chute when it comes to security patches, it's got a winner with the Windows Update Tool. It's a little icon that sits in the task bar and notifies you whenever there's a hot-fix or a patch available for your machine. If this had been around when the Code Red virus hit the world, it might have minimized the impact that nasty little bug had on the industry.
If you're one of those creeps that ignore the news when a service pack is released, don't come whining to me. I don't want to hear it. I'll bet you're still running Windows NT 4.0 without any updates - aren'tcha?
MS puts out a service pack for a reason. Don't play the 'macho' game of waiting till "it's stable" - that's a lame excuse for not doing your job.
First off, if you're not familiar with IIS or you're not a full time IIS administrator, don't mess with permissions. Period. If you're not a wiz with NT permissions, you could be opening up a hole wide enough to fit the entire "I Hate Bill" community - and that's not a good thing.
I suggest using the IIS Lockdown Wizard to close off any holes or security snafus that you might have lying-in-wait. It'll help you plug those holes that'll make the "little Dutch boy" blush.
Warning: This should take care of many of your permission problems, but don't fall into a false sense of security just because you ran a 'wizard'. There's more work to do after the lockdown wizard.
A few important features of the lockdown wizard include:
- Server Roles - These are basically templates of security settings. If you're running Outlook, you want security setting most suited for Outlook. If you're running a web site, you'll want to choose the server role that corresponds with IIS.
- Disable Services - With the lockdown wizard, you'll be able to remove or disable IIS services such as HTTP, FTP, SMTP and NNTP.
These features allow an IIS administrator to strip off unnecessary roles, permissions and services that ship 'out of the box' with IIS.
Read up on this tool and use it.
The IIS Lockdown tool works like a charm - but it doesn't take care of all of your problems - in fact, you might have to re-up security to a few folders, especially if you're using the System.Web.Mail namespace and the IIS Lockdown has stripped your box of SMTP permission.
In our case, we had to grant the ASPNET user permission to write mail to the SMTP 'outbox'. The ASPNET user needed WRITE access to the mailroot - you'll know when you bump up against a security setting that's too tight - you might not know when it's too loose.
Remember, it's always good practice to tighten down the hatches and then loosen them up as needed - rather than the other way around.
Don't Expose Yourself
Er... don't expose your errors! Make sure that your web.config custom error section is set to 'On' or 'RemoteOnly' when you've released. NEVER set this to 'Off' if you've released your application - you'll show the world your errors. To be on the safe side, keep your customErrors to RemoteOnly - this will show errors on your local (debugging) machine and never show the real cause of an error.
Your web.config error section should look like this:
Ok, I'm going to sound paranoid but...
Don't trust anyone or anything.
Always check your Request.Params before you use the input.
Use RegEx to validate that your input is what you're expecting.
Make sure that you use stored procedures rather than hand-rolling SQL Statements.
Always plan that someone is going to try and jack your code - because someone will.
Down on the Web Farm
We're using a Round-Robin system for piping our end users to our clustered web-farm. Problem was, we forgot all about that damn view state. Don't know what I'm talking about? Well you soon will if you don't have your server keys synchronized. If you're using server side controls, running a web farm and plan on keeping view state from postback to postback... you'll be seeing this tasty little error:
The View State is invalid for this page and might be corrupted
If you're running a web farm this is pretty easy to fix - you'll need to make sure that the server keys on your farm all match. Why is this important? Because view state is encrypted via a server key - and there's no telling which machine an end-user may request a resource from or where they go after posting to a form. That's why it's important all keys on the web farm match up - so machine2 can decrypt the view state from machine1.
In the end, you'll modify your
machine.config file and replace the existing
<machineKey> section with the new key you'll generate. You'll need to do this on every machine you have on your web farm.
The end result will look something like this:
Warning: Don't get lazy and copy one machine.config file around to all of your machines. You'll be very, very sorry.
C# Compiler Problems
One of the most vexing problems we encountered when deploying our C# application was a very funky error.
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS1595: 'System.Runtime.CompilerServices.CompilerGlobalScopeAttribute' is defined in multiple places; using definition from 'C:\winnt\microsoft.net\framework\v1.0.3705\mscorlib.dll'
The trick here was that since we've removed the Everyone and Users accounts for the security tight-down, the
Csc.exe cannot snake out a valid path name - Basically, this occurs because the C# compiler does not have permission to access the folders in the path to the mscorlib.dll assembly. But don't make the mistake of slapping Everyone access on the microsoft.net\framework folder. We're concerned here with security, so what we need to do is modify our machine.config file and add a /nostdlib flag to our C# compiler definition.
Don't copy this verbatim into your machine.config or you could be in a world of hurt. Just add the
compilerOptions="/nostdlib" directive after the
warningLevel line - this tells your C# compiler not to import the mscorlib.dll assembly, which defines the entire System namespace.
I hope this has been of some help to you when deploying your C# and ASP.NET application.
There are literally hundreds of resources out there that will help you lock down your application and site - but you'll have to do the 'hunt and peck' for most of the problems you'll encounter. Make sure that you keep and clear head and plan for problems ahead of time.
Security isn't just an administrator's business. It's everyone's business. Code defensively.
This should be your first stop when encountering problems with deploying applications on IIS.
This one is a no-brainer. Dev Teams all over the world encounter many of the same problems and errors that you're having - remember - you're not an island.
Lockdown Wizard - This is an important tool in the arsenal of any ASP.NET administrator.
C# compiler error - You may or may not get this. If you've locked down your machine and you're releasing with C#, I'm going to bet that you will. Follow the instructions for the first scenario and you'll be fine.
Windows Update Tool - This is a critical tool for all administrators, developers or users of the different flavors of Windows OS.
IIS 5.0 Checklist - Make sure you use it.
View State - This is an error you'll get when you're deploying on a web farm.
Creating Machine Keys - This article describes and provides all the code you need to make a machine key.
IIS 6.0 - A taste of the future of IIS...
Top Ten Security Tips in .NET