In this lesson we will learn about some of the basic tools and services/protocols.


One of the most fundamental questions you might ask involving IP networking is this: is there a host at a given IP address? The shell utility ping is designed to answer this question. It takes an IP address (or a symbolic name that it resolves for you via a DNS query) and sends an ICMP (Internet Control Message Protocol) "echo request" packets with that address. It waits for a response for a while, then tries again. It prints out statistics about how many packets were received, round trip time, etc. Here are the results of two pings:
$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=255 time=0.269 ms
64 bytes from icmp_seq=2 ttl=255 time=0.363 ms
64 bytes from icmp_seq=3 ttl=255 time=0.229 ms
64 bytes from icmp_seq=4 ttl=255 time=0.243 ms
--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.229/0.276/0.363/0.052 ms
$ ping
PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Host Unreachable
From icmp_seq=2 Destination Host Unreachable
From icmp_seq=3 Destination Host Unreachable
From icmp_seq=4 Destination Host Unreachable
From icmp_seq=5 Destination Host Unreachable
From icmp_seq=6 Destination Host Unreachable
--- ping statistics ---
7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6032ms
, pipe 3
In the first case the host was up and everything transmitted was received. In the second case, there was no host at that address. Ping is useful for debugging network problems (e.g. is not refreshing ... is the server down/unreachable right now, or is it something else?) It's also used as a tool for network reconnaissance, as we'll see later in this course. You could ping every address in a range in order to find out what hosts there are on a given network. Another nefarious use for ping is to have a group of computers send lots and lots of ping requests to a given server, hoping to keep it so busy answering the stupid pings that it can't do any useful work. This is a simple denial of service attack, which we'll see more of later. Not all hosts reply to a ping request, mainly because the tool is sometimes abused by malicious people and programs. Still, it is a useful tool.

ICMP is an Internet Layer protocol, which means it doesn't have an associated port number the way application level protocols that are built on top of the transport layer do.


HTTP (HyperText Transfer Protocol) is the application layer protocol that the web is based on, which we've talked quite a bit about. HTTP servers (web servers) use TCP and listen on port 80. HTTP clients are called browsers. If we like, we can act as rudimentary web-browsers/web-servers using netcat, although it's really tedious. At the very least, we can check whether there's really a webserver listening to port 80 for a given host. The GET method from the HTTP protocol, which we've seen several times, would suffice for this. There's also a method called HEAD that gives us less information usually, since we don't get all the page text. Here's the check (what you type is in red):
$ nc 80
                                                ← NOTE: you need this blank line!
HTTP/1.1 200 OK
Date: Mon, 11 Jul 2011 17:38:14 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=ISO-8859-1
This shows that really is running a webserver. If there isn't a webserver on that machine and listening to port 80, netcat just returns with no output:
$ nc 80
If you replace the HEAD with GET, you can get server responses to the request a browser would make to actually fetch a webpage. The / is the path. Replace stuff like "/images/foo.jpg" to get particular files. Like this:
$ nc 80
GET /Users/cs/wcbrown/index.html HTTP/1.0
                                                ← NOTE: you need this blank line!

TLS (Transport Layer Security) is a newer version of the protocol known as SSL (Secure Sockets Layer).
... BUT how secure is it???
(read this)
HTTPS (HTTP Secure) is simply HTTP that doesn't just run over TCP. Instead it runs over TLS/SSL which is essentially TCP with authentication and encryption, which means that you get some assurances that the server is who it says it is and that none of the HTTP messages you send can be eavesdropped upon, because all of the Application Layer data is sent encrypted, i.e. scrambled so that it would look like garbled non-sense to any evesdropper. TLS/SSL is kind of the exception that proves the rule in the sense that it doesn't fit nicely into the protocol stack. It is sandwiched between the application layer and the transport layer. It uses TCP and is used by application layer protocols.

You can see the difference between HTTP and HTTPS quite clearly if you use netcat to pretend to be a webserver.

So the GET request sent by a browser over HTTPS just looks like scrambled nonsense!


We've discussed the role of DNS already. The DNS protocol is an application layer protocol used by DNS resolvers and DNS nameservers to communicate. It uses UDP rather than TCP, and DNS servers usually listen on port 53. The DNS message format is not plain text, like basic HTTP, but rather uses bytefields to represent numbers, so it's hard to read or write DNS messages by hand and, in fact, we won't try. The tool nslookup provides a simple way to resolve domain names on the command line. It issues on your behalf those DNS client requests that are so card to craft by hand. There are two simple ways to use it:
$ nslookup
Address:	canonical name =
This tells us that ginger's address is, and that it's canonical name (it's one true name) is Run this way, nslookup sends its query request to whatever nameserver your system has set as its default. If you're in class, that'll probably be The other way to run it is to specify the nameserver to query as a second argument:
$  nslookup
Address:	canonical name =
The site lets you enter a domain name and shows you the steps a nameserver has to go through in order to resolve that name.

DNS is a complicated system, with millions of servers spread out across the earth. Suppose you query your local nameserver for The general scheme works like this: There are 13 root nameservers. If your name server doesn't know the IP address of, it sends a query to one of the 13 root nameservers. If that server doesn't know the answer, it at least is able to send you to a nameserver that knows about all the .com domains. This .com nameserver will send you to the nameserver for the domain, and that nameserver ought to be able to give the IP address for If this much traffic was required for every name resolution, the internet would be a much slower place. Instead, nameservers remember the answers to queries they've answered recently. (The technical term is they cache the answers.) So the first time you ask for's IP address it might take a while. But subsequent requests will be fast.

It must be emphasized that from a security perspective it's crucial that DNS works properly. If the name gets resolved incorrectly to an IP address owned by a bad guy, I could be in trouble. He could put up a dummy webpage that looks just like's, but which isn't and he could perhaps steal my password ... and then my money.


There are SSH clients for Windows, for example PuTTY, which is freely available.
Unix/Linux users tend to make more use of the shell than Windows users. Thus, they can as effectively control a machine far away from their desktop as long as they can get a shell running on the remote machine that they can interact with on their local machine. SSH (Secure SHell) is a protocol that allows this to be done in a secure manner — where secure means nobody snooping on the network traffic can read off your password when you login or other information that gets sent back and forth during the session. Generally, you use ssh like this: ssh username@hostname, e.g. ssh You'll be prompted for a password, and assuming you give the right one, you have a shell on the remote machine ( in the example).

SSH is a client/server system just like the web (HTTP). There is an ssh-server process running on, for example, rona listening on port 22 for connection requests. On Windows the ssh command (which is actually an alias for a program called PuTTY) is an ssh-client. When you run it as ssh, the client resolves the name to an IP address, makes a TCP connection to that IP address on port 22, and from that point on follows (communicates using) the SSH protocol with the server process to carry out your shell commands.

So, you already have an ssh client installed on your machine (PuTTY). You just need to pull up a Windows shell and start up the ssh client with


The "Remote Desktop Protocol" is sort of like the Windows equivalent of ssh, except that you a full desktop on the remote machine instead of just a shell. It uses TCP on port 3389. In this class, we won't do this from one Windows host to another, but we will be doing this from a Unix host to a Windows host using the Unix tool rdesktop, but (of course) there are RDP clients for Windows. Just like HTTP, DNS and SSH, this is a client/server system. The Windows host you want to rdesktop into must have an RDP server process listening to port 3389 waiting for connection requests from remote desktop clients.


Secure File Transfer Protocol (SFTP) offers secure file transfer. You've already used WindSCP, which is an SFTP client, to transfer web content over to rona. SFTP uses TCP port 22 ... just like SSH. That's because SFTP is actually and extension of SSH. So the "secure" in SFTP comes from the fact that traffic is encrypted, so folks can't snoop in


Connecting to and using a network is effortless for even beginner computer users. Right now, you are using a network to access this page, but you probably did not concern yourself with configuring your IP settings and DNS server address. That is because it was automatically done for you by a service called DHCP (Dynamic Host Configuration Protocol) provided by the network. Your computer is already configured to use DHCP, so when you plug in the Ethernet cable (or connect to a wireless network), your computer broadcasts a request for an IP address. The DHCP server replies with an IP address and other necessary IP settings, which we will discuss in the next lecture. For networks without the DHCP service, users must obtain their IP settings from the network administrator and manually configure their computers.

A broadcast is a special message that is sent to all hosts on the same network. It is the similar to a live news cast on television, where everyone tuned into the same channel is simultaneously watching the same presentation.


The SMB (Server Message Block) protocol, is an application layer protocol used for network file sharing. There are two popular implementations of the SMB protocol: Microsoft SMB and Samba. Windows systems use Microsoft SMB to share files over the network, which is what most people are familiar with. Unix systems use Samba primarily to use resources shared using the Microsoft SMB protocol. Both versions are based on the original SMB protocol and are compatible with one another. SMB servers usually listen on port 445.

Other Services/Protocols

Important! It's really important to come to the following understanding:
Each network service a host provides corresponds to a process sitting and listening for requests at a specific TCP or UDP port.
Each of these processes is a "server". Each is a positive thing in the sense that they're providing (hopefully!) useful services to the outside network, but each is a negative thing in the sense that each represents a potential aveneue into the host for attackers. These are programs reading input from the outside network. They are expecting input that follows the rule of whichever protocol the service uses. But what happens when input doesn't follow the rules? We know how hard it is to write programs that deal gracefully with all possible inputs!

Summarizing it all

The following table summarizes all of this service/protocol/port/tool information. You need to be able to match up the service to protocol name to standard tool for each table entry. Why, because these are all so fundamental. For associated ports you only need to memorize those listed to the right of the table.

"ping", check if node is alive ICMP --* -- ping
World Wide Web HTTP 80 TCP browsers
Secure Web HTTPS 443 SSL/TLS browsers
Name Resolution DNS 53 UDP nslookup
Secure Remote Shell SSH 22 TCP ssh (PuTTY)
Remote Desktop (Windows) RDP 3389 TCP rdesktop (a Unix tool)
Secure Remote File Transfer SFTP 22** TCP WinSCP
Dynamic Host Configuration*** DHCP 67/68**** UDP builtin Windows DHCP client, dhclient
Network file & printer sharing SMB 445 TCP the file browser's "map network drive"
* Ping doesn't use the transport layer, so there's no associated port
** Same port as SSH because it actually uses SSH
*** Port 67 is for the server, 68 is for the client
**** Means you can join a netword "on the fly" and get assigned an IP Address and find a DNS server
NOTE: You are expected to know this table, except that the only port numbers we will expect you to memorize are
  • port 80 for HTTP
  • port 443 for HTTPS
  • port 22 for SSH
  • port 53 for DNS