Re: [ActiveDir] Domain Controller Security

[Kamlesh Parmar]

I agree, thanks joe, for your efforts !

Your answers always widens my thinking horizons,

 

I am not into ADS extensively, like you all experts, but have ambition to become one. 

I have to go long way, and I am here to learn.

 

joe> How exactly are you monitoring your group memberships ?

I am using the logparser utility to parse security eventlogs of DCs for group membership modification events. and just plainly taking a look at all the accounts who are members of special-privilege groups thru nested grouping.

 

I am also trying to setup a system for monitoring & reporting the changes to some specific user attributes. :-)

And changes made to special-privilege groups using some SPECIAL account.

 

I would like some pointers for nuts and bolts details of AD.

I already have some mspress books, and AD 2nd edition.

joe, I am eagerly waiting for 3rd edition.

 

 

On 9/24/05, DeStefano, Dan <[EMAIL PROTECTED]> wrote:

As lucid, eloquent and logical as ever, joe.

 

 

Dan

 

---

From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of joe
Sent: Friday, September 23, 2005 9:59 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Domain Controller Security

 

That is fine, I have no problem with people disagreeing with me. It still won't make me prove a point by documenting how it is done. If I gave a step by step or even a high level that gave people who couldn't figure it out on their own a clue as to how it is done, I would have to kick my own ass.

 

As was stated by others, knowing how this is done does not arm you so that you can do anything more about it. Windows has always had two areas you needed to secure and had different assumptions of who should be in those areas. There is the remote access "zone" and the local access "zone". I am talking from a software angle, not physical. If someone has physical access and can do what they want, there really isn't any security that can not be compromised in some way shape or form.

 

So now you have remote and local access (or unrestricted remote system access such as c$ or registery access, etc). If you have remote access, you have to go up against the fixed function interfaces MS has made available to connect to and manipulate the machine such as LDAP or kerberos or remote RPC calls, etc. These have been built by MS to be as secure as they, at the time they built the interface, could. This is the most secure you will find things to be and even this can be compromised. I simply ask you to review the history of all of the various worms and viruses that have torn through networks infecting machines through unauthenticated remote access. Think RPC interfaces, web interfaces, SQL interfaces, etc. Again, making people use the system resources through remote fixed function access interfaces is going to be the MOST secure you will see. Honestly, for a long time this only secured you against people who didn't want to harm you that were smart enough to keep their machines from being infected by keeping the services that exposed handles to THEIR machines to a minimum and ran firewalls to block all but the smallest amount of remotely activated connections and didn't run code that they didn't fully trust.

 

If you have local access (such as TS to the desktop or remote console), you have bypassed a great deal of the security barriers Microsoft has put into place. You are within at least the semi-trusted zone and quite honestly in my opinion, the pretty much fully trusted zone. You know the MS history in keeping the untrusted zone safe, do you expect the semi-trusted zone to be that much more successful at repelling people trying to do you harm? Look at your own house as an example, once someone is past your locked (lol) windows and doors, how much more security is there in place to make sure people do not get access to sensitive information or modify your stuff in a way that you do not know? Probably little to none because it isn't feasible to audit and/or monitor everything in real time. Further to that, how many automated systems do you have in your house that you have no understanding of and wouldn't know one way or the other if they were compromised and being used against you. How do you know someone hasn't installed a mini-cam in your bathroom and bedroom and not filming your most intimate moments that you want no one to know about. That is very much like the state of having local access on a PC. You giving someone access to your house to put a camera in place and me telling you, hey, they can put a camera in place does not mean you can detect it or prevent it. Your option, is to disallow the person from being in a position where they can easily put that camera in place in to begin with.

 

How exactly are you monitoring your group memberships, what interfaces are being used? Most folks I have seen who implement group monitoring only watch the membership and not both membership and primary group membership. These are recorded differently for LDAP interfaces. In that case, someone could act fast enough and get themselves primary group membership before your LDAP interfaces ever picked up on the membership change. What about the binaries on your machine. Having AV software on your machine doesn't mean the machine isn't compromised. It doesn't look to determine what should be there, it looks at a fixed set of signatures and tried to determine what shouldn't be there based on those signatures. Just because it says that some important exe isn't infected doesn't mean it is what MS produced. Are your favorite plugins and utilities and CPLs all the way they should be from MS or have they been compromised? Has someone replaced one or more of your service or driver binaries? How do you know? This has become more difficult but still isn't 100%, heck it probably still isn't even 50%. Show me someone who can tell me 100% where every single file and component on their machine came from and I can almost certainly show you a liar or at best, a hopeful guesser. I have asked Microsoft for years to publish a database containing checksum codes and file date/times for every single file they have ever installed on any machine ever so that you could scan a machine and determine every file that came from MS (and those that didn't) and where they are from and whether or not they should be on the machine at the current patch level and OS. Sadly, the answer is always a look of incredulity and an admittance that no that isn't even remotely possible. Heck I had someone in a meeting at a MS Security conference tell me that they couldn't even do that with NEW files coming out because too many are coming out through too many different channels...

 

Again, once you are on the local machine, you are in the semi-trusted zone. If someone isn't fully trusted, they shouldn't be there in the first place because once there, someone stupid or someone intentionally out to get you will eventually hurt you. The deck is stacked against you.

 

Right now, we are lucky in that no one who seriously understands the technology has gone after domain controllers and domains and forests as a whole. This means a lot of the possible holes that could be taken advantage of to cause enterprise wide disruption and destruction are not being attacked or at least not being attacked in the most advantageous way possible. You need to be thankful for that because if you can't sit down and work out on your own how someone could attack your forest and you feel that granting local access to DCs is a responsible thing to do then you probably don't have anywhere near the skill set and understanding needed to stop someone who does have the ability to figure it out on their own or has been taught how to do it.

 

Something I like to tell people about with security is simply this.... Just because YOU don't know how to compromise a given system doesn't mean someone else doesn't and it can't be compromised. You can never, yes NEVER, prove a system to be secure, only secure from you. The best you can do is prove a system to be insecure and hopefully come up with a workaround to prevent that insecurity from biting you.

 

If we start publishing the various ways in which someone could compromise your domain controllers, your domains, and your forests, all we have done is lower the bar for the script kiddies and others to start doing it. If someone is adamant about giving local access to domain controllers or even remotely allowing them to reconfigure services and/or modify system components there is nothing that I nor anyone else can do to protect them. Simply step back and let them play Russian roulette on their own.

 

In my mind, anyone who allows people who are not fully trusted DAs local access to DCs or allows remote modification capabilities of system components is simply careless and deserving of anything that happens. This could be you or it could be the manager who forces you to do it after you fought tooth and nail. Microsoft has given you an untrusted area to place untrusted people into and you have decided you know more than they do and that it is safe to put untrusted people into an area that requires trust. At the same time I would both love to see it and hate to see it if some admin who felt so strongly that they knew all of the holes and all of the ways to protect themselves from someone with local access to a DC walked into work one day to find that every single domain controller in their forest had suddenly ceased to be a domain controller or they had been locked out of their own forest.

 

Again, it isn't just local logon capability, it is anything that can be done to modify the system components of a DC. Remotely or locally. Locally is just scarier because the bar is much lower once you are there. Why do you not run email programs as Domain Admins (and if you do run email programs as domain admins I don't care to hear about it, good luck) or any other ID with enhanced rights? Why do people go through the hassle of having multiple IDs, normal business type IDs as well as enhanced privilege IDs?

 

I know I don't know every way a DC, a domain, or a forest can be compromised and/or damaged. THAT is why I don't allow anyone but fully trusted DAs access to DCs that I am responsible for. It isn't because I know of several ways in which it can be compromised. My opinion is such that if I allow a porcupine in my house instead of keeping it outside, I am at some point probably going to get poked. The more determined that porcupine is to poke me, the more likely it is going to happen and the less chance I have to prevent it even though I know it can and I know what that poke will look and feel like. Knowing after the fact that I was poked is moot in my book, too little too late.

 

 

   joe