Tim Rains' WebLog

Windows Vista Resource Kit

tim_rains — Mon, 06 Aug 2007 23:45:00 GMT

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

Microsoft TechNet Session: Network Diagnostics in Windows Vista

tim_rains — Fri, 02 Mar 2007 00:47:00 GMT

Recently I recorded this TechNet webcast focusing on the new network diagnostics built into Windows Vista:

http://www.microsoft.com/winme/0702/20430/index.html

This webcast focuses on the Network Diagnostics Framework (NDF) and the Network Connectivity Status Indicator (NCSI). These features will help you determine if you are connected to a local network and the Internet, and get you re-connected when there are common problems.

This webcast is slightly more technical than the Support webcast that I recorded in December.

Windows Vista Network Diagnostics Whitepaper

tim_rains — Mon, 05 Feb 2007 20:41:00 GMT

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.

Windows Vista Support WebCast: Troubleshooting Network Issues on Windows Vista - New Network Diagnostics

tim_rains — Tue, 09 Jan 2007 01:22:00 GMT

Recently I recorded this webcast focusing on the new network diagnostics built into Windows Vista:

http://support.microsoft.com/kb/927551

During this 45 minute webcast I introduce two new features in Windows Vista: the Network Diagnostics Framework (NDF) and the Network Connectivity Status Indicator (NCSI).

The webcast is worth a look if you are interested in advances in network troubleshooting or if you simply want to get a head start learning about some of the new features in Windows Vista.

The Problem with Network Support Tools - Windows Vista Will Help

tim_rains — Wed, 15 Nov 2006 02:35:00 GMT

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.

List of Tim Rains' Windows Support Tools

tim_rains — Thu, 12 Oct 2006 19:31:00 GMT

Wow, it’s been a while since my last blog post.

I have developed and released numerous networking and security support tools over the years. I get e-mail weekly from customers who use my tools. Frequently I get e-mail from people who have difficulty finding some of my tools. Many of these tools have been released as part of the Support Tools directory on the Windows XP CD and on the Windows Server 2003 CD. These tools are also available as free downloads from the Download Center on www.microsoft.com .

I have been asked many times to publish a list of the resources/URLs for each tool to make them easier to find. I hope this helps.

PortQry

TCP/IP connectivity test tool, port scanner, and local port monitor. Networking and security usages.

Download link

http://www.microsoft.com/downloads/details.aspx?familyid=89811747-C74B-4638-A2D5-AC828BDC6983&displaylang=en

KB articles

PortQry Overview

http://technet2.microsoft.com/WindowsServer/en/Library/52704f7f-dfda-4656-90fc-c747a565b4ca1033.mspx

New features and functionality in PortQry version 2.0

http://support.microsoft.com/kb/832919/

Webcasts

Port Scanning Using PortQry

http://support.microsoft.com/kb/325494/

New features and functionality in PortQry 2.0

http://support.microsoft.com/default.aspx?kbid=834626

Port Reporter

TCP/IP port usage logging service. Networking and security usages.

Download link

http://www.microsoft.com/downloads/details.aspx?FamilyID=69ba779b-bae9-4243-b9d6-63e62b4bcd2e&DisplayLang=en

KB article

Availability and description of the Port Reporter tool

http://support.microsoft.com/kb/837243

Webcast

Port Reporter

http://support.microsoft.com/kb/840832/

Port Reporter Parser (PR-Parser)

Log parser for Port Reporter log files. Networking and security usages.

Download link

http://download.microsoft.com/download/2/8/8/28810043-0e21-4004-89a3-2f477a74186f/PRParser.exe

KB article

Description of the Port Reporter Parser (PR-Parser) tool

http://support.microsoft.com/kb/884289

DNSLint

Domain Name System (DNS) troubleshooting/health monitoring tool.

Download link

http://download.microsoft.com/download/2/7/2/27252452-e530-4455-846a-dd68fc020e16/dnslint.v204.exe

KB articles:

Description of the DNSLint utility

http://support.microsoft.com/kb/321045/

How to use DNSLint to troubleshoot Active Directory replication issues

http://support.microsoft.com/?kbid=321046

Webcast

Microsoft Windows: Using the DNSLint Utility

http://support.microsoft.com/kb/329982

Promqry

Detects Windows systems possibly running network sniffers. Networking and security usages.

Download links

Command line version

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

GUI version

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

KB article

Description of Promqry 1.0 and PromqryUI 1.0

http://support.microsoft.com/kb/892853

NetBIOS Browsing Console (browcon)

Helps troubleshoot NetBIOS browsing issues in Windows domain environments.

Download link

http://download.microsoft.com/download/b/2/a/b2ae4b0e-dc51-40d8-98bf-7a4ade88dcdf/browcon.exe

KB article

Description of NetBIOS Browsing Console (Browcon.exe)

http://support.microsoft.com/?kbid=818092

Webcast

Using the NetBIOS Browsing Console to Troubleshoot NetBIOS Browsing

http://support.microsoft.com/kb/820914

NBLookup

WINS/name resolution troubleshooting/monitoring tool.

Download link

http://download.microsoft.com/download/f/3/a/f3adc5b4-2716-4ef3-bbb8-f4cd4446d415/nblookupv1.exe

KB article

NBLookup.exe command-line tool

http://support.microsoft.com/kb/830578

SPCheck

Helps identify the service pack level of networking components on a file by file basis.

KB article

How to Use the SPCheck Tool to Determine the Service Pack Level of Components

http://support.microsoft.com/kb/279631

Download links

Windows Server 2003:

http://download.microsoft.com/download/c/5/6/c56eb418-9b8a-4ced-b077-998b662c807c/w2k3.exe

Windows XP:

http://download.microsoft.com/download/6/e/0/6e0b8c10-a71b-44f1-99d5-27f6fc535f5c/xpspchk.exe

Windows 2000:

http://download.microsoft.com/download/5/7/6/57622a9c-d6b4-47bb-9f37-008a8b1405c8/w2kspchk.exe

Windows NT 4.0:

http://download.microsoft.com/download/5/c/4/5c426317-7403-4e05-8183-7f370c383017/nt4spchk.exe

Exchange 5.5:

http://download.microsoft.com/download/1/8/8/1882bcc6-c940-4904-8330-8aa1faabfe5e/exchange55.exe

Internet Security and Acceleration Server (ISA) 2000:

http://download.microsoft.com/download/2/8/a/28a889cf-6880-4b97-b7e8-12ccf5fa8d74/isaspchk.exe

New Tool to Detect Network Sniffers Running on Windows Systems

tim_rains — Fri, 04 Feb 2005 23:07:00 GMT

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.

DNSLint – what does Lint mean?

tim_rains — Wed, 15 Dec 2004 22:27:00 GMT

One of the most popular tools that I have developed over the last few years is DNSLint. This tool shipped with the Support Tools on the Windows Server 2003 CD and has been available for download from the download center on www.microsoft.com for a few years.

I frequently get asked where the idea for this tool came from, so I thought I would post the story here. I developed this tool when I worked on the Enterprise Platform Support Networking team in Product Support Services (here at Microsoft). One of the services that this team supports is DNS. After Windows 2000 shipped it seemed like almost every customer I talked to needed help designing a DNS namespace or had implemented a design that they needed help with. The primary reason for this is that Windows 2000 requires DNS for Active Directory and many customers were upgrading from Windows NT 4.0 which did not require DNS for domain building purposes. Many people needed help with DNS during this transition period.

After spending hours with nslookup troubleshooting lame delegation issues, I decided to build a tool to automate the process and save everyone some time. DNSLint was born. Travis Adams from the Enterprise Platform Support Directory Services team asked me to add a feature to help troubleshoot Active Directory replication issues caused by missing or inconsistent DNS records. Then I added a feature that allows you to query all the DNS records specified in an input file. With this feature you can check all the DNS records for all of your critical servers (domain controllers, web servers, SQL servers, etc) on every DNS server that should know about them in a very short time frame.

I receive e-mail about DNSLint weekly. A frequently asked question I get about this tool is not a technical question at all: Is the Lint in DNSLint an acronym and if so…what does it mean? Just to clear this up…lint is something you find in your blue jeans after they come out of the dryer. When you find lint, it is useless and sort of embarrassing…so you quickly throw it away. Not unlike outdated or inaccurate DNS records for important systems. ;>)

You can read all the technical details about DNSLint in this Knowledge Base article:

http://support.microsoft.com/?kbid=321045

I also recorded a webcast for your listening and viewing pleasure:

http://support.microsoft.com/default.aspx?scid=kb;en-us;329982

Also, there are lots of good DNS resources at the DNS center:

http://www.microsoft.com/Windows2000/technologies/communications/dns/default.asp

Is Windows Automatic Update Client rebooting your system unexpectedly? Read this to “fix” it….

tim_rains — Mon, 15 Nov 2004 23:36:00 GMT

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:

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

Scenario following a scheduled installation	With NoAutoRebootWithLoggedOnUsers enabled	With NoAutoRebootWithLoggedOnUsers disabled or not configured
No users logged on	Automatic restart immediately following installation	Automatic restart immediately following installation
Single user with administrative privileges	Restart notification that allows user to initiate the shutdown or postpone it. This notification does not have a countdown timer. Therefore the user must initiate the system shutdown.	Restart notification that allows user to initiate the shutdown or postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.
Single user with restart privileges but no other administrative privileges	Restart notification that allows user to initiate the shutdown but not to postpone it. This notification does not have a countdown timer. Therefore the user must initiate the system shutdown.	Restart notification that allows user to initiate the shutdown but not to postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.
Single non-administrator without restart privilege	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification does not have a countdown timer. Therefore the user must wait for an authorized user to initiate the system shutdown.	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.
Administrator while other users are logged on	Restart notification that does not allow the user to initiate the shutdown but does allow the user to postpone it. This notification does not have a countdown timer. Therefore the user must initiate the system shutdown.	Restart notification that does not allow the user to initiate the shutdown but does allow the user to postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.
Non-administrator with restart privilege while other users are logged on	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification does not have a countdown timer. Therefore the user must initiate the system shutdown.	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.
Non-administrator without restart privilege while other users are logged on	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification does not have a countdown timer. Therefore the user must wait for an authorized user to initiate the system shutdown.	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.

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.

Why you still run Windows Internet Naming Service (WINS)

tim_rains — Tue, 05 Oct 2004 20:25:00 GMT

When Mark Minasi wrote this very flattering article about me, I felt it was only right to develop the tool that he had been waiting years for.

http://www.winnetmag.com/Article/ArticleID/39436/39436.html

Why does Mark, and many other people, think that NetBIOS name resolution is still so important? You still run WINS on your network…right? The vast majority of customers that I talk to, still run a WINS service somewhere on their network.

Many people anticipated the demise of WINS when Windows 2000 was released. They had a vision of a simplified network where the only types of name resolution problems to troubleshoot were related to DNS. No more name registration problems, replication issues, record tomb stoning riddles or secure channel troubleshooting to do. This was going to be a world where every application was directory aware and discoverable via protocols like DNS and LDAP.

There are several reasons why WINS is still necessary on most networks. The biggest reason I can think of is that many applications still use NetBIOS to provide some functionality to users. In the past I tried to compile a list of such applications, but this was a daunting task because an application’s use of NetBIOS can be very subtle.

As it turns out, for most administrators, the question of whether to use WINS or not is an easy one to answer and doesn’t require an exhaustive list of applications that use NetBIOS. Two of the most popular applications that have shipped with different Windows operating systems over the years are Network Neighborhood and My Network Places. These applications are used heavily by administrators and the end-users that they support. End-users love these applications.

If you or your users use these applications, you are probably going to want to use WINS to help populate the lists of network resources that these applications present to the user. These lists are generated and maintained by the NetBIOS Browsing mechanism built into the Windows operating system. In fact, if you run applications that allow the user to open and/or save data across the local network or pick a computer to connect to, i.e. select a server or workstation from a list of network resources, then it’s a good chance those applications use the NetBIOS Browsing mechanism to populate those lists. Where NetBIOS Browsing is used, WINS is typically involved too. WINS helps facilitate the distribution of the browse lists of network resources, to all the Windows systems on a network.

Some applications are now using mechanisms other than NetBIOS to populate these types of lists. But, upon close inspection, it may surprise you how many applications that you use still rely on the NetBIOS Browsing mechanism and WINS.

If you have been considering retiring a WINS server on your network it would be prudent to determine how much it is being used before stopping the service. One method that many customers have found effective is to use Performance Monitor on the WINS server. When WINS is installed on a server, some performance monitor counters for WINS are also installed. These counters can tell you how many queries and responses the WINS server is handling.

If it turns out that you still need to run the WINS service, there are a few Resource Kit tools to help you manage it and troubleshoot problems. As I mentioned above, I developed a tool that may help you with troubleshooting and name registration/record availability confirmation tasks.

Nblookup.exe is a tool that is modeled very closely to the nslookup.exe utility that is used to troubleshoot DNS issues. It is relatively small (around 102 Kb) and does not have an installation program (just copy it into any directory and run it). It allows you to query WINS servers for name registration records just like nslookup allows you to query DNS servers for DNS records. Unlike most other WINS tools that you may have used, nblookup does not require an authenticated connection to the WINS server, i.e. you don’t have to run this tool in administrator context. I also added some features like ability to query/verify large numbers of records very quickly using an input file. This makes it very easy to quickly determine whether all of the important systems/applications on your network are registered and discoverable using all of the WINS servers on your network.

This tool is not part of any resource kit, but it can be downloaded (for free) from microsoft.com. You can download nblookup and read all the details in this Knowledge Base article:

http://support.microsoft.com/Default.aspx?kbid=830578

Mark Minasi was kind enough to include nblookup as one of his “The Magnificent Six” list of tools. Did I mention that Mark is a great author. ;>)

http://www.winnetmag.com/Article/ArticleID/42914/42914.html

If you still run WINS, and you probably do, it may be worth your while to add nblookup to your toolkit.

Assessing the Risk: which TCP/UDP ports does your favorite application use?

tim_rains — Fri, 10 Sep 2004 22:16:00 GMT

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?” ;>)

What is really happening on your Windows system? Port Reporter & Port Reporter Parser may help answer this...

tim_rains — Thu, 02 Sep 2004 20:53:00 GMT

"What is really happening on my Windows system?"

As a Technical Lead on the Microsoft Product Support Services Incident Response team, I talk to customers every day that ask me this question. Whether you use a single computer in your home or office, or run a business using thousands of systems, at some point you have probably wondered what is really happening on your system(s). Has your system been compromised? Is it running processes for someone other than you?

Determining if a system has been compromised can be difficult and time consuming. Even if evidence of an intrusion isn’t found, how confident are you that the system has not been compromised and is running only authorized, legitimate processes? Auditing system activity can be complex and time consuming. In my experience most compromised systems typically have at least two things in common:

They were compromised via the network. i.e. attackers did not have physical access to the system so they attacked the system over the wire. I am not saying that I haven’t seen systems that have been purposely compromised by people sitting in front of the keyboard. But this type of case seems to be much rarer than cases where the attackers are remote.
After the system was successfully compromised, the attackers used the system for some purpose. i.e. they are not satisfied with gaining access to the system, they want to run their own processes on the system to accomplish whatever goal they have in mind. If you are interested in what attackers use compromised systems for, a co-worker of mine, Robert Hensing, has done a good job of outlining the different types of hackers that we encounter: http://blogs.msdn.com/robert_hensing/archive/2004/08/09/211383.aspx

Because most compromised systems have these two things in common (or at least one of them will inevitably be true) if you audit the TCP/IP port usage and the processes running on a system you can get some idea about what your Windows system is really doing. One caveat I have to make is that this approach is not fool proof. If the attackers install “rootkit” programs designed to hide port and process usage data (along with files, registry entries, etc) from the operating system itself, a combination of techniques and/or tools may be needed to detect them.

Rootkits aside, lots of software has been written to help monitor system integrity and monitor the processes that run on a system. How much money, time and effort you are willing to spend on software to help in this endeavor is probably related to the level of confidence that you require in your systems’ integrity.

I have developed several tools to help customers answer that fundamental question, "what is really happening on my Windows system?" Two of these tools, Port Reporter and Port Reporter Parser (PR-Parser) are publicly available and are free.

Port Reporter is a logging service that logs port to process activity on Windows 2000, Windows XP and Windows Server 2003 systems. This service runs in the background and does not require any user intervention. It generates text log files that contain data that will help determine what your system is doing. Specifically, these log files contain data on running processes and the TCP and/or UDP ports that processes use. On Windows Server 2003– and Windows XP–based computers, the Port Reporter service can log the following information:

· The ports that are used

· The processes that use the port

· Whether a process is a service

· The modules (.dll, etc) that a process loaded

· The user accounts that start a process

This tool can be downloaded from: http://www.microsoft.com/downloads/details.aspx?familyid=69ba779b-bae9-4243-b9d6-63e62b4bcd2e&displaylang=en

Depending on how busy your system is, Port Reporter can generate a lot of data. This is where the second tool that I mentioned, PR-Parser can help.

The Port Reporter Parser (PR-Parser) is a tool that parses the logs that the Port Reporter service generates. I have built some features into this parser to help identify suspicious processes and ports running on Windows systems and to provide some useful statistics on a system’s usage. Some features of PR-Parser include:

· PR-Parser has a Windows graphical user interface (GUI), which makes it easier to review logs than trying to use a text editor. The GUI enables you to sort and filter the data in a number of ways.

· PR-Parser helps you identify and filter data you are interested in. The tool:

o Identifies ports of interest that are used on the system.

o Identifies processes of interest running on the system.

o Identifies modules of interest, such as .dlls, etc loaded on the system.

o Helps to determine when user accounts of interest are active on a system.

o Helps to determine when IP addresses, fully qualified domain names (FQDNs), or computer names of interest are found communicating with the system.

o Attempts to identify when a process using the name of a legitimate process is run from the wrong directory on the system. Example: is Svchost.exe running from the wrong directory – if it is the system may be compromised.

· PR-Parser provides some log analysis data as well. This data can help you understand how the system is used. This data includes:

o Ranked list of local TCP port usage. Which TCP ports have been used? If they include TFTP or FTP and they shouldn’t, then maybe you have an issue to investigate. If TCP port 4444 is being used a lot on a system, maybe it’s infected with the Blaster worm – you should investigate.

o Ranked list of local process usage. Which processes have been running on the system?

o Ranked list of remote IP address usage. Which remote IP addresses have connected to your system?

o Ranked list of user context usage. Which user accounts are used to launch processes most often on your system?

o Port usage by hour of the day. Is someone connecting to the system in the middle of the night when they shouldn’t be?

o Svchost.exe service enumeration. What services are hosted by each instances of svchost.exe? You need to know this to understand what the system is really doing.

o Internet Explorer usage by user. Where have users been going with Internet Explorer? It may be tough to get this information if you don’t have access to firewall or proxy logs.

PR-Parser and a detailed readme file can be downloaded from:

http://download.microsoft.com/download/2/8/8/28810043-0e21-4004-89a3-2f477a74186f/PRParser.exe

While these tools and this approach cannot detect all instances of compromise, they can give you some help in identifying compromised systems. They should be used in combination with other tools and approaches in order to gain some level of confidence in your system’s integrity. That said, many customers and my team (PSS Security) have had some good results with these tools. I hope you find them as useful as we have.

This posting is provided "AS IS" with no warranties, and confers no rights.