• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 441
  • Last Modified:

Locking down a Windows Domain

I need your help with brainstorming ideas:

I am considering writing an EE (go-to) article that outlines best practices for locking down WINDOWS domains. I can't think of every point and would certainly like to get feedback from you on what really works for you.

Any replies will be directly quoted, where you will be accredited and referenced from your input. Let's show these folks what EE can do for them.

For this article, I wish to leave out names of packaged software. Instead, I hope the reader researches the best software packages for his/her environment.

So far, these are the points I have brainstormed:

MAIN POINT:-don't fall under the false impression that an antivirus package protects the user and administrator from getting infected.
1) You might consider looking for a all inclusive package that has both Antivirus and Antispyware
2) look for an AV package that is user friendly and easy to configure for administrators
3) look for an AV package where the manufacturer provides good customer support and feedback
5) Keep an open mind when administrators tell you that their solution is the best for you and expect IT experts to disagree about the best AV package available out there.
6) ask questions on how to best configure that AV package of your choosing for your domain.
7) look for an antivirus enterprise solution that is centrally managed
8) take some time to test, plan and design and IT security package that best suits your needs

-Consider a WSUS server that downloads and installs all critical security updates and service packs by default
-create group policies to manage your updates and how they install

Group policies:
-create group policies that will:
1) prevent LMhash in a kerberos environment
2) govern complex passwords
3) disable autorun on all periphrial devices.
4) prevent simple file sharing
5) maybe software restriction policies
6) control Windows updates

Educate the users and administrators of your LAN:
1) Create a website that explains the different threats and how they come about. You can model after an already existing web site, such as this:
2) consider a mandatory IT security course for users and administrators

1) the differences between software and hardware/NAT firewalls

Outside access to within the domain: (This is a topic I could use some serious help in since I don't allow outside access to my domains)
1) securing outside access to inside the domain. Example secure web access to mail services.

Mail services:
1) preventing open relays
2) Spam controls

Compliance monitoring and enforcement:
Example: Network Access Controls, Vulnerabilty scanners, and IT security awareness coursework monitoring.

1) Enterprise Vulnerabilty auditing tools (Free and commercial)
>>>Examples of these would be helpful<<<
2) Mac filtering for DHCP recipients
>>>More brainstorming can be done on this topic as well<<<

  • 4
  • 3
1 Solution
Rich RumbleSecurity SamuraiCommented:
I covered quite a bit of LUA here: http://www.experts-exchange.com/articles/Virus_and_Spyware/Anti-Virus/LUA-Anti-Virus-Best-Practices-and-User-Education.html
However the article is under scrutiny, mainly because it is generic...
Any who, LUA and patching, and choosing strong passwords, no lm hash aren't good enough. Pass the hash tool kit, gsecdump/msvctl (which require admin rights) are scary prospects when coupled to a 0-day or forgotten hole, bad coding practices or insider threat. You also need separation of  duty/access
For me most security, past the av and patching, is AAA... authentication, authorization and accounting. Authentication like a web login or AD username/password, authorization like User_X is in the "Remote Desktop Group" or User_x is a part of Sales-Europe and has read+write to fileshare_2 and accounting, user_x logged into computer_19, user_x accessed file_22 on fileshare_2.

NAC, or DHCP monitors
I've tested an tried quite a few NAC vendors this year, and if your in a good place to make network changes, I think those network changes can benefit you more than a nac solution. Nac typically utilizes 802.1x to authenticate users via installed certificates or username/password, or snmp traps if 802.1x isn't available. 802.1x is technically the better solution, however depending on your switch hardware, you might not have the proper ram, switch OS or even equipment to support 802.1x. Snmp solutions like Cisco's NAC, PacketFence, FreeNac and others should be used. Symantec NAC, formerly Sygate NAC, does not offer SNMP. Static IP's are a bypass to dhcp, so 802.1x and even snmp traps aim keep static ip's from being used without authorization. Then if they are authenticated, they are possibly subject to external scan's, having a client installed to check patch levels and if AV is running+up2date.
After passing that the ip is allowed or a dhcp ip is assigned an they are allowed on to the lan. If they fail, the can be automatically remediated like updating the AV dat, or applying a few patches then retesting and allowing or denying the asset.
For us, we wanted all those things working, but the products that have clients installed, or even thin (disovlable) clients installed, did not work as advertised, in particular the automatic remediation fails to deliver. So i thought, do we need to have guests up to a certain patch level, do we need them to run av to be protected? Since we don't run AV on most workstations, I didn't think so, so we enabled the firewall on our hosts, made exceptions in the firewalls for IT/helpdesk subnets and only allow rdp port incoming. We put PacketFence in, and guests get assigned to a guest vlan and can't reach our users, our users can't reach one another or our guests, so a guest can come in as infected as they want, if our IDS doesn't see the traffic it will remain on the network, unable to reach anyone really.
We already maintain our users patch levels and scan the computers nightly using the latest AV, so we didn't need a flaky NAC client to tell us the patch levels of our users. Further we don't need to dictate what patch levels our guests have or don't have, they get internet access only. It was creating for more headaches than it was solving.
We solved NAC a different way than most go, but that was just us, not everyone will be in the place we were to change their network as we did, which basically came down to a firewall GPO policies, network access list changes, and setting up SNMP traps and utilizing PacketFence.
ChiefITAuthor Commented:
Some very good points:

We solved our guests by putting them on a MAC authenticated VLAN. Prior to getting an IP, they needed to bring their machine to the local admin, who extracts their mac address and allows that through DHCP. Then, in return the Admin will look at the machine for a manual overview of the computer's AV/AS and firewall software.
Rich RumbleSecurity SamuraiCommented:
Well it's a bit harder for 5,000+ across the globe, and systems like packetfence can inform you have spoofed/cloned mac address's. Physically unplugging a printer, and cloning the mac and IP (which is very easy to print out or display the printer config on most printers) is a downside, but both 802.1x as well as snmp nac solutions have this "weakness", some devices have to be trusted and are too dumb to run 802.1x or authenticate, like VOIP phones... however we do have ACL's on the router or firewall for the offices that only allow traffic from those printer IP's to flow to/from a certain number of hosts. We trust those devices, just not that much ;)
VMPS is ok, but when you ask me to pen-test, I get in :-) We have gov contracts so we have to be extra paranoid anyway.
Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to Squarespace.com and use offer code ‘EXPERTS’ to get 10% off your first purchase.

ChiefITAuthor Commented:
It appears like you have an extensive IT security background.

I agree that the scrutiny of your article was somewhat unwarranted. Certainly granting the lesser of user authorization is important, especially with the new types of virii that are coming out. Take, for instance, the conflicker/downadup. This is where no user interation is required to infect domain computers because the virus somehow was granted admin rights to install the virus throughout the domain.

I also had the recommendation of including Web and email proxies within the list as an access control measure. I thought that was a good idea.

Hey, what do you think about opening up a blog in EE and getting ideas for an all-inclusive list for Domain/network security?

I'll tell what I hate to see is someone struggling with securing their network. The way I see it, is if I can help one person secure their lan, that's one less person that can infect me.
Rich RumbleSecurity SamuraiCommented:
The article has changed quite a bit, but I've leaving it as is now, it was more biased before that is certain. Nonetheless, I like the ideas of blogs, but I don't have the time for them :( Security is tough, and getting traction to make changes is the hardest part of my day, not using a tool or buying one, which is a close second, but making necessary changes and changing the way things are done. Even if I come into a place with policies setup to do this and that, they aren't enforcing them until some embarrassing situation comes up and it's CYA time. They ask for help, but when you tell them what they need to do, it's often a pill they can't swallow or convince someone "upstairs" to swallow.
But I'll tell you this, improve your golf game, get out on the lynx with these same people, and you can make them see it your way more than on their own "turf" in the office. It must be the fresh air, or me threatening to drive the cart down a ravine if they don't see things my way... we may never know ;p
All joking aside, I have had more success making the same point on the green than in the board room, it's weird.
ChiefITAuthor Commented:
Well, I liked it!!!!

Thanks for the idea. It will be encorporated on the article.
Rich RumbleSecurity SamuraiCommented:
Here is the article if you still want quotes ideas, I asked for it to be deleted I don't have the time to do whatever needed to be done "fix" the article.

LUA, Anti-Virus, Best Practices and User Education

This article mainly focuses on Micorsoft XP Professional.
A commonly accepted, but often overlooked best practice is the Principal of Least Privilege, commonly referred to a LUA, least-privileged user account. Which basically means running software and applications in least privileged account possible. For example, to surf the internet using the browser of your choice, you don't need to be an administrator. Sending IM's, or checking your mail in Outlook, doesn't require administrator rights. Installing most applications does however require you have such an elevated privilege.
But again once the software is installed, typically, you don't need to be an admin to run or use it, there are plenty of exceptions to this, in fact Microsoft was keeping a large list of software known to suffer from this milady:
http://support.microsoft.com/default.aspx?scid=kb;en-us;307091 The list is not updated any longer.
The rationale of using LUA is that the less access(privilege) you have, the less damage the account/group can do.

LUA is a founding security principal and practice of many operating systems, particularly multi-user operating systems like Linux, Apple(Mac) and Unix. In a perfect world LUA shouldn't be needed in the first place, but it does aid users and IT admins with running software that isn't as secure as it could be. It helps mitigate the damage software could do if misused or exploited. It is not guaranteed to mitigate every time, but it certainly helps to do so for the majority of exploits.

Linux/Unix started off as multi-user operating systems, but Microsoft did not. However Microsoft did intend Windows-NT and later operating systems to be multi-user OS's. Before Windows Vista, Server 2008, and Windows 7, whenever users were added to a system, they were placed into the administrators group by default. Most of the IT admins I talk to know this to be true, and simply don't move users out of that group to a properly privileged group, and for a number of reasons. This includes software makers and developers, they develop and test their software using accounts with administrator access. Perhaps they didn't test or try to run their software as a lesser account... So headaches can occur when trying to move to LUA because the software developer might make calls or want to write files to places only an administrator has access to, but a lesser account does not. For example if a company developed a game of Solitaire that keeps your latest scores in the windows registry, if you were running that game from an account in the Users group, you couldn't save your latest scores because you don't have the registry access by default in that group.

RunAs / Su / Sudo
Microsoft created RunAs.exe to help with this issues, allowing you to interact with a program that was launched or started from a higher privileged account. Linux and other OS's have had this function for a long time, typically using the "su" command which means switch user. Switch User is more like RunAs than the other popular Linux command called "sudo", which stands for Super User Do. RunAs saves you the trouble of logging out of your current login session, and then logging in with a higher privileged account to run the software. You can use RunAs in the opposite direction, just like you can with "su", you can be logged in as an administrator for example and launch FireFox or Outlook as a lower privileged account. With Sudo, you cannot, it only runs as the highest user.

Anti-Virus vs Anti-Administrators
Recent studies indicate that LUA alone, could of prevented around 90+ percent of exploits and virii from doing the damage they were intended to do: http://www.computerworld.com/action/article.do?command=viewarticlebasic&articleid=9127318

Security is a Process; Not a Program
This is not to say that Anti-virus software is only needed for 10-20% of the time, it just means that security is a process and not a program. Securing users and systems is not as simple as patching as soon as possible, and running AV and Anti-Malware software, although that is a very typical approach. There are windows of time between software patches, versions and when updates are not available. During that time your systems and users could still get exploited, or infected. LUA can significantly reduce the impact those nasties might have until an update/patch/new version becomes available. Further there are also times that LUA isn't enough, the exploit or flaw allows the malware to gain a higher privilege regardless, but thankfully that is a very small minority.

User Education
Educating users about the risks associated with high privileged accounts can be troublesome. While IT admins and security professionals know LUA is a best practice, that is one thing, but to move your organization over to it is another. RunAs and other applications like it can significantly help when "LUA Bugs" are found, but don't solve the issue entirely for all software. While your company might want to make the change to LUA, your users might not like the change or feel jilted that they can't put a picture of their family on the desktop background any longer. Informing the users of LUA can help the companies security and practicing it in their own homes can help protect them as well. You can also create a process where users can ask for software that isn't on the "list", or ask that they have their background changed to a certain picture they provide.

Internet Explorer / BHO / Active-X
Internet Explorer is a very common vector for attacks, exploits and infections. Browser Helper Objects and Active-X controls can still allow infections to occur even to LUA users. Hardening Internet Explorer settings can help to mitigate those vectors, but that typically makes the browser unable to render web pages in a less than useful or productive manner. I typically suggest a compromise, don't use IE unless the page requires it and use a browser like FireFox, Opera, Chrome or Safari. This is another point to make when educating users about LUA and how there are many more attacks focused on IE than there are on the alternative browsers.

Migrating to LUA
Migrating to LUA takes considerable planning and testing. In most of my deployments users workstations do not have antivirus clients installed, but do get remotely scanned every night with an AV scanner on the network. I've developed a RunAs.vbs script that allows users to launch applications that still suffer from needing admin rights to run. We also have a home grown application that depends on an Active-X control we developed before moving to LUA. Once XP SP2 came out it failed to work on our test users running in the LUA environment, however we quickly located a simple fix, namely renaming the short-cut from .html to .hta so that it ran in the local intranet zone instead of the internet zone. There are lots of issues like this when moving to LUA, fortunately we had software vendors that were willing to work with us to resolve some other issues, still with others we were forced to find work arounds for ourselves.

You can adopt a model of LUA where you put users in the lowest privileged group, or you can work from the upper end, perhaps assigning users to the Power Users group and running a tool like DropMyRights to lessen the privileges for most software the users launch. Not everyone can migrate to LUA, and laptop users are typically the hardest. There are many other applications and innovative security solutions out there but it's hard to find one for this price point (free). We used to just throw money at the problems, using SandboxIE, DeepFreeze and Go-Back, we tried a lot of others too, but we've never been as happy as we are now using  LUA. While our Laptop Users still have Admin rights, we try to educate them the most about internet best practices, using the shortcuts we place on their desktops that we created to use the RunAs.vbs scripts. We've made changes to registry keys and other files and folders so that "normal" users can use the software we've purchased for them.

FURTHER READING: http://www.microsoft.com/protect/computer/advanced/useraccount.mspx
http://xinn.org/win_bestpractices.html http://xinn.org/RunasVBS.html
http://xinn.org/annoyance_spy-ware.html http://nonadmin.editme.com/
http://www.schneier.com/news-026.html http://www.schneier.com/essay-237.html

In Closing
While I have had great success at migrating several companies, with 15,000+ users across the world, to using LUA, it didn't happen overnight. Careful planning, coordination, testing and engaging our software makers all came together to further secure these various deployments. From an IT perspective, helpdesk tickets related to infections, "wonky-ness" and really in general day to day issues are down by 80% for each company. Laptop users have the majority of such issues, and workstations get the occasional infection, typically the Vundo/Virtumonde "virus". One company used to out-source the helpdesk and IT functions in their company, but now uses in house technicians because their users can no longer "wreak havoc" on their own machines like they used to do. They are saving money by using in-house tech's (again) and they directly attribute this to the reduction of helpdesk and IT related tasks.

I like helping people, and I hope this article helps you and your people.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now