Locking out AD?

[Triage]

Occasionally we experience brute force attacks in the form of a non-domain member infected machine getting the list of users from our AD, then trying a dictionary attack on their accounts. How do we shield our AD from the outside so this info (user accounts, etc) cannot be seen?

Thanks!

"I enjoyed my youth so much that I decided to bring it along with me."
-GC

 

[gmail2]

hmmm ... I'm by no means a security expert, but firstly, what do you mean by a non-domain "infected" machine. Are you saying that the attack is being done by a virus? By default all users have Read Only permissions to accounts, groups etc on AD - so even if that machine is not joined to the domain, if it is being operated by a user who knows a domain username and password (either legitimately or otherwise) then they would be able to easy get a list of domain users. Is this computer connected to your corporate network? if it's compromizing your security then why not remove it?

A few things you can do:
1. Define a security policy that will lock out user accounts after x (typically 3) unsuccessful logon attempts.
2. Define a policy that says users must change their password after x days (maybe 45).
3. Enable password complexity - that will make it harder for dictionary attacks to be successful because the passwords will need to have letters, numbers, special characters etc. Also define a minimum length (6 as an absolute minimum).
4. Some friday evening, turn on the "user must change password at next login" for all users - just once so that all users will have to change their password. Do this after you've defined the above policies

In addition to no. 2 above, you may also want to define a MINIMUM password age. This may sound strange at first, but if you don't define this (default 0) it means that when a user's password expires, they can pick a new password, then change back to their old password again straight away. So defining a minimum password lenght prevents this. Or alternatively define the number of passwords to remember - but bear in mind that AD will not remember passwords that were used before this policy was enabled.

Also, I presume you have a firewall protecting your network. Make sure that the policies here are water tight ... this will make it harder for virisus to propagate and also keep unwanted intruders out. If you're worried that visitors are connecting to your LAN without your permission/knowledge then you can invest in some software that will check that all of your PC's have AV software installed etc (you define the requirements for each PC to have). I've never used one of these - but try out

http://www.landesk.com

OK, I hope I've given you enough food for thought here. Post back with more details and we'll see what else we can do to help.

Good Luck !!

Irish Poetry - Karen O'Connor
Irish Poetry and Short Stories - Doghouse Books
Garten und Landschaftsbau

 

[gmail2]

... you may also want to define a MINIMUM password age ... Or alternatively define the number of passwords to remember ...

Sorry, I'm wrong - you should probably define both actually. If AD remembers the last 3 passwords used without defining minimum password age, then users could just change their password 3 times in the same day and then back to their original password. It may sound like alot of work for somebody to go to, just to keep their password, but we are escentially dealing with a potential security compromize here.

Or course the down side to this is users forgetting their passwords, locking out their accounts etc, but it can be difficult to get a right balance between user friendlyness and security. If you trust you are from a large organization and trust your managers enough, then you could give them permission to unlock user accounts and/or reset user passwords JUST for their department. But if you don't think your department managers are very security conscious then don't do this as all you're really doing is opening up another hole for unauthorized users to access or even modify AD.

OK, I've said enough now. Hope I haven't confused you too much. Hopefully somebody else who'se a bit more AD security savvy will post and might have some better ideas.

Irish Poetry - Karen O'Connor
Irish Poetry and Short Stories - Doghouse Books
Garten und Landschaftsbau

 

[Triage]

By default all users have Read Only permissions to accounts, groups etc on AD - so even if that machine is not joined to the domain, if it is being operated by a user who knows a domain username and password (either legitimately or otherwise) then they would be able to easy get a list of domain users.

What would be the downside if I did deny the Read Only permissions for accounts and groups?

Thanks!

"I enjoyed my youth so much that I decided to bring it along with me."
-GC

 

[markdmac]

I would begin focusing on the firewall. What ports do you have open and why?

You probably just need the following ports to be open:

IP 80 (http)
IP 443 (https)
IP 25 (smtp)
UDP 123 (time sync)

and maybe 3389 for RDP.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[58sniper]

I'd even close 80 if you're only using https for OWA and nothing else.

Pat Richard, MCSE MCSA:Messaging CNA
Microsoft Exchange MVP

 

[markdmac]

Correction to my post, those are TCP not IP ports.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[markdmac]

Pat, I like to allow port 80 but then setup the automatic redirect to https. This allows my users to use the Ctrl+Enter keyboard shortcut when typing addresses in IE.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[SuperJenks]

If a pc on the network has been comprimised, there is not much you can do to stop them from gaining knowledge of users in the AD other than what GMail2 suggested which is remove the pc. Its likely that if a hacker has somehow found a way into the network, that he knows the IP subnet of the network and could do a "nbtstat" command to a range of IPs which will return domain, group and user names logged into any given pc. It's unlikely they are querying that information from the AD itself but from the client pcs. You could always enable windows firewall on all client pc's but could possibly deny other applications running on pc's unless you create a script to add exceptions to windows firewall. I think you need to really figure out the source of the attack. If you can close the door on them, problem solved. What kind of firewall do you have?

 

[Triage]

The source of the attack is a machine from a neighboring department from within our institution, and it has been subsequently removed from the network. I was just curious as to how our info (usernames) could be accessed from such a machine, but your nbstat theory may very well be the answer. Our client machines are running the Windows firewall, but could the nbstat commands still get around that?

Thanks!

"I enjoyed my youth so much that I decided to bring it along with me."
-GC

 

[markdmac]

So the machine was physically on your network but not a member of the domain?

Does your institution have any standards for AntiVirus or SpyWare detection?

Where/how did the machine become infected?

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at

http://www.thespidersparlor.com/vbscript

Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.

 

[SuperJenks]

No, windows firewall will block all nbtstat requests unless there is an exception for the netbios port in windows firewall.

 

[SuperJenks]

As for how the hacker got in, there could be many ways. It was most likely a user internally that initiated a browser request to an unsecured website and likely got infected with a trojan downloader of some sort. That is the most common method of security breaches. Once that little sucker is executed on the target machine, it likely sends a email, msg or even worse, an irc bot notification to all their hacking buddies. Trojan downloaders are also known for sending the local users name and passwords if any are cached on the machine, or password dump. You get the idea though. Did you happen to notice if the brute-force attacks came from the same IP or multiple IPs?

 

[Triage]

Our SNORT log just showed the one IP address, and the event log on the target AD machine was identifying the failed login attempts of the offending machine by name and IP.

"I enjoyed my youth so much that I decided to bring it along with me."
-GC