Re: Configuration Arguments... In House...

[\"D. Clyde Williamson\" <D Clyde Williamson]

Agreed, I'm not beating on IIS in particular, (though that is one of
my favorite hobbies) eEye and company are merely examples of how a
system could be compromised. No one should be willing to bet their
corporate security on any single piece of software. Not an FTP deamon
or HTTP deamon etc. Exploits happen, and if the box that gets
exploited in on the internal /trusted/ network, then the network is
compromised. Yuchhy, Yuchhy.


Otto Goencz writes:
 > First of all, I do agree with your suggestion about isolating the web
 > server, but the eEye vulnerability is another ball game.
 > 
 > A properly secured IIS server would not be vulnerable to the Unicode
 > exploits, or eEye vulnerability for couple of reasons. One is the ACL on the
 > cmd.exe, which prohibits the user IUSR_MACHINE accessing it. The other is a
 > simple file move. By default the cmd.exe is in the Winnt\System32 folder.
 > Just create a new folder, like %any drive%:\Stayaway, and move most of the
 > executables there from the System32 folder. The local execution of the
 > commands are also disabled by the move, however they can be executed from
 > the new folder. A small inconvenience at the most.
 > The Unicode, which depends on those executables being in at the default
 > location, becomes useless. Even if the proper location of the cmd.exe
 > becomes known, the ACL would prevent the execution. Every web server has
 > exploits, however, leaving the server unpached should be blamed on the admin
 > not on the actual server.
 > 
 > Otto
 > 
 > ----- Original Message -----
 > From: "D. Clyde Williamson" <[EMAIL PROTECTED]>
 > To: "Brian Steele" <[EMAIL PROTECTED]>
 > Cc: <[EMAIL PROTECTED]>
 > Sent: Friday, February 02, 2001 11:55 AM
 > Subject: Re: Configuration Arguments... In House...
 > 
 > 
 > >
 > > Let's use the example of the eEye vulnerability. With this attack, the
 > > webserver on port 80 could be dumped and a hacked copy of netcat
 > > could replace it... the proxy would still permit this traffic, (if the
 > > proxy is set to look for specific http stuff in the stream... a
 > > hacked copy of netcat client could pass commands wrapped in what looks
 > > like http, and the server could strip the http, and execute the
 > > commands) and the attacker would be sitting at an Administrator
 > > prompt. From there he could telnet to other servers in the network, or
 > > install a packet sniffer, or L0phtcrack, or work on the proxy server
 > > from behind, and attempt to install a backdoor on the proxy
 > > itself. Then he would be able to connect to the proxy directly, and
 > > gain access to the network.
 > >
 > > It is always best to use the idea of isolation, any system touched by
 > > 'untrusted' users or networks should be quarantined from the corporate
 > > network.
 > >
 > > Brian Steele writes:
 > >  > Hmm.. Can someone give an example of how a "compromise" that opens the
 > >  > internal network to the attacker could work, if the proxy server is
 > passing
 > >  > only HTTP traffic on port 80 between the internal server and the
 > Internet
 > >  > client?
 > >  >
 > >  >
 > >  > Brian
 > >  >
 > >  >
 > >  > ----- Original Message -----
 > >  > From: "Paul Cardon" <[EMAIL PROTECTED]>
 > >  > To: "Kelly Slavens" <[EMAIL PROTECTED]>
 > >  > Cc: <[EMAIL PROTECTED]>
 > >  > Sent: Friday, February 02, 2001 11:55 AM
 > >  > Subject: Re: Configuration Arguments... In House...
 > >  >
 > >  >
 > >  > > Kelly Slavens wrote:
 > >  > > >
 > >  > > >          I have a situation where I have a Server, which will host
 > web
 > >  > > > content from "Internal" Data to the external world. This Server
 > Needs
 > >  > only
 > >  > > > have web services accessible to the outside world beyond our
 > network.
 > >  > Our
 > >  > > > current configuration is a Cisco Hardware Nat/Router Packet filter
 > >  > directly
 > >  > > > connected to the Internet connection. Connected to that is our
 > MSProx2.0
 > >  > > > (Being replaced with ISA Server soon)... One individual wishes to
 > place
 > >  > this
 > >  > > > new web server directly behind the NAT alongside the Prox, With a
 > so
 > >  > called
 > >  > > > "one way" push only network connection to the internal network.
 > This
 > >  > seems
 > >  > > > like a bad idea to me. My suggestion was Place the Web server
 > behind the
 > >  > > > prox and use Reverse prox to redirect all web traffic to only this
 > >  > single
 > >  > > > internal Web server. This to me seems to be more secure than a
 > second
 > >  > > > machine sitting in the DMZ with a connection to the internal
 > network.
 > >  > >
 > >  > > With the web server behind the Proxy, if the web server is
 > compromised
 > >  > > (eg. IIS Unicode vulnerability) then the entire internal network is
 > open
 > >  > > to the attacker.  The other configuration is better but it isn't the
 > >  > > only solution.
 > >  > >
 > >  > > -paul
 > >  > > -
 > >  > > [To unsubscribe, send mail to [EMAIL PROTECTED] with
 > >  > > "unsubscribe firewalls" in the body of the message.]
 > >  >
 > >  > -
 > >  > [To unsubscribe, send mail to [EMAIL PROTECTED] with
 > >  > "unsubscribe firewalls" in the body of the message.]
 > >
 > > -
 > > [To unsubscribe, send mail to [EMAIL PROTECTED] with
 > > "unsubscribe firewalls" in the body of the message.]
 > >
 > 

-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]