Recently I received a copy of the Windows Vista Resource Kit. 

This is the best resource kit I have seen since the box set was released for Windows 2000.  This book is worth buying as it is a great resource to have on all things Windows Vista.  Among the 1500+ pages of goodness are several chapters dedicated to networking topics and to network troubleshooting on Windows Vista.  The CD that accompanies the book includes many useful tools, scripts and resources.

If you are an old hand at networking and troubleshooting network issues you might be thinking that you can get by without another resource kit on your shelves.  Maybe you can.  But...this book contains information on most of the new technologies built into Windows Vista that you haven't read about in past resource kits from Microsoft.  LOTS of things have changed between Windows XP and Windows Vista.  It’s worth a look.

You can read more about it here:  http://www.microsoft.com/mspress/books/9536.aspx 

Recently my team published a whitepaper on the Network Diagnostics that we built into Windows Vista.  The target audience for the paper is IT Professionals. 

The paper covers the Network Diagnostics Framework (NDF) and the Network Connectivity Status Indicator (NCSI) in depth including related registry keys/values and event log IDs.

http://www.microsoft.com/downloads/details.aspx?FamilyID=1698e42b-03fd-4cd9-b568-d948de55b0f8&displaylang=en

This is a great resource if you really want to get the most out of these features.

For the better part of the last two years I have been working as a Program Manager on the Network Experience team in the Core Operating System Division at Microsoft.  I have been working on the network diagnostics built into Windows Vista with a team of talented and dedicated Developers, Testers and Program Managers. 

These are v1 features that I hope will help every Consumer user running Windows Vista overcome the most common networking issues that they typically experience.  I also hope that experienced support folks can also leverage these features to reduce the amount of work they have to do to isolate and fix common networking issues.  I plan to make a few blog posts to evangelize these features in the near future.

Why did we build network diagnostics into Windows Vista?  In the past, in order to troubleshoot a network issue a knowledgeable individual would have to use several support tools to gather information, test hypotheses, and identify how to fix an issue.  As you can see from some of my other blog posts, I developed many support tools in the past to help experienced troubleshooters do just that. 

There are several issues that limit the usefulness of support tools:

• Accessibility: the number of users that can really take advantage of support tools is limited for a couple of reasons:
• Typically the user of a network support tool needs to have knowledge of networking and experience troubleshooting network issues to effectively make use of a network support tool.  Although there are many IT Pros that have the required mix of knowledge and experience to use such tools, there are many, many more people that do not.  Support tools are not useful to the vast majority of users that experience network issues.
• Many support tools are not localized.  i.e. they only support the language of the developer that wrote them.  If the user doesn’t understand the same language they probably won’t be comfortable using the tool.   

• Consistency (Variable Input/Output): every tool takes different input (or the same input but with a different format) and generates different output. i.e. there is no universal syntax for support tools.  If the user must use three or four support tools to troubleshoot an issue, chances are each tool requires different switches than the others.  The user has to be able to interpret each tool’s output and determine which pieces of output need to be used as input for the next tool.

• Serviceability: maintaining support tools can be challenging for their developers.  As new requirements emerge it can be difficult (and expensive) to retro-fit old tools to meet the new requirements.  Many times it is easier to develop new tools to meet the new requirements.  This exacerbates the previous two issues I mentioned above.

One of the goals we had for network diagnostics in Windows Vista was to mitigate the need for users to use network support tools when they encountered common network related issues.  This simplifies the troubleshooting process for both Consumers and IT Pros and makes network diagnostics more accessible for everyone.  We wanted to simplify the input and output that users had to deal with (this is much harder to do than it sounds).  Since these network diagnostics are built into Windows Vista, the output is localized in all the languages that Windows Vista supports and being built-in will also improve our ability to service network diagnostics over time.

I will introduce you to some of these new features included in Windows Vista in my upcoming blog posts.

Do you know whether your Windows system is sniffing network traffic off the network without your knowledge?  

This type of passive attack can be very difficult to detect.  There are numerous third party tools that try to detect network sniffers running on the network by looking for signs of systems with network interfaces running in “promiscuous mode.” Since many of these tools use network-based detection techniques that rely on bugs in operating systems and/or specific sniffer behavior, they can generate false positive and false negative results.

I have developed a tool that can detect managed Windows systems that have network interfaces running in promiscuous mode – a key indicator that a network sniffer is running on the system.  I use a host based detection technique instead of a network based detection technique in order to make this tool as accurate as possible.

I built two versions of this tool:

• Promqry – a command line tool
• PromqryUI – a tool with a GUI

Both of these tools essentially have the same functionality:

• Query the local system’s network interfaces
• Query a single remote system’s interfaces
• Query a range of remote system’s interfaces

Both tools require the .Net Framework to run.  This means you need the .Net Framework installed on the system you run Promqry or PromqryUI from, but not on the remote systems you want to query.  If you don’t have the .Net Framework already installed, you can get it from here:  http://msdn.microsoft.com/netframework/downloads/framework1_1/   The “general users” install package will be sufficient for most users. 

You can get both versions of Promqry (for free) from the download center on www.microsoft.com using these links:

A command line version:

http://www.microsoft.com/downloads/details.aspx?FamilyID=4df8eb90-83be-45aa-bb7d-1327d06fe6f5&DisplayLang=en

A version with a GUI:

http://www.microsoft.com/downloads/details.aspx?FamilyID=1a10d27a-4aa5-4e96-9645-aa121053e083&DisplayLang=en

I hope you find these tools useful.

Recently I exchanged e-mail with several people who were complaining that the Windows Update (AU) client on their Windows system was guilty of automatically rebooting their system.  They were upset that their system was rebooted even though they had unsaved work open or were using the system when it was rebooted.

Some examples…One person’s Windows Media Center Edition system was rebooted while they were watching their favorite show on TV.  Another person, who uses their laptop as an alarm clock when they travel, slept in because they system was rebooted and the alarm clock application didn’t restart.  Another person said they were working on a Word doc and went to the restroom only to return to find their system rebooted and the Word doc gone (lucky it is so easy to recover Word docs).

Most of the stories have two things in common:

1. The system was a Windows XP SP2 system with the AU client configured to “Automatically download recommended updates for my computer and install them on a schedule.”
2. A user was logged on to the system and the console wasn’t visible (it was locked or they were away from the console) when the reboot occurred.

The answer is NOT to disable the AU client.  You definitely want to keep your system up to date with the least amount of effort…so please don’t disable the AU client…read on….

As it turns out, the reboot is actually expected behavior.  You have Automatic Updates on your system configured to “Automatically download recommended updates for my computer and install them” on a schedule.  When one or more of those updates requires a reboot, the system gets rebooted. 

But let me explain why it does this and how to prevent it from happening again.  First, check what AU client settings are currently set on the system.  To do this, open the Control Panel and double click on the Automatic Updates icon. 

With the recommended setting (“Automatically download recommended updates for my computer and install them” on a schedule), I should expect my system to reboot at approximately 3:00 AM if any installed updates require a reboot.  If you have this set to install during your work hours or when you are watching TV, etc…you should expect an automatic reboot during that period if updates are installed and one or more of them requires a reboot.

If the AU client has rebooted your system, you should see a few related events in your system’s event log.  One event is logged when updates are ready to install.  The event below is logged when the updates are installed and this results in an automatic reboot (notice the time is shortly after the default 3:00 AM install time).

Event Type:      Information

Event Source:   Windows Update Agent

Event Category:            Installation

Event ID:          22

Date:                10/15/2004

Time:                3:02:02 AM

User:                N/A

Computer:         MY-COMPUTER

Description:

Restart Required: To complete the installation of the following updates, the computer will be restarted within 5 minutes:

- Critical Update for Office XP on Windows XP Service Pack 2 (KB885884)

- Cumulative Security Update for Internet Explorer for Windows XP Service Pack 2 (KB834707)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Data:

0000: 57 69 6e 33 32 48 52 65   Win32HRe

0008: 73 75 6c 74 3d 30 78 30   sult=0x0

The key is this line:  “To complete the installation of the following updates, the computer will be restarted within 5 minutes…”   When you are logged on to the system, whether the console is locked or not, a dialog box pops up with a timer counting down to reboot.  If you are logged on as an administrator, you can abort the count down.  If the console is locked or you are not in front of the system when the timer appears…it counts down and reboots the system.

This behavior is controlled by a registry entry.  A great source of information on the AU client (and Software Update Services) is the “Software Update Services Deployment White Paper.  You can download a copy of this paper from here: 

http://www.microsoft.com/windowsserversystem/sus/susdeployment.mspx

Page 57 - 59

To prevent Automatic Updates from restarting a computer while users are logged on, the administrator can create the NoAutoRebootWithLoggedOnUsers registry value in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU. The value is a DWORD and must be either 0 (false) or 1 (true). If this value is changed while the computer is in a restart pending state, it will not take effect until the next time an update requires a restart.

Summary of behavior for NoAutoRebootWithLoggedOnUsers settings

The following table shows the difference in behavior with NoAutoRebootWithLoggedOnUsers enabled (set to 1) or disabled or not configured (not set to 1).

Hopefully you are not logged on very often as an administrator, but either way, pick the scenario that matches how you use your system from the grid above and set NoAutoRebootWithLoggedOnUsers to give you the behavior that you are looking for.

IMPORTANT:  If you choose to configure your system not to reboot when a security update which requires a reboot is installed, you are taking a huge risk.  The fixed code is not actually loaded (in memory) by the system until after the reboot.  i.e. the old, vulnerable code is still running until a reboot is completed.  If you do not reboot the system for whatever reason (you didn’t realize a security update was automatically installed, you want to wait for a regular maintenance window, you forget, you were on vacation, etc.) your system will still be vulnerable.  You also risk system stability by delaying a required reboot.  When some files that are in use are replaced but not loaded, and other files that are not in use are replaced, you can get into a mixed binary situation. Depending on the binary, there may be conflicts that cause system instability.

Given this reality, it may be prudent to deal with “unexpected” reboots in order to always be up to date and safe.  You need to weigh the risk…

I hope this tip saves you some confusion. 

In order to determine how to implement security on your Windows system(s) you need to assess and understand the ways in which your individual systems can be compromised.  Systems can be very unique depending on the role of each system and the software that is running on each system.  Generally speaking, the more roles a system plays and the more software that a system is required to run, the more ways that system can be attacked.  One of the first steps in hardening a system is to determine the role that the system is going to play and then turn off and/or uninstall as many unnecessary applications and services as possible.

It is important that you understand how an application is going to behave before you run it on a system attached to a network and/or the Internet.  You need to answer some basic questions about your applications:

• Does the application require TCP/IP in order to install and run?  If it does, you need to understand why.
• Which TCP and/or UDP ports does the application’s author state that the application uses?  Some developers document this better than others.  The list you get from the author may be exhaustive, but more likely it will be incomplete.
• Does the application listen on or bind to specific ports while the application is running?  If it does, it is prudent to understand what kind of traffic those ports are expecting and from which systems.
• Can the list of ports that you developed from the questions above be mapped to specific functions within the application?  For example, does a specific port get used when you make a specific menu selection within the application?  This is probably a very tough question to answer, but worthwhile if you can answer it.

This level of detail may sound like its a little overkill, but attackers are using ever-improving tools and are spending a lot of time reverse engineering software.  Even if your systems run behind firewalls or have host-based firewalls installed on them, the applications that the systems run can still be attacked depending on how those applications use the network.

Network monitor and other tools that watch the network traffic that goes to/from a system only report part of the picture.  These tools only catch the traffic that a system either puts on the wire or receives from the network.  They do not log which ports are listening or are bound to the network interface(s) on a system unless those ports are actually used while the capture is taken.

There are some good tools available to help you determine what ports are in use and which applications are using them.  One such tool, for example, is:  http://www.sysinternals.com/ntw2k/source/tcpview.shtml 

I have also developed some tools which can also help do this, one of which I mentioned in my last blog on Port Reporter and Port Reporter Parser: http://weblogs.asp.net/tim_rains/archive/2004/09/02/224905.aspx

These tools can be useful when trying to “profile” an application’s port usage.

Another popular tool that I developed to help get this type of data is called PortQry.  This tool will give you this type of data in near real time as opposed to Port Reporter which is good for supplying data for post-usage analysis over a longer period of time.  Most people think of PortQry as a TCP/UDP port scanner - and it is.  But, in version 2.0 I added a lot of functionality into PortQry so that it could get data on the local system’s TCP/UDP ports.

Three PortQry options can help gather this type of data:

• portqry –local
• portqry –wport
• portqry –wpid  

On a Windows XP or Windows Server 2003 system the command “portqry –local –v “ will provide a “snapshot” of all of the ports and process data currently running on the system.  This data is very similar to the type of data you will find a PR-INITIAL-*.log file created by Port Reporter.  It shows you each process running, any ports each process is using (including their state and remote IP/port data), and a list of the modules that each process has loaded.

Running “portqry –wport –v” allows you to watch a specific port for activity.  This can help determine what process (or processes) uses a particular port and when/how the port gets used.  For example, if you see a system using a particular port (say TCP port 4444) in firewall logs, and want to see which application is actually using the port you can watch it by running portqry –wport 4444 –wt 1 –v.  The –wt option allows you to specify how often to check for changes (in seconds).  The –v option (verbose) will list all the modules that the process has loaded.  This output can also be logged to a text log file using the –l option. 

Running “portqry –wpid –wt 1 –v” allows you to watch a specific process (process ID) for port activity.  This can help determine what ports are used by particular process and when/how the ports get used.  I found it really interesting watching applications (some that I supported for years) and which ports they actually use.  In some cases this data was merely interesting and in other cases it was an eye opening revelation.  Again, the –wt option specifies how often to check for changes (in seconds) and –l can be used to log the output to a text file.

Port Reporter has some advantages over PortQry.  Because it runs as a service which in system context, it can provide a more complete, long term picture of port and process usage.  It is also much more efficient in the way it monitors ports.  But it must be “installed” on a system and it takes more time to analyze the data.  PortQry is a small (140 KB) command line utility that can simply be copied onto a system (no installation program, no registry entries) and then deleted afterwards.  Keep in mind that neither of these tools is designed to show you all of the traffic coming to and/or leaving a system.  You need a network sniffer like Network Monitor to get that type of data.

You can read more about PortQry version 2.0 in this Knowledge Base article:  http://support.microsoft.com/default.aspx?scid=kb;en-us;832919

Whether you use a tool that I have mentioned here or other good tools, understanding how your applications use the network is crucial to protecting them.  After-all the last question you want to ask during the next big worm attack is equivalent to “SQL Server uses UDP port 1434?” ;>)