October 15, 2000
Network Uptime - October 15, 2000
The Resource for Network Management and Protocol Analysis Professionals
A Newsletter of http://www.NetworkUptime.com
Issue 02 00 00 00 01 00 01 05
October 15, 2000
ISSN: 1529-6938
This Issue:
* Starting Delimiter - Interop, Fall, and Travel
* Uptime Tutorial - Introduction to Telnet
* Surf Report - Online Updates
* Network Uptime Tip of the Month - Real-World Sniffing - The Dashboard
====
Starting Delimiter
- Interop, Fall, and Travel -
====
Networld+Interop 2000 Atlanta was the last week of September, and I attended the show for the first time in a couple of years. Did you see me? I was the guy with the bag full of t-shirts.
I stopped by every network analysis company booth and checked out the latest and greatest software, hardware, and strategic directions in network management. A recurring theme was the emphasis in analyzing converged networks. Voice over IP is now supported in almost every network analysis tool I saw, although some companies have a better implementation than others. I've seen a lot of networks in a lot of organizations over the last 4 months, and only a few brave souls have ventured into the precarious world of sending telephone calls over Ethernet connections. It appears that our network analysis tools will have VoIP capability before our networks!
In the last Network Uptime newsletter, I mentioned that I moved from South Florida to the northern part of the state. I had forgotten that the rest of the country has SEASONS, and the weather tends to get COLD in the Fall of the year! After living in Miami for ten years, I had become used to decorating the palm tree for the holidays and wearing shorts all year. I just bought jeans this week for the first time in years, and I'm planning on participating in a strange custom that involves bringing pieces of a tree into one's home and setting it on fire inside of a large brick enclosure! If the newsletter takes an odd slant over the next few months, I'll blame it on the cold weather. I still can't believe that I have to wear socks with my shoes. I hate that.
I'm traveling a bit more these days, and I'm having my own challenges with obtaining a good dial-up connection at an airport. If you have a good laptop/dial-up/networking/road-warrior story, we'd love to hear it. Send it to me, and I'll include it in the next newsletter. I'm also fascinated by the networks used by the airlines. If you've worked on an airline's network, we'd love to hear about it! For that matter, if you work on a 'unique' network, or use your network for a not-so-usual purpose, let us know about it, and we'll tell your story in Network Uptime!
Also, thanks for your feedback last month about our TCP tutorial. We're continuing the series this month with a frame-by-frame breakdown of Telnet. Enjoy!
- James 'Is It Cold In Here' Messer
Editor, Network Uptime
James@NetworkUptime.com
====
Uptime Update
- Introduction to Telnet -
====
PLEASE NOTE: Due to the size of this tutorial, we were not able to include all of the decode text within the newsletter. Visit http://www.NetworkUptime.com for the complete decode output and the Ethernet trace file in an uncompressed Sniffer .ENC trace file format.
This tutorial is best viewed with a fixed-width font.
- Introduction to Telnet -
Albert Martinez, Team Uptime
Albert@NetworkUptime.com
Every network manager has used a telnet client at one time or another. The telnet specifications were set in 1983 as part of RFC 854. Telnet is a client- erver application, which means that one machine has to provide the Telnet service (or in UNIX terms, the Telnet daemon). Telnet allows one to become a user on a remote computer.
Telnet uses TCP, an OSI layer 4 (or transport layer) connection oriented protocol who's primary function is to make sure that each and every packet arrives to it's destination by way of acknowledgement frames (described in detail the NeworkUptime.com TCP tutorial).
The purpose of this telnet tutorial is to walk through the telnet login and logout process frame by frame. Some telnet rules and options will be illustrated, as well as security concerns when using this protocol over the Internet.
The TCP port of 23 is used for the default telnet connection. In this tutorial the workstation executing the telnet client has an IP address of 192.168.10.4, and the telnet daemon is 172.24.9.204. This tutorial will walk through the process of login and logout to a telnet server using the username of 'al' and the not-so-high security password of 'al.'
Starting at the first frame, the telnet client asks to connect to the telnet daemon with a port connection identifier of 1089. This is a 'synchronize' in TCP terms, as shown by the binary 1 in the SYN field found in the TCP header. This arbitrary port number changes for every new connection that is formed, and is incremented on the client workstation for every new TCP connection.
In simple terms, the telnet client 192.168.10.4 is asking if it's okay to connect to the telnet daemon 172.24.9.204 by setting up a TCP call. The default port number for telnet is port number 23. This port value can be found in the TCP header and is used as the destination port to signal intent of service.
Frame Source Address Dest. Address Summary
1 [192.168.10.4] [172.24.9.204] TCP: D=23 S=1089 SYN SEQ=1206549 LEN=0 WIN=8192
What happens next is indicative of a normal TCP 'call setup,' where the telnet daemon 172.24.9.204 responds to the client with the same port number 1089. Also, note that the acknowledgement field is set to binary bit 1, and the SYN bit is also set to 1. The Telnet daemon is acknowledging that it is okay to connect.
Frame Source Address Dest. Address Summary
2 [172.24.9.204] [192.168.10.4] TCP: D=1089 S=23 SYN ACK=1206550 SEQ=46775 LEN=0 WIN=8760
Next, a standard TCP acknowledgement frame is sent from the Telnet client station to the Telnet daemon, acknowledging that it received the go-ahead from the Telnet daemon to connect.
Frame Source Address Dest. Address Summary
3 [192.168.10.4] [172.24.9.204] TCP: D=23 S=1089 ACK=46776 WIN=8760
The Telnet daemon now sends a frame back to the Telnet client containing a sequence of telnet-specific option negotiations. In this case we see one option, but there can be as many as 8 to 10 options initiated at this point. This frame shows only one option initiated - 'IAC Don't Echo.' When the sender, the telnet daemon, sends an 'IAC Don't Echo,' it is communicating that the sender wants the receiver (the telnet client) to disable the echo option. Echo can be found in RFC 857.
Frame Source Address Dest. Address Summary
4 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 IAC Don't Echo
The next few frames will show you why this is an optional negotiation process.
The Telnet client at 102.168.10.4 responds to the previous frame with a telnet 'Won't Echo' command. The telnet client is saying it's okay not to echo.
As a side note, IAC stands for "Interpret As Command".
Frame Source Address Dest. Address Summary
5 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 IAC Won't Echo
Depending on the telnet daemon's code, this next process may or may not occur. In this case, the telnet daemon sends a 'Will Echo' command to the telnet client, saying that the sender (the telnet daemon) now wants to enable echo.
This is a good example of application level troubleshooting. Based on the telnet specifications, there is no reason for this back-and-forth echo/no-echo play to occur. The programmer should be contacted to fix this minor bug in his code.
If you ever used Telnet, you probably noticed that it takes a bit longer to get a telnet login screen compared to an FTP login screen. This is because there is extra overhead in option negotiations, resulting in extra frames to complete the initial connection process. The more options to be negotiated, the greater the lag time in getting a login prompt.
The following frame shows the 'Will Echo' option sent by the Telnet daemon, thus accepting the enable echo sent by the Telnet client. The Username prompt is also sent in the same frame. The text '<0D0A0D0A>' represents two carriage returns, or the equivalent of pressing the enter key twice (<0D0A> equals one carriage return).
SECURITY NOTE: Key strokes are not encrypted, making Telnet login sessions easy to read by any packet capturing application.
Frame Source Address Dest. Address Summary
6 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 IAC Will Echo
The telnet client at 192.168.10.4 responds with a 'Do Echo', which is an acknowledgement to the previous frame sent by the Telnet daemon who wanted to enable the Echo option.
Frame Source Address Dest. Address Summary
7 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 IAC Do Echo
A standard TCP acknowledgement frame from the telnet daemon is sent to the Telnet client. The telnet option negotiation process is now finalized. Now the user has control of when the telnet packets are sent and received.
Frame Source Address Dest. Address Summary
8 [172.24.9.204] [192.168.10.4] TCP: D=1089 S=23 ACK=1206556 WIN=8754
The user decides to type in his user name. Frame 9 is the first frame sent by the user, who types the first letter of the username, 'a.' The Telnet client is shown sending a frame with an "a" in the Telnet header.
Frame Source Address Dest. Address Summary
9 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 a
A TCP acknowledgement frame is sent to the Telnet client. The frame also contains a telnet header that contains the letter 'a' This information is pushed up the OSI stack, and ultimately appears on the client's screen. This is the function of Echo. If Echo was disabled, you would only see keyboard updates sent one way and not acknowledged in the Telnet header.
Frame Source Address Dest. Address Summary 10 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 a
The second letter is now typed by the user, thus completing the username 'al.' Frame 11 carries the letter "l" in the telnet header as it is sent to the telnet daemon.
Frame Source Address Dest. Address Summary 11 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 l
Echo is doing its job, and frame 12 is sent to the telnet client.
Frame Source Address Dest. Address Summary 12 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 l
Every key stroke is echoed, even the enter key. The telnet header in this frame contains the carriage return '<0D0A>.' This frame shows the telnet client sending the enter keystroke.
Frame Source Address Dest. Address Summary 13 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 <0D0A>
Again, Echo replies with a TCP acknowledgement frame and the carriage return code within its header. Frame 14 shows the Telnet daemon acknowledging the prior frame. Note the carriage return code '<0D0A>' in the FTP header.
Frame Source Address Dest. Address Summary 14 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 <0D0A>
A standard TCP acknowledgement frame is now sent to the telnet daemon, stating that the telnet client received frame 14.
Frame Source Address Dest. Address Summary 15 [192.168.10.4] [172.24.9.204] TCP: D=23 S=1089 ACK=46802 WIN=8734
Immediately after the acknowledgement is received by the telnet client, the telnet daemon sends a packet which contains the password prompt.
Frame Source Address Dest. Address Summary 16 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 Password:
Frame 17 shows the Telnet client sending a standard TCP acknowledgement frame to the Telnet daemon. At the same time, the user sees a 'Password:' prompt and is ready to type his password.
17 [192.168.10.4] [172.24.9.204] TCP: D=23 S=1089 ACK=46812 WIN=8724
As you follow the next few frames, note something slightly different about the password transaction. As the user types, each character is sent to the daemon but is acknowledged with a standard TCP acknowledgement frame with no telnet header containing the typed letter. This is due to an intrinsic security feature in telnet where the password is not Echoed due to visual security reasons.
Other than this minor change in the telnet conversation, this communication is very similar to the prior login transaction.
Frame Source Address Dest. Address Summary 18 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 a19 [172.24.9.204] [192.168.10.4] TCP: D=1089 S=23 ACK=1206561 WIN=8749
20 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 l
21 [172.24.9.204] [192.168.10.4] TCP: D=1089 S=23 ACK=1206562 WIN=8748
22 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 <0D0A>
This next frame sent by the telnet daemon accomplishes two tasks. It first acknowledges the previous frame, and then it sends back or 'Echoes' a carriage return '<0D0A>' so the user will actually see the cursor move one line down. Frame 24 shows the TCP acknowledgement.
Frame Source Address Dest. Address Summary 23 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 <0D0A>24 [192.168.10.4] [172.24.9.204] TCP: D=23 S=1089 ACK=46814 WIN=8722
The telnet daemon now sends a pre-configured message by the administrator. The message is contained within the telnet header and fits in one frame as shown below. The message reads "June/1999<0D0A>We got this GREAT Daemon!"
Frame Source Address Dest. Address Summary 25 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 <0D0A0D0A>June/1999<0D0A> We got this GREAT Dae...
Now, the telnet client confirms frame 25 by sending a standard TCP acknowledgement frame. This ends the login sequence for telnet. In all, 26 frames were sent.
Frame Source Address Dest. Address Summary 26 [192.168.10.4] [172.24.9.204] TCP: D=23 S=1089 ACK=47318 WIN=8218
After the user has finished using telnet, it's time to close out the session. The user types the word 'exit' to logout. The telnet client sends each character in its own frame to the Telnet daemon.
Frame 27 is sent by the Telnet client 9.5 seconds after the previous frame. This means that the user waited almost 10 seconds to log out. The user types the first letter in the word "exit" to signal the Telnet daemon that he wishes to log out. The first letter "e" is typed and contained within the Telnet header of this frame. The conversation continues as the exit command is completed and the enter key is pressed.
Frame Source Address Dest. Address Summary 27 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 e28 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 e
29 [192.168.10.4] [172.24.9.204] TCP: D=23 S=1089 ACK=47319 WIN=8217
30 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 x
31 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 x
32 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 i
33 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 i
34 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 t
35 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 t
36 [192.168.10.4] [172.24.9.204] Telnet: C PORT=1089 <0D0A>
37 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 <0D0A>
To signal the user and the telnet client that the telnet session has finished, the telnet daemon sends the user the 'bye' message in the telnet header (<0D0A>Bye.<0D0A>). It also sets the FIN bit to 1. This is the start of the TCP call tear-down procedure, ending the TCP connection.
Frame Source Address Dest. Address Summary 38 [172.24.9.204] [192.168.10.4] Telnet: R PORT=1089 <0D0A>Bye.<0D0A>
The telnet client acknowledges frame 38 with a simple TCP acknowledgement frame.
Frame Source Address Dest. Address Summary 39 [192.168.10.4] [172.24.9.204] TCP: D=23 S=1089 ACK=47333 WIN=8204
The client then immediately sends a TCP frame with the FIN bit set to 1, confirming the TCP connection (port 1089) to be closed.
Frame Source Address Dest. Address Summary 40 [192.168.10.4] [172.24.9.204] TCP: D=23 S=1089 FIN ACK=47333 SEQ=1206570 LEN=0 WIN=8204
Finally, the telnet daemon acknowledges the frame and completes the telnet session.
Frame Source Address Dest. Address Summary 41 [172.24.9.204] [192.168.10.4] TCP: D=1089 S=23 ACK=1206571 WIN=8740
The plain-text method of telnet communications makes it very easy to trace on the network, once you know the conversational basics. Unfortunately, this same plain-text view into a transactions makes the Telnet application a poor choice for secure communications.
Some of the most popular (and free) network management programs have been updated over the last month. Download and enjoy!
MRTG v2.9.2 - Multi-Router Traffic Grapher - The most popular SNMP-based trending tool on the Internet has been updated! MRTG version 2.9 includes better performance, interface addressing by IP, MAC, description, name, etc., and updated documentation. MRTG has even been translated into 29 different languages! Try it, you'll like it.
You can download MRTG from the following Network Uptime Tools pages:
UNIX: http://www.networkuptime.com/tools/unix/mgmt/trend/index.html
Windows: http://www.networkuptime.com/tools/winnt/mgmt/trend/index.html
NOTE: This is a new series of monthly tips that helps apply a real-world explanation to the functions and capabilities of Network Associates' Sniffer Pro network analyzer. This month's tip details one of the most-used monitor statistics - the dashboard.
Keep watching the Real-World Analysis section on Network Uptime for additional Real-World tips and screen-shots!
http://www.NetworkUptime.com/realworld
Some of the most requested network statistics from network managers are utilization, errors, and packets per second. The Sniffer Pro dashboard provides a graphical view of these statistics.
The Dashboard in Sniffer Pro looks different than previous versions. The new dashboard uses Dynamic HTML to enhance the dashboard graphics. The red background of the dashboard signifies threshold values for each statistic. If any of these values are exceeded, an event is recorded in the error log of the Sniffer and notification events (if any) are sent. These thresholds can be viewed by clicking the 'Set Thresholds...' button, or by selecting 'Tools/Options/MAC Threshold' from the Sniffer pull-down menus.
The Monitor MAC Thresholds can be changed or reset from this dialog box. For those who prefer a more text-based view of the network statistics, the dashboard includes a 'Detail' tab. This view allows the option of displaying a cumulative view of the dashboard statistics, or the average per second.
The text-based Detail view provides network, size distribution, and error statistics as a total for the monitoring period or the average for each second. The dashboard also includes graphs of the three detail categories. Each graph will display the 'checked' statistic, and will update the value every thirty seconds (short term) or every thirty minutes (long term).
The dashboard graph displays short-term and long-term views of network traffic, errors, and size distribution.
Dashboard graph lines can be enhanced by placing the mouse over the name of the statistic. The graph line will change to a bold line and can be viewed easier relative to the other lines on the graph. The history of statistical values can be viewed by clicking the left and right arrows, or by clicking anywhere inside the graph. The timestamp will change to show the selected time and date for the selected moment-in-time.
Clicking on the arrows or on the graph sets the marker line and displays the timestamp and associated statistics for the selection.
The network, size distribution, and detail errors are gathered in these dashboard graphs while Sniffer Pro is executing. The dashboard can be closed, but the statistics will continue to gather and graph as long as Sniffer Pro remains active. This allows the network analyst to review the history of network statistics at any time, even if the Sniffer has been decoding trace files for the last few hours.
The dashboard gives two views of the world; what's happening now, and what's happened in the past. The gauges and detail views provide immediate feedback about the present operations of the network, especially relating to utilization and network errors. The historical information on the graphs provide a 'feel' of the network's health over the past hour or more, much like a doctor would analyze the heart's rhythm strip on an EKG (or a seismologist's Richter scale, depending on the network!).
These statistics provide immediate feedback on the basic values of network health. Although this provides a starting point, network and application level errors can't be seen from the dashboard; you'll need to view the Sniffer Pro Expert to locate that data. However, problems seen in the dashboard can affect the higher layer protocols (high utilization, excessive number of errors, etc.), so any issues that appear in the dashboard need to be resolved before investigating the higher network layers.
If you're reading a forwarded copy of Network Uptime, sign up for your own FREE subscription:
http://www.NetworkUptime.com/newsletter/
Promote Network Uptime! Add Network Uptime graphics and banners to your web page:
http://www.NetworkUptime.com/graphics
To unsubscribe from Network Uptime, use the above URL, or email Majordomo@NetworkUptime.com with the following text in the body of the message:
unsubscribe NetworkUptime
For questions or comments, email us at James@NetworkUptime.com or visit the web page!
Posted by james_messer at October 15, 2000 01:59 PM