A comprehensive reference dedicated to the ubiquitous Wireshark protocol analyzer, authored by the foremost expert in protocol analysis and Wireshark, Laura Chappell, is now available for pre-order. Due to be released on March 29, 2010, you can view sample pages by visiting wiresharkbook.com. Be sure to visit wiresharktraining.com and chappellseminars.com for additional training and reference material.
Leave a Comment » | 
General, Networking | 
Permalink
Posted by Richard Hicks
NMap, the venerable network security scanner, has recently been updated. NMap 5.21 includes a ton of new enhancements. If you are new to NMap or would simply like to enhance your skills I would strongly encourage you to read the NMap Network Scanning book, written by the author of NMap.
Leave a Comment » | Networking, Utilities | Permalink
Posted by Richard Hicks
Recently I encountered an issue when after installing and configuring Microsoft Forefront Threat Management Gateway 2010 (TMG) I was unable to gather performance data remotely. I found this puzzling because I was able to perform other management tasks such as connecting remotely with RDP and the TMG management console without issue. Since my management workstation was a member of the Remote Management Computers network object for the array, I assumed that I would have sufficient access to perform this task. Looking at the access logs revealed something interesting; traffic on TCP port 445 from my management workstation was being denied.
Upon reviewing the system policy I noticed that the Remote Performance Monitoring policy was not enabled. I’ve never had to enable this rule in the past to collect performance data remotely, but I tried enabling it anyway just for good measure.
Enabling this system policy rule did not resolve my issue, and the access log still showed my CIFS traffic being denied. A closer look at this rule shows that only NetBIOS protocols were included, not CIFS.
Under normal circumstances, enabling this rule isn’t required if you have the Allow remote management from selected computers using MMC system policy rule enabled (it is enabled by default). What made this situation unique, and ultimately caused the communication failure, was that NetBIOS over TCP/IP was disabled on all network interfaces.
To understand why monitoring performance remotely fails when NetBIOS over TCP/IP is disabled requires an understanding of Server Message Block (SMB) communication. SMB is an application-layer protocol that uses TCP for transport layer communication. In Microsoft operating systems prior to Windows 2000, all SMB communication took place over NetBIOS, which in turn ran on top of TCP/IP using the familiar TCP port 139. Beginning with Windows 2000, SMB runs directly on top of TCP/IP using TCP port 445. In Windows 2000 and later, the default behavior of SMB communication is to attempt to communicate directly over TCP/IP using TCP port 445 first, then if there is no response, an attempt to use NetBIOS over TCP/IP is made using TCP port 139 (provided NetBIOS has not been explicitly disabled). The performance monitor utility (perfmon.exe) communicates in exactly this way. Since NetBIOS over TCP/IP was disabled, communication only takes place over TCP port 445. In the absence of an access rule allowing Microsoft CIFS (TCP) inbound to the local host, the communication fails.
This issue can be resolved in several ways. First, enabling the Allow remote management from selected computers using MMC or the Allow remote performance monitoring of Forefront TMG from trusted servers system policy rule and enabling NetBIOS over TCP/IP on the network interface will resolve the issue. Since disabling NetBIOS over TCP/IP was required by security policy in this case, creating an access rule allowing Microsoft CIFS (TCP) inbound to the local host from Remote Management Workstations was the best choice.
Another option is to enable the Allow access from trusted servers to the local configuration storage server system policy rule, as this rule allows Microsoft CIFS (TCP) protocol inbound to the local host.
This may not be desirable because the rule includes additional protocols that aren’t required for remote performance monitor data collection, and increases exposure of services running on the TMG firewall needlessly.
2 Comments | Networking, Threat Management Gateway, Troubleshooting | Permalink
Posted by Richard Hicks
Wireshark just announced the availability of Wireshark v1.2.3. Included in this release is version 4.1.1 of WinPcap that now works with Windows 7! Download your copy today!
Leave a Comment » | General, Networking, Utilities | Permalink
Posted by Richard Hicks
As a follow up to my last blog post I wanted to share with you a way to perform basic HTTP connectivity testing using VBScript. Using the GetAllResponseHeaders method of the XMLHTTP object we can easily retrieve and display response headers returned by a web server. The VBScript code looks like this:
Option Explicit
Dim HTTP, Site
Site = InputBox(“Enter site name:”, “Get All Response Headers”)
Set HTTP = WScript.CreateObject(“Microsoft.XMLHTTP”)
Call HTTP.Open(“HEAD”, “http://” & Site, False)
Call HTTP.Send()
MsgBox HTTP.GetAllResponseHeaders(), vbInformation, “Response Headers for ” & Site
Set HTTP = Nothing
Copy the code above to a text file and save it with a .vbs extension. Double-click on the file and you will be prompted to enter a web site to test.
Enter the name of the web site to test and choose ‘Ok’. The script will send a request to the web server and display the response headers returned.
Admittedly this code is very rudimentary, but it is a simple and effective way to troubleshoot HTTP connectivity issues. If you are interested in something similar that has many more features, including the ability to use specific HTTP commands, perform logging, use a proxy server, specify a USER AGENT string and much more, visit Jim Harrison’s ISATools.org and download his very powerful HTTP_TEST VBScript.
Leave a Comment » | Networking, Troubleshooting, Utilities | Permalink
Posted by Richard Hicks
In my last blog post I demonstrated how to use the Windows telnet client to perform basic network connectivity troubleshooting. In this post I will demonstrate how to use the telnet client to interactively perform basic HTTP troubleshooting.
Note: This post assumes that you have a fundamental understanding of the HTTP protocol. If you are not familiar with HTTP and would like to learn more, there are some excellent books on the subject available. Two books that I recommend are HTTP – The Definitive Guide and the HTTP Pocket Reference, both from O’Reilly Books.
To begin, open a command prompt and enter the command telnet. This will bring up a telnet command prompt.
Notice that the escape character is CTRL+]. We’ll need to know this later. Next, enter the command set localecho. This command allows us see the text that we type in the command window.
To establish a connection to a web server on the default port, the command syntax is open <IP address, FQDN, or hostname> <port>.
For example…
open intranet.celestix.net 80
After you enter the open command and hit enter, it is not readily apparent that a connection has been made to the web server. That’s because the cursor immediately jumps to the upper left corner of the command window.
Before entering commands, hit the enter key a few times to bring the cursor to a clear area in the window.
Now that we have established a connection, we are ready to issue some basic HTTP commands to the web server. Let’s begin by retrieving the default web page for the site intranet.celestix.net. Although a full-featured HTTP client will send many request headers to a web server to retrieve content, the RFC specifies that only the HOST header is mandatory for HTTP 1.1. First we will send a GET command requesting the default page, then we will provide the HOST header to let the web server know which web site we are requesting content from (this is required because the web server may be hosting multiple web sites using the same IP address).
To retrieve the default page from intranet.celestix.net, enter the following commands:
GET / HTTP/1.1
HOST: intranet.celestix.net
These commands are case sensitive! Be sure to enter them exactly as shown above. After entering the HOST information, hit enter twice to send the commands to the web server. If successful, the web server will respond with the requested content.
Enter the escape command sequence CTRL+] to return to the telnet command prompt.
Additional Examples
Instead of retrieving the content of the web page, we could request that the web server send response headers only. This can be accomplished by entering the following commands:
HEAD / HTTP/1.1
HOST: intranet.celestix.net
If successful, the web server will send only the response headers and not the content of the web page itself.
Although somewhat useful in troubleshooting basic HTTP communication, the telnet client isn’t the best tool to use. As you will quickly see, the telnet client will not allow you to backspace if you make a typo entering a command. The advantage of using the telnet client is that it is installed on most Windows operating systems by default. Thankfully, a much more robust and feature rich tool is available from Microsoft. WFetch is a GUI utility that allows you to issue many different commands to the web server and includes support for multiple authentication methods. It includes the flexibility to manipulate headers and provides the ability to direct communication through a proxy server. If you are performing advanced troubleshooting or want to learn more about HTTP communication, you can find out more about using WFetch here.
1 Comment | Networking, Troubleshooting, Utilities | Permalink
Posted by Richard Hicks
The telnet client included with Windows is a useful low level diagnostic tool. When troubleshooting a network connectivity issue, it is a simple and effective way to determine if you can establish a TCP connection with a remote host on a particular port. The command syntax is:
telnet <IP address, FQDN or hostname> <port>
For example…
telnet fileserver.celestix.net 445
This command instructs the telnet client to open a TCP connection to the server fileserver.celestix.net on port 445 (which is used by SMB). A successful TCP connection was made if the command prompt disappears and you are left with only a flashing cursor.
You can confirm this by monitoring the communication with a protocol analyzer (e.g. Network Monitor or Wireshark) when you execute the command.
Note: The example above uses a fully-qualified domain name (FQDN). When using FQDN’s or hostnames, make certain that name resolution is working properly if you are unable to establish connectivity.
Additional Examples
telnet dc01 389
This command establishes connectivity to dc01 on TCP port 389 (LDAP).
telnet 192.168.1.100 3389
This command establishes connectivity to 192.168.1.100 on TCP port 3389 (RDP).
Unable To Connect
If a connection cannot be established you will receive the following error message:
Could not open connection to the host, on port <port number>: Connect failed
This error message does not explain why the connection could not be established, however. It may be that the remote host was not listening on the specified port, the remote host was not reachable, or perhaps a firewall on the remote host or in the network path between the client and the remote host denied the connection. Looking at the communication with a protocol analyzer provides more information. For example, if the remote host is reachable but not listening on the port requested, the remote host will reply with a TCP reset.
If the remote host was not reachable or a firewall denies the communication there will be no replies.
Telnet Clients
Historically the telnet client has been installed by default on all Windows operating systems. That changed beginning with Windows Vista. With Windows Vista and Windows 7 you will need to open the ‘Programs and Features’ control panel application and in the task pane select the option to ‘Turn Windows features on or off’.
Select ‘Telnet Client’ and choose ‘Ok’ to install it.
On Windows Server 2008 systems it is even easier to install the telnet client. From an elevated command prompt enter the following command:
servermanagercmd -i telnet-client
In addition there are numerous third-party telnet clients available for Windows. Some are free such as the popular Putty telnet client, and some are commercial such as SecureCRT. Third-party telnet clients offer advanced featuers not found in the native Windows telnet client and also support additional protocols such as SSH and RLogin.
In my next post I will demonstrate how to perform basic HTTP troubleshooting using a telnet client.
Leave a Comment » | Networking, Troubleshooting, Utilities | Permalink
Posted by Richard Hicks
Using Web Proxy Auto Discovery (WPAD) is a simple and effective way to configure web browsers to use the ISA firewall as a proxy server. WPAD can be implemented using DNS or DHCP, with DNS being the more common of the two. For WPAD using DNS, configuration is simple and straightforward; all that is required is that you configure a host record in DNS called WPAD that resolves to the IP address of your ISA firewall’s internal network interface.
On the ISA firewall, enable the ‘Publish automatic discovery information for this network’ option on the ‘Auto Discovery’ tab for the Internal network.
For Internet Explorer, navigate to ‘Tools/Internet Options/Connections/Lan Settings’ and select the option to ‘Automatically detect settings’ and your work is done!
Unfortunately this functionality can be easily leveraged for nefarious purposes. An attacker could create their own WPAD record (which can be accomplished simply if dynamic DNS is not configured correctly) and redirect traffic through a host that they control. From there they could have full view in to all web-based communication between a client and an Internet-based remote host.
In order to address this security concern, Microsoft has made changes to the way DNS works beginning in Windows Server 2008. DNS in Windows Server 2008 now includes a feature called the global query block list. Essentially this is a list of names that the DNS server will not respond to if queried. By default this list includes two entries; WPAD and ISATAP. You can view this list by executing the following command from an elevated command prompt:
dnscmd /info /globalqueryblocklist
If you are using Windows Server 2008 DNS and you wish to leverage DNS WPAD functionality you must instruct the DNS server to respond to these requests. Simply creating the DNS record by itself is not enough. On Windows Server 2008 you can configure WPAD by creating your DNS record as usual, then remove WPAD from the global query block list by executing the following command from an elevated command prompt:
dnscmd /config /globalqueryblocklist isatap
This command replaces the existing global query block list with only isatap. Remember to execute this command on each DNS server that is authoritative for your zone.
Although not recommended, you can also disable the global query block list functionality altogether by executing the following command from an elevated command prompt:
dnscmd /config /enableglobalqueryblocklist 0
Of course this functionality can be restored by executing the following command from an elevated command prompt:
dnscmd /config /enableglobalqueryblocklist 1
The global query block list functionality is also now included in security update MS09-008 for Windows Server 2003 DNS and WINS servers. This means that everything we’ve discussed here applies to Windows Server 2003 DNS servers with the MS09-008 update installed, with the exception of how the block list is configured. With Windows Server 2003 DNS and the MS09-008 update, management of the global query block list is done through the following registry key:
HKLM\SYSTEM\CurrentControlSet\Services
\DNS\Parameters\GlobalQueryBlockList
If you have already configured WPAD record in DNS, the good news is that if you perform an in-place upgrade to Windows Server 2008, WPAD functionality will not be disabled. The same holds true if you install the security update for MS09-008. Any existing functionality will remain if it was in place prior to the upgrade or update. For additional information on the MS09-008 security update, read this blog post by the Microsoft Security Research and Defense team.
Leave a Comment » | ISA 2006 Configuration, ISA 2006 General, Networking, Threat Management Gateway | Permalink
Posted by Richard Hicks
Another common ISA alert that I often get questions about is the following:
“ISA Server detected routes through the network adapter [network interface] that do not correlate with the network to which this network adapter belongs. When networks are configured correctly, the IP address ranges included in each array-level network must include all IP addresses that are routable through its network adapters according to their routing tables. Otherwise valid packets may be dropped as spoofed. The following ranges are included in the network’s IP address ranges but are not routable through any of the network’s adapters: [address ranges];. Note that this event may be generated once after you add a route, create a remote site network, or configure Network Load Balancing and may be safely ignored if it does not re-occur.
The routing table for the network adapter [network interface] includes IP address ranges that are not defined in the array-level network [network object], to which it is bound. As a result, packets arriving at this network adapter from the IP address ranges listed below or sent to these IP address ranges via this network adapter will be dropped as spoofed. To resolve this issue, add the missing IP address ranges to the array network. The following IP address ranges will be dropped as spoofed: [network object][address ranges];”
Essentially what this alert means is that there is a there is a mismatch between the configuration of the network object in the ISA management console and the routing table of the corresponding network interface. If you are not experiencing any network connectivity issues, or you just made changes to your network configuration, you can probably safely disregard this message. You will not, in most cases, see this message again. If you are seeing this alert on a consistent basis however, you might wish to look at your networking configuration more closely. For the networking to work correctly on the ISA firewall, each network interface should contain routes that correspond to any networks that are reachable through that particular network interface. The network objects in the ISA management console should be configured to include this network and all reachable networks as well. This is critical because if the routing table is configured to include networks that are not included in the ISA network object, the ISA firewall will reject this traffic as spoofed.
There are times when you will have network objects configured with addresses or networks that do not have routes associated with them, and in which case you will see this alert. A case in point would be when a situation arises that you need to exclude a particular address , address range, or subnet that your underlying routing infrastructure routes through another gateway. A common scenario that I have encountered is when registered IP addresses are used for private connectivity over dedicated circuits when connecting to business partners. In this case I would include the IP address(es) of the business partner in the ‘Internal’ network object so that my web proxy and firewall clients would bypass the ISA firewall when communicating with hosts on these networks.
Leave a Comment » | ISA 2006 Configuration, ISA 2006 Enterprise, ISA 2006 Standard, Networking | Permalink
Posted by Richard Hicks
With all of the talk recently regarding the availability of Microsoft’s Intelligent Application Gateway (IAG) SP2 and its official support for running in a virtual infrastructure, as well as the support for Microsoft’s Forefront Threat Management Gateway running in virtual environments, there has been a quiet debate running among my colleagues and peers regarding the virtualization of security systems.
I realize that by virtue of the fact that I work for a hardware vendor (Celestix Networks) that my opinions will be considered by many to be biased. Somewhat perhaps, but the fact remains that virtualization, especially the virtualization of a security system, can prove to be extremely risky. Without proper planning, deployment, and ongoing monitoring of the virtual infrastructure the likelihood of a configuration error leading to a total and complete compromise of your security model is extremely high.
For those of you who might think this is just an alarmist’s point of view, I would encourage you to read this story posted recently at InformationWeek.Com. The article talks about a new virtualization security product, but the interesting thing to note here is that it includes a reference to a documented case where the misconfiguration of a virtual network resulted in a sensitive internal database server being connected directly to the public Internet. According to the article, this was put in to operation and was running for some period of time, until someone later discovered the error. Can you imagine if in this case it wasn’t a database server, but a security system responsible for protecting your entire internal private network?
This of course illustrates clearly the point I am trying to make – that there are substantial security risks associated with virtualizing your security infrastructure. Yes, there are some benefits, but I firmly believe that the risks far outweigh the rewards.
Leave a Comment » | ISA 2006 Configuration, ISA 2006 General, Networking, Threat Management Gateway | Permalink
Posted by Richard Hicks
You are currently browsing the archives for the Networking category.
