Re: Hardening Windows XP

From: cquirke (MVP Win9x) (cquirkenews_at_nospam.mvps.org)
Date: 05/11/04


Date: Tue, 11 May 2004 01:52:56 +0200

On Mon, 10 May 2004 01:16:02 -0700, "Ashish Mishra"

>Can somebody please guide me on hardening operating system
>and if there are any tools and /or scripts available for the same.

I haven't written that web page yet ;-)

Basic approach:
  - the risks you never need, rip out
  - the risks some may need but not others, password protect
  - the risks you may need, evaluate first
  - the risks you decide to take, virus scan first

Define the frontier

Any material that comes in from outside - be it email, IM, diskettes,
or even network packets or junk from web sites - is a risk.

The trouble with XP is that there are many risky things that
stand-alone users don't need, but can't rip out. Hence the problems
with Remote Procedure Call services and so on. Too often these things
are embedded and subject only to password control.

Risk management approaches

Passwords, account rights settings and security zones all slice up the
system in various ways, usually with a larger and more porous surface
between the divisions than the external frontier. So leakages and
holes tend to abound, so that all three management stratagies are poor
substitutes for an *absence* of risky functions that no-one wants.

Security zones leak, as many security alerts and patches testify -
e.g. scripts within cookies that can run in local hard drive zone.

Account permissions can be broken through or bypassed, and usually
once code has escalated above the allocated rights, it can keep right
on going - plus, resticting accounts in XP Home also kills several
settings that confer better risk management.

Passwords are non-optional, when the usual dumbo ":to change password,
enter old password" model is used. The "option" to use a blank
password that will allow unfettered use becomes a DoS opportunity as
anything or anyone can set an unknown password and lock you out.

Passwords should *only* be used where some folks are to use a facility
while others are not. Where no-one is to use a facility, the facility
should be removed, not hidden under a crackable band-aid. Where
everyone is to use a facility, a password is a potential lock-out.

Data hygiene

XP has a clue that data should be gathered in one place, and does so
within each user profile's subtree. Unfortunately, within this
subtree, all sorts of material are mixed up; you small and unique data
files, huge slabs of off-the-peg media files, unsolicited emaul
attackments hidden in mailboxes that av can't scan, downloads dumped
from IE, and incoming files arriving through MS Messenger. Duuuumb.

Data hygiene in this sense means a data/backup set that can be
restored with confidence after an unknown disaster, without fear of
bringing back dormant malware that triggered the last meltdown.

That means no incoming material, and no infectable material even if
this was clean when it arrived (think roving Win32PE infectors).

I choose applications that facilitate data hygiene, such as Eudora's
email client, which splits out attachments and stores them as
av-scannable files in a location you determine. I direct Eudora nd MS
Messenger to store files in an "Incoming" subtree, along with IE's
downloads, p2p-sharer's file collections, download accelerator and
archive workspaces, and the desktop dumping ground.

The email data is safe in Eudora (it doesn't auto-run scripts and so
on) and can be included in the data backup. I usually relocate the
large "My Pics", "My Music" and "My Vids" outside the data set, which
is itself relocated off C: for safety.

Evaluating and managing risk

Make sure that your system...
  - does not automatically take risks behind your back
  - shows you the information you need to assess risk
...and that your users...
  - build the skill sets to assess risk effectively

That means setting Windows to show file name extensions and paths, not
hide files, and so on - all settings that are lost in XP Home, if a
user account is converted to limited rights after it's been set up.

That also means killing dumb-ass auto-run risks, such as \Autorun.inf
processing on HD volumes, etc. All the risky functionalities you
don't intend to use, you should seek to rip out or squash:
  - hidden admin shares
  - incoming network "service requests" (turn on the firewall!)
  - WSH, if you don't use stand-alone script files yourself
  - ...etc.

The goalies of last resort

Only after doing the above, do you end up with things that you decided
to do that turn out to have been a bad idea. That's where antivirus
protection will hopefully catch the dropped plates before they hit the
floor - and that can only happen if the malware is not too new for
your av to recognise (the "Day Zero" effect) or is malicious
commercial software that the av ignores for fear of litigation.

You may need to salvage matters after malware has gone active on your
system. You can usually tackle commercial malware from within the
system its infected; the pretence to be there by your consent
currently limits the steps this software will take to foil removal.

But traditional malware - your viruses, worms and Remote Access
Trojans - have no need to play by the rules, and these should be
tackled formally. NTFS is usually touted as "more secure", but it's
of limited use when it comes to defence against malware, as Witty so
ably demonstrates (it writes directly to raw disk from within NT).

Once infected, NTFS gets in the way by limiting your ability to clean
the system without running potentially infected code first. This is
discussed at http://cquirke.mvps.org/whatmos.htm, and I see this as
sufficient reason to avoid the use of NTFS.

  

>-- Risk Management is the clue that asks:
      "Why do I keep open buckets of petrol next to all the
      ashtrays in the lounge, when I don't even have a car?"
>----------------------- ------ ---- --- -- - - - -



Relevant Pages

  • Re: PHP blamed for security problems
    ... > By not running code taken from remote machines, ... >> and flags possible security risks. ... scripts just b4 release so that they can get a report of possible security ...
    (comp.lang.php)
  • Re: DoS, Exes not working
    ... some av have started to get clue where commercial malware is ... - ensure PC doesn't automatically take risks ... - fixing product design bugs ... Some folks are so confident in the meat in thier security sandwich ...
    (microsoft.public.security.virus)
  • Re: So, windows doesnt get viruses and worms eh?
    ... and fastest-propagated risks. ... about malware numbers much less significant. ... recognizing the number of different threats to Windows. ... We also have to consider the growth rate. ...
    (comp.sys.mac.advocacy)
  • Re: Administrator Privileges a Danger?
    ... administrator increases he risks of infection with malware. ...
    (alt.comp.anti-virus)
  • Administrator Privileges a Danger?
    ... administrator increases he risks of infection with malware. ...
    (alt.comp.anti-virus)

Quantcast