Oct 15 2009   6:44PM GMT

Free Training - Laura Chappell presents: Wireshark 201 Jumpstart - Filtering on the Good, the Bad, the Ugly

Posted by: Troy Tate
network analysis, protocol analysis, packet analysis, packet capture, training, education, wireshark, ethereal, tcp/ip, trace files, Networking, tools, Monitoring, reporting, IT education, performance monitoring, troubleshooting, howto, Metrics, analysis, Laura Chappell

Laura Chappel, the BitGirl, is at it again with another in her series of Wireshark Jumpstart webinars. The next one is called Wireshark Jumpstart 201: Filtering on the Good, the Bad, the Ugly. It will be held on October 27 - 10:00am-11:00am PDT (GMT-7). If you manage networks or want to manage a network, a good understanding of protocol and packet analysis will help you immensely with your career.

Some things you will learn in this webinar:

• Using the Default Capture and Display Filters
• Creating a Few Hot Capture Filters
• Filtering Tips and Tricks for Troubleshooting
• Filtering Tips and Tricks for Security

Even if you are very familiar with Wireshark or other packet capture and protocol decode tools, Laura’s seminars are well worth attending. You might even find out a little tidbit here or there because Repetition is one of the keys of learning. Unfortunately I will not be able to attend this webinar since I will be on a golf vacation in North Carolina. So, if you attend this event, please come back and share with me and other IT Trenches readers what you learned and how valuable the webinar was for you.

Thanks for reading and let’s continue to be good network citizens!

Sep 30 2009   1:06PM GMT

Where do TCP resets come from?

Posted by: Troy Tate
tcp, udp, network management, network performance, network monitoring, application performance, network analysis, performance analysis, protocol analysis, packet capture

I recently came across an excellent article on the topic of TCP resets. TCP is a connection-oriented protocol as opposed to the connectionless nature of UDP. So, if there are TCP resets on your network, this is not a bad thing and is just inherent in the protocol. Without TCP resets, a host could have a lot of partial connections established which are in the wait state awaiting further transmissions. This can exhaust the number of available sockets and cause the host to become unresponsive. This is what happened several years back with the TCP SYN flood and LAND denial of service attacks. Another reset type includes the ACK/RST. This is where a client attempts to connect to a service that is not available on that destination host.

If you manage a network and have taken packet captures to work on a problem and have seen RST packets or if you need to do this at some point in your career, you need to understand the purpose and source of the RST packets. Take a few minutes, read this excellent article that is the best explanation that I have seen on this topic. You will become better informed and better able to understand the nature of the network beast.

Where do resets come from? (No, the stork does not bring them.)

Thanks for reading and let’s continue to be good network citizens.

Jul 20 2009   6:36PM GMT

Wireshark quickstart tutorial - learn to capture network traffic

Posted by: Troy Tate
network analysis, protocol analysis, packet analysis, packet capture, training, education, wireshark, ethereal, tcp/ip, trace files, Networking, tools, Monitoring, reporting, IT education, performance monitoring, troubleshooting, howto, Metrics, analysis, Laura Chappell

There are more upcoming sessions in the Laura Chappell seminar series called Wireshark 101Jumpstart tutorials. Check out the schedule at Chappell University website. Some of the things you will learn include:

• Wireshark elements and capabilities
  
• Tapping into the wired or wireless network
  
• Capturing and filtering basics
  
• Graphing basics

If you cannot attend the seminar, you can still register and download the seminar notes and gain access to the trace files used in the session. If you manage a network, you should learn this stuff! Be sure to register and attend early. The sessions are limited to 1000 viewers and these fill up FAST!

See my entry

Repetition is one of the keys of learning

for a how attending one of these seminars helped address an issue I was having with using Wireshark.

Thanks for reading and lets continue to be good network citizens!

May 26 2009   7:34PM GMT

Repetition is one of the keys of learning

Posted by: Troy Tate
network analysis, protocol analysis, packet analysis, packet capture, training, education, wireshark, ethereal, tcp/ip, trace files, Networking, tools, Monitoring, reporting, IT education, performance monitoring, troubleshooting, howto, Metrics, analysis, Laura Chappell

I recently posted an update about Laura Chappell’s Chappell University Online seminars. I attended one of these seminars today. What a great experience! I always try to attend Laura’s events and always pickup a tidbit that makes my life as a network manager easier. She gives you information about tools you can use to fight the battle of “the network is down”. Most of the time the network is behaving as designed. It’s poorly written applications or too high user expectations that create issues. So, if you want be the expert on fighting the network is “bad” syndrome - check out Laura’s presentations - I did and I learned something new… Continued »

May 21 2009   12:57PM GMT

Master key tasks for network troubleshooting - Chappell University Online Seminars

Posted by: Troy Tate
network analysis, protocol analysis, packet analysis, packet capture, training, education, wireshark, ethereal, tcp/ip, trace files, Networking, tools, Monitoring, reporting, IT education, performance monitoring, troubleshooting, howto, Metrics, analysis

I’m a huge fan of Laura Chappell. She has a great sense of humor and is a great educator about all things packet oriented. Previous posts about Laura have included:

Is protocol analysis or network management your thing?

ARP as a network auditing tool

Did you see this? - Latest Laura Chappell Newsletter

Did you see this? - the viral bitgirl

She has now started a new online seminar series. Some of the presentation are free and others are accessible for a fee of $99. If you cannot get away for education, then this is an excellent alternative and you can gain a great amount of knowledge from this packet analysis expert. I recommend that you visit Chappell Online University and sign up for the free Wireshark Jumpstart: Master Key Tasks for Network Troubleshooting seminar to get a feel for the seminars.

Thanks for reading and let’s continue to be good network citizens!

Apr 29 2009   12:11PM GMT

Doing Microsoft packet analysis? - Microsoft releases Network Monitor 3.3

Posted by: Troy Tate
packet analysis, packet capture, protocol analysis, tools, analysis, analysis tools, Microsoft, network analysis, network, tcp, udp, network monitor

If you do packet capture or analysis in a Microsoft environment, then you are probably already familiar with Microsoft Network Monitor. If not, please read my real-world use of it for PROTOCOL analysis vs protocol analysis (with a small p). Microsoft has updated Network Monitor to v3.3. The announcement of its release can be found on the Technet blog. Some of the new features listed are:

· Ability to capture WWAN (mobile broadband) and Tunnel traffic on Windows 7.

· Full Hyper-V support on Windows Server 2008

· Right-click-add-to-alias: Right-click a frame in the Frame Summary window with an IPv4, IPv6 or MAC address to add that address as a new alias. This is one of those little things that simplifies your work-flow.

· Right-click-go-to-definition: Have you ever wondered where and how the protocols fields you see in the Frame Details are defined in our in-built parsers? Wonder no more. Introducing right-click-go-to-definition: right-click a field in the Frame Details window and select Go To Data Field Definition or Go To Data Type Definition to see where the field is defined in the NPL parsers.

· Autoscroll: Another one of those little, but priceless things … auto-scroll. See the most recent traffic as it comes in. In a live capture, click the AutoScroll button on the main toolbar to have the Frame Summary window automatically scroll down to display the most recent frames as they come in. Click Autoscroll again to freeze the view in its present location.

Several other new features are described in the Technet blog. If you capture packets on a Microsoft network, then you should get this upgraded version to add to your toolbox.

Thanks for reading and let’s continue to be good network citizens.

Mar 23 2009   3:57PM GMT

Need help? Ask questions - help someone - read my blog & win one of 3 XBox 360’s

Posted by: Troy Tate
Security, protocol analysis, contest, xbox, social engineering, social networking, network throughput, network capacity, analysis tools, tools, Cisco

Looking for some help on some troublesome IT isssues? Post your question on IT Knowledge Exchange. Maybe take some time to read through some of the questions on ITKE. Provide an answer or even improve answers already given or give some discussion feedback. By doing these things with other IT peers, you could just win one of three XBox 360’s to be given away in April.

While you are her on ITKE, why not take some time, read through a few of my blog postings, maybe there is something there that would be of value to you or someone else you know. Send your fellow IT peers to ITKE. Make this the best free online support community and a one-stop shop for getting the support you need for those IT issues we each face every day.

Some of my blogs that will hopefully be of interest to you include:

What did I just do with my contacts list? - Social Engineering/Networking & contact list scraping

Network speed & capacity are NOT the same

Financial crisis due to poor risk understanding & management - IT security next?

Nifty tools for tracking down that “interesting” network traffic

PROTOCOL analysis vs protocol analysis (with a small p)

Good luck with the contest! Stay tuned for more and thanks for reading. Let’s continue to be good network citizens together.

Feb 19 2009   1:47PM GMT

Is protocol analysis or network management your thing?

Posted by: Troy Tate
network analysis, protocol analysis, packet analysis, packet capture, training, education, wireshark, ethereal, tcp/ip, trace files

Laura Chappell (the Viral Bitgirl) has announced that Sharkfest 09 registration is open and all registered attendees get a FREE AIRPCAP ADAPTER (US $198)! Sharkfest is the Developer/User Conference for Wireshark and it is sponsored by CACE Technologies and Wireshark University. Laura will be there with new, hot (or cool, if you prefer) topics, trace files, case studies and hands-on labs. Register today at Sharkfest.09 to get your free AirPcap adapter. [Dates: June 16-18, 2009-registration and BBQ on June 15th]

Laura has also announced that Chappell University is open for registration. Subscription-level service will be open soon. Chappell University is an affordable, on-demand, online training system to maintain and enhance IT skills in the area of analysis, troubleshooting and security. Some of the content includes two lab workbooks with over 100 lab exercises using Wireshark to spot network problems, security breaches, and analyze normal and abnormal TCP/IP communications. There are video answers to all the lab exercises. In addition, there’s an extensive trace file respository and additional WLAN, VoIP, bot-infections, application, etc., trace files will be added each quarter. Check out the new YouTube Channel for Chappell University and the video “Ethical Hacking with NetScanTools Pro: Tutorial on ARP Scanning to Discover All Local Hosts” (even those hidden behind firewall applications).

If you have never experienced training presented by Laura, this is your chance to get very in-depth, easy to understand technical training. Sure, some of the stuff may cost a little, but she has tons of free stuff out there also. The paid content is definitely worth it. I have her Master Library (pre-dates the new Chappell University) and I still refer to the content occasionally to refresh my skills in network analysis.

Thanks for reading and let’s continue to be good network citizens!

Feb 2 2009   5:15PM GMT

ARP as a network auditing tool

Posted by: Troy Tate
ARP, protocol, testing, tools, toolkit, scanning, education, video, training, protocol analysis, Laura Chappell

ARP - or Address Resolution Protocol is a necessary element for network traffic. Per Wikipedia: “In computer networking, the Address Resolution Protocol (ARP) is the method for finding a host’s link layer (hardware) address when only its Internet Layer (IP) or some other Network Layer address is known. ARP is defined in RFC 826.^[1] It is Internet Standard STD 37.” It is not an IP only protocol.

What this means, is that ARP is not a protocol that is easily blocked or disabled on a network. This is as designed but this also means that attackers can use this protocol for malicious activities. It is important that you understand the ARP protocol and the ways it is used and the dangers associated with it.

Laura Chappell, the BitGirl, has created a new tutorial on using ARP to scan networks which may be firewalled or ICMP pings are blocked. ARP will permit you - and attackers - to find hosts on the network. Take some time and watch this short video and gain some valuable insights into ARP.

Watch Chappell University - Ethical Hacking with NetScanTools Pro - ARP Scanning

Thanks for your time and let’s be good network citizens!

Jan 9 2009   4:38PM GMT

PROTOCOL analysis vs protocol analysis (with a small p)

Posted by: Troy Tate
protocol analysis, SMTP, tcp, network monitor, wireshark, Microsoft, Microsoft Exchange, patches, OSI model

Recently we had an issue at a site where outbound messages larger than 1MB were backing up in the outbound message queue. The messages were tagged with a 421 4.4.2 Connection dropped error. This was a puzzling issue since the smart relay host was on the local LAN, and in fact, on the same switch as the Exchange server.  We checked the switch ports and NICs for errors. None were found. We knew messages were successfully coming inbound through this site because the smart relay host was processing hundreds of them per hour (we use regional hubs and this is one of our hub sites).

We first contacted the vendor for the smart relay host appliance and opened a support ticket. No real issues were identified at first review. Since the errors were being reported at the Exchange server, we contacted Microsoft and opened a support ticket. We spent hours testing and changing configuration to another regional smart relay host which seemed to get the messages delivered successfully, but we were still not able to find out what was causing the conversations with the local smart relay host to timeout.

So, we went into deeper debug mode since the application and server event logs did not shed any light on the issue. The Microsoft engineer enabled protocol logging on this particular send connector. The protocol logs did give a little more information on the situation. A snippet is shown below.

2009-01-08T22:36:19.495Z,SendConn,08CB3FF87FA34699,16,exchsvr:20709,relayhost:25,>,RCPT TO:<someone@there.com>,
2009-01-08T22:36:19.495Z,SendConn,08CB3FF87FA34699,17,exchsvr:20709,relayhost:25,<,”250 Requested mail action okay, completed.”,
2009-01-08T22:36:19.589Z,SendConn,08CB3FF87FA34699,18,exchsvr:20709,relayhost:25,>,DATA,
2009-01-08T22:36:19.589Z,SendConn,08CB3FF87FA34699,19,exchsvr:20709,relayhost:25,<,”354 Enter mail, end with “”.”” on a line by itself.”,
2009-01-08T22:36:25.417Z,SendConn,08CB3FF87FA34699,20,exchsvr:20709,relayhost:25,-,,Remote
2009-01-08T22:37:25.431Z,SendConn,08CB3FF87FA346A1,0,,relayhost:25,*,,attempting to connect
2009-01-08T22:37:25.431Z,SendConn,08CB3FF87FA346A1,1,exchsvr:20736,relayhost:25,+,,

The conversation seemed to go fine at the beginning but something was happening at the end. Since this log did not freely give up that information, we used Microsoft’s Network Monitor 3.2 (btw-if you are still using an older version of Network Monitor, you should upgrade to v3.2. It does have some nice features that make it more user friendly - but not as nice as Wireshark) to capture the actual packets between the Exchange server and the smart relay host. We ran Network Monitor directly on the Exchange server.

At this point, we were able to capture the transaction failures. The results were very interesting and a good lesson in packet analysis versus protocol analysis. The packet analysis showed that TCP was working well. Everything at layer 4 and below seemed to be working well. This was a relief. However, it appeared that the actual problem existed at layer 6 & 7. The Exchange server was ending the SMTP (Simple Mail Transport Protocol) conversation with the “.” command (a single dot on a line by itself). The Exchange server was then waiting for the smart relay host to reply with a 250 2.6.0 status message saying the message was successfully queued for delivery. The Exchange server would then reply with a QUIT command and end the SMTP session. Since the smart relay was not responding at all with the expected status message, the SMTP conversation was timing out and messages were building up in the queue.

We found out that there were some patches for the smart relay host so we applied those. Once that was done, the messages seemed to flow normally. The other puzzling thing about this is that we have two other hub sites with the same configuration that are not experiencing this problem. So, sometime today we will be rolling out the patches to those smart relay hosts to prevent this problem from happening at those sites. This issue started out of the blue but seemed coincide with the same time Exchange Server 2007 rollup 5 was applied.

The point of this whole blog posting is that while the TCP protocol was working fine and everything looked good there, the SMTP protcol was not working correctly. It is important for a network engineer to understand networking through all of the OSI layers. You cannot just assume that if things are working well at the lower levels that things at the higher levels will work too. The reverse logic is true also. So, understand the protocols at the lower layers and also the PROTOCOLS at the upper layers if you really want to be an effective troubleshooting expert.

Let’s be good network citizens out there!