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
---------------------------------------------------------------------------
---------------------------------------------------------------------------
