Re: Hardening an ISA Server
- From: "Will" <westes-usc@xxxxxxxxxxxxxx>
- Date: Fri, 6 Oct 2006 17:18:59 -0700
"Andy" <andy@xxxxxxxxxx> wrote in message
news:5AC655E1-BD9E-4CB1-ABA3-6970162C0F1A@xxxxxxxxxxxxxxxx
I'm in the process of setting up a new ISA server, and I'm working on theOS
(W2K2 SP1).there
In the ISA Server 2004 hardening guide they state that I should apply the
the Microsoft Baseline Policy. But, in the Windows 2003 Security guide
are 3 levels within this baseline policy. What level should I choose ofthe
3 mentioned to have a secure and functional OS to install ISA to?
My general experience with Microsoft's security policies for high security
levels has been that they break things. What's worse, you open up a
trouble ticket with Microsoft, and what is the first thing they want you to
do to recover from such breakages? That's right, install the zero-security
policy to bring things back to the insecure (but easy to make work)
baseline.
I once had an almost comical conversation with a Microsoft tech support rep
in which I asked if he could supply us any security policy for ISA Server
that would work and that would make the OS more secure than a default OS
install. He couldn't supply us with one, then after some conversation
actually told me that the security policies are actually intended to be used
as "just a general guideline to use in developing your own policy." I
asked him if Microsoft can't make their own OS work in a secure mode with
their own application, then how can the customer? Those kinds of
conversations just go in loops. Microsoft won't take responsibility for
making the OS secure because doing that in a way that won't break many
applications is actually damn hard and requires a significant amount of
human resource to make work. If you are willing to pay more in time than
you paid for the hardware and software together, then by all means go for
it. :)
The core OS SACL and DACL mechanisms look very good to me, and well
implemented throughout the core OS. But the ugly truth is that the higher
level applications, shared DLLs, and various housekeeping directories
layered on top of that don't use security in a very coherent or consistent
way. Reading through the security settings in various subdirectories of
Windows 2000 is almost like looking at a random number generator. It's
difficult to understand why certain things are left so exposed and others
not. One assumes they had 20 teams all competing against a deadline to
just make their code work at all, and security was the last thing anyone
thought about or cared about.
Anyway, Phil's point seems right to me that the firewall protects the box.
But I would add if you are going to rely on the firewall alone, then in your
access rules don't allow any paths into that box, even for remote
management. God forbid you allow any RPC into that box, have someone do a
buffer overflow on some RPC service and install a new RPC service, which
then you can't see clearly on the monitor. If there are zero paths into
the box except from the console, the fact that you did not harden the OS
becomes less of an issue.
--
Will
.
- References:
- Hardening an ISA Server
- From: Andy
- Hardening an ISA Server
- Prev by Date: Re: Any Way to Get Mail Alerts?
- Next by Date: Re: Any Way to Get Mail Alerts?
- Previous by thread: Re: Hardening an ISA Server
- Next by thread: Re: Hardening an ISA Server
- Index(es):
Relevant Pages
|
