I wrote:
> Why would you put your firewall into the same authentication domain as
> your users?
>
> Maybe I'm missing something, but that seems like you're putting an awful
> lot of trust in the NT security model.
Russ responds:
> Actually, its possible to establish a trust relationship between two
> seperate NT domains such that attempts to log onto the Firewall Domain
> would be validated against an internal Administrative Domain, but accounts
> on the Firewall Domain would not be permitted to log into the
> Administrative Domain.
Like I said, you're putting an awful lot of trust in the NT security model.
And in any case that doesn't even begin to address my concerns. That reduces
the security of the firewall to the security of your administrative domain.
My firewall doesn't trust any other host... all administration has to be
done from the console. Users even have to go through challenge-response to
change their passphrases, or request a new one from me if they forget them.
> So even if the Firewall were compromised, none of its accounts would be
> permitted to access the resources protected internally by the
> Administrative Domain security,
And if the Administrative Domain is compromised (say by an ActiveX trapdoor),
the firewall is wide open to whatever additional holes the malicious code is
capable of installing.
And... I've mentioned this before, but the biggest invasion of a system I
know of was the result of a cracker stumbling across a trapdoor left by a
naive insider. I'd prefer it if this sort of compromise of internal security
didn't leave a company open to a secondary infection.
References:
|
|
