Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-Microsoft
[Top] [All Lists]

RE: patching servers...

Subject: RE: patching servers...
Date: Wed, 11 Jan 2006 08:13:23 -0500
 

-----Original Message-----
From: Murad Talukdar [mailto:talukdar_m@subway.com] 
Sent: Tuesday, January 10, 2006 12:06 AM
To: focus-ms@securityfocus.com
Subject: patching servers...

Hi all,
I wanted to get a few ideas of what people do to test their 
systems once
they have applied a patch/hotfix.

Currently I pull one of the hotswap drives that has the OS 
mirrored on it
and then let it run with the patch applied for a few days/week before
letting it rebuild.
In that time I will check things like event logs/performance 
and do some
general 'listening' for any issues. 
Does anyone have a more scientific method? What do you keep 
an eye on? Also,
Do you actually ever check whether the vulnerability(for 
example) that the
patch was designed to thwart has actually been plugged? 
In the last two years I've only had one instance of a patch 
causing an OS to
fail--and then just removing and then reapplying the patch 
seemed to work
just fine. However, I don't want to get complacent.

Kind Regards
Murad Talukdar


I'm an advocate of standard configurations and fast patching. I've had a
server hosed by Windows Updates once, but the way it had been set up
probably didn't help things much.

I typically will patch my own workstation first (if it is a
cross-platform patch) and restart. Then I'll patch a couple
non-production servers as they aren't as important and typically have
messier configurations. If those work out then I move on to the rest of
the non-production servers, then production servers.

When it comes to domain controllers, I run dcdiag first and then
transfer any FSMO roles off the server I'm going to patch (and I never
patch more than one DC at once). After the transfer I run dcdiag again
just to be sure. Then I patch the server and if it comes back up I do
the rest of the DCs in a similar fashion.

The time I wait between servers depends on how important and complex the
patch is. For the WMF patch I wasted no time getting it on all the
servers: it's an (was? Whatever) 0-day exploit and frankly if I don't
see pretty thumbnails on my servers who cares. A service pack (important
but complicated) or Windows Malicious Software Removal Tool (not
important but simple) can wait a few days.

Also if you have a test environment you should load it up with
everything you can and make some configuration changes. A fresh install
of Windows 2003 isn't a real good patch test for a heavy-duty server.

Derick Anderson

---------------------------------------------------------------------------
---------------------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>