|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: *potential* Windows 2000 holes
From: David LeBlanc (dleblanc
MINDSPRING.COM)Date: Fri Oct 13 2000 - 14:17:24 CDT
- Next message: Phil Cox: "Re: *potential* Windows 2000 holes"
- Previous message: Jesper M. Johansson: "Re: *potential* Windows 2000 holes"
- In reply to: Phil Cox: "Re: *potential* Windows 2000 holes"
- Next in thread: Paul Leach: "Re: *potential* Windows 2000 holes"
- Reply: David LeBlanc: "Re: *potential* Windows 2000 holes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 06:01 PM 10/12/00 -0700, Phil Cox wrote:
>-----Original Message-----
>From: Paul Leach [mailto:paulle
EXCHANGE.MICROSOFT.COM]
>> > From: "Phil Cox" <Phil.Cox
SystemExperts.com>
>> > > Thus if anonymous connections are allowed, then this may be
>> > a way in if
>> > > security is highly reliant on GPOs.
>> I would comment, in general, that machine A can and should never
>> rely for its security on machine B having had group policy applied.
>> I can always bring in my own laptop running Linux and attach it to
>> the network, and it won't have group policy applied.
>If I am not mistaken, I see the situation more in the light of a potential
>attacker using an anonymous connection to not have GP applied. Follow me...
>As an admin, I just read a great book (Windows 2000 Security Handbook,
>shameless plug), and it told me how I should be applying security in a
>centralized manner with GPOs. So I set all of these restrictions, and have a
>super robust set of GPOs to restrict and limit users. If I was not mindful
>(i.e. set "apply to" to the Everyone group), an attacker could connect with
>an anonymous connection, and be totally unencumbered by my terrific user
>GPOs.
I think there might be a little bit of confusion here - first of all, we
can use domain-level machine policies to enforce consistent machine
security policies across a domain. This happens when the machine boots as a
member of a domain, joins a domain, and at certain refresh intervals.
Now if you're talking user policies, not machine policies, then we have to
look at what is and is not appropriate use of user polcies. We absolutely
cannot depend on user-level policies to secure a server from clients - the
attacker probably controls their own hardware to a high degree, and can use
a client system that isn't even joined into the domain, or is running a
different OS - many, many possibilities. A user-level policy is meant to
restrict what the client can do on the system where they have logged on
locally, so anonymous connections aren't an issue. The client system is
pulling down a policy that it uses to protect itself from the user.
>I will say that for this to happen, you have to allow anonymous connections
>that an attacker can use, and you have to have fully invested in the GPO
>style of management. The first should be a show stopper, but the second is
>what Microsoft would have you move towards (and I agree).
Also, let's step back and get some idea of what really affects security and
what doesn't. For example, if you have domain admin with password same as
user name, then nearly anything you do aside from correcting that problem
won't really help the overall security much. It is a matter of identifying
and correcting the weakest link. I've seen situations where people were
worried about really arcane stuff like permissions on the SAM file (they're
fine) while having the backup server running as a domain admin level user
on a machine with a blank admin password.
The real weak links are generally systems with weak local admin passwords,
systems missing critical hotfixes and service packs, and then we can move
on into bad management practices like having too many domain admin-level
users. If you've got a network where the weak link is whether or not the
GPO gets applied, then I'd like to see it.
David LeBlanc
dleblanc
mindspring.com
_____________________________________________________________________
** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listserv
listserv.ntsecurity.net
- Next message: Phil Cox: "Re: *potential* Windows 2000 holes"
- Previous message: Jesper M. Johansson: "Re: *potential* Windows 2000 holes"
- In reply to: Phil Cox: "Re: *potential* Windows 2000 holes"
- Next in thread: Paul Leach: "Re: *potential* Windows 2000 holes"
- Reply: David LeBlanc: "Re: *potential* Windows 2000 holes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]