Thursday, Microsoft is giving a TechNet Webcast on Securing IIS.
* Securing Internet Information Services (IIS)
August 14, 2003, 9:30 A.M. - 11:00 A.M. Pacific time
<http://go.microsoft.com/?linkid=217417>
Its going to say the following:
Uninstall the IIS Service.
Goto apache.org and click HTTP
Goto to downloads, download it
Install it and use this instead
Note: Just a joke I know there are some IIS fans out there but we all know how unsecure it is. They patch something like every week it seems.
Quote from: drake on August 11, 2003, 04:32 PM
Its going to say the following:
Uninstall the IIS Service.
Goto apache.org and click HTTP
Goto to downloads, download it
Install it and use this instead
Note: Just a joke I know there are some IIS fans out there but we all know how unsecure it is. They patch something like every week it seems.
Apache is supposed to be rather insecure on the Win32 platform?
Quote from: drake on August 11, 2003, 04:32 PM
Its going to say the following:
Uninstall the IIS Service.
Goto apache.org and click HTTP
Goto to downloads, download it
Install it and use this instead
Note: Just a joke I know there are some IIS fans out there but we all know how unsecure it is. They patch something like every week it seems.
I don't understand your logic. If a company patches their software, it is not secure?
Does that mean if a company never patches their software, it is secure?
Also, would you by chance be exaggerating the patch rate for IIS?
I don't know that a well administered IIS is inherently insecure. Maybe you have knowledge I could use.
Grok: I adminned IIS 2 summers ago. It sucked so badly, I can't even start talking about it.
Twisted Web has to be the easiest server to admin :)
No matter what software you run on your server, it's only as secure as the administrator(s) that keep it updated.
Ya I was exaggerating on the time. The point being they patch it a lot because of holes that they didn't see when they released the first version. Its actually a bad practice and a very microsoft one (sometimes definitely not in all cases) to release something and fix all the bugs later.
Although obviously sometimes programs that don't get patches are going to be insecure, it also could mean (and in most cases does), there are no holes or bugs that are KNOWN to them or the majority of people who would exploit them.
I am actually not sure how secure Apache in on Windows but I don't use it anyways. I hate running Apache or any Web Server on windows cause in most cases (except with IIS from what I hear), you have to run PHP as a CGI process rather than an HTTP Module which is insecure in itself. I leave the web hosting up to Linux machines. If was going to host off of a windows machine, I would use IIS cause it was built for windows unlike Apache and ultimately with as many holes that get patched, it would SEEM more secure although I don't really know or care enough to.
I'm not a particularly big Microsoft advocate but anyway:
How do you know that Microsoft products have more bugs than others? You're making a judgement without all the information available. Is it not entirely possible that Microsoft's products have similar numbers of bugs to products by other companies, but that Microsoft are better at finding them and more conciencious about releasing patches?
I have more confidence in a company that release patches regularly than in those that don't. As a programmer, I understand that bug-free software is in most cases a mathematical impossibility. Therefore I accept that bugs will always be a problem. Therefore I appreciate regular patches.
Despite IIS's shady history, Thing is quite right when he says that a server is only as secure - or insecure - as the administrator who runs it.
I'd use IIS if a client needed a Windows web solution. I'd stick it behind a firewall and I'd have Apache talk to it through mod_rewrite.
I concur that having the exploits patched is a good thing. Either through relative levels of security or through different amounts of publication, I hear about far more IIS problems than I do problems with competing Web servers. The implication is that either IIS does require more patches to work right or it is under significantly greater scrutiny for security vulnerabilities.
Regardless of which is the case, it seems that running another system is safer because either it really is safer or the majority of attackers are focused on IIS and therefore you're more likely to be left alone. All that said, it behooves a systems administrator to keep up to date on patches to all publicly accessible services, regardless of how secure the services supposedly are. Given the number of patches that IIS seems to require to remain secure (again, based on what I have seen, which as Arta points out may be incomplete evidence), it would appear to be more work to maintain a secure IIS because you must spend more time fetching+testing+installing patches for it than for something which has exploits published/patched rarely.
IMO, one of the problems with many Microsoft programs/services (they supposedly wised up about this in Win2k3EE though) is that they come with too many things turned *on* or running at unnecessarily high privilege levels. So unless the admin sits down and disables everything he doesn't need, he has lots of potentially exploitable services enabled.
I love how you guys drop my kudos cause you disagree with my opinion. I am not officially retiring from this site cause obviously I am not entitled to a different opinion then what the ones that the members here have without being punished for it.
Punished? This is discussion, not punishment. Don't be a such a prat.
Kp: I agree that IIS requires more work to keep secure, and that more people seem to enjoy attacking it than other web servers, but more people also seem to audit it, so perhaps they cancel eachother out? Who knows.
Certainly Win2k3 is *vastly* better than previous versions of windows from a security standpoint - at least, based on my experience thus far. I haven't yet done any in-depth testing but it seems like a great improvement. I'm running IIS6 at the moment to see if its improvements over IIS5 make it worth using. So far, it seems ok, i'll be interested to see what comes up on the lists over the next few months :)
Quote from: Arta[vL] on August 13, 2003, 02:55 AM
Certainly Win2k3 is *vastly* better than previous versions of windows from a security standpoint - at least, based on my experience thus far. I haven't yet done any in-depth testing but it seems like a great improvement. I'm running IIS6 at the moment to see if its improvements over IIS5 make it worth using. So far, it seems ok, i'll be interested to see what comes up on the lists over the next few months :)
Doesn't IIS6 have a kernel mode web server? That would make it rather hard for it to drop any privileges, and anyone that exploits it would get very very much access to the system?
Wow, if that's true, that's BAD.
QuoteDirectory of C:\WINDOWS\system32\drivers
2003-04-03 14:00 334,336 http.sys
Yes, there it is
[old point]
From what I understand, the reason Apache is so insecure on the Win32 platform is for the most part because of flaws/insecurities in Windows itself, not in Apache.
[/old point]
Quote from: Camel on August 13, 2003, 02:23 PM
[old point]
From what I understand, the reason Apache is so insecure on the Win32 platform is for the most part because of flaws/insecurities in Windows itself, not in Apache.
[/old point]
Of course, you'll have no trouble giving specific examples of these problems and exactly the trouble they cause, right?
Quote from: Skywing on August 13, 2003, 04:29 PM
Quote from: Camel on August 13, 2003, 02:23 PM
[old point]
From what I understand, the reason Apache is so insecure on the Win32 platform is for the most part because of flaws/insecurities in Windows itself, not in Apache.
[/old point]
Of course, you'll have no trouble giving specific examples of these problems and exactly the trouble they cause, right?
Of course he can. Apache, simply because it is Apache, is magically and inherently secure when run on secure platforms. When run on insecure platforms, it is magically and inherently insecure.
For me, that describes a product with no security build-in.
Quote from: Yoni on August 13, 2003, 11:38 AM
QuoteDirectory of C:\WINDOWS\system32\drivers
2003-04-03 14:00 334,336 http.sys
Yes, there it is
Ah, I thought so. That should make for some interesting exploits!
Quote2003-04-03 14:00 334,336 http.sys
Hey! How come you have a different version than me?
2003-03-25 14:00 334,336 http.sysI want my money back!
Ok, I have composed a few tutorials on web server security. If you follow these instructions, you will be completely safe. I promise.
IIS on Windows (http://www.vpnsys.com/images/iis.jpg)
Apache on Windows (http://www.vpnsys.com/images/winapache.jpg)
Apache on RedHat (http://www.vpnsys.com/images/nixapache.jpg)
I had no idea. My faith is shattered in an instant (once again). Can a Microsoft junkie possibly suggest *why* they might have done this? On the face of it, it seems so amazingly stupid.
Quote from: Arta[vL] on August 14, 2003, 09:09 AM
I had no idea. My faith is shattered in an instant (once again). Can a Microsoft junkie possibly suggest *why* they might have done this? On the face of it, it seems so amazingly stupid.
Performance reasons - it probably uses TDI directly from kernel mode to eliminate overhead due to extra kernel <-> user mode transitions.
That's not a good enough reason to run one of the world's most exploited web servers in kernel mode. I was thinking about switching to ASP.NET, I guess I won't.
Quote from: St0rm.iD on August 14, 2003, 11:04 AM
That's not a good enough reason to run one of the world's most exploited web servers in kernel mode. I was thinking about switching to ASP.NET, I guess I won't.
I don't think it really changes much security-wise, since before it was running as LocalSystem and could already do anything or give itself permissions to do anything, including loading and running kernel mode code.
Besides, you
do know that virtually the entire Win32 subsystem runs in kernel mode since NT 4, right?
The Win32 subsystem normally doesn't directly respond to remote requests though. Considering how Apache on a unix system will typically switch to the user "nobody" to prevent security breaches, one could've wished that Microsoft would attempt to do the same - drop privileges so if the web server *is* exploited, nothing will be gained.
Plus, most of the winnt subsystem isn't meant to a be a public access system, HTTP is. Making security sacrifices for speed doesn't cut it for me; look at all the buffer overflows because no one does bounds check/data sanitation.
Quote from: Adron on August 14, 2003, 04:40 PM
The Win32 subsystem normally doesn't directly respond to remote requests though. Considering how Apache on a unix system will typically switch to the user "nobody" to prevent security breaches, one could've wished that Microsoft would attempt to do the same - drop privileges so if the web server *is* exploited, nothing will be gained.
What is RPC / MSBlaster all about? Is RPC kernel mode?
Quote from: Grok on August 14, 2003, 09:42 PMWhat is RPC / MSBlaster all about? Is RPC kernel mode?
On an initial install of Win2k, the built-in services, including RPC, run as LocalSystem. As Skywing pointed out earlier, the LocalSystem account can do essentially anything; therefore, any code which manages to run in the context of the RPC service can do anything. The RPC service isn't quite in kernel mode, but it has so many privileges that it's pretty dangerous despite being "only" in user mode.
Quote from: Grok on August 14, 2003, 09:42 PM
Quote from: Adron on August 14, 2003, 04:40 PM
The Win32 subsystem normally doesn't directly respond to remote requests though. Considering how Apache on a unix system will typically switch to the user "nobody" to prevent security breaches, one could've wished that Microsoft would attempt to do the same - drop privileges so if the web server *is* exploited, nothing will be gained.
What is RPC / MSBlaster all about? Is RPC kernel mode?
While it's not kernel mode itself, it has permissions to load and run code in kernel mode (NtSetInformationSystem, NtLoadDriver - SeLoadDriverPrivilege).
Proving once again why Window's priviledge system sucks. Should see me at school demonstrating it :)
A mod_dotnet for Apache on Freebsd would be so awesome :)
Quote from: St0rm.iD on August 15, 2003, 06:35 PM
Proving once again why Window's priviledge system sucks. Should see me at school demonstrating it :)
A mod_dotnet for Apache on Freebsd would be so awesome :)
Actually, this has little-to-none to do with the Windows privilege model - it's a problem with application developers writing sloppy code that doesn't work well without lots of privileges.
Skywing, one could argue that the problem is that when the core of windows was written, security was not an issue, or even very much of a consideration. That's why there are so many holes that can be taken advantage of.
MSBlast is a prime example of the typical windows security flaw. Go ahead; convince me that the reason MSBlast spread was because of "application developers writing sloppy code..."
[edit] BTW Skywing, I agree with you but I just feel like playing the devil's advocate tonight. :D
Quote from: Camel on August 15, 2003, 09:59 PM
Skywing, one could argue that the problem is that when the core of windows was written, security was not an issue, or even very much of a consideration. That's why there are so many holes that can be taken advantage of.
MSBlast is a prime example of the typical windows security flaw. Go ahead; convince me that the reason MSBlast spread was because of "application developers writing sloppy code..."
The Windows NT privilege model is actually quite complex in terms of how well subdivided it is. The problem is that, as Skywing points out, the applications that Microsoft provides in many cases wrongly rely on these high privilege levels. Based on the duties of an RPC endpoint mapper, I would expect it to require filesystem access to read its configuration data, registry read to do the same, and permission to bind a network socket / send datagrams. However, Microsoft chose to have it running under an account which can do all those things and
far too much more. That is why MSBlast can spread and cause problems.
If the people responsible for choosing what services to run under which IDs had consulted a listing of the RPC mapper's requirements and then matched it to an account with just that access and nothing more, MSBlast's damage would be significantly reduced. It would be able to crash unpatched RPC mappers, possibly install itself, and that's about it. It wouldn't have permission to write to anywhere terribly important, couldn't create accounts, couldn't create raw sockets, etc. IMO, the fault lies with the people who chose to just run everything as LocalSystem rather than tailoring the services to IDs of appropriate access.
I agree with Kp.
Microsoft did indeed write Windows NT with security in mind, from the ground up. The Pentagon can purchase NT and secure it by paying attention to the details of which services run on which accounts, locking down the registry and file system, and physically restricting access.
But Microsoft also needed to sell it to the general public .. which in 1993 did not require Pentagon type security. Thus, someone probably in marketing made the decision to relase Windows NT with all services running as SYSTEM, and all file system permissions and most registry permissions set to 'Everyone'. Not even 'Authenticated Users'.
To gain widespread acceptance, Windows NT had to have widespread usability, thus be configured for the general user. It's still a configuration issue though, and not one of architecture or design, in my understanding.
Actually, doesn't RPC need impersonation/token management rights?
Grok, wouldn't it make much more sense to have 'System' group of accounts that would notrmally not be visible to the end user, thus relieving said marketing problem?
Window's priviledge system sucks simply because most services run at *much* higher priviledge level than they need to. Why? Because the software vendors feel that users are too stupid to create new accounts for which the service to run on.
Also, I got Mono to run on redhat (!!!)
Quote from: Adron on August 16, 2003, 04:15 AM
Actually, doesn't RPC need impersonation/token management rights?
Some of the remotely invokable services might, but the endpoint mapper shouldn't. An endpoint mapper's only task (to me) is to provide a well known port which can be queried to find the ephemeral ports of other services. Perhaps I'm misexplaining which program I meant (or don't know all of its other duties -- I haven't poked at it much).
I don't really know, but I thought that whatever runs on that port was able to *start* a server running on an unused port under the credentials of whoever is connecting. Then your next step would be to connect directly to that server.
Quote from: St0rm.iD on August 16, 2003, 05:43 PM
Window's priviledge system sucks simply because most services run at *much* higher priviledge level than they need to. Why? Because the software vendors feel that users are too stupid to create new accounts for which the service to run on.
Also, I got Mono to run on redhat (!!!)
Typically you install things with admin privileges, so setup programs can often create accounts if necessary.
LocalService and NetworkService are preexisting accounts that can be used in XP/2003.
Quote from: St0rm.iD on August 16, 2003, 05:43 PM
Window's priviledge system sucks simply because most services run at *much* higher priviledge level than they need to. Why? Because the software vendors feel that users are too stupid to create new accounts for which the service to run on.
Also, I got Mono to run on redhat (!!!)
I fail to see how Windows' privilege system sucks because services written
for Windows choose to use too high of a user. That's up to the publisher, not Windows.
Quote from: Myndfyre on September 21, 2003, 03:18 PM
Quote from: St0rm.iD on August 16, 2003, 05:43 PM
Window's priviledge system sucks simply because most services run at *much* higher priviledge level than they need to. Why? Because the software vendors feel that users are too stupid to create new accounts for which the service to run on.
Also, I got Mono to run on redhat (!!!)
I fail to see how Windows' privilege system sucks because services written for Windows choose to use too high of a user. That's up to the publisher, not Windows.
I concur with you about it being a problem with the services, not with the base OS model. However, I should point out that most of the services in question are written by Microsoft and distributed in the default Windows install. Some services, such as the RPC services, are actually vital for basic tools to work fully. For instance, Windows Explorer right-drag&drop facility breaks down if the RPC services get stopped.