Few network services to target, few complex networking applications to pull about. Instead of exploiting those, attackers considered as the best way to reach their victims was creating new engaging points. So Trojan horses like Sub-Seven started spreading on Windows, arriving mainly by e-mail and chat file exchanges.
Since that time a lot of things changed: the firewall "culture" reached the masses, new and improved security tools were developed, modern Windows operating systems got a huge amount of network services, every application became network oriented, people's security awareness increased.
Now, with Trojan horses no more effective, attackers needed to find a new way to reach targets.
Fortunately for malicious users, Windows 2000 and XP offer a large number of services ready to receive malicious input and provide unauthorized access. Not to mention the thousands of applications, from news aggregators to P2P clients and MMORPG games, where one could use to send malformed network traffic in order to gain remote computer control.
The days of Trojan horses are not over yet but the large majority of attacks are now based on exploiting application vulnerabilities. Why? Have developers started producing more insecure applications? No, quite the opposite.
The attackers focused on them, plainly exposing what has always been there - crucial development errors.
Development errors are here and will most certainly always exist. They are the product of a typical human brain behavior: taking things for granted.
Developers sometimes don't check applications inputs, assuming users will provide data in the correct form, and malformed inputs crash their applications, and in some cases give access to the underlying system with full permissions.
These validation input errors are quite probable in modern networked applications. The more complex the application, the easier it will be to forget something.
Even if today's vendors apply secure development frameworks to reduce errors, we'll likely have to handle validation input errors for many years to come and possibly forever.
How hardening can help
The best way to mitigate the inherent application insecurity is to harden our systems, hoping endpoint security methods will soon offer something more defenses.
Hardening means reducing the amount of services listening on the system, the amount of installed applications and the way applications handle inputs. In other terms hardening means reducing the attack surface area.
Typically hardening is something applied to Operating Systems but it should be considered an approach valuable with any back-end server and desktop application as well.
Today we have hardening guidelines written by well-known security experts and organizations (like NIST), and have partially automated hardening tools, covering several aspects of an OS.
Microsoft released its official tool for hardening within the Windows Server 2003 Service Pack 1: Security Configuration Wizard (SCW) that addresses a lot of problems.
Other OSes have their semiautomated hardening tools like JASS for Sun Solaris or Bastille for Red Hat Linux distributions.
Hardening can be a risky business
Hardening practices exist since a lot of years but are hard to apply.
Before stopping a service or modifying a registry key, people should have a deep knowledge of the system. And even in that case, a hardening set of modifications could break an installed application, requiring infrequent access to what you disabled.
A hardened configuration could work for a system doing a specific task and not for another. Every platform needs its hardening tuning which is time-consuming and error-prone.
Just consider that even when hardening two identical systems you can always miss something. And if the platform role or base of installed application changes, you'll need to review the hardening procedure and adjust it accordingly.
It's a hard security life-cycle to achieve, even on a small server farm.
The bottom line is that hardening a system can invalidate vendor support for an installed product because it essentially changes the supported environment.
Exploring the SCW
SCW lets you approach hardening in two ways: per-role or custom.
Hardening with a per-role approach means you just explain the wizard what servers and applications your operating system is going to run.
For example, you can choose to declare the SQL Server 2000 role and the ISA Server 2004 role, but also to declare the system will act as a DNS client. Depending on which roles you selected the wizard will submit you a hardened configuration where unneeded services are stopped and registry keys are disabled.
This is the best way to start with for a hardening novice.
Hardening with a custom approach means you details every single setting modification of your system. The resulting configuration will be a hybrid-role model tailored for a specific environment.
This is the expert way to work with the SCW and should be adopted carefully.
Services and registry keys aren't the only settings SCW can modify. You'll be asked to choose how to setup Local Policies, IPSec filters, Windows Firewall ingress filters and IIS web extensions (if you are going to harden a web server).
The whole amount of things you can control is impressive and will require a lot of time and testing before reaching optimal configurations.
SCW explains every setting and therefore enables the user to make the correct choice and becomes a sort of a learning too.
SCW also offers a rollback feature, able to revert your system to its pre-hardening state. This feature is a must-have since troubleshooting a problematic service or application after a hardening can be highly complex.
When something you disabled or removed prevents the proper starting of a depended service, it's not always reported on the Windows event log, or if reported, it's not always declared in a clearly. Starting back from a working environment can save a lot of time and availability problems, otherwise the rollback feature always summarizes how the previous state was configured, so you could eventually invoke it just to check and find where the problems could lay.
One of the best parts of SCW is its configuration file. When you finish producing your hardening template it's saved as an XML file. This permits you to deploy it on every single machine in your server farm equipped with SCW, without restarting the template creation process, avoiding mistyping errors and saving lot of time.
The whole procedure is done just typing a single command:
If you work in an Active Directory environment you can assign the XML configuration file to a Group Policy and deliver hardening to all servers within an Organizational Unit (OU) at once.
SCW is distributed as free tool but it won't work on anything but Windows Server 2003 SP1 platforms. A bad decision from Microsoft that hopefully will change its mind for the next version.
Best practices
Even if SCW greatly simplifies the hardening procedure, many things can go wrong.
Before hardening a system be sure to study and check service dependencies and applications needs. Custom applications are particularly important to verify.
In Active Directory environments, a hardening configuration applied to apparently similar servers can produce different results and eventually cause services down-time (for example because similar servers weren't installed in unattended ways).
So, if you want to deploy the SCW template to a whole OU, you better define a subset of hardening modifications, commons to every OU member and then apply specific hardening settings to every single server. Do a lot of testing in a lab environment with cloned productions servers before deploying SCW templates.
Remember to document every choice and update documentation on changes.
Finally plan a periodical review of hardening templates to adapt them with new knowledge and new needs.
Conclusion
SCW is a great step forward in securing Windows platforms. It does the large part of the job, offers you a basic documentation of what you're modifying and addresses some distribution problems you'll have when dealing with multiple servers.
It requires a good knowledge of Windows behavior and a fair amount of testing before deploying in production. I'd still consider it a tool for experts.
This article originally appeared on (IN)SECURE Magazine #5.
