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. |

| 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> |
|---|---|---|
| ||
| Previous by Date: | How to disable interactive logon for service accounts on W2K and W2K3, nairsaji |
|---|---|
| Next by Date: | SecurityFocus Microsoft Newsletter #273, Marc Fossi |
| Previous by Thread: | Re: patching servers..., Duncan |
| Next by Thread: | RE: patching servers..., Steveb |
| Indexes: | [Date] [Thread] [Top] [All Lists] |