I completely agree with this and I would rather prefer to have the Web
servers running on a Unix box, but unfortunately this is not the case
since the customer has already chosen to use NT.
What you are suggesting has already been done in the very same fashion
it would have been done on a Unix server. The Web servers are behind
a router with an access list enable, and all services but HTTP are
turned of
on the servers. However this is not enough: in a properly designed
firewall
this is the first part, the second part consists of tools and procedure
to detect if an attacker manages to break in. This is the part I am
missing. There is also a third part (how to respond to an attack) which
is however irrelevant for this discussion.
Basically, if an attacker manages to break in, exploting a bug in the
HTTP
server or in a cgi script or the like, the access list on the router is
not going to help much. I could still detect the intruder on a Unix
server
with tools like Tripwire and others. What about NT? Do we have anything
like that available on NT? NT experts, are you listening?
--
Alberto U. Begliomini Email: aub @
sirius .
com
Coldstone Consulting Phone: 415-370-7723
Theory guides, experiment decides. Fax: 415-631-8722
> Alberto> I am looking for documentation, articles, and papers on how
> Alberto> to make a NT Web server, sitting on the perimeter network of
> Alberto> a firewall, secure.
>
> Aside from the philosophical point that you can never really
> understand your risk level with a closed system (i.e., Microsoft
> didn't even know their risk, and was taken off the 'net for two days
> last week), there are some things that you can do practically.
>
> I can't comment on what tools you can run on an NT host...hopefully
> others can.
>
> Stuff to do:
> o Go write your policy. Articulate, on paper, or electrons, exactly
> what hosts will be out there, which IP addresses will be active,
> which ports on each IP will be active, what daemon or service will
> be responsible for each of those ports, etc. Now you can implement
> your solution based on that policy. If you get run over by a bus
> or quit suddenly, etc., the poor sucker who has to take over with
> no introduction to how things have been set up won't be such a poor
> sucker after all.
>
> o Don't run any service you don't need
>
> o Turn on access control lists on your access router. If it's a web
> server, don't let anything but tcp/80 come in through the router to
> that host. (If you've got other ports doing HTTP, then let them
> in, of course, but don't let in anything besides the services you
> need.)
>
> o If you can, try and rig and alarm such that if anyone DOES hit a
> port on that machine that the router is supposed to block, you'll
> know about it quickly.
>
> Again, this is not rocket science, but just a straightforward view of
> your network and all of its components as a bunch of pieces that
> collectively make your network secure.
>
> --
> Matt Curtin Chief Scientist Megasoft Online cmcurtin @
research .
megasoft .
com
> http://www.research.megasoft.com/people/cmcurtin/ I speak only for myself
> Pull AGIS.NET's plug! DES has fallen! http://www.frii.com/~rcv/deschall.htm
References:
|
|
