Groups | Blog | Home
all groups > iis security > may 2004 >

iis security : IIS Seperate Partition?


Ryan Riddell
5/29/2004 4:01:04 PM
I'm running Server 03 with a web server and file server as well as acting as a domain controller

My question is if it would be more secure or considered a good idea to have the web server on its own partition

The idea being that if a malicious user manages to take control of IIS they are sort of stuck on the individual partition. Also, if they manage to hose the partition it won't effect the other functions of the server

Thanks
Ryan Riddell
5/29/2004 5:46:02 PM
Yeah, that's what I meant, throw the served files on a seperate partition. Just wanted to make sure I was headed down the right path

Thanks for the advice
Rya

----- Jonathan Maltz [MS-MVP] wrote: ----

Hi

There's no way to install the IIS system files on a partition other than th
system partition, but you can move the files being served to anothe
partition/folder (as most people do) so if a buffer overflow is found i
your scripts a hacker doesn't know the right dynamic path (i.e
/../../windows/system/cmd.exe) right off the ba

--
--Jonathan Maltz [Microsoft MVP - Windows Server, Virtual PC
http://www.visualwin.com - A Windows Server 2003 visual, step-by-ste
tutorial site :-
http://vpc.visualwin.com - Does <insert OS name> work on VPC 2004? Find ou
her
Only reply by newsgroup. I do not do technical support via email. An
emails I have not authorized are deleted before I see them


"Ryan Riddell" <anonymous@discussions.microsoft.com> wrote in messag
news:DDB4975B-E550-47E7-AF08-68DD979B09FB@microsoft.com..
[quoted text, click to view]
they are sort of stuck on the individual partition. Also, if they manage t
hose the partition it won't effect the other functions of the server
[quoted text, click to view]


Jonathan Maltz [MS-MVP]
5/29/2004 7:41:38 PM
Hi,

There's no way to install the IIS system files on a partition other than the
system partition, but you can move the files being served to another
partition/folder (as most people do) so if a buffer overflow is found in
your scripts a hacker doesn't know the right dynamic path (i.e,
/../../windows/system/cmd.exe) right off the bat

--
--Jonathan Maltz [Microsoft MVP - Windows Server, Virtual PC]
http://www.visualwin.com - A Windows Server 2003 visual, step-by-step
tutorial site :-)
http://vpc.visualwin.com - Does <insert OS name> work on VPC 2004? Find out
here
Only reply by newsgroup. I do not do technical support via email. Any
emails I have not authorized are deleted before I see them.


[quoted text, click to view]
they are sort of stuck on the individual partition. Also, if they manage to
hose the partition it won't effect the other functions of the server.
[quoted text, click to view]

Roger Abell [MVP]
5/31/2004 7:25:22 AM
Placing the content on a separate partition offers some amount
of added difficulty to an invader, but do not believe it is very great.
Mostly that is a measure that will guard you against misuse of the
accounts granted permissions in your web server and/or your
misconfiguration of them
If someone does get in, and gets ahold of the processes, they
will have little difficulty walking around your system.
--
Roger Abell
Microsoft MVP (Windows Server System: Security)
MCDBA, MCSE W2k3+W2k+Nt4
[quoted text, click to view]

Jonathan Maltz [MS-MVP]
5/31/2004 12:55:25 PM
Well if you buffer overflow the script you can use it to do a directory
traversal attack, no?

--
--Jonathan Maltz [Microsoft MVP - Windows Server, Virtual PC]
http://www.visualwin.com - A Windows Server 2003 visual, step-by-step
tutorial site :-)
http://vpc.visualwin.com - Does <insert OS name> work on VPC 2004? Find out
here
Only reply by newsgroup. I do not do technical support via email. Any
emails I have not authorized are deleted before I see them.


[quoted text, click to view]

Bernard
5/31/2004 6:32:17 PM
You meant 'directory traversal' not buffer overflow.

--
Regards,
Bernard Cheah
http://www.tryiis.com/
http://support.microsoft.com/
http://www.msmvps.com/bernard/



[quoted text, click to view]

Paul Lynch
6/1/2004 9:56:44 AM
On Tue, 1 Jun 2004 16:08:02 +0800, "Bernard"
[quoted text, click to view]

The Nimda worm (which was essentially a directory traversal attack)
made use of the buffer overflow vulnerabilities previously exploited
by the Code Red II worm.


Regards,

Paul Lynch
Paul Lynch
6/1/2004 9:57:03 AM
On Mon, 31 May 2004 12:55:25 -0400, "Jonathan Maltz [MS-MVP]"
[quoted text, click to view]

Yes, thats what Nimda was doing.


Regards,

Paul Lynch
Bernard
6/1/2004 4:08:02 PM
Errr.... not sure. but I guess no ?
As it's two different techniques, and the former mainly execute arbitary
codes to attack. which does not really involve in directory travese ?

--
Regards,
Bernard Cheah
http://www.tryiis.com/
http://support.microsoft.com/
http://www.msmvps.com/bernard/



[quoted text, click to view]

Bernard
6/1/2004 5:20:29 PM
I see ! I know now. but it is using two exploits then.
it's using a)directory travese and b)buffer overflow.

a buffer overflow could be using directory travesal or not using it, to
overrun the program buffer.

--
Regards,
Bernard Cheah
http://www.tryiis.com/
http://support.microsoft.com/
http://www.msmvps.com/bernard/



[quoted text, click to view]

jcochran.nospam NO[at]SPAM naplesgov.com
6/1/2004 10:39:37 PM
On Sat, 29 May 2004 16:01:04 -0700, Ryan Riddell
[quoted text, click to view]

It's a great idea to separate the content partition from the OS
partition. But it's not much of a security help.
[quoted text, click to view]

If they can take control of one partition, you've already lost.


[quoted text, click to view]

It would hose the web server, and anything else on that partition.
Which is bad enough already. So concentrate on keeping them out, not
keeping them from getting into the bedroom once they climbed in the
living room window.

John Alderson
6/2/2004 6:40:05 AM

[quoted text, click to view]

Whoa Paul. Hold on here. Nimda did NOT depend on Code
Red backdoors, etc. The two worms are entirely separate
entities with entirely separate attack vectors.

Code Red was a buffer overrun in the Index Server
components, not even strictly an IIS problem. This is
similar to MS03-007, called the WebDAV vulnerability,
which is really an OS issue that just happens to be
accessible via IIS but could be accessible via any other
program listening on the network and manipulating the
file system.

See eEye's analysis of Code Red and Code Red II.
http://www.eeye.com/html/Research/Advisories/AL20010717.ht
ml
http://www.eeye.com/html/Research/Advisories/AL20010804.ht
ml

CodeRed II introduced the C:\ and D:\ virtual directory
mappings. Is that what you are thinking of Paul? While
those were used by script kiddie attack kits in the
months after Nimda and Code Red hit, they weren't part of
the Nimda threat. They are also a great illustration of
why it's a best practice to flatten and rebuild infected
systems. Folks that thought they had 'cleaned' CRII
still had these huge backdoors open.

Nimda took advantage of the Unicode directory traversal
bug detailed here:
http://www.microsoft.com/technet/security/bulletin/MS00-
078.mspx

This was the main vector, although there was also the
share and email vectors. However, the main vector once
the worm was inside the perimeter was direct IIS to IIS
infection via poorly configured web servers. In order to
carry out the infection, the worm required a number of
prerequisites to be present.

1. The web server must have a virtual directory marked
with Execute access on the system partition (C:\)
2. The anonymous user must have write access to this
virtual directory
3. The anonymous user must have execute access to
CMD.EXE and TFTP.EXE.
4. Obviously, the server must be susceptible to the
drectory traversal attacks detailed in MS00-078 and/or
MS01-026.

There were no buffer overruns used. Even if you had not
patched your systems for MS00-078 or MS01-026, you would
be protected from Nimda and variants by simply removing
#1 or #3 above.

The bottom line is, by moving your content off of the
system partition, you absolutely have a more secure
system. If one took ONLY that step back in 2001, their
server would not have been infected by Nimda.

John Alderson
6/2/2004 6:49:16 AM

[quoted text, click to view]


I have to disagree Jeff. Take a look at my reply to Paul
Lynch in this thread on Nimda vs. CodeRed. Even if the
*only* thing you did was move your web content off of the
OS partition - that would have protected you from Nimda,
it's variants and many scripted attack kits.

Even if, for the sake of argument, we assume that there
will never again be a directory traversal vulnerability
in IIS, what about the third party code you might have
loaded up to get at some functionality? What about the
custom application code? There are many sources of input
to a reasonably functional web application.


[quoted text, click to view]
control of IIS they are sort of stuck on the individual
partition.
[quoted text, click to view]

Let me borrow your analogy here. By virtue of allowing
connection from the network, you are already letting them
into the house. Keep them in the front hall/living room
by strictly segregating content, don't give them the run
of the house ;-)

Paul Lynch
6/2/2004 3:12:22 PM
On Wed, 2 Jun 2004 06:40:05 -0700, "John Alderson"
[quoted text, click to view]

Really ? I beg to differ. And so, it would appear do, CERT.

No offence John, but I'll take their word over yours every time :-)

"Overview

The CERT/CC has received reports of new malicious code known as the
"W32/Nimda worm" or the "Concept Virus (CV) v.5." This new worm
appears to spread by multiple mechanisms:

< SNIP >

from client to web server via scanning for the back doors left behind
by the "Code Red II" (IN-2001-09), and "sadmind/IIS" (CA-2001-11)
worms "

http://www.cert.org/advisories/CA-2001-26.html


Regards,

Paul Lynch
jcochran.nospam NO[at]SPAM naplesgov.com
6/2/2004 11:39:35 PM
On Wed, 2 Jun 2004 06:49:16 -0700, "John Alderson"
[quoted text, click to view]

Or, had you installed the security patch, available six months prior
to Code Red and a year prior to Nimda, you would have accomplished the
same. Or even more prudently, moved the CMD.EXE file to a separate
directory, a practice which has died off in the last decade since DOS
bulletin boards have dropped out of style.

Scripted attacks using any directory traversal are also not possible
under Server 2003, the OS the original poster said he's running.
Thus, moving the folder to another volume to prevent directory
traversal is "not much of a security help."

[quoted text, click to view]

And no way to predict the attack vector, nor to predict the mode of
attack. Which makes moving the folder to a separate partition a shot
in the dark that currently is of little use. Like changing the
version reported for IIS and FTP banners, advising the change for
security reasons is potentially more harmful since it imbues a false
sense of security.

[quoted text, click to view]

Or deny all connections and keep them out. All security is a matter
of balances. And anyone who is able to control a partition already
has too much control. Even the ability to change content on a
partition is too much access, and at that point a server should be
rebuilt from scratch.

John Alderson
6/3/2004 6:20:20 AM

[quoted text, click to view]

I apologize Paul. My recollection was that the CR backdoors were one of the
many variants that came after the original Nimda. I was doing Incident
Response as well as server support at the time of Nimda so I have vivid
memories of the event ;-) The CR backdoor angle was academic for me as I
didn't see any of those in the wild and so didn't have that angle
prominently in my memory. I should have done better homework. During that
time, servers I managed had configs as I've described in this thread and
didn't require an ounce of effort during either CR or Nimda. Others within
my company were not so well off...

However, your original description is misleading. I chose the wrong
phrasing in response - but fundamentally the CR backdoors were at the point
of Nimda simply misconfigurations from an IIS perspective. IIS was simply
serving what it thought was a legitimate request to
/c/winnt/system32/cmd.exe because the vdir existed, had X access and the
anonymous users had X to cmd.exe. I'm not trying to minimize the link
between them but for the purposes of the OP in determining how best to
protect his system, an understanding of the fundamental threat is necessary.
In this case, Nimda was not using any buffer overrun, just a
misconfiguration. It was a misconfiguration that resulted from a buffer
overrun and subsequent full compromise of a server but for the purposes of
attack vector identification and mitigation strategy development, IIS was
doing what it was configured to do.

The point I'm trying to make is that simple, common sense configurations
(removing Index Server mappings if not used for CodeRed, restricting access
via NTFS to cmd.exe, moving web content, etc for Nimda) do result in
substantial security gains for IIS installations. I'm not preaching to you
as I'm confident that you understand these fundamentals from your postings
here. But I do want to give people like the OP, Ryan, practical examples of
why it makes sense to take the time to put together a solid configuration to
start with. IIS 6.0 bears that premise out nicely as well.

Anyway, again I apologize for the inaccuracy.

John Alderson
John Alderson
6/3/2004 6:40:13 AM

[quoted text, click to view]

Hi Jeff,

Moving cmd.exe and setting proper NTFS permissions would accomplish the same
goal, would you agree? Clearly, many people hadn't applied the patch ;-)
At the time, for my servers anyway, the patch was scheduled for the next
maintenance cycle which was a month or so away when Nimda hit. But I had
already assessed that the configuration disallowed meaninful exploitation.
This was proven out during the outbreak.

[quoted text, click to view]

Here, we know the attack vector - directory traversal. What we don't know
is what component will fall to it. However, rather than treating the
symptoms - component X allows directory traversal - treat the problem.
Directory traversal allows you to break out of a web root and move *on that
volume*. If we agree that the majority of sensitive executables that could
do us damage reside on the OS partition, then not allowing any Directory
Traversal from wherever it might be from occurring on that volume is a
positive security step.

I've given proven, real world examples here of where that step alone
provided tangible and effective defense of otherwise defenseless servers. I
would submit that assuming that there won't be some component, either OS or
3rd party, that allows for directory traversal on a server that you might
control is a bad assumption.

[quoted text, click to view]

Give the book Exploiting Software a look, particularly with respect to heap
overflows. That mechanism in particular is what I was thinking of when I
rewrote your analogy. I think you'll see what I mean. Any time you are
allowing outside parties to connect to your system and send you data, you
are at risk. You're right, security is a matter of balances and managing
risk. Knowing where your threats are coming from is essential in that
battle.

John
Paul Lynch
6/3/2004 12:31:10 PM
On Thu, 3 Jun 2004 06:20:20 -0400, "John Alderson"
[quoted text, click to view]


[quoted text, click to view]

John,

No need to apologize. Having re-read the OP's question I agree with
your comments entirely :-)


Regards,

Paul Lynch
jcochran.nospam NO[at]SPAM naplesgov.com
6/3/2004 6:05:02 PM
[quoted text, click to view]

Keep in mind I'm not arguing you're wrong, I just pointed out that *in
the original poster's setup* moving the IIS content to a separate
partition wasn't as much of a benefit for security as he assumed. And
I am still concerned about the number of people who may move the
folders and falsely assume they are now thoroughly protected. There
are no definitive answers for secuity, it's a process, not an event.

Plus, you state a condition with third party controls and other code
that may be in error, and I submit that the vast majority of security
breaches aren't due to bad code as much as poor administrators. Or at
least poor administrator's not patching or adapting to bad code.

And for what it's worth, I wasn't affected by Code Red either, even on
the two test servers we hadn't patched, since I had the content on a
separate partition... :)

Paul page
6/10/2004 10:31:02 AM
Logically- Depending on your RAID configuration, accesss to one partition means access to all partitions and even if you are not striping your data if access is gained to one partition it is only a few more steps (hacks) to the other partitions.

Theoretically - having a separate partition for your webserver seems like a good idea but hardly makes your other partitions or data anymore secure from outside attackers. The most important things to remember as far as security are root pass, user pass, and superusers, ensure you change this info on a revolving basis and make sure your passes are not common names but a mixture of characters, numbers and punctuation. Rename Local Administrator account on server to something other than administrator or admin, make all passwords difficult for dictionary attacks, password (.,RyZl76vQ) took my brute force cracker more than 39 hours to crack. Ensure all the latest patches/hotfixes have been applied, implement network layer firewalls and intrusion detection (depending on your critical needs).

Got something to say? Click here to post a reply to this thread.
Don't see what you're looking for? Try a search.
View other messages about iis security
AddThis Social Bookmark Button
View Other Months
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
home · blog · groups Questions? Comments? Contact the dn