Re: Microsoft Strategic Technology Protection Program

From: Tony Chow (tchow@BLUETENTACLE.COM)
Date: 10/04/01 

Message-ID:  <50B30C640EC48648ABAA34F00D737A96CDA3@leto.bluetentacle.local>
Date:         Wed, 3 Oct 2001 15:10:24 -0700
From: Tony Chow <tchow@BLUETENTACLE.COM>
Subject:      Re: Microsoft Strategic Technology Protection Program
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

I second David, the key to securing NT/2000 environments is taking
maximum advantage of existing tools. I have been able to create a
completely automated system to secure both servers and workstations in
our Windows 2000 environment using, among others, the following tools:

-Security Templates/GPO
-Administrative Templates/GPO
-IPSec filters/GPO/ipsecpol.exe
-scheduled tasks
-WSH scripting

Watertight security for both NTFS and the registry are applied to
servers and workstations through GPOs. End users do not have write
access at all to their hard drives. Different templates are applied to
different types of systems depending on the services they provide.

Custom administrative templates applied through GPOs set necessary
registry settings. For example, one template makes the default
double-click behavior of script file types "Edit" rather than "Open", so
that it's impossible for users to inadvertently execute worm scripts.

IPSec is a powerful filtering mechanism that is especially useful in
environments that can't use firewalls for one reason or another (like
when you share a segment with other independently managed departments in
a university). It also has many limitations, and should be used with
care. Here at our organization, workstations receive a limited set of
IPSec filters propagated through GPO which blocks crucial ports from
outside access (SMB, CIFS, RPC mapper, ident). Filters for servers need
to be modified quickly and to adjust to the specific services each
server provides, and so they are set locally using the ipsecpol.exe tool
included in the resource kit. Ipsecpol.exe is made more convenient to
operate by encapsulating it in a WSH scripting interface, so that
creating a policy is as simple as calling a few functions and passing
them predefined arrays of addresses, subnets, and port ranges:

CreateRule(ANYIP, ipsAllPorts, null, ipsBlock, "All IP Traffic",
"Local", ipsReg);
CreateRule(ANYIP, ipsICMP, null, ipsBlock, "All ICMP", "Local", ipsReg);
CreateRule(WEBADMINSYS, ipsAllPorts, null, ipsPermit, "WEBADMINSYS",
"Local", ipsReg);
CreateRule(DCS, ipsAllPorts, null, ipsRequestSec, "ARCHIVEDC", "Local",
ipsReg);
CreateRule(ANYIP, HTTP, ipsInbound, ipsPermit, "Web Ports", "Local",
ipsReg);

The policy created by the above JScript code blocks all non-HTTP IP
traffic on a web server except to domain controllers and local
workstations authorized to administer the web server. Scripts such as
these are automated through the startup script functionality of GPOs as
well as through a scheduled task run with local system credential on
each server (server accounts must have access to scripts).

Windows 2000's augmented scripting capabilities can be enormously
powerful in securing workstations and servers alike. We have
successfully been able to automatically apply service packs, hotfixes,
IE, and other security patches using startup scripts written in JScript.
(These operations are not possible with Windows Installer packages
because they cannot replace files protected by SFP.) Applying a new
hotfix to all workstations in the domain is as simple as dropping the
executable in a network folder and then reboot. Servers cannot afford
constant reboots, of course, so on each server, in addition to the
startup script, a scheduled task is set up, running under the local
system context, to check for new hotfixes every night and install them
when found, and then sending the administrator an e-mail notification to
reboot when convenient. With these custom-tailored scripts and
supporting tools, we have very little trouble keeping all workstations
and servers up-to-date.

We also have an automated script that periodically randomizes local
administrator account names and passwords on all workstations and
servers then store them in a database.

All of the above techniques are currently employed at our organization
with no problems. Each, nonetheless, have its own peculiarities and
pitfalls that can only be overcome with extensive experimentation. For
example, securing NTFS and the registry is a tough task on workstations,
because many third-party applications do not observe the security
guidelines and write information to where they are not supposed to, and
you need to make sure that end users can operate these applications with
their limited privileges. The administrator needs to find out the exact
permissions that an application needs, and then modify the security
template to accomodate only those permissions. If an application has
permission requirements that significantly compromise system security
(as when it needs to go willy nilly in the system32 directory), its
replacement should be considered.

Another potential area of confusion lies in IPSec. IPSec is not as
capable as a firewall. It cannot distinguish between incoming and
outgoing TCP traffic, and between the various types of ICMP messages.
These and other limitations must be kept firmly in mind when using
IPSec, otherwise one will end up with a false sense of security which is
worse than no security at all. This principle also applies to every
other tool.

Tony Chow
Systems Administrator

======================================
Delivery co-sponsored by Trend Micro, Inc.
======================================
BEST-OF-BREED ANTIVIRUS SOLUTION FOR MICROSOFT EXCHANGE 2000
Earn 5% rebate on licenses purchased for Trend Micro ScanMail for
Microsoft Exchange 2000 between October 1 and November 16. ScanMail
ensures 100% scanning of inbound and outbound traffic and provides
remote software management. For program details or to download your
30-day FREE evaluation copy:
http://www.antivirus.com/banners/tracking.asp?siS&BI;$5&UL;=http://www.ant
ivirus.com/smex2000_rebate

Relevant Pages

  • Re: [Full-disclosure] Brute force attack - need your advice
    ... to setup properly" and as I stated nothing is foolproof or totally ... is more of a point that security is ever evolving. ... But as I said, this is pure populism, servers are here to serve, not ... there are e.g. scripts which evaluate failed logins from ...
    (Full-Disclosure)
  • Re: Where should security exist?
    ... Even if all the data was being saved on the servers, ... the entire network. ... would it be a bad practice to harden the security on ... >> should you not secure workstations in a enterprise? ...
    (microsoft.public.win2000.security)
  • finding bad things and centralizing security
    ... I manage 10 servers, each hosting a large number of virtual servers using ... to centralize management of the security and the services on the servers, ... reporting intrusion attempts, and tripwire for reporting unusual filesystem ... with users who are installing scripts with the purpose of exploiting their ...
    (Security-Basics)
  • Re: Remote Access to servers
    ... > I am looking at some security issues on our NT and 2002 servers and a ... > XP workstations. ... I have done some searching on the Microsoft site, ... How do I make sure no one can access our servers ...
    (microsoft.public.security)
  • Re: Need urgent help regarding security
    ... There is plenty of security info out there ... email from even a dozen servers is small. ... an OS version upgrade should not be taken lightly. ... Given that your root password was apparently found on the servers, ...
    (freebsd-questions)