Insecure? Not overly if you know what your doing. Evil? They wouldn't be fun otherwise...
They have to have it. They have to have it. Really. For some fairly reasonable reasons, VS.NET *prefers* FPSE as its publish to server mechanism. The biggest of these, I suppose, is that WebDAV isn't far enough along for general use yet developers shouldn't get administrative access to production servers. The biggest thing about using FrontPage that we've found is to understand how their security model works. The biggest point here is if you aren't using NTFS, you're hosed from a security view point from the get-go. I can't think of a good reason to ever put a virtual web or ftp directory on a FAT drive. Ever. With NTFS, you have fighting chance. 70% of FrontPage's "problems" can be address by the disciplined use of "Domain users go into Local Groups." The other 20% is best addressed by have a good policy about applying security updates and auditing system usage. The last 10% is typically a matter of configuring IIS correctly. Let's start with that... On configuration: Never run FPSEs on an Exchange Server. That's just trouble waiting to happen IMHO. Mail Servers should server mail, web servers should serve web content. Starting by sealing any security holes you can find. Audit the local machine group memberships -- especially the admins groups. Enable security logging. Remove any shared folders you can, particularly WWWROOT$. Disable any unneeded services. Get up the current service pack and hot fixes. You probably know that drill. Install the extensions package themselves. You'll find the default web is automatically "extended." Remove the extensions from that web if you are using Host-Header-Names (which is a good idea if you control your own DNS) to create site. Leaving them on the default web is just an easy vector of attack that you don't need to leave dangling open. If applicable, running IIS lockdown. That seals a number of holes (and potential holes.) On the Server Extension tab in IIS, you should check "Log Authoring Actions" without question. I'm neutral about requiring SSL -- if you can afford it, its another step up in security, but its marginal. Never check "manually manage permissions" unless you really want a mess to deal with. At the highest level off IIS you can manage -- Default Web Site typically -- disable anonymous access and basic authentication if at all possible. Yes, that means use Windows Integrated. Why? It forces the user to authenticate against the web (sending back a 401.3) then IIS will log the user in the IIS logs. For each site, try to make this (Windows Integrated( requirement and only supported option. That's a bit more daunting than it sounds if you haven't standardized in IE and if you haven't put your internal domain in the local intranet zone. If you've done those things, the whole process is seamless to the user (they auto-authenticate without a pesky UI under these conditions.) If you've not got IE in shape, shame on you. Get that done first. Oh, and BTW, never, never, never install the double-ding-blasted SMTP service that ships with IIS when avoidable. This isn't a FrontPage issue per se, but it's an open relay waiting for abuse by default. Your .NET developers have access to System.Web.Mail.SmtpMail which can spin up a relay session to your well-secured Exchange servers. I love ASPMail otherwise. If you can't avoid it, lock it down as much as possible. On auditing and administration: Configure the logs to log everything for every site, every time. Plan to spend some effort moving those logs off to long term storage every so often. CDs and CD-Writers are cheap ways to preserve evidence. Same is true for the event logs: Export, burn and save before flushing. When you are visiting the machine to take care of these chores, it's a great time run windows update and see what's available for fixes. I generally recommend running Windows Update at least once a week and see what there is to install. FrontPage fixes are fairly rare, IIS fixes aren't. Look through the logs periodically for anything smelling fishy. Accessing EXEs is generally fishy. Excessive 404 or 5xx errors with "_vti_" in the URI stem or query should stink like a half gutted fatty carp left on the dock for a few hot July days. Ok, now back to NTFS: In the top most directory where you intend to create directories for the v-webs, remove the DACLs for everyone from that root on down. If these DACLS are subsequently needed, FrontPage will add them. No reason to leave that DACL out there otherwise. When extending a web with FPSE, the process normally creates three local groups and modifies the DACLS on the root (and child) directories appropriately. Do this, then add the developers to the "admin" group this creates. This gets you around the need to make them local admins. One of the other groups FPSEs create is "users" If the web needs INTERNET anonymous access, then add "IUSR_" to this group. With .NET, you'll probably also need to add ASPNET account there too. You'll probably have to back off a bit an enable anonymous access too in the directory security tab. If the web needs INTRANET "anonymous" access, add "Domain Users" to this group, but don't back off the Windows Integrated security unless you absolutely have to. The result of this fairly substantial effort is a reasonably secure server running FPSEs. You've put enough barriers in place to make the less-determined folks go find a softer target. Is it completely secure? No. Is it less secure than before? That depends, but probably slightly. Why? You've added an in-process ISAPI filter to IIS. That's a vector for attack that you can't eliminate unless you completely remove it. The process hardens it substantially, but you still have that possibility. It's risk reduction and migitigation at best. Now, as far a .NET-based, internet-exposed production server goes. Ideally: don't install FSPE on them. Once you have the application running in staging/test as best possible, copy to disk/or CD, walk over the production server and copy the files down. Such machines shouldn't be connected to your internal network at all, nor should developers have any admin-type access to them (or need them for that matter.) Xcopy deployments do "just work." Otherwise, production servers secured like I've just described should ok. For an extra measure of security, consider running the production servers behind a reverse-proxy like ISA in publishing mode. Or even Apache with mod_proxy. I suspect that a lot of evil-doers will look to see what kind of server you are running. If you can "fake out" an IIS server hiding behind a Apache box, you've just thrown them a seemingly whole new set of problems to work with. They just might move on. So long as you're using HTTP or HTTPs, your apps will normally be just fine too. Installing FPSEs on not-Windows is outside of experiences, but it seems that same principals would probably apply. Let me know if I can be of more help, Kent Tegels, MCSE+I, MCDBA, MCP+SB (and formerly, CLU, ChFC, FLMI/M) Sr. Systems Analyst, HDR, Inc. Wrox Press Contributing Author -----Original Message----- From: Martin Blackstone [mailto:MBlackstone@;superioraccess.com] Sent: Friday, October 11, 2002 11:10 PM To: IIS50 Discussions Subject: FPSE and .NET What are your guys thoughts on FPSE? My developers are screaming that they HAVE TO HAVE IT for thier .NET development. Apparently they say you have to have it to deploy .NET web apps. It seems to me that all I hear about FPSE is that it is evil and insecure. I need some input on this. Martin Blackstone Director, Information Technologies Microsoft Exchange MVP Superior Access Insurance Services 949.470.2111 x279 --- You are currently subscribed to iis50 as: [EMAIL PROTECTED] To unsubscribe send a blank email to %%email.unsub%% --------- Administrated by 15 Seconds : http://www.15Seconds.com List Archives/Search : http://local.15Seconds.com/search Subscription Information : http://www.15seconds.com/listserv.htm Advertising Information: http://www.internet.com/mediakit/ --- You are currently subscribed to iis50 as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] --------- Administrated by 15 Seconds : http://www.15Seconds.com List Archives/Search : http://local.15Seconds.com/search Subscription Information : http://www.15seconds.com/listserv.htm Advertising Information: http://www.internet.com/mediakit/
