Anyways...
I'm going to ramble on a bit about the rest of the MS Recommendations from their whitepaper found here:
Instead of a long and drawn out explanation for everything, I'm going to group the remaining findings into categories by what they accomplish and go from there. Many of the remaining "recommendations" are just rehashes (pun intended) of the same old stuff...
Security 101
- Remove standard users from the local admins group
- Limit the number and use of privileged domain accounts
- Secure / manage domain controllers
- Update apps / OS
- Remove LM hashes
Most of the stuff in this category I think is covered by any basic security course. The concept of "least privilege" has been around a while. So has the idea of protecting your critical assets. And let's not forget "Patch Tuesday" because that horse hasn't been beaten dead for years... (Don't forget 3rd party apps!)
LM hashes are kinda fun. Little known fact (and it actually gets a sentence in the whitepaper, I'll leave it to the astute reader to find it) : Even if you have the flag set to not save LM passwords, if the password is 14 characters or less, it is still created and stored in the token in memory. Of course, all of this is overshadowed by the fact that the "Digest Auth Package" (possibly among others) essentially stores the user's password in plaintext, rendering the hashed version irrelevant. (Hint: Search for mimikatz, lazy click here: )
Don't Be Stupid
- Avoid logons to less secure computers that are potentially compromised
- Ensure administrative accounts do not have email accounts
- Configure outbound proxies to deny internet access to privileged accounts
So, clicking on the spam link in my domain admin's email account and then surfing to the porn site is a bad idea? Say it isn't so!
Seriously? I'd like to think that common sense would prevail in most circumstances... however the Darwin awards were created for a reason...
More Pain, Less Gain
- Use remote management tools that do not place reusable creds on a remote computer's memory
- Rebooting workstations / servers
- Smart cards / multifactor authentication
- Jump Servers
- Disable NTLM
The first 2 manage the availability of elevated tokens on the network. This assumes that your network is already pwned. If that's the case, then potentially limiting your ability to manage the network or rebooting really doesn't help out that much...
Smart cards / multifactor auth have been heralded as the next best thing in computer security. However, setting up the necessary infrastructure is crazy expensive, not to mention difficult to implement. Oh, and BTW, there's still hashes stored in AD independent from whatever multifactor auth you've set up that can be easily used to access file shares, email, web sites, etc...
This is because multifactor auth generally only protects "interactive logons". This typically means sitting down in front of the computer and logging in. Some edge applications can be configured to require the use of multifactor auth, such as web sites, vpns, etc. File shares, Outlook, SQL databases and several other applications typically cannot be configured to use multifactor auth. Oh, let's not forget about service accounts... they can't use multi-factor either. Of course all service accounts on your network don't have elevated permissions, right?
An interesting (and often not thought about) side effect of "smart card" logons is that when the check box is selected in Active Directory, the NT password hash is randomized. By default, this new "password" doesn't expire. This means that a 3-year old hashdump or backup of AD is as good as a recent one for the purposes of accessing content as that user on the network. In addition, some places will even set an explicit password for all the accounts, so if that one password is cracked, every user has the same 'password' even though they all have individual smart cards.
One other quick thing... You cannot truly lock out an account via password guessing that has a smart card available. If the person logs in with the smart card, the account is automatically unlocked. This means unlimited attempts at guessing a password even if the password policy is set to lock out after a certain number of bad password attempts!
Jump servers are kinda a strange one to bring up. "In theory" they are placed at the edge of 2 different "security zones" (like DMZ / secure network) and can be used for management of one of the segments. All of the devices in the segment are configured to only allow admin access from the jump server, so it marks a single point of entry. However, this really doesn't do much for the overall security. "In theory" the connections are better monitored or more secure, but in reality, I've never seen an environment that ever used them.
That leaves disabling NTLM. That would solve everything, right? Not exactly. First off, for most apps, NTLM is used when Kerberos cannot be used. There are several conditions where Kerberos cannot be used, namely (among others) when one end of the connection isn't in the domain or is accessed by IP address. Typically NAS/SAN devices typically aren't members of the domain, so they can't use Kerb. Same thing with network-aware devices like printers, digital senders, copy machines, etc... There are usually multiple devices on the network at any given point in time that cannot be joined to the domain.
Secondly, up until fairly recently it was actually impossible to disable NTLM. The only way to do it is to use Windows Server 2008R2 running in the highest domain functional level and everybody's clients must be Windows 7. And since I know that Windows NT, 2000, XP, 2003, Vista and 2008 are completely eradicated from the world like smallpox... oh wait....
No comments:
Post a Comment