|
With all eyes on the Internet, it is sometimes easy to forget that our security concerns don't end at the Web server. We focus primarily on our firewalls, DMZ configurations, and on hardening the systems that support our web presence and other Internet-based services. This only makes sense. There are countless eyes from around the globe drawing a bead on our systems and looking for the slightest chink in our armor. And with attackers whose motives range from corporate espionage to getting one's cracker handle posted on Attrition.org, we are sometimes forced to use all of our resources just to ensure that our sites are protected.
However, the Internet is not the only front that we need to defend; we need to consider the security of our internal systems as well. In addition to our SQL data warehouses, which hold the company's Crown Jewels, we also deploy intranet web, file, and print servers that house much, if not all, of the intellectual property of the company. Given the importance of this data, do you know what permissions are most commonly set on these files and directories? Yes, you in the back? Exactly. All together now: "Full Control."
And let's see a show of hands from all of you that have your SQLServer service running as Administrator. Oh, that's not good.
One last question: there is no doubt that you have all secured your IIS5 Internet servers from the latest '.printer' overflow issue, but who has gone through the countless internal boxes that have IIS5 running on them? One, two. Two. Two of you have. Now the real question is - "why?"
The more cynical of us would blame this laxness on the competency of the administrators, spouting things like "zero knowledge administration breeds zero knowledge administrators," and "he only got that job because he knew how to change the toner in the copier." While these statements may be valid in many cases, I don't accept them as status quo. To be honest, I think that although many of us know better, we don't lock everything down because it is too damn hard to administer.
This was certainly the case with NT. If you only had a couple of servers, then it was no big deal. But if you managed an enterprise-wide deployment of NT boxes in different physical locations, it got to be a bear. A great big bear with nasty teeth and sharp claws. That smelled. Bad!
In Windows 2000, this has all changed. At the risk of receiving some "what are you smoking?" emails, I will go so far as to say that not only is administering a Win2k enterprise easy, but it is fun too! And that is what this series of articles is all about: securing your Win2k enterprise. Note the word 'enterprise'; that means not just servers, but workstations too! I have seen many documents telling me what settings to use on a server to "harden" it in Win2k, but that is only part of the battle. Properly controlling what the workstations can do and, more importantly, what they can't do is crucial to the concept of a secure environment. This series won't just talk about WHAT to configure, but HOW to configure it.
Since a strong foundation makes for a strong structure, let's begin with a little review.
The Golden Years of NT
The NT mold is hard to break out of. While a "from scratch" blueprint of an NT network could be made functional, fast, and efficient, the state of real-world networks was almost always the result of functionality-first domain structures coupled with other pragmatic considerations, such as: departmental workgroup/domain configurations, uncontrolled growth, departmental cutbacks, and other organizational changes. Throw in a couple of outsourced resource domains, remote facilities connected by who-knows-what-and-where with everyone logged in as Administrator, along with a good healthy dose of Windows 9x, and you had an organizational nightmare.
The best efforts to secure an environment like this inevitably failed to hit the bull's-eye, if it hit the target at all. Some admins used Resource Kit solutions, others rolled their own Perl scripts, and some didn't even care to light up. RAS servers lurked in dark corners, PC Anywhere waited on web servers, bosses demanded to be 'administrators' in case we got canned, and "Full Trust" relationships ran rampant. And this was on a good day!
Policies helped a bit, but they only went so far. And replication to all the DCs could be a pain, particularly to other domains. We could get a bit more granular with other system settings by rolling out a custom version of IE with the IEAK, but keeping up with what-did-what-to-whom was a daunting task. And if that all weren't enough, the "once a controller, always a controller" role of our servers made moving things around difficult, if not impossible. Of all the third party products designed to relieve the burden of the administrator, the only one that really helped was one called Jaegermeister.
A New Dawn
Then one day, it happened. I walked into my office, and there on my desk was a shiny new copy of Windows 2000 Server. I ripped into it as if it were a WonkaBar, and I was Charlie looking for the last Golden Ticket! I rushed over to the first available server, performed an upgrade, and eagerly began exploring. I immediately mastered Active Directory, Site configuration, Organizational Units, Security Policies, Group Policies, and the Security Configuration and Analysis MMC plug-in.
Just kidding...
In actuality, I think I shrugged and went to lunch. But these were all new capabilities of Win2k that I would come to love, and that would offer systems adminstrators a clear path to easy enterprise administration. In the next few sections, I will offer an overview of these tools, jumping back and forth between the NT way and Win2k way to provide a basis for the recommendations to follow.
Active Directory
Although an in-depth overview of Active Directory is outside of the scope of this series, we do need to go over a few things. In its simplest definition, Active Directory is a database of all of the network objects. Whereas NT was limited to 40,000 group, user or computer objects per domain, Win 2000's Active Directory supports 1 million objects (or a size of 17 terabytes) and can include many other types of objects like printers, Organizational Units, Shares, Applications, etc. Breaking NT into manageable units often required creating a separate domain, hence the different types of domain models you could choose from: Single, Single-Master, Multi-Master, and Full Trust.
Active Directory gives users a context in which to build domains called a forest. Within the forest, you can build flat, or contiguous, namespace domains (kind of like the DNS namespace) or different domain namespaces with trust relationships between them. So, whereas in NT you might have had a 'Poindexter' domain for corporate, and a 'Scrubs' domain for some guys in the field, Active Directory lets you create the 'Poindexter.Com' and 'Scrubs.Poindexter.Com' domain space. A new domain object called an Organizational Unit, or OU, will let you create a single domain namespace, such as 'Poindexter.Com', and manage what used to be NT domain units within the context of the OU. Of course, if circumstances dictate, you could have multiple contiguous namespaces trusting other multiple contiguous namespaces, each with multiple OU's that contain other OU's (however, we won't be using those in our example.)
And as far as trusts go, Active Directory introduces transitive trust logic. In NT, if the Poindexter domain trusted the Scrubs domain, and the Scrubs domain trusted the Peanut domain, that did not mean that Poindexter trusted Peanut - this tertiary trust had to be created manually. A transitive trust solves this for you. Where the trust is transitive, Poindexter will indeed Peanut if Poindexter trusts Scrubs and Scrubs trusts Peanut.
Finally, with Active Directory, you have the option of initially installing a box as a Member Server and later configuring Active Directory to make it a domain controller. If you want to, you can then go back and uninstall AD to demote the box to Member Server status again (as long as someone else is still a controller.) This affords you some powerful options as you migrate to a new domain structure.
The Domain Structure
I know I shouldn't introduce Domains and then talk about Organizational Units, but I'm going to anyway, if only because the OU might save you some headaches. If you had multiple domains in NT, it might make you automatically create a sub-domain structure in AD. Moving from Poindexter, Scrubs, and Peanut might make you think that configuring Poindexter.Com, Scrubs.Poindexter.Com, and Peanut.Poindexter.Com is a good idea. But before we jump to that conclusion, lets take a look at what Organizational Units can do for you.
An OU is an Active Directory container into which you can place objects. In NT, we may have created domains based on geographic location, department, or some other classification. Regardless of how we chose to configure the domain, it was all done in order to ease administration. Though some domains never even came close to 40,000 objects, they may have been broken up so that the user account operators did not have to wade through 5,000 objects to find what they were looking for. For instance, a 'Sales' domain may be created to house the accounts of 1000 sales people, and a 'Support' domain may have been created to house the accounts of 4000 other personnel.
In Active Directory, we can accomplish the same thing in a single domain with an Organizational Unit. For example, in the Poindexter.Com domain, we could house all 5000 users, but create a 'Sales' OU and a 'Support' OU and then move the users into their respective groups. The same could be done with Scrubs. In fact, we could create different OUs to group objects by many different criteria. If you wanted to, you could create a 'Systems' OU, and create OU's within Systems for 'WebServers', 'PrintServers', 'MailServers', 'ScrubWorkstations', 'AdminWorkstations', etc, and move the different systems into these different OU's. As we will see shortly, this will allow us to use some powerful administrative tools to automatically configure different options on the different OUs based on the object type. The methodology you use to create OUs is completely up to you.
As I have said before, we sometimes setup NT domains in order to separate different physical locations for ease of administration. Active Directory does this for us in the configuration of Sites. Since TCP/IP is required for AD, and since our sites will (or, at least, should) have different subnets, we can effectively use the Sites configuration to tell AD which controllers are in which physical locations. This makes replication more efficient. It also increases the speed and availably of the logon process, as clients will already know which controller to authenticate to based on the subnet. That is not to say that all objects in a site necessarily have to belong to the same domain, because they don't. It is just a typical configuration.
Now that we have covered that, you can go on to the process of determining exactly how you will create your domain structure. You can still create sub-domains if you want to, but I prefer the ease of a single domain namespace, particularly since I can configure my sites for optimum performance, as well as group my boxes and users into different Organizational Units (note that boxes in different sites can still be in the same Organizational Unit!)
Security Policies
This is where it starts to get good. Similar to our old policy options in NT, the Security Policy plug-in allows us to automatically impose configuration parameters upon our systems. The default scope that we can work with is Local System, Domain Controllers, and Domain, but we will look at how to expand this using Group Policies. Account policies (like password age, lockout options, complexity), Audit policies, User Rights, and Security Options (like RestrictAnonymous, LM Authentication settings, and Secure Channel setups) can all be set using this tool. In the next article in this series, we will get into painful detail of all the options you can set to secure your systems, as well as why we are recommending them.
Group Policies
Group Policies are amazing. With them, you can control almost every aspect of the user's configuration. To me, this is extremely important. There are lots of exploits out there that target servers, but there are even more that target the end user: malicious script on a web site that is counting on Active Scripting to be turned on, Email attachments that are hoping that users read their mail in the Internet Zone, and credential-grabbing methods that are hoping that certain ActiveX controls are marked safe for scripting. Each zone, and every option within that zone, can be controlled using Group Policies. Don't want your users changing the proxy settings? Turn it off. Don't want them sharing their desktop in NetMeeting? Lock it down. Want a cool spinning logo in a custom browser? Plug it in. Toolbars, Certificates, MMC Snap-ins, Task Scheduler, you name it, you've got it in Group Policies.
What makes Group Policies really strong is that you can impose them at any level you want. You can set up a policy for the entire domain, for a site, for an individual organizational unit, or for any combination of the above. Put your "trouble" users in lockdown. Give your favorite users unlimited access. Change your boss's default home page. The possibilities are endless! As it will with the Security Policies, this series of articles will go into intimate detail of all the various settings you have control over in the Group Polices (a topic that might take up an article all by itself!) And, as the Security Policies are provided as a sub-set of tools in the Group Policies, you will see how combining the two into policies-by-unit will allow you to secure your servers while you control your users at the same time. And as if that were not enough, the Group Policy extensions even allow you to set permissions on directories, configure services, and automatically control group membership. This is extreme management.
Security Configuration and Analysis
If we survive the detailed exploration of Security and Group Polices, we will conclude this series with a look at the Security Configuration and Analysis, or SCA. I used to be in a group called the SCA, The Society for Creative Anachronism, in which members beat on each other with fake swords. Windows 2000's SCA is very much the same, except we will be beating on our boxes, and the swords will be real. Security Configuration and Analysis allows us to compare our boxes against a security template, and to push out configuration changes where necessary. This is particularly helpful for audits and 'what if' scenarios where you might want to get a view of the current state of affairs without actually changing anything. Although this is a box-by-box analysis, command line tools are available for scripting, as well as a complete API for the truly brave of heart. Combine this with the Security/Group Policies in a properly configured domain structure, and you will soon find yourself wielding a mighty weapon in the most heated battle of IT: security.
So, brush up on your Active Directory, get some systems in place to mess with, fix a pot of coffee, and get ready for the next installment in this series, when we will jump head first into the pool of Security Policies. This is where we leave NT behind! Remember, if you want to discover new oceans, you must first lose sight of the shore.
To read Hardening Windows 2000 in the Enterprise: Seeing the Forest in Spite of the Trees, Part Two, click here.
|