%\documentclass[colorBG,slideColor,troispoints,pdf]{prosper} \documentclass[total,pdf]{prosper} %\documentclass[colorBG,slideColor,ps]{prosper} \usepackage[toc,highlight,Tycja]{HA-prosper} \usepackage{alltt,key,xr,cols,rcs,acro,nick,% graphicx,varioref,explanation,booktabs,amsmath,amstext,multicol,version} %\usepackage[nolineno,noindent]{lgrind} %\hypersetup{breaklinks} \excludeversion{extra} \newif\ifpprprvloaded \makeatletter% \@ifclassloaded{ppr-prv}{\pprprvloadedtrue}{\pprprvloadedfalse}% \makeatother% \newcommand{\positionPicture}{% \ifpprprvloaded \else \vspace*{-15mm}\par \hspace*{-13mm}% \fi } \newcommand{\positionPictureOpt}[2]{% \ifpprprvloaded \else \vspace*{#1}\par \hspace*{#2}% \fi } %\definecolor{green}{rgb}{0,1,0} \RCS $Revision: 1.4 $ % Copyright (c) 2004 by Nick Urbanik . % This material may be distributed only subject to the terms and % conditions set forth in the Open Publication License, v1.0 or later % (the latest version is presently available at % http://www.opencontent.org/openpub/). % For Prospe\renewcommand*{\bs}{\texttt{\char '134}} % Backslash `\' %\newcommand*{\labTitle}{LDAP Directories}1 \newcommand*{\subject}{Systems and Network Management} \newcommand*{\emphcolour}[1]{\emph{\red#1}} \providecommand*{\RPM}{\acro{RPM}\xspace} \providecommand*{\CD}{\acro{CD}\xspace} \providecommand*{\IPC}{\acro{IPC}\xspace} \providecommand*{\UID}{\acro{UID}\xspace} \providecommand*{\GID}{\acro{GID}\xspace} \providecommand*{\SMP}{\acro{SMP}\xspace} \providecommand*{\API}{\acro{API}\xspace} \providecommand*{\OK}{\acro{OK}\xspace} \providecommand*{\IETF}{\acro{IETF}\xspace} \providecommand*{\SMTP}{\acro{SMTP}\xspace} \providecommand*{\ICMP}{\acro{ICMP}\xspace} \providecommand*{\ARP}{\acro{ARP}\xspace} \providecommand*{\IOS}{\acro{IOS}\xspace} \providecommand*{\MS}{\acro{MS}\xspace} \providecommand*{\POP}{\acro{POP}\xspace} \providecommand*{\LILO}{\acro{LILO}\xspace} \providecommand*{\HCI}{\acro{HCI}\xspace} \providecommand*{\KDE}{\acro{KDE}\xspace} \providecommand*{\MBR}{\acro{MBR}\xspace} \providecommand*{\BSD}{\acro{BSD}\xspace} \providecommand*{\GPL}{\acro{GPL}\xspace} \providecommand*{\MB}{\acro{MB}\xspace} % Get rid of that horrible hash mark in slide numbers in ppr-prv.cls: \def\no{} \setlength{\extrarowheight}{0pt} \title{\mbox{}\blue{}Network Troubleshooting}% \subtitle{Troubleshooting Tools} \author{Nick Urbanik\\ \footnotesize{}Copyright Conditions: GNU FDL (see \url{http://www.gnu.org/licenses/fdl.html}) \email{nicku@vtc.edu.hk}\\ \institution{A computing department}} \author{Nick Urbanik \texttt{}\\ \footnotesize{}Copyright Conditions: GNU FDL (see \url{http://www.gnu.org/licenses/fdl.html})}% %\institution{A computing department}% \slideCaption{SNM --- Network Troubleshooting --- ver. \RCSRevision} %%\Logo{\includegraphics[width=15mm]{ict-logo-smaller}} \DefaultTransition{Wipe} \TitleSlideNav{FullScreen} \NormalSlideNav{ShowBookmarks} \LeftFoot{SNM --- ver. \RCSRevision} \RightFoot{Network Troubleshooting} \begin{document} \maketitle \begin{slide}{References} \begin{itemize} \item Joseph D. Sloan, \emph{Network Troubleshooting Tools}, O'Reilly, August 2001, ISBN: 059600186-X, TK5105.5\,.S557\,2001 \item Cisco's \emph{ Troubleshooting Overview} at: {\scriptsize \url{http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1901.htm}} \item Craig Hunt, \emph{TCP/IP Network Administration}, Third Edition O'Reilly, April 2002, ISBN: 059600297-1. Chapter 13 covers troubleshooting TCP/IP. \item Martin A. Brown, \emph{Guide to IP Layer Network Administration with Linux}, \url{http://linux-ip.net/} \item Noah Davids, \emph{Don't forget to check your ARP cache}, {\footnotesize \url{http://members.cox.net/~ndav1/self_published/The_ARP_cache.doc}} \end{itemize} \end{slide} \tsection{Introduction} \begin{slide}{Focus: Basics and Standard Tools} \begin{itemize} \item Solving network problems depends a lot on your understanding \item Simple tools can tell you what you need to know \item Example: \texttt{ping} is incredibly useful! \end{itemize} \end{slide} \begin{slide}{Troubleshooting} \begin{itemize} \item Avoid it by: \begin{itemize} \item redundancy \item documentation \item training \end{itemize} \item Try quick fixes first \begin{itemize} \item simple problems often have big effects: \item is the power on? \item is the network cable plugged into the right socket? Is LED flashing? \item has anything changed recently? \end{itemize} \item Change only one thing at a time \begin{itemize} \item test thoroughly after the change \end{itemize} \item {\mbox{}\blue{}Be familiar with the system} \begin{itemize} \item \emphcolour{maintain documentation} \end{itemize} \item {\mbox{}\green{}Be familiar with your tools} \begin{itemize} \item \emphcolour{before trouble strikes} \end{itemize} \end{itemize} \end{slide} \begin{slide}{Troubleshooting: Learn as you go} \begin{itemize} \item Study and {\blue{}be familiar with} the \emphcolour{normal behaviour} of your network \item Monitoring tools can tell you when things are wrong \begin{itemize} \item if you know what things look like when they are right \end{itemize} \item Using tools such as Ethereal can help you understand \begin{itemize} \item your network, and \item \TCPIP --- better \end{itemize} \end{itemize} \end{slide} \tsection{Dcoumentation} \begin{slide}{Documentation} \begin{itemize} \item Maintain an inventory of equipment and software \begin{itemize} \item a list mapping \MAC addresses to machines can be very helpful \end{itemize} \item Maintain a change log for each major system, recording: \begin{itemize} \item each significant change \item each problem with the system \item each entry dated, with name of person who made the entry \end{itemize} \item Two categories of documentation: \begin{itemize} \item Configuration information \begin{itemize} \item describes the system \item use system tools to obtain a snapshot, e.g., sysreport in Red Hat Linux \end{itemize} \item Procedural information \begin{itemize} \item How to do things \item use tools that automatically document what you are doing, e.g., \texttt{script} \end{itemize} \end{itemize} \end{itemize} \end{slide} \begin{slide}{Documentation Tools} \begin{itemize} \item Use \texttt{script}: \begin{alltt} $ \textbf{script \(\sim\)/logs/logfile-$(date +%F-%R).log} \end{alltt} \begin{itemize} \item starts a new shell \item all you type, all output goes into the file \item Add comments with \texttt{\# I tried this\ldots} \end{itemize} \item Use \texttt{tee}: \begin{alltt} $ \textbf{arp -a | tee outfile} \end{alltt}%$ \item Use \texttt{sudo}: all commands are recorded in \texttt{/var/log/secure} \item Use \texttt{plod} from \url{http://bullwinkle.deer-run.com/~hal/plod/} \begin{itemize} \item lets you record a worksheet easily \item Perl, so fine on any platform \end{itemize} \end{itemize} \end{slide} %% \tsection{Purchasing} %% \begin{slide}{Purchasing Equipment} %% \begin{itemize} %% \item Better to: %% \begin{itemize} %% \item spend enough for the short term (one or two years) or %% \item ``invest for the long term?'' %% \end{itemize} %% \item Moore's Law: exponential growth in ``bang for the buck'' %% \item Maintenance costs more for older equipment %% \item Count all the costs %% \item Conclusion: often (but not always), getting cheaper equipment %% to cover needs for the next two years will save money %% \item Buying excess capacity can waste a lot of money %% \end{itemize} %% \end{slide} \tsectionandpart{General Troubleshooting} \begin{slide}{Problem Solving} \centering% \positionPictureOpt{-0.045\slideWidth}{0pt}% %\vspace*{-0.045\slideWidth} \includegraphics[totalheight=0.85\slideWidth]{troubleshooting-flowchart} \end{slide} \begin{slide}{Identify the Problem} \begin{itemize} \item Problem is reported by a person or by software \item Often involves \emphcolour{communicating} with others \begin{itemize} \item Somewhat like gathering requirements in software design \item An \emphcolour{iterative} process \end{itemize} \item Possible questions to ask: \begin{itemize} \item What does \emphcolour{not} work? \item What \emphcolour{does} work? \item Are the things that do and do not work \emphcolour{related}? \item Has the thing that does not work \emphcolour{ever} worked? \item When the problem was \emphcolour{first noticed}? \item What has \emphcolour{changed} since the last time it did work? \item Did anything \emphcolour{unusual} happen since the last time it worked? \item \emphcolour{When} exactly does the problem occur? \item Can the problem be \emphcolour{reproduced} and if so, \emphcolour{how} can it be reproduced? \end{itemize} \end{itemize} \end{slide} \begin{slide}{Gather the Facts} \label{sld:gather-the-facts} \begin{itemize} \item You probably need to find out more about the problem from other sources, including \begin{itemize} \item Asking other people: affected users, network administrators, managers, and other key people \item Network management systems, such as \emphcolour{Nagios} \url{http://nagios.org/} \item Tools such as Ethereal, \texttt{tcpdump}, \texttt{ntop} (\url{http://ntop.org/}) --- see slides starting at \S\ref{sld:packet-capture} \item Server log files \item Documentation about your servers and network created by local staff \item Documentation about software and hardware that are provided by the vendors \end{itemize} \end{itemize} \end{slide} \begin{slide}[toc=Consider Possibilities,bm=Consider Possibilities]% {Consider Possibilities based on Facts} \begin{itemize} \item Using the information you have gathered, try to \emphcolour{eliminate} some potential problems from your list. \end{itemize} \end{slide} \begin{slide}[toc=Action Plan,bm=Action Plan]{Create an Action Plan} \label{sld:create-action-plan} \begin{itemize} \item Start with the \emphcolour{most likely} \begin{itemize} \item \ldots{} and those that are \emphcolour{easiest to test} \end{itemize} \item Plan needs to be \emphcolour{methodical} \item Plan to {\green{}change only one thing at a time} \begin{itemize} \item You can then understand the cause of the problem \item Aim to understand the problem so you can learn from it, solve (or prevent) similar problems in the future \end{itemize} \item {\mbox{}\blue{}Aim higher than just removing the symptoms!} \end{itemize} \end{slide} \begin{slide}{Implement Action Plan} \begin{itemize} \item Perform each step carefully \item Test to see if symptoms go away \end{itemize} \end{slide} \begin{slide}{Observe Results} \begin{itemize} \item Gather results as you change \emphcolour{each variable} \item Use same techniques you used in slide~\ref{sld:gather-the-facts}: \begin{itemize} \item Check with the key people \item Check with your tools \end{itemize} \end{itemize} \end{slide} \begin{slide}[toc=document,bm=document]% {If Solved: Document Solution} \begin{itemize} \item Record the problem and its resolution in the documentation you maintain for your company. \item Ensure others in your team can benefit from the insight you have gained \end{itemize} \end{slide} \begin{slide}[toc=modify action plan,bm=modify action plan]% {Otherwise, Modify Action Plan} \begin{itemize} \item Go back to the steps in slide~\S\ref{sld:create-action-plan}: \begin{itemize} \item Modify your action plan, selecting the next most likely action from your list \item You may have discovered more information in your investigation, so this can help you focus on likely causes. \end{itemize} \item If you have exhausted all the items on your list, and cannot think of what else to do: \begin{itemize} \item Get help from the vendor \item Get help from mailing lists \item Discuss the problem with your network of colleagues (e.g., the people who are now studying with you, but who move on to work in a similar field!) \item You could even track me down and ask me! Quite a few of my ex-students do. \end{itemize} \end{itemize} \end{slide} \tsectionandpart{TCP/IP} \begin{slide}{OSI---TCP/IP} %\hspace*{-0.13\slideWidth} \positionPictureOpt{0pt}{-0.13\slideWidth}% \includegraphics[width=1.15\slideWidth]{iso-tcpip-with-protocols} \end{slide} \begin{slide}{IP Header---Layer 3} \includegraphics[width=\slideWidth]{ipheader} \end{slide} \begin{slide}{IP Header} \begin{itemize} \item Version --- this is a 4-bit IP header length field that indicates the version of IP currently used. The current version of IP is 4 (IPv4) but IPv6 is already being implemented experimentally and will be supported on future versions of the IOS. \item IP Header Length (IHL) --- this indicates the datagram header length in 32-bit words. \item Type of Service (ToS) --- ToS specifies how a particular upper-layer protocol would like the current datagram to be handled. Datagrams can be assigned various levels of importance with this field. \item Total length --- this specifies the length of the entire IP packet, including data and header, in bytes. \item Identification --- this field contains an integer that identifies the current datagram. This field is used to help piece together datagram fragments. \end{itemize} \end{slide} \begin{slide}{IP Header (continued)} \begin{itemize} \item Flags --- a flag is a 3-bit field of which the 2 low-order bits control fragmentation. One bit specifies whether the packet can be fragmented; the second bit specifies whether the packet is the last fragment in a series of fragmented packets. \item Time-to-Live --- this field maintains a counter that gradually decrements down to zero, at which point the datagram is discarded. This prevents packets from looping endlessly. \item Protocol --- protocol indicates which upper-layer protocol receives incoming packets after IP processing is complete. \item Header Checksum --- this field helps ensure IP header integrity. \item Source Address --- this field specifies the sending node. \item Destination Address --- this field specifies the receiving node. \item Options --- this field allows IP to support various options, such as security. \item Data --- this field contains upper-layer information. \end{itemize} \end{slide} \begin{slide}{TCP Header---Layer 4} \includegraphics[width=\slideWidth]{tcpheader} \end{slide} \begin{slide}{TCP Header} \begin{itemize} \item Source port and destination port --- these fields identify the points at which upper-layer source and destination processes receive TCP services. \item Sequence number --- this field usually specifies the number assigned to the first byte of data in the current message. Under certain circumstances, it can also be used to identify an initial sequence number to be used in the upcoming transmission. \item Acknowledgment number --- this field contains the sequence number of the next byte of data the sender of the packet expects to receive. \item Data offset --- this field indicates the number of 32-bit words in the TCP header. \item Reserved --- this field is reserved for future use. \item Flags --- this field carries a variety of control information. \end{itemize} \end{slide} \begin{slide}{TCP Header (continued)} \begin{itemize} \item Window --- this field specifies the size of the sender's receive window (that is, buffer space available for incoming data). \item Checksum --- this field indicates whether the header was damaged in transit. \item Urgent pointer --- this field points to the first urgent data byte in the packet. \item Options --- this field specifies various TCP options. \item Data --- this field contains upper-layer information. \end{itemize} \end{slide} \begin{slide}{UDP Header---Layer 4} \includegraphics[width=\slideWidth]{udpheader} \par\bigskip\par% \begin{itemize} \item Source and Destination Port fields serve the same functions as they do in the TCP header. \item Length field specifies the length of the UDP header and data \item Checksum field allows packet integrity checking. It is optional. \end{itemize} \end{slide} \tsectionandpart{Troubleshooting TCP/IP} \begin{slide}{Troubleshooting TCP/IP} \positionPictureOpt{0pt}{-0.13\slideWidth}% %\hspace*{-0.13\slideWidth}% \includegraphics[width=1.15\slideWidth]{troubleshooting-tcpip} \end{slide} \begin{slide}{Troubleshooting TCP/IP} \begin{description} \item[Step 1] First, determine whether your local host is properly configured (for instance, correct subnet mask and default gateway configuration). \item[Step 2] Next, use the \texttt{ping} or \texttt{traceroute} commands to determine whether the routers through which you must communicate can respond. Start with the most local router and progressively \texttt{ping} outwards through the Internet or use \texttt{traceroute}. \item[Step 3] If you cannot get through a particular node, examine the node configuration and use the various show commands to determine the state of the router (these include \texttt{show ip route}, \texttt{show ip arp}, \texttt{show running-configuration}, and so on.) \item[Step 4] If you can get to all the routers in the path, check the host configuration at the remote host (or get someone's help to do so), and check its configuration. \end{description} \end{slide} \tsection{Host Configuration} \begin{slide}[toc=Host Configuration,bm=Host Configuration]% {Host Network Configuration tools} \begin{description} \item[\texttt{ps}] --- information about processes \item[\texttt{top}] --- dynamic information about processes \item[\texttt{netstat}] --- show connections and services, routing \item[\texttt{lsof}] --- list open files \item[\texttt{ifconfig}] --- shows and changes network interfaces \item[\texttt{route}] --- shows, changes routing table \item[\texttt{ip}] --- show, change, set network configuration \item[\texttt{arp}] --- shows MAC addresses \item[\texttt{nmap}] --- portscanner: shows open ports, identifies \OS \end{description} \end{slide} \begin{slide}[toc=Host Configuration,bm=Host Configuration]% {Checking (and Setting) Host Configuration} \begin{itemize} \item Solving Boot problems: \S\ref{sld:boot-problems-with-Linux}, \S\ref{sld:boot-problems-with-Windows} \item Determine \IP address, netmask, broadcast address: \S\ref{sld:determine-addresses} \item Deterine correct \MAC $\leftrightarrow$ \IP address mapping: \S\ref{sld:mac-ip-mapping-1}, \S\ref{sld:mac-ip-mapping-windows} \item Examine routing table: \S\ref{sld:examine-routing-table} \item Examine access controls: \S\ref{sld:access-controls} \item Examine web proxy settings: check web browser \item Examine \DNS resolver settings: \S\ref{sld:dns-resolver-settings} \item Determine services provided: \S\ref{sld:services-provided}, \S\ref{sld:using-ps-to-see-if-server-running} \item Determine \CPU, memory load conditions (is the server overloaded?) \S\ref{sld:top} \end{itemize} \end{slide} \begin{slide}[toc=Boot Linux,bm=Boot Linux]{Boot problems: Linux} \label{sld:boot-problems-with-Linux} \begin{itemize} \item Use \texttt{grub} to interactively boot the computer (see my extensive grub handout: {\footnotesize\url{http://nicku.org/ossi/lab/grub/grub.pdf}}) \item Verify that \texttt{/etc/fstab} mounts the correct filesystems \item Use a rescue disk such as Knoppix or the Red Hat installation \CDROM. \item This gives you full access to the system and repairing boot problems is pretty straightforward. \end{itemize} \end{slide} \begin{slide}[toc=Boot Windows,bm=Boot Windows]{Boot problems: Windows} \label{sld:boot-problems-with-Windows} \begin{itemize} \item Use the installation Windows \CD to enter the (extremely limited) system repair mode. I believe this is called the recovery console. \item Use the Linux floppy bootdisk at \url{http://home.eunet.no/~pnordahl/ntpasswd/} to replace the Administrator password \item Use the bootable Windows \CDROM: \url{http://www.nu2.nu/pebuilder/}; \begin{itemize} \item Gives full access to the NTFS file system. \item Not as good with Windows as Knoppix is with Linux, but better than another reinstall. \item takes some time to build. \item Henry Leung (in A204d) has built some. \end{itemize} \end{itemize} \end{slide} \begin{slide}{Determine Addresses} \label{sld:determine-addresses} \begin{description} \item[Linux:] On Linux, these commands all show the \IP address, \MAC address, netmask and broadcast address for all (or the specified) interface. The commands \texttt{ip} and \texttt{ifconfig} are in the directory \texttt{/sbin}; \texttt{netstat} is in \texttt{/bin}. \begin{alltt} $ \textbf{ip addr} $ \textbf{ip addr show eth0} $ \textbf{ifconfig} $ \textbf{ifconfig eth0} $ \textbf{netstat -i} \end{alltt}%$ \par% \item[Windows:]\mbox{} \begin{alltt} C:\bs> \textbf{ipconfig /all} \end{alltt} \par% \item[Cisco IOS:] these are both privileged commands, as shown by the prompt: \begin{alltt} Router# \textbf{show running-config} Router# \textbf{show ip interface brief} Router# \textbf{show ip interface} \end{alltt} \end{description} \end{slide} \begin{slide}[bm=MAC <-> IP mapping 1]% {MAC $\leftrightarrow$ IP mapping --- 1} \label{sld:mac-ip-mapping-1} \begin{description} \item[Linux:]\mbox{} \begin{alltt} $ \textbf{arp -a} $ \textbf{ip neigh show} \end{alltt} The lifetime of the \ARP cache entries is settable in \texttt{/proc/\allowbreak{}sys/\allowbreak{}net/\allowbreak{}ipv4/\allowbreak{}neigh/\allowbreak{}\meta{interface}/\allowbreak{}gc\_stale\_time} and is normally 60 seconds. \item[Cisco IOS:]\mbox{} \begin{alltt} Router# \textbf{show ip arp} \end{alltt} \end{description} Note that this document: {\footnotesize \url{http://members.cox.net/~ndav1/self_published/The_ARP_cache.doc}} has a good discussion on troubleshooting \ARP. The online book at \url{http://linux-ip.net/} has an excellent chapter on \ARP. \ARP is probably the most dangerously exposed protocol in a \LAN, and can easily be subverted by tools such as \texttt{dsniff} and \texttt{Ettercap}. Hardcode important \ARP entries to avoid attack. \end{slide} \begin{slide}[bm=MAC <-> IP mapping 2]% {MAC $\leftrightarrow$ IP mapping --- 2} \label{sld:mac-ip-mapping-windows} \begin{description} \item[Windows:]\mbox{} \begin{alltt} C:\bs> \textbf{arp -a} \end{alltt} You may wish to clear the \ARP cache on a Windows machine with: \begin{alltt} C:\bs> \textbf{arp -d \meta{IP address}} \end{alltt} or clear the entire \ARP cache with: \begin{alltt} C:\bs> \textbf{arp -d *} \end{alltt} since the Windows \ARP cache lives 10 minutes by default, a rather (too?) long time. It can be changed by two registry entries under \path{HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters}. \end{description} \end{slide} \begin{slide}{Routing Table} \label{sld:examine-routing-table} \begin{description} \item[Linux:] The commands \texttt{ip} and \texttt{route} are in \path{/sbin}, the command \texttt{netstat} is in \path{/bin}. \begin{alltt} $ \textbf{ip route} $ \textbf{route -n} $ \textbf{netstat -nr} \end{alltt}%$ \item[Windows:]\mbox{} \begin{alltt} C:\bs> \textbf{route print} C:\bs> \textbf{netstat -nr} \end{alltt} \item[Cisco IOS:]\mbox{} \begin{alltt} Router# \textbf{show ip route} \end{alltt} \end{description} \end{slide} \begin{slide}{Access Controls} \label{sld:access-controls} \begin{itemize} \item Access controls can block access mysteriously unless you think to check for it. \end{itemize} \begin{description} \item[Linux:] There are two main things to check. The \texttt{iptables} command is in the \path{/sbin} directory. \begin{alltt} $ \textbf{iptables -L -n} \end{alltt}%$ Note that Linux and many other \POSIX systems implement the tcpwrappers access control in \path{/etc/hosts.allow} and \path{/etc/hosts.deny}. See \texttt{man~hosts.allow} and \texttt{man~hosts.deny}. \item[Cisco IOS:]\mbox{} \begin{alltt} Router# \textbf{show ip access-list} \end{alltt} \end{description} \end{slide} \begin{slide}[toc=DNS resolver,bm=DNS resolver]{DNS resolver settings} \label{sld:dns-resolver-settings} \begin{description} \item[Linux:] The configuration for the resolver is \path{/etc/resolv.conf}. This determines what name servers the system will ask. It also tells what domain will be appended to a hostname. The \path{/etc/hosts} file is usually the first way hostname $\leftrightarrow$ \IP address mappings are made, but this can be changed in \path{/etc/nsswitch.conf}. To ask the operating system for what it can see there, do: \begin{alltt} $ \textbf{getent hosts} \end{alltt}%$ Linux provides three tools for troubleshooting \DNS and \DNS servers: \texttt{dig}, \texttt{host} and \texttt{nslookup}. \item[Windows:] See the output of \begin{alltt} C:\bs> \textbf{ipconfig /all} \end{alltt} for the names of the \DNS server the resolver will use. Recent versions of Windows provide the program \texttt{nslookup} to help with \DNS troubleshooting. \end{description} See Slides starting at \S\ref{sld:dns-troubleshooting} for details of \texttt{dig} and \texttt{nslookup}. \end{slide} \begin{slide}{Checking services provided} \label{sld:services-provided} \begin{description} \item[Linux:] There are four main ways to check: \begin{itemize} \item Verify the processes with \texttt{ps} (see \S\ref{sld:using-ps-to-see-if-server-running}) \item Verify the services that are configured to start when the system boots: \begin{alltt} $ \textbf{chkconfig --list | grep on} \end{alltt}%$ \item Check that the service is listening on the network interface: \begin{alltt} $ \textbf{netstat -tua} \end{alltt}%$ will show all network connections to this machine. \item The \texttt{lsof} program can be helpful in diagnosing problems with network services. See~\S\ref{sld:lsof}. \end{itemize} \item[Windows:] Check network connections with \begin{alltt} C:\bs> \textbf{netstat -a} \end{alltt} \end{description} \end{slide} \begin{slide}[toc=Server Running?,bm=Server Running?]% {Using \texttt{ps} to See If Server Running} \label{sld:using-ps-to-see-if-server-running} \begin{itemize} \item Is the network service running on the server? \item Is the web server running? \begin{alltt} $ \textbf{ps aux | grep httpd} \end{alltt}%$ \item Is the DHCP server running? \begin{alltt} $ \textbf{ps aux | grep dhcpd} \end{alltt}%$ \item Is the directory server running? \begin{alltt} $ \textbf{ps aux | grep slapd} \end{alltt}%$ \item Windows: use the task manager \end{itemize} \end{slide} \begin{slide}[toc=\texttt{top},bm=top]% {Using \texttt{top} to see Resource Hogs} \label{sld:top} \begin{itemize} \item The program \texttt{top} shows: \begin{itemize} \item \emphcolour{load average} (the average number of processes that are ready to run, but for which no \CPU is available) \begin{itemize} \item a load average of 4 or more is ``quite high'' \end{itemize} \item processes that use the most resources \end{itemize} \end{itemize} \end{slide} \begin{slide}[toc=\texttt{netstat -tua},bm=netstat -tua]% {\texttt{netstat -tua}: See Network Connections} \begin{itemize} \item \texttt{netstat -tua} shows all network connections, including those listening \item \texttt{sudo netstat -tuap} shows all network connections, including those listening, and the processes responsible \item \texttt{netstat -tul} shows all network listeners \item \texttt{netstat -t} shows only \TCP connections that are established \item \texttt{netstat -i} is like \texttt{ifconfig}, shows info and stats about each interface \item \texttt{netstat -nr} shows the routing table, like \texttt{route -n} \item Windows provides \texttt{netstat} also. \end{itemize} \end{slide} \begin{slide}{\texttt{lsof}: List Open Files} \label{sld:lsof} \begin{itemize} \item An amazingly useful tool \item Available for almost any Unix system \item \textbf{\texttt{lsof -i}} shows output to Internet and X.25 files, but won't show connections that have terminated \item \textbf{\texttt{lsof -i@nicku.org}} will show only connections to that machine \item Can monitor progress of an FTP transfer, many, many other applications \item See manpage, \FAQ and quick start guide. \item Apparently, no equivalent tool available on Windows. \end{itemize} \end{slide} \begin{slide}{\texttt{ifconfig}} \label{sld:ifconfig} \begin{itemize} \item \textbf{\texttt{ifconfig eth0}} --- show stats on network interface eth0 \item \textbf{\texttt{sudo ifconfig lo 127.0.0.1}} --- configure the loopback interface, start it up \item \textbf{\texttt{sudo ifconfig eth0 172.19.233.5 netmask 255.255.255.0}} --- configure eth0 with IP address 172.19.233.5/24 \item \textbf{\texttt{ifconfig}} --- show all configured network interfaces \item \textbf{\texttt{ifconfig -a}} --- show all interfaces, including those not configured yet. \end{itemize} \end{slide} \begin{slide}{\texttt{route}} \label{sld:linux-route} \begin{itemize} \item \texttt{route -n} --- print routing table \item \texttt{route add 127.0.0.1} --- add a route to localhost; \item should have been done automatically when created device with \texttt{ifconfig} \item \texttt{route add -net 172.19.233.0} --- add a route to the eth0 configured on previous slide \item should have been done automatically by \texttt{ifconfig} \item \texttt{route add 172.19.64.0 gw 172.19.233.254} --- add a static route to network 172.19.64.0 through router 172.19.233.254 \item \texttt{route add default gw 172.19.233.253} --- add a default route to 172.19.233.253 through eth0 \end{itemize} \end{slide} \tsection{Cables} \begin{slide}{Connectivity Testing: Cabling} \label{sld:cables} \begin{itemize} \item Label cables clearly at each end \item Cable testers \begin{itemize} \item ensure wired correctly, check: \item attenuation \item length --- is it too long? \begin{itemize} \item 100BaseT: less than 100m \end{itemize} \end{itemize} \item Is the activity light on the interface blinking? \end{itemize} \end{slide} \tsectionandpart{Ping} \begin{slide}{Software tools: \texttt{ping}} \begin{itemize} \item Most useful check of connectivity \item Universal \item If \textbf{\texttt{ping}} hostname, includes a rough check of \DNS \item Sends an \ICMP (Internet Control Message Protocol) \texttt{ECHO\_REQUEST} \item Waits for an \ICMP \texttt{ECHO\_REPLY} \item Most \textbf{\texttt{ping}}s can display round trip time \item Most \textbf{\texttt{ping}}s can allow setting size of packet \item Can use to make a crude measurement of throughput---see \S\ref{sld:one-hop-throughput-measurement} \end{itemize} \end{slide} \begin{slide}[toc={Good \texttt{ping}, Bad \texttt{ping}?},bm={Good ping, Bad ping?}]% {What \texttt{ping} Result is Good, Bad?} \begin{itemize} \item A steady stream of consistent replies indicates probably okay \item Usually first reply takes longer due to \ARP lookups at each router \begin{itemize} \item After that, \ARP results are cached \end{itemize} \item \ICMP error messages can help understand results: \begin{itemize} \item Destination Network Unreachable indicates the host doing ping cannot reach the network \item Destination Host Unreachable may come from routers further away \end{itemize} \end{itemize} \end{slide} \begin{slide}{How to Use \texttt{ping}?} \begin{itemize} \item Ensure local host networking is enabled first: ping localhost, local \IP address \item ping a known host on local network \item ping local and remote interfaces on router \item ping by IP as well as by hostname if hostname ping fails \begin{itemize} \item confirm DNS with \textbf{\texttt{dig}} (or \textbf{\texttt{nslookup}}) --- see slide~\S\ref{sld:dns-troubleshooting} \end{itemize} \item Ping from more than one host \end{itemize} \end{slide} \begin{slide}{\texttt{fping}: flood ping} \begin{itemize} \item Designed to test a large number of hosts \item more efficient than \texttt{ping} \item Used extensively by monitoring software such as \texttt{mon}: \url{http://www.kernel.org/software/mon/}, \textbf{\red{}nagios}: \url{http://www.nagios.org/} \item take care not to flood too much! \item \RPM{}s are available; I built one (a long time ago) and put it on ictlab under $\sim$ftp/pub/redhat/contrib \end{itemize} \end{slide} \begin{slide}[toc=hping2,bm=hping]% {\texttt{hping2}: ping anything with anything} \begin{itemize} \item able to send custom TCP/IP packets and \item display target replies like ping program does with \ICMP replies. \item Can install with \begin{alltt} $ \textbf{yum -y install hping2} \end{alltt}%$ on Fedora Core 1. \item See \url{http://www.hping.org/}. \end{itemize} \end{slide} \begin{slide}{\texttt{arping}: uses ARP requests} \begin{itemize} \item Limited to local network \item Can work with \MAC or \IP addresses \item use to probe for \ARP entries in router (very useful!) \item packet filtering \begin{itemize} \item can block \ICMP pings, but \item won't block \ARP requests \end{itemize} \end{itemize} \end{slide} \tsection{\texttt{traceroute}} \begin{slide}{Path Discovery: \texttt{traceroute}} \begin{itemize} \item Sends \UDP packets \begin{itemize} \item (Microsoft \texttt{tracert} sends \ICMP packets) \end{itemize} \item increments Time to Live (\TTL) in \IP packet header \item Sends three packets at each \TTL \item records round trip time for each \item increases \TTL until enough to reach destination \end{itemize} \end{slide} \begin{slide}{\texttt{traceroute}: How it Works} \begin{itemize} \item As \IP packets pass through each router, \TTL in \IP header is decremented \item Packet is discarded when TTL decrements to 0 \item ROUTER sends \ICMP \texttt{TIME\_EXCEEDED} message back to traceroute host \item When \UDP packet reaches destination, gets \ICMP \texttt{PORT\_UNREACHABLE}, since uses an unused high \UDP port \end{itemize} \end{slide} \begin{slide}{\texttt{traceroute} Limitations} \begin{itemize} \item Each router has a number of \IP addresses \item but \texttt{traceroute} only shows the one it used \item get different addresses when run \texttt{traceroute} from other end \item sometimes route is asymmetric \item router may be configured to not send \ICMP \texttt{TIME\_EXCEEDED} messages \begin{itemize} \item get stars: \texttt{*} instead of round-trip time in \textbf{\texttt{traceroute}} output \end{itemize} \end{itemize} \end{slide} \tsection{Measurements} \begin{slide}{Performance Measurements: delay} \begin{itemize} \item Three sources of delay: \item \emphcolour{transmission delay} --- time to put signal onto cable or media \begin{itemize} \item depends on transmission rate and size of frame \end{itemize} \item \emphcolour{propagation delay} --- time for signal to travel across the media \begin{itemize} \item determined by type of media and distance \end{itemize} \item \emphcolour{queuing delay} --- time spent waiting for retransmission in a router \end{itemize} \end{slide} \begin{slide}[toc=bandwidth and throughput,% bm=bandwidth and throughput]% {Is Bandwidth == Throughput?} \begin{itemize} \item \emphcolour{bandwidth} --- the difference between the upper frequency and the lower frequency that a channel can carry \begin{itemize} \item measured in Hertz \end{itemize} \item \emphcolour{throughput} --- amount of data that can be sent over link in given time \begin{itemize} %\item relates to all causes of delay \item is {\blue{}not the same as bandwidth}, which really has no direct meaning with digital information \end{itemize} \item bandwidth is related to throughput by the Shannon-Hartley Theorem; throughput $\propto$ bandwidth if signal to noise ratio is fixed: \begin{align*} C_{\text{max}} &= B\log_2\left(1 + \frac{S}{N}\right) \text{ bits/sec}\\[0.7ex] \text{where $C_{\text{max}}$} &= \text{maximum channel capacity,}\notag\\ B &= \text{bandwidth in Hz,}\notag\\ S &= \text{signal power in W,}\notag\\ N &= \text{noise power in W.}\notag \end{align*} \end{itemize} \end{slide} \begin{slide}{Quality of a Link} \begin{itemize} \item Other measurements needed \begin{itemize} \item i.e., for quality of service for multimedia \end{itemize} \end{itemize} \end{slide} \begin{slide}[toc=Throughput: \texttt{ping},bm=Throughput: ping]% {\texttt{ping} \emph{Roughly} Estimating Throughput} \label{sld:one-hop-throughput-measurement} \begin{itemize} \item Example: measuring throughput {\blue{}between \emphcolour{this} machine and \emphcolour{one remote} \blue{}machine.} \item ping with packet size = {\red{}100 bytes}, round-trip time = {\red{}30ms} \item ping with packet size = {\red{}1100 bytes}, round-trip time = {\red{}60ms} \item So takes 30ms extra ({\red{}15ms one way}) to send additional {\green{}1000 bytes}, or {\red{}8000 bits} \item Throughput is \emphcolour{roughly} {\blue{}8000 bits per 15ms}, or about 530,000 bits per second \item A \emphcolour{very crude} measurement: \begin{itemize} \item no account for other traffic, treats all links on path, there and back, as one. \item Routers sometimes send packets onwards with much higher priority than with which they answer pings. See slide~\S\ref{sld:limitations-of-ping}. \end{itemize} \end{itemize} \end{slide} \begin{slide}[toc=Througput: \texttt{ping} One,bm=Throughput: ping One]% {Throughput: \texttt{ping} One Remote Host} \begin{itemize} \item This can be expressed as a simple formula: \begin{align*} TP &= 16 \times \frac{P_l - P_s}{t_l - t_s} \text{\ bits per second, where}\\ P_l &= \text{size of large packet} \\ P_s &= \text{size of small packet} \\ t_l &= \text{round-trip time for large packet} \\ t_s &= \text{round-trip time for small packet} \\[-2ex] \intertext{Here we have:}\\[-10mm] TP &= 16 \times \frac{1100 - 100}{(60 - 30) \times 10^{-3}}\\ &= 16 \times \frac{1000}{30 \times 10^{-3}}\\ &= \frac{16}{30} \times 10^{6}\\ &\approx 530{,}000 \text{ bps}\\ \end{align*} \end{itemize} \end{slide} \begin{slide}[toc=Throughput \texttt{ping} 2 remote,% bm=Throughput ping 2 remote]% {Throughput: \texttt{ping} Two Remote Hosts} \label{sld:ping-2-remote-hosts-throughput} \begin{itemize} \item Measure throughput {\red{}between two remote hosts}: may use tools like \texttt{ping} \item ping two locations with two packet sizes (4 pings altogether, minimum) \begin{itemize} \item Many ping programs calculate average ping time: better to make a number of pings, use the average ping time. \item First ping time may be longer due to the time to get an answer to the \texttt{arp} request \item May be better to ping once, then start pinging again, and use the average ping time. \end{itemize} \item Example: \end{itemize} \begin{tabular}[t]{@{}lll@{}} \toprule% \textbf{Address} & \textbf{RTT 100 bytes} & \textbf{RTT 1100 bytes} \\ \midrule% 205.153.61.1 & 1.380\,ms & 5.805\,ms \\ 205.153.60.2 & 4.985\,ms & 12.823\,ms \\ 165.166.36.17 & 8.621\,ms & 26.713\,ms \\ \bottomrule \end{tabular} \end{slide} \begin{slide}[toc=Throughput \texttt{ping} 2 remote,% bm=Throughput ping 2 remote]% {Throughput: \texttt{ping} Two Remote Hosts --- 2} \label{sld:ping-2-remote-hosts-throughput-2} \vspace*{-2ex}\par {\footnotesize \begin{tabular}[t]{@{}lll@{}} \toprule% \textbf{Address} & \textbf{RTT 100 bytes} & \textbf{RTT 1100 bytes} \\ \midrule% 205.153.61.1 & 1.380\,ms & 5.805\,ms \\ 205.153.60.2 & 4.985\,ms & 12.823\,ms \\ 165.166.36.17 & 8.621\,ms & 26.713\,ms \\ \bottomrule \end{tabular} } \par\medskip\par% \begin{itemize} \item Time difference / 2 (round trip time (RTT) $\to$ one way) \item Divide by size difference in bits: $8000 = 8 \times (1100 - 100)$ \item Multiply by 1000 (ms $\to$ seconds) \item $\text{Mbs} = \text{bps} / 10^{6}$ \end{itemize} \begin{tabularx}{\slideWidth}[t]{@{}YYYY@{}} \toprule% \textbf{Near link} & \textbf{Far link} & \textbf{Time difference} & \textbf{Est. Throughput}\\ \midrule% 205.153.61.1 & 205.153.60.2 & 3.413\,ms & 4.69\,Mbps \\ 205.153.60.2 & 165.166.36.17 & 10.254\,ms & 1.56\,Mbps \\ \bottomrule \end{tabularx} \begin{align*} 3.413\,\text{ms} &= (12.823 - 4.985) - (5.805 - 1.380)\,\text{ms}\\ 10.254\,\text{ms} &= (26.713 - 8.621 ) - ( 12.823 - 4.985)\,\text{ms} \end{align*} \end{slide} \begin{slide}[toc=Throughput \texttt{ping} 2 remote,% bm=Throughput ping 2 remote]% {Throughput: \texttt{ping} Two Remote Hosts --- 3} \label{sld:ping-2-remote-hosts-throughput-3} \begin{align*} TP &= 16 \times \frac{P_l - P_s}{t_{fl} - t_{fs} - t_{nl} + t_{ns}} \quad \text{bits per second} \intertext{where:} P_l &= \text{\textbf{\emph{l}}arge packet size, bytes} \\ P_s &= \text{\textbf{\emph{s}}mall packet size, bytes} \\ t_{nl} &= \text{ping time for \textbf{\emph{l}}arger packet to the \textbf{\emph{n}}ear link, seconds} \\ t_{ns} &= \text{ping time for \textbf{\emph{s}}maller packet to the \textbf{\emph{n}}ear link, seconds} \\ t_{fl} &= \text{ping time for \textbf{\emph{l}}arger packet to the \textbf{\emph{f}}ar link, seconds} \\ t_{fs} &= \text{ping time for \textbf{\emph{s}}maller packet to the \textbf{\emph{f}}ar link, seconds} \\ \end{align*} \end{slide} \begin{slide}[toc=Throughput \texttt{ping} 2 remote,% bm=Throughput ping 2 remote]% {Throughput: \texttt{ping} Two Remote Hosts --- 4} \label{sld:ping-2-remote-hosts-throughput-4} \vspace*{-3ex}\par% \scriptsize \begin{align*} P_l &= \text{\textbf{\emph{l}}arge packet size, bytes} = 1100\,\text{bytes}\\ P_s &= \text{\textbf{\emph{s}}mall packet size, bytes} = 100\,\text{bytes}\\ t_{nl} &= \text{ping time for \textbf{\emph{l}}arger packet to the \textbf{\emph{n}}ear link, seconds} \\ &= 5.805 \times 10^{-3}\,\text{seconds}\\ t_{ns} &= \text{ping time for \textbf{\emph{s}}maller packet to the \textbf{\emph{n}}ear link, seconds} \\ &= 1.380 \times 10^{-3}\,\text{seconds}\\ t_{fl} &= \text{ping time for \textbf{\emph{l}}arger packet to the \textbf{\emph{f}}ar link, seconds} \\ &= 12.823 \times 10^{-3}\,\text{seconds}\\ t_{fs} &= \text{ping time for \textbf{\emph{s}}maller packet to the \textbf{\emph{f}}ar link, seconds} \\ &= 4.985 \times 10^{-3}\,\text{seconds}\\ TP &= 16 \times \frac{P_l - P_s}{t_{fl} - t_{fs} - t_{nl} + t_{ns}} \quad \text{bits per second}\\ &= 16 \times% \frac{1100 - 100}{(12.823 - 4.985 - 5.805 + 1.380) \times 10^{-3}} \quad \text{bits per second}\\ &= 16 \times \frac{1000}{3.413 \times 10^{-3}}\\ &\approx 4{,}687{,}958\\ &\approx 4.69\,\text{Megabits per second} \end{align*} \end{slide} \begin{slide}[toc=Throughput \texttt{ping} 2 remote,% bm=Throughput ping 2 remote]% {Throughput: \texttt{ping} Two Remote Hosts --- 5} \label{sld:ping-2-remote-hosts-throughput-5} \vspace*{-3ex}\par% \scriptsize \begin{align*} P_l &= \text{\textbf{\emph{l}}arge packet size, bytes} = 1100\,\text{bytes}\\ P_s &= \text{\textbf{\emph{s}}mall packet size, bytes} = 100\,\text{bytes}\\ t_{nl} &= \text{ping time for \textbf{\emph{l}}arger packet to the \textbf{\emph{n}}ear link, seconds} \\ &= 12.823 \times 10^{-3}\,\text{seconds}\\ t_{ns} &= \text{ping time for \textbf{\emph{s}}maller packet to the \textbf{\emph{n}}ear link, seconds} \\ &= 4.985 \times 10^{-3}\,\text{seconds}\\ t_{fl} &= \text{ping time for \textbf{\emph{l}}arger packet to the \textbf{\emph{f}}ar link, seconds} \\ &= 26.713 \times 10^{-3}\,\text{seconds}\\ t_{fs} &= \text{ping time for \textbf{\emph{s}}maller packet to the \textbf{\emph{f}}ar link, seconds} \\ &= 8.621 \times 10^{-3}\,\text{seconds}\\ TP &= 16 \times \frac{P_l - P_s}{t_{fl} - t_{fs} - t_{nl} + t_{ns}} \quad \text{bits per second}\\ &= 16 \times% \frac{1100 - 100}{(26.713 - 8.621 - 12.823 + 4.985) \times 10^{-3}} \quad \text{bits per second}\\ &= 16 \times \frac{1000}{10.254 \times 10^{-3}}\\ &\approx 1{,}560{,}366\\ &\approx 1.56\,\text{Megabits per second} \end{align*} \end{slide} \begin{slide}[toc=Limitations of \texttt{ping},bm=Limitations of ping]% {Limitations of measuring with \texttt{ping}} \label{sld:limitations-of-ping} \begin{itemize} \item Most modern routers give {\blue{}high priority to routing} \begin{itemize} \item Expecially switching routers, such as the Cisco 6509 in our Campus \item Many give much {\blue{}lower priority to answering pings} \item The difference can be so great that the ping reply sometimes comes sooner from a more distant router, which according to our formula, indicates a {\green{}negative throughput!} \item Do not blindly apply this formula! \end{itemize} \item Measurements may not match the kind of traffic created by the application you support \item The big \emphcolour{advantages} of these \ICMP measurements are: \begin{itemize} \item you do not need access to the machines, and \item you do not need to install any special software on them. \end{itemize} \end{itemize} \end{slide} \begin{slide}{Path Performance: Other tools} \begin{itemize} \item Could use a tool like \texttt{pathchar}, \texttt{bing}, \texttt{clink}, \texttt{pchar}, or \texttt{tmetric} that performs this calculation for you \item Use \url{http://www.google.com/} to locate these tools \item \texttt{pathchar} is only available in binary form \item Others in source form, need compile with commands something like this: \begin{alltt} $ \textbf{cd bing-1.1.3} $ \textbf{make} $ \textbf{sudo make install} \end{alltt}%$ \end{itemize} \end{slide} \begin{slide}[toc=\texttt{pathchar},bm=pathchar]% {Path measurement with \texttt{pathchar}} \ptsize{12}% \begin{alltt}\tiny $ \textbf{sudo ./pathchar sina.com.hk} pathchar to sina.com.hk (202.85.139.140) can't find path mtu - using 1500 bytes. doing 32 probes at each of 45 sizes (64 to 1500 by 32) 0 localhost (127.0.0.1) | 106 Mb/s, 293 us (698 us), +q 1.18 ms (15.7 KB) 1 172.19.35.246 (172.19.35.246) | 28 Mb/s, 488 us (2.10 ms) 2 192.168.83.2 (192.168.83.2) 3 * 1 448 798 2 | 20 Mb/s, 273 us (3.25 ms) 4 cw7204.vtc.edu.hk (202.40.210.220) | 6.8 Mb/s, 521 us (6.04 ms) 5 210.176.123.37 (210.176.123.37) | 52 Mb/s, 20 us (6.31 ms) 6 210.87.254.61 (210.87.254.61) | 136 Mb/s, 116 us (6.63 ms) 7 g5-0-0.wttbr01.imsbiz.com (210.87.254.129) | 33 Mb/s, 0.94 ms (8.88 ms), +q 1.48 ms (6.10 KB) *6 8 iadvantage3-RGE.hkix.net (202.40.161.172) | 164 Mb/s, 45 us (9.04 ms), +q 1.74 ms (35.6 KB) *6 9 v005-m02.hk01.iadvantage.net (202.85.129.53) | ?? b/s, -66 us (8.88 ms) 10 202.85.129.136 (202.85.129.136) | ?? b/s, 459 us (9.79 ms) 11 202.85.139.11 (202.85.139.11) 11 hops, rtt 6.18 ms (9.79 ms), bottleneck 6.8 Mb/s, pipe 9361 bytes \end{alltt}%$ \end{slide} \begin{slide}{Measuring Throughput} \begin{itemize} \item May use \textbf{\texttt{\red{}ftp}} to transfer a large file, measure time \begin{itemize} \item tests whole path \item problem: affected by disk \IO, \texttt{xinetd} \end{itemize} \item May use a \emphcolour{web browser} and measure download time \begin{itemize} \item Problem: may be affected by caching in the web browser \item May be affected by caching in web proxies \end{itemize} \item \emphcolour{Better}: measure using traffic similar to that created by the application. \end{itemize} \end{slide} \begin{slide}{Measuring Throughput with \texttt{ttcp}} \begin{itemize} \item Use \textbf{\texttt{\red{}ttcp}}, not affected by disk \IO \item Consists of a client and server \item Need have installed at both ends \item Part of Red Hat Linux, Cisco \IOS \item Example: first, start receiver on \texttt{ictlab}: \begin{alltt}\scriptsize $ \textbf{ttcp -r -s} ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: socket ttcp-r: accept from 172.19.32.30 ttcp-r: 16777216 bytes in 1.45 real seconds = 11285.88 KB/sec +++ ttcp-r: 9704 I/O calls, msec/call = 0.15, calls/sec = 6684.46 ttcp-r: 0.0user 0.2sys 0:01real 14\% 0i+0d 0maxrss 0+2pf 0+0csw \end{alltt}%$ \item Second, start transmitter on nickpc: \begin{alltt}\scriptsize $ \textbf{ttcp -t -s ictlab} ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp -> ictlab ttcp-t: socket ttcp-t: connect ttcp-t: 16777216 bytes in 1.45 real seconds = 11335.64 KB/sec +++ ttcp-t: 2048 I/O calls, msec/call = 0.72, calls/sec = 1416.95 ttcp-t: 0.0user 0.0sys 0:01real 4\% 0i+0d 0maxrss 0+2pf 0+0csw \end{alltt}%$ \end{itemize} \end{slide} \tsectionandpart{iproute} \begin{slide}{The \texttt{ip} program, iproute} \begin{itemize} \item The \texttt{ip} program in the iproute package provides complete control over \TCPIP networking in a Linux system \item Provides more networking control facilities than other \TCPIP implementations \item Supports tunneling in many forms \item iproute documentation is in two manuals, one for \IP routing, the other for tunnelling \end{itemize} \end{slide} \begin{slide}{iproute and \texttt{iptables}} \begin{itemize} \item Between these software packages, you can: \begin{itemize} \item throttle bandwidth for certain computers \item throttle bandwidth to certain computers \item fairly share bandwidth \item protect your network from DoS attacks \item protect Internet from your customers \item multiplex many servers into one, for load balancing or for high availability \item restrict access to your computers \item limit access of your users to other hosts \item do routing based on user id, \MAC address, source \IP, port, type of service, time of day or content \end{itemize} \item See the Linux Advanced Routing and Traffic Control HOWTO at \url{http://tldp.org} for details \end{itemize} \end{slide} \begin{slide}{Traffic Measurements: \texttt{netstat -i}} \begin{itemize} \item The \texttt{netstat} program can show statistics about network interfaces \item Linux \texttt{netstat} shows lost packets in three categories: \begin{itemize} \item errors, \item drops (queue full: shouldn't happen!) \item overruns (last data overwritten by new data before old data was read: shouldn't happen!) \item drops and overruns indicate faulty flow control --- bad! \end{itemize} \item These values are cumulative (since interface was up) \item Could put a load on interface to see current condition, with \texttt{ping -l}, to send large number of packets to destination \item See the difference in values \end{itemize} \end{slide} \begin{slide}{Measuring Traffic: \texttt{netstat -i}} \begin{itemize} \item Here we run \texttt{netstat -i} on \texttt{ictlab}: \begin{alltt} $ \textbf{netstat -i} Kernel Interface table\tiny Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 407027830 0 0 0 1603191764 0 0 {\red3} BMRU lo 16436 0 2858402 0 0 0 2858402 0 0 0 LRU \end{alltt}%$ \item Notice that of the 1.6 billion bytes transmitted, there were 3 overuns. \item Next, blast the path you want to test with packets using \texttt{ping -l} or the \texttt{spray} program, and measure again. \end{itemize} \end{slide} \begin{slide}{Traffic measurements: \texttt{ifconfig}, \texttt{ip}} \begin{itemize} \item \texttt{ifconfig} and \texttt{ip} give more information than \texttt{netstat~-i}: \end{itemize} \begin{alltt}\scriptsize $ \textbf{ifconfig eth0} eth0 Link encap:Ethernet HWaddr 00:00:E2:35:AF:EE inet addr:172.19.64.52 Bcast:172.19.127.255 Mask:255.255.192.0 IPX/Ethernet 802.2 addr:33001601:0000E235AFEE UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:407579600 errors:0 dropped:0 overruns:0 frame:0 TX packets:1605655688 errors:0 dropped:0 overruns:3 carrier:0 collisions:0 txqueuelen:100 RX bytes:3055300191 (2913.7 Mb) TX bytes:2048217058 (1953.3 Mb) Interrupt:18 Base address:0xd000 $ \textbf{ip -s link list eth0} 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:00:e2:35:af:ee brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 3058362227 407610495 0 0 0 0 TX: bytes packets errors dropped carrier collsns 2140511920 1605768150 0 0 0 0 \end{alltt} \end{slide} \begin{slide}{Getting more info using \texttt{ip}} \begin{itemize} \item The \texttt{-s} (\texttt{-statistics}) option to \texttt{ip} provides statistics. Adding a second gives you even more: \begin{alltt}\scriptsize $ \textbf{ip -s -s link list eth0} 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:00:e2:35:af:ee brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 3070792102 407726727 0 0 0 0 RX errors: length crc frame fifo missed 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 2445799644 1606151878 0 0 0 0 TX errors: aborted fifo window heartbeat 0 3 0 0 \end{alltt}%$ \end{itemize} \end{slide} \begin{slide}[toc=Guide to \texttt{ip} 1,bm=Guide to ip 1]% {Quick Guide to using \texttt{ip}: set up interface} \begin{itemize} \item Here we set up a network interface and give it the IP address 192.168.0.1/24: \begin{alltt} $ \textbf{ip link set dev eth1 up} $ \textbf{ip addr add 192.168.0.1/24 brd + dev eth1} \end{alltt} \item Two important points: \begin{itemize} \item If you do not specify the netmask, a netmask of /32 is assumed \item \textbf{\texttt{brd +}} means obtain broadcast address by setting the host bits \end{itemize} \end{itemize} \end{slide} \begin{slide}[toc=Guide to \texttt{ip} 2,bm=Guide to ip 2]% {Quick Guide to using \texttt{ip}: set up routes} \begin{alltt} $ \textbf{ip route add default dev eth1 via 192.168.0.254} $ \textbf{ip route add 192.168.1.0/24 via 192.168.0.10} \end{alltt} \begin{itemize} \item The last adds a static route to another network \item the first adds the default route. \item You can omit the device if the network can be reached through a particular interface without any ambiguity \begin{itemize} \item I.e., \texttt{ip} is smart enough to figure out which network device to use, though specifying it doesn't hurt. \end{itemize} \end{itemize} \end{slide} \tsectionandpart[toc=Packet Capture,bm=Packet Capture]% {Packet Capture\\[3ex]\texttt{tcpdump}, Ethereal and Ntop} \begin{slide}{What is Packet Capture?} \label{sld:packet-capture} \begin{itemize} \item Real time collection of data as it travels over networks \item Tools called: \begin{itemize} \item packet sniffers \item packet analysers \item protocol analysers, and sometimes even \item traffic monitors \end{itemize} \end{itemize} \end{slide} \begin{slide}{When Packet Capture?} \begin{itemize} \item Most powerful technique \item When need to see what client and server are actually saying to each other \item When need to analyse type of traffic on network \item Requires understanding of network protocols to use effectively \end{itemize} \end{slide} \begin{slide}{Warning: Don't Get Sacked!} \begin{itemize} \item Be sure that your boss agrees with you capturing packets on your company's network \item People have been sacked for doing this without permission! \item Some have suffered long lawsuits and \emphcolour{criminal records}: \begin{itemize} \item See \url{http://www.stonehenge.com/merlyn/}, and \url{http://www.lightlink.com/spacenka/fors/} for a famous example \end{itemize} \item {\mbox{}\blue{}Do not invade the \emphcolour{privacy} \blue{}of others} \begin{itemize} \item Capturing passwords with insecure protocols such as telnet, ftp, http (that is not encrypted with \TLS) is very easy \begin{itemize} \item DON'T DO IT! \end{itemize} \end{itemize} \end{itemize} \end{slide} \begin{slide}{\texttt{tcpdump}} \begin{itemize} \item Available everywhere \item Windows: \url{http://windump.polito.it/} \item Syntax also used by other programs (such as Ethereal) \item Often it is the only tool available, so good to know \item Works by putting network interface into \emphcolour{promiscuous} mode \begin{itemize} \item normal Ethernet interface will ignore packets not addressed to it \item in \emphcolour{promiscuous mode}, will examine \emphcolour{all packets} that arrive, even those not addressed to it \end{itemize} \end{itemize} \end{slide} \begin{slide}{How to use \texttt{tcpdump}} \begin{itemize} \item Can just type its name (as root): \begin{alltt} $ \textbf{sudo tcpdump} \end{alltt}%$ \item \ldots{}but get a huge amount of data! \item Can restrict the data collected using a \emphcolour{filter} \item A filter may select addresses, protocols, port numbers,\,\ldots \end{itemize} \end{slide} \begin{slide}{\texttt{tcpdump}: some options} \begin{description} \item[\texttt{-c } \meta{n}] capture a \underline{c}ount of \meta{n} packets then stop \item[\texttt{-w } \meta{file}] \underline{w}rite raw data to \meta{file}. \begin{itemize} \item Very useful --- can filter and analyse this later with \texttt{tcpdump}, \texttt{ethereal} or other tools \item but you cannot see what you are capturing till later! \end{itemize} \item[\texttt{-i } \meta{interface}] collect from \meta{interface} instead of lowest numbered network \underline{i}nterface \item[\texttt{-s } \meta{bytes}] collect no more than \meta{bytes} of data from each packet instead of default 68 bytes \item[\texttt{-e}] show link level info, e.g., \underline{E}thernet addresses \item[\texttt{-x }] gives a he\underline{x}adecimal dump of packets \item[] excluding link level data \item[\texttt{-X}] display \ASCII as well as hexadecimal if have \texttt{-x} option too \item Many more options: \texttt{man tcpdump} \end{description} \end{slide} \begin{slide}{\texttt{tcpdump} Filters: host and port} \begin{itemize} \item Show all network traffic to and from 192.168.0.1: \begin{alltt} $ \textbf{tcpdump host 192.168.0.1} \end{alltt}%$ \item Show packets to 192.168.0.1: \begin{alltt} $ \textbf{tcpdump dst 192.168.0.1} \end{alltt}%$ \item Show packets to port 68 on 192.168.0.1: \begin{alltt} $ \textbf{tcpdump dst 192.168.0.1 and port 68} \end{alltt}%$ \end{itemize} \end{slide} \begin{slide}{\texttt{tcpdump} filters: networks} \begin{itemize} \item Capture traffic to or from 205.153.60/24: \begin{alltt} $ \textbf{tcpdump net 172.19.64/18} \end{alltt}%$ \item can specify network as source or destination: \begin{alltt} $ \textbf{tcpdump src net 205.153.60/24} $ \textbf{tcpdump dst net 172.19.64/18} \end{alltt} \end{itemize} \end{slide} \begin{slide}{\texttt{tcpdump} filters: protocol} \begin{itemize} \item \texttt{tcpdump ip} \item \texttt{tcpdump tcp} \item \texttt{tcpdump ip proto ospf} \item This will catch DNS name lookups, but not zone transfers (which use tcp): \item \texttt{tcpdump udp port 53} \end{itemize} \end{slide} \begin{slide}{\texttt{tcpdump} filters: combining} \begin{itemize} \item This will not work as you might expect: \item \texttt{tcpdump host ictlab and udp or arp} \item Instead, need group with parentheses, and quote: \item \textbf{\texttt{tcpdump "host ictlab and (udp or arp)"}} \item many more ways of filtering: \texttt{man tcpdump} \end{itemize} \end{slide} \begin{slide}{Writing data to a file} \begin{alltt} $ \textbf{sudo tcpdump -c 1000 -w \(\sim\)/tmp/tcpdump.pcap} tcpdump: listening on eth0 1014 packets received by filter 0 packets dropped by kernel \end{alltt}%$ \end{slide} \begin{slide}{Reading a Dumped File} \begin{alltt}\scriptsize $ \textbf{tcpdump -nr \(\sim\)/tmp/tcpdump.pcap arp}\scriptsize 22:32:41.751452 arp who-has 172.19.127.254 tell 172.19.127.29 22:32:41.863173 arp who-has 172.19.64.52 tell 172.19.64.63 22:32:41.863198 arp reply 172.19.64.52 is-at 0:0:e2:35:af:ee 22:32:42.082584 arp who-has 172.19.65.16 tell 172.19.125.229 22:32:43.113655 arp who-has 172.19.123.211 tell 172.19.65.2 22:32:44.635149 arp who-has 172.19.65.16 tell 172.19.127.106 22:32:44.874117 arp who-has 172.19.65.6 tell 172.19.126.174 22:32:45.147178 arp who-has 172.19.65.16 tell 172.19.126.240 22:32:45.209507 arp who-has 172.19.127.254 tell 172.19.125.127 22:32:45.212484 arp who-has 172.19.127.175 tell 172.19.125.127 22:32:45.239445 arp who-has 172.19.127.254 tell 172.19.125.212 22:32:45.455863 arp who-has 172.19.65.16 tell 172.19.126.194 22:32:45.540507 arp who-has 172.19.126.50 (44:30:54:59:43:4d) tell 172.19.65.10 22:32:45.562004 arp who-has 172.19.126.50 tell 172.19.65.2 \end{alltt}%$ \end{slide} \begin{slide}{HTTP} \begin{alltt}\scriptsize $ \textbf{tcpdump -nr \(\sim\)/tmp/tcpdump.pcap port http} 22:43:32.633636 192.168.25.9.14075 > 172.19.64.52.http: S 1015952778:1015952778(0) win 6144 (DF) 22:43:32.633693 172.19.64.52.http > 192.168.25.9.14075: S 1929920485:1929920485(0) ack 1015952779 win 5840 (DF) 22:43:32.635828 192.168.25.9.14075 > 172.19.64.52.http: P 1:590(589) ack 1 win 6144 (DF) 22:43:32.635906 172.19.64.52.http > 192.168.25.9.14075: . ack 590 win 6479 (DF) 22:43:32.636758 172.19.64.52.http > 192.168.25.9.14075: P 1:217(216) ack 590 win 6479 (DF) 22:43:32.636982 172.19.64.52.http > 192.168.25.9.14075: F 217:217(0) ack 590 win 6479 (DF) 22:43:32.639080 192.168.25.9.14075 > 172.19.64.52.http: R 590:590(0) ack 217 win 0 (DF) \end{alltt}%$ \end{slide} \begin{slide}{\texttt{tcpdump}: When reading TCP} \begin{itemize} \item format: \item src > dst: flags data-seqno ack window urgent options \item Flags are some combination of S (SYN), F (FIN), P (PUSH) or R (RST) or a single `\texttt{.}' (no flags). \item The first time tcpdump sees a tcp 'conversation', it prints the sequence number from the packet. \item On subsequent packets of the conversation, the difference between the current packet's sequence number and this initial sequence number is printed. \end{itemize} \end{slide} \begin{slide}{Window} \begin{itemize} \item \texttt{win} \meta{nnn} specifies data window the sending host will accept in future packets \begin{itemize} \item I.e., the maximum number of bytes \end{itemize} \item \TCP flow-control: \begin{itemize} \item host reduces this number if congested or overloaded \item will sometimes set to 0 to temporarily halt incoming traffic in this connection \end{itemize} \end{itemize} \end{slide} \tsectionandpart[toc=Ethereal,bm=Ethereal]% {Ethereal\\King of the Packet Analysers!\\Available for Linux, Unix, Windows} %% \begin{slide}{Ethereal} %% \begin{center} %% King of the Packet Analysers! %% \end{center} %% \begin{center} %% Available for Linux, Unix, Windows %% \end{center} %% \end{slide} \begin{slide}{Ethereal} \begin{itemize} \item Ethereal can read data captured by \texttt{tcpdump}, e.g., \begin{alltt} $ \textbf{ethereal -r tcpdump.pca} \end{alltt}%$ \item or File $\to$ Open \item Can capture data itself \item Uses same filter language as \texttt{tcpdump} \end{itemize} \end{slide} %% \newcommand{\positionPicture}{ %% \vspace*{-0.15\slideWidth}\par %% \hspace*{-0.1\slideWidth}% %% } \begin{wideslide}[toc=Ethereal Screenshot,bm=Ethereal Screenshot]{} \positionPictureOpt{-0.1\slideWidth}{-0.1\slideWidth}% \includegraphics[scale=0.5]{Screenshot-Ethereal-big-top-frame} \end{wideslide} \begin{slide}[toc=Ethereal Screenshot,bm=Ethereal Screenshot]{} %\includegraphics[width=\slideWidth]{Screenshot-Ethereal-capture} \positionPictureOpt{-0.15\slideWidth}{-0.1\slideWidth}% \includegraphics[scale=0.5]{Screenshot-Ethereal-capture} \end{slide} \begin{slide}{You can expand any protocol:} \setlength{\fboxsep}{0.4pt} \begin{itemize} \item If we click on the \fbox{+} next to \texttt{Bootstrap Protocol}, we can see the details of the DHCP Request: \end{itemize} \end{slide} \begin{wideslide}[toc=Ethereal 2,bm=Ethereal 2]{} %\includegraphics[width=\slideWidth]{Screenshot-Ethereal-1-big-middle-window} \positionPictureOpt{-0.1\slideWidth}{-0.1\slideWidth}% \includegraphics[scale=0.5]{Screenshot-Ethereal-1-big-middle-window} \end{wideslide} \begin{slide}{Display Filters} \begin{itemize} \item Note the box at the bottom of Ethereal for display filters \item Select only some of the packets captured for display \item see man ethereal and search for DISPLAY FILTER SYNTAX \item Different syntax than the syntax for capture filters \item Example: \item \texttt{ip.src==172.19.64.52 and ip.dest==172.19.64.57} \end{itemize} \end{slide} \begin{slide}{Tools $\to$ Follow TCP Stream} \begin{itemize} \item Can view the contents of an entire \TCP stream conversation, in \ASCII or in hexadecimal. \item Be careful not to invade your customers' privacy. \item Can use to check if a communications stream is \emphcolour{really} encrypted \end{itemize} \end{slide} \begin{slide}[toc=Ntop,bm=Ntop]{Ntop: monitoring data at a point} \begin{itemize} \item The Ntop program: \begin{itemize} \item listens on a network interface \item puts an Ethernet interface into promiscuous mode and \item displays statistics through a web interface \end{itemize} \item Shows: \begin{itemize} \item percentages of protocols, \item which machines generate most traffic \item which traffic is purely local, which traffic comes from outside, which traffic goes from inside to outside of network \end{itemize} \end{itemize} \end{slide} \begin{slide}[toc=Ntop,bm=Ntop]{Ntop: Installing} \begin{itemize} \item Installation is pretty easy. On my Fedora Core 1 machine: \end{itemize} \begin{alltt}\footnotesize $ \textbf{rpmbuild --rebuild ntop-3.0-0.src.rpm} $ \textbf{sudo rpm -Uhv /home/nicku/RPM/RPMS/i386/ntop-3.0-0.i386.rpm} $ \textbf{ls -l /etc/ntop.conf*} -rwx------ 1 root root 13203 Apr 27 03:47 /etc/ntop.conf.sample $ \textbf{sudo cp -a /etc/ntop.conf.sample /etc/ntop.conf} $ \textbf{sudo emacs /etc/ntop.conf &} # temporarily comment out the line --daemon $ \textbf{sudo /usr/bin/ntop @/etc/ntop.conf -A} $ \textbf{sudo service ntop start} \end{alltt}%$ \begin{itemize} \item Then open the web browser on \path{http://localhost:3000/} \end{itemize} \end{slide} %% \begin{slide}{Ntop RPM} %% \begin{itemize} %% \item I have made an RPM package of \texttt{ntop} %% \begin{itemize} %% \item it's the best one available, or at least it was when I made %% it \texttt{:-)} %% \end{itemize} %% \item Can get from %% \path{/home/nfs/redhat/contrib/ntop-2.1.51-20021031nu2.i386.rpm} %% \begin{itemize} %% \item source rpm is there too %% \end{itemize} %% \item Or search for it on \url{http://rpmfind.net/} %% \item Note that you will be prompted for a password when you install it. %% \end{itemize} %% \end{slide} \tsectionandpart[toc=Switched Networks,bm=Switched Networks]% {Switched Networks\\[3ex]Using Ethereal, \texttt{tcpdump}, Ntop \\in a switched network} \begin{slide}[toc=Port Monitoring,bm=Port Monitoring]% {Port Monitoring: Switched Networks} \label{sld:port-monitoring} \begin{description} \item[Problem:]\mbox{} \begin{itemize} \item a switched network is really a point-to-point network \item You cannot normally capture the unicast traffic from other hosts on a single switch port \item {\mbox{}\blue{}How do you use Ethereal, \texttt{tcpdump} or Ntop to monitor traffic between a number of hosts?} \end{itemize} \item[Solution:] many switches support \emphcolour{port monitoring}, where one port can monitor all traffic on a specified VLAN \item[Example:]\mbox{} \begin{itemize} \item Cisco 3500XL switches provide the \textbf{\texttt{port monitor}} command: \item \textbf{\texttt{port monitor vlan VLAN1}} \end{itemize} \end{description} \end{slide} \begin{slide}{How monitor one machine?} \begin{itemize} \item You are asked to check out a server on a switched network: The switch does not support port monitoring (\S\ref{sld:port-monitoring}), or you do not have administrative access to the switch: what to do? \item Use a small hub, and use a notebook running the capture software \end{itemize} \centering% \includegraphics[width=0.6\slideWidth]{hub-switch-monitor.eps} \end{slide} \begin{slide}{Are switched networks secure?} \begin{itemize} \item Is all unicast traffic on one port of a switch private? \item No, there are tools (\texttt{dsniff} and \texttt{Ettercap}) freely available to automate \ARP spoofing and man-in-the-middle attacks, that provide various ways to compromise switch security. \end{itemize} \end{slide} \tsectionandpart{Port Scanning} \begin{slide}{What is a port scanner?} \begin{itemize} \item Sends packets to various ports on a network device \item Best one available everywhere is nmap \item can identify the OS of the target machine \item Do not port scan arbitrary machines in your company's network without permission! \item May be interpreted as a cracking attempt \end{itemize} \end{slide} \begin{slide}{How does \texttt{nmap} identify OS?} \begin{itemize} \item \RFC{}s leave interpretation of some things up to the implementer \item \RFC{}s do not specify how should work if get contradictory flags, strange sequences of inconsistent packets \item Most \TCPIP implementations are not complete \item Every implementation of \TCPIP is different; the ``grey areas'' are different from one \OS to another. \item \textbf{\texttt{nmap}} sends ``strange'' packets to the machine, detects how reacts, matches this against a file of \OS fingerprints \end{itemize} \end{slide} \begin{slide}{Running \texttt{nmap}: Use \texttt{xnmap}} \begin{alltt} $ \textbf{sudo -v} $ \textbf{sudo xnmap &} \end{alltt} \begin{itemize} \item Enter the \IP address of machine(s) to identify \item select other choices from buttons \item press Start \item \texttt{xnmap} is simply a way to easily generate command line options to \texttt{nmap} using a graphical interface \end{itemize} \end{slide} \begin{slide}{Uses of \texttt{nmap}} \begin{itemize} \item Identify the type of a computer that is causing trouble on the network \item Check what network services a computer is really offering \begin{itemize} \item compare with \texttt{netstat -tua} output \item A cracked computer may be hiding some services with trojaned utilities \item \texttt{nmap} can help you discover such services \end{itemize} \end{itemize} \end{slide} \tsectionandpart[toc=DNS troubleshooting,bm=DNS troubleshooting]% {DNS troubleshooting\\[3ex]Troubleshooting DNS Servers} \begin{slide}{DNS troubleshooting} \label{sld:dns-troubleshooting} \begin{itemize} \item Suspect \DNS when get long timeouts before see any response \item ping name, \IP address, see if only \IP address works \item tools on Linux, Unix: \begin{itemize} \item \texttt{dig}, \texttt{nslookup}, \texttt{host} \end{itemize} \item tools on Windows: \begin{itemize} \item \texttt{nslookup} \end{itemize} \end{itemize} \end{slide} \begin{slide}{DNS: \texttt{dig}} \begin{itemize} \item The people who write the most common name server (Bind) promote \texttt{dig}, deprecate \texttt{nslookup} \item \texttt{dig} output is in form of \DNS resource records \begin{itemize} \item can copy and paste straight into \DNS database files \end{itemize} \end{itemize} \end{slide} \begin{slide}{\texttt{dig}: Checking forward DNS lookup} \begin{alltt} $ \textbf{dig nicku.org}\scriptsize ; <<>> DiG 9.2.1 <<>> nicku.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23568 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;nicku.org. IN A ;; ANSWER SECTION: nicku.org. 60 IN A 202.69.77.139 ;; AUTHORITY SECTION: no-ip.com. 60 IN NS nf1.no-ip.com. no-ip.com. 60 IN NS nf2.no-ip.com. no-ip.com. 60 IN NS nf3.no-ip.com. ;; ADDITIONAL SECTION: nf1.no-ip.com. 60 IN A 66.185.166.131 nf2.no-ip.com. 60 IN A 66.185.162.100 nf3.no-ip.com. 60 IN A 216.66.37.10 ;; Query time: 254 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Feb 24 10:55:26 2003 ;; MSG SIZE rcvd: 154 \end{alltt} \end{slide} \begin{slide}{\texttt{dig}: reverse lookup 1} \begin{alltt} $ \textbf{dig -x 202.69.77.139}\scriptsize ; <<>> DiG 9.2.1 <<>> -x 202.69.77.139 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22117 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;;139.77.69.202.in-addr.arpa. IN PTR ;; ANSWER SECTION: 139.77.69.202.in-addr.arpa. 3600 IN PTR 077-139.onebb.com. ;; AUTHORITY SECTION: 77.69.202.in-addr.arpa. 3600 IN NS ns2.onebb.com. 77.69.202.in-addr.arpa. 3600 IN NS ns1.onebb.com. ;; Query time: 310 msec ;; SERVER: 172.19.64.52#53(172.19.64.52) ;; WHEN: Mon Feb 24 11:07:04 2003 ;; MSG SIZE rcvd: 111 \end{alltt} \end{slide} \begin{slide}{\texttt{dig} syntax} \begin{alltt} \textbf{dig [\meta{options}] [@\meta{server}] \meta{name} \meta{type}} \end{alltt} \begin{itemize} \item main option is \texttt{-x} \item \meta{server} is the name server to query \begin{itemize} \item by default, use first server in \texttt{/etc/resolv.conf} \end{itemize} \item \meta{name} is what you want to look up \item \meta{type} can be: \texttt{any}, \texttt{a}, \texttt{mx}, \texttt{axfr}, \texttt{soa}, etc. \item default is to get A record(s) \end{itemize} \end{slide} \begin{slide}{\texttt{dig}: axfr (Zone Transfer)} \begin{itemize} \item \texttt{dig} can request a complete zone transfer: \begin{alltt}\scriptsize $ \textbf{dig @ns tyict.vtc.edu.hk axfr} ; <<>> DiG 9.2.2-P3 <<>> @ns tyict.vtc.edu.hk axfr ;; global options: printcmd tyict.vtc.edu.hk. 86400 IN SOA ns.tyict.vtc.edu.hk. nicku.vtc.edu.hk. 2004031000 3600 1800 604800 600 tyict.vtc.edu.hk. 86400 IN NS ns.tyict.vtc.edu.hk. tyict.vtc.edu.hk. 86400 IN NS ns1.tyict.vtc.edu.hk. tyict.vtc.edu.hk. 86400 IN NS dns1.vtc.edu.hk. tyict.vtc.edu.hk. 86400 IN NS dns2.vtc.edu.hk. 000081667.tyict.vtc.edu.hk. 86400 IN A 172.19.64.92 \ldots \end{alltt} \item result can be copied and pasted as a master file in a DNS server \end{itemize} \end{slide} \begin{slide}{\texttt{nslookup}: an interactive program} \begin{alltt} $ \textbf{nslookup} Note: nslookup is deprecated and may be removed from future releases. Consider using the `dig' or `host' programs instead. Run nslookup with the `-sil[ent]' option to prevent this message from appearing. > nicku.org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: nicku.org Address: 202.69.77.139 \end{alltt}%$ \end{slide} \begin{slide}{\texttt{nslookup}: reverse lookups} \begin{alltt}\scriptsize > 202.69.77.139 Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: 139.77.69.202.in-addr.arpa name = 077-139.onebb.com. Authoritative answers can be found from: 77.69.202.in-addr.arpa nameserver = ns1.onebb.com. 77.69.202.in-addr.arpa nameserver = ns2.onebb.com. ns1.onebb.com internet address = 202.180.160.1 ns2.onebb.com internet address = 202.180.161.1 > \end{alltt} \end{slide} \tsectionandpart[toc=telnet,bm=telnet]{Telnet:\\Troubleshooting Email and Other Protocols} \begin{slide}{Email: testing with \texttt{telnet}} \begin{itemize} \item Email protocols \SMTP, \POP{}3 are text \item \texttt{telnet} a good tool to test them \item syntax: \begin{alltt} $ \textbf{telnet \meta{server} \meta{portnumber}} \end{alltt}%$ \item SMTP: port 25 \item POP3: port 110 \end{itemize} \end{slide} \begin{slide}{Test the VTC mail server:} \begin{alltt} $ \textbf{telnet smtp.vtc.edu.hk 25}\scriptsize Trying 192.168.79.191... Connected to smtp.vtc.edu.hk (192.168.79.191). Escape character is '\^{}]'. 220 pandora.vtc.edu.hk ESMTP Mirapoint 3.2.2-GA; Tue, 25 Feb 2003 11:15:30 +0800 (HKT) helo nickpc.tyict.vtc.edu.hk 250 pandora.vtc.edu.hk Hello [172.19.32.30], pleased to meet you mail from: nicku@vtc.edu.hk 250 nicku@vtc.edu.hk... Sender ok rcpt to: nicku@vtc.edu.hk 250 nicku@vtc.edu.hk... Recipient ok data 354 Enter mail, end with ``.'' on a line by itself My message body. . 250 AFF21826 Message accepted for delivery quit 221 pandora.vtc.edu.hk closing connection Connection closed by foreign host. \end{alltt}%$ \end{slide} \begin{slide}{SMTP commands for sending mail} \begin{description} \item[\texttt{helo}] identify your computer \item[\texttt{mail from}] specify sender \item[\texttt{rcpt to}] specify receiver \item[\texttt{data}] indicates start of message body \item[\texttt{quit}] terminate session \end{description} \begin{itemize} \item Use names, not IP addresses, to specify destination \end{itemize} \end{slide} \begin{slide}{Testing the VTC pop3 server 1} \begin{alltt}\scriptsize $ \textbf{telnet pop.vtc.edu.hk 110} Trying 192.168.79.12... Connected to pop.vtc.edu.hk (192.168.79.12). Escape character is '^]'. +OK carme.vtc.edu.hk POP3 service (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) user nicku +OK Name is a valid mailbox pass \emphcolour{password} +OK Maildrop ready stat +OK 1 673 \end{alltt}%$ \end{slide} \begin{slide}{Testing the pop3 server 2} \begin{alltt}\scriptsize retr 1 +OK 673 octets Return-path: Received: from pandora.vtc.edu.hk (pandora.vtc.edu.hk [192.168.79.191]) by carme.vtc.edu.hk (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HAU00I35H3HGL@carme.vtc.edu.hk> for nicku@ims-ms-daemon (ORCPT nicku@vtc.edu.hk); Tue, 25 Feb 2003 11:16:29 +0800 (CST) Received: from nickpc.tyict.vtc.edu.hk ([172.19.32.30]) by pandora.vtc.edu.hk (Mirapoint Messaging Server MOS 3.2.2-GA) with SMTP id AFF21826; Tue, 25 Feb 2003 11:16:01 +0800 (HKT) Date: Tue, 25 Feb 2003 11:15:30 +0800 (HKT) From: Nick Urbanik Message-id: <200302250316.AFF21826@pandora.vtc.edu.hk> My message body. . dele 1 +OK message deleted quit +OK Connection closed by foreign host. \end{alltt} \end{slide} \begin{slide}{pop3 commands: retrieving mail} \begin{itemize} \item See RFC 1939 for easy-to-read details \item First, must authenticate: \end{itemize} \begin{description} \item[\texttt{user} \meta{username}] \item[\texttt{pass} \meta{password}] \item[\texttt{stat}] shows number of messages and total size in bytes \item[\texttt{list}] list all the message numbers and size in bytes of each message \item[\texttt{retr} \meta{messagenum}] retrieve the message with number \meta{messagenum} \item[\texttt{dele} \meta{messagenum}] delete the message with message number \meta{messagenum} \item[\texttt{quit}] \end{description} \end{slide} \begin{slide}{\texttt{telnet}: Testing Other Applications} \begin{itemize} \item Many network protocols are text. \texttt{telnet} can be helpful in checking: \begin{itemize} \item IMAP servers: \begin{alltt} $ \textbf{telnet \meta{hostname} 143} \end{alltt}%$ \item Web servers: \begin{alltt} $ \textbf{telnet \meta{hostname} 80} \end{alltt}%$ \item Ftp servers: \begin{alltt} $ \textbf{telnet \meta{hostname} 21} \end{alltt}%$ \item Even ssh (can check version, if responding): \begin{alltt} $ \textbf{telnet \meta{hostname} 22} \end{alltt}%$ \end{itemize} \end{itemize} \end{slide} \begin{slide}{Conclusion} \begin{itemize} \item Check the \emphcolour{simple} things first \item Be \emphcolour{methodical} \item \emphcolour{Document} what you do \item Become {\blue{}familiar} with \emphcolour{common tools} \item Use the tools to become {\blue{}familiar} with your \emphcolour{network} {\green{}before troubles strike} \item Know what is \emphcolour{``normal''} \item Get\emphcolour{ permission} from the boss before using {\blue{}packet sniffing and port scanners} \end{itemize} \end{slide} \end{document}