Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-Microsoft
[Top] [All Lists]

RE: Domain Controller Best Practice - Thanks!

Subject: RE: Domain Controller Best Practice - Thanks!
Date: Thu, 03 Mar 2005 11:36:10 -0500
Jerry,

1. You are correct about the virus issue.  

2. Out of the box, users have access this server from the network on all
the domain controllers.  I.e. They already have the capability to use
any of the remote admin access vulnerability to gain Admin right to the
domain.  (You do patch your domain controllers right!!!)

3.  This default behavior is changed in Windows 2003 I believe.

4.  Having access to shares on the server does not give you the ability
to logon via terminal services.  The former requires "Access this
computer from the network" while the later require "logon locally"
rights.

Dennis


-----Original Message-----
From: Murtland, Jerry [mailto:MurtlandJ@Grangeinsurance.com] 
Sent: Sunday, February 27, 2005 7:21 PM
To: 'Frank Knobbe'
Cc: focus-ms@securityfocus.com
Subject: RE: Domain Controller Best Practice - Thanks!

I'm not even sure where to start.  I've gone over this a few times, and
there are just too many things wrong with this scenario.  I'm not going
to
go into details about how to hack a Windows box for obvious reasons, but
here are some simple no brainers:

1.  Single Point of Failure (Infrastructure)  A virus on this machine
can
knock out your entire infrastructure.  A trojan on this machine and the
integrity of your data, along with protection of any sensitive
information
is gone.

2.  Even if they don't have access locally, you give them access to the
box
over the network.  Pick any one of Microsoft's critical (Remote Admin
Access) vulnerabilities coming out each month to gain access to the box
with
a legitimate User ID and Pass to the system.  (Example:
http://www.microsoft.com/technet/security/Bulletin/MS05-011.mspx)  SMB
traffic has been known to have tons of vulnerabilities, just do a google
search on "SMB Vulnerability".  There is ample traffic to be footprinted
to
identify what systems do what, especially if authentication and file
sharing
happen to go to the same IP.  Remember, defense in depth.  Your internal
users are more dangerous than your external threats.  It's one thing to
authenticate everyone on this system, but it's another to give everyone
access to this system via share permissions.

3.  You may not be sharing your SAM file, but then again you probably
don't
need to after a simple Null Session displays every user ID on the
system.
And isn't it just handy that this same system is the Domain Controller.
Frank, you are probably familiar with this, but here is a link:
http://www.softheap.com/security/session-access.html.

4.  Remember there is a difference between shares and NTFS permission
access.  If you have shared permission on this system, the users ID's
are
authenticated locally as well.  This means that Terminal Services can be
used to access the system via remote access.  I think you mentioned that
you
would use NTFS throughout your system, this would be critical if you
want to
keep users off your DC.

Generally speaking and in your defense, you can come up with security
controls for just about any attack I throw out there. The key is knowing
how
much time you plan to spend on keeping your system up to date with
patches
(testing included), anti-virus, log reviews, user access reviews, etc.

I certainly am not trying to sell fear, my job is to minimize it by
deploying those security controls of which we are both speaking.  Is it
incredibly wrong to put both on the same system?  Maybe, maybe not.
It's
certainly not best practice, but it's also not the end of the world.
For
every pro there's a con and visa versa.


Jerry J. Murtland, CISSP



-----Original Message-----
From: Frank Knobbe [mailto:frank@knobbe.us]
Sent: Saturday, February 26, 2005 11:00 PM
To: Murtland, Jerry
Cc: focus-ms@securityfocus.com
Subject: RE: Domain Controller Best Practice - Thanks!


On Thu, 2005-02-24 at 16:00 -0500, Murtland, Jerry wrote:
I don't think I've heard anyone say that "you are not creating a real
security risk by allowing your DC to also function as a file server".
In
fact you are.  All user authentication is occurring on this system.
User
ID's and Passwords for your entire organization are stored here in the
SAM
file.  I would consider this a substantial risk to any IT
infrastructure.

But you wouldn't be sharing the "SAM file" now, would you?

Aside from availability/load issues, what security risks are really
present? You have a Domain Controller in your network. Network
authentication is possible/exposed one way or another. One the other
hand, you have a simple file server service files via a share point. Why
can't the domain controller also be sharing files? (Again, focus on
security, not availability concerns. For this example, assume that hosts
has oodles of CPU power and bandwidth, and the share is located on a
separate dive from the AD data.)

Could you please outline some attack vectors that you would not have on
a layout using two servers (one for authentication and one for file
sharing)? Remember, we're talking access to file shares, not local logon
access.

Thanks in advance,
Frank



------------------------------------------------------------------------
---
------------------------------------------------------------------------
---


---------------------------------------------------------------------------
---------------------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>