Secure non-Microsoft server apps with your own SCW extensions.
we talked about the Windows Server 2003 Security Guide. That well-written document,
which uses the Security Configuration Wizard (SCW) as its toolbox, is your guide
to securing your servers.
But for all its usefulness, the SCW only works with Microsoft applications. If you’ve got Symantec AntiVirus,
Veritas NetBackup, or any other non-Microsoft applications running on that server, the SCW’s helper functions won’t recognize and automatically secure them. So this month, we’re going to DIY our own SCW extensions to handle these apps.
If I Had a Hammer
Before we start constructing new extensions, let’s talk a minute about what’s
going on behind the scenes when you run the SCW. First, if you haven’t already,
install Windows Server 2003 Service Pack 1 onto a prototype machine. Then check
out the contents of the %windir%\security\msscw\kbs folder. In that folder, you’ll
see a number of Knowledge Base files with .XML extensions. These files contain
the data that tells the SCW what to secure, as well as what descriptive text to
populate the SCW GUI with when you launch it.
You can view and edit them in any text editor. There are three types of Knowledge Base files:
- The Root KB defines the basic information about a particular
OS version and should never be modified. The Root KB for Windows 2003 is named
- Extension KBs spell out the security settings for a particular
server’s role. As an example, the KB for ISA server is called ISA.xml.
- Localization KBs provide the text you see on the
GUI screens when you launch the SCW. The associated Localization KB for ISA
server is named ISAloc.XML.
When you run the SCW’s GUI, the three types of files merge on your prototype machine to make the file main.XML. This file contains what we’ll call "the questions." Or, more technically, this file contains all the options you potentially could select to secure that machine with the SCW.
As you work through the SCW’s GUI interface, selecting the services you want
to secure and the options you want to disable, you end up creating another XML
file that contains what we’ll call "the answers." This policy file,
called policy.xml, is what you use to apply the security policy to this and
other machines on your network.
[Click on image for larger view.]
|Figure 1. Securing the three
types of applications on the left yields the policy on the right, named
"policy.xml," that’s applied to network servers.
In last month’s column, we discussed how you can use the SCW to fill out "the
questions" and how to use the "Windows Server 2003 Security Guide"
to give you the correct answers. But, as discussed earlier, these correct answers
only work when the questions relate to Microsoft products. What if you’ve got
the Veritas NetBackup client installed on a server you want to secure? You’re
out of luck -- unless you create your own questions.
For a simplistic example of how to do that, let’s pretend our servers all have
the Veritas NetBackup client installed. If I were to run a default installation
of SCW, the SCW’s helper functions would likely not find the NetBackup installation
on the server. They would suggest that I shut down any unnecessary network ports
and services, which might include the obviously necessary NetBackup Client Service
that runs on network port 13782/tcp.
If I’m using the SCW to secure my servers, I’m going to need to extend it so that the NetBackup question is available to me in the GUI. Otherwise, I could end up with a very secure server, but with very unusable backups.
To do this, you would typically locate the default Extension and Localization KBs found in the %windir%\securitymsscw\kbs folder. Make a copy of one, open it in a text editor, and rewrite it to include the necessary NetBackup service. This can be a challenging exercise, as the KBs in that folder can be very long and very complicated.
Fortunately, we’ve created a much simpler example you can use as a template.
This template is intended to be simplistic, as there are more services and network
ports necessary for Veritas NetBackup, but it’ll do for our purposes. We’ve
removed all the extra bits out of the sample Extension and Localization KBs
and compressed them into a single file. We’ve also highlighted in green the
sections you need to modify.
<?xml version="1.0" ?>
<KB Type="Extensions" Update="TRUE">
<Version OSVersionMajorInfo="5" OSVersionMinorInfo="2"
ServicePackMajor="1" ServicePackMinor="0" ProductType="Server"/>
<SCWKnowledgeBase Functionalversion="0.8" Schemaversion="0.8">
<Role Type="Client" Name="NetBackup
<Role Name="File Server"
<Service Name="NetBackup INET
<Service Name="NetBackup INET Daemon">
<Role Name="NetBackup Client Service">
<DisplayName>NetBackup Client Service</DisplayName>
<Description>Manages Backups to a NetBackup
<Service Name="NetBackup INET Daemon">
<DisplayName>NetBackup INET Daemon</DisplayName>
<DisplayName>NetBackup Client Port</DisplayName>
<Description>Used by NetBackup Clients
to connect to the server</Description>
Note that the file includes four major sections: Roles, Services, and Ports
for the Extension information, and a separate section for Localization information.
- In the Roles section, you describe the role that
this Extension KB will secure; in other words, its name and type. Note here
the role that your NetBackup role depends on. In our example, the NetBackup
Client Service role depends on the File Server role. You’ll see that Selected
Value = True. This means that this service is enabled by default in the SCW
GUI when launched.
- In the Services section, you name the actual Windows Service
and its startup default. We set this service’s Startup_Default as Automatic,
but you can choose Default or Manual. You’ll notice also that for the service
you must use the actual Service Name rather than its Display Name. You can
find this information if you view the properties of the service in Computer
Management. Lastly, we’ve marked this service as Optional.
- For Ports, you need to give the port a name, identify
it as a static or dynamic port, and define its value and protocol. Static
ports never change, while dynamic ports start on a single port and later negotiate
a high-number port. For the protocol, you can select TCP or UDP.
- Lastly, you’ll see the Localization information at the
bottom of the file. Here, you give a Display Name and Description for each
of the items configured previously. This becomes the textual information you’ll
see in the SCW GUI when you configure this service on your prototype machine.
You can leave the other text alone. It’s necessary for the SCW to recognize that this is a custom "questions" file you’re importing.
You’re nearly done. To import your "questions" file into the SCW,
drop it into the folder %windir%\security\msscw\kbs with all the other Knowledge
Base files. Then, run this command to import the file: scwcmd
register /kbname:<Friendly Name> /kbfile:<Questions File>.
The next time you run the SCW on this machine, you’ll see your questions listed right there with the default ones from Microsoft.
Obviously, all this work takes some time and preparation before you start looking
at XML files. You’ll need to do some research into your non-Microsoft applications,
the services they use, and the network ports on which those services are listening.
To help with this, from a command prompt you can use the native netstat tool
to get a list of the ports on which the system is currently listening. For more
detailed information, try using netstat –ab. This
command lists the active connections on a machine and maps those connections
to the executable listening on the port.
The payoff, though, is a more secure network. Surely that’s worth the extra