In this lesson we will learn about some of the basic tools and
One of the most fundamental questions you might ask involving IP
networking is this: is there a host at a given IP address? The
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:
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. espn.com 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.
$ ping 126.96.36.199
PING 188.8.131.52 (184.108.40.206) 56(84) bytes of data.
64 bytes from 220.127.116.11: icmp_seq=1 ttl=255 time=0.269 ms
64 bytes from 18.104.22.168: icmp_seq=2 ttl=255 time=0.363 ms
64 bytes from 22.214.171.124: icmp_seq=3 ttl=255 time=0.229 ms
64 bytes from 126.96.36.199: icmp_seq=4 ttl=255 time=0.243 ms
--- 188.8.131.52 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 184.108.40.206
PING 220.127.116.11 (18.104.22.168) 56(84) bytes of data.
From 22.214.171.124 icmp_seq=1 Destination Host Unreachable
From 126.96.36.199 icmp_seq=2 Destination Host Unreachable
From 188.8.131.52 icmp_seq=3 Destination Host Unreachable
From 184.108.40.206 icmp_seq=4 Destination Host Unreachable
From 220.127.116.11 icmp_seq=5 Destination Host Unreachable
From 18.104.22.168 icmp_seq=6 Destination Host Unreachable
--- 22.214.171.124 ping statistics ---
7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6032ms
, pipe 3
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 www.usna.edu 80
HEAD / HTTP/1.0
← NOTE: you need this blank line!
HTTP/1.1 200 OK
Date: Mon, 11 Jul 2011 17:38:14 GMT
Content-Type: text/html; charset=ISO-8859-1
This shows that www.usna.edu 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 ns1.usna.edu 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.
$ nc www.usna.edu 80
GET /Users/cs/wcbrown/index.html HTTP/1.0
← NOTE: you need this blank line!
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
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
TLS (Transport Layer Security) is a newer version of the
protocol known as SSL (Secure Sockets Layer).
... BUT how secure is it???
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
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 ginger.cs.usna.edu
ginger.cs.usna.edu canonical name = mich316csd05d.cs.usna.edu.
This tells us that ginger's address is 126.96.36.199, and that it's
canonical name (it's one true name) is
mich316csd05d.cs.usna.edu. 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
macallan.cs.usna.edu. The other way to run it is to specify the
nameserver to query as a second argument:
$ nslookup ginger.cs.usna.edu ns1.usna.edu
ginger.cs.usna.edu canonical name = mich316csd05d.cs.usna.edu.
DNS is a complicated system, with millions of servers spread
out across the earth. Suppose you query your local nameserver
for www.foo.com. The general scheme works like this:
There are 13 root nameservers. If your name server
doesn't know the IP address of www.foo.com, 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 foo.com domain, and
that nameserver ought to be able to give the IP address for
www.foo.com. 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 google.com's IP
address it might take a while. But subsequent requests will
It must be emphasized that from a security perspective it's
crucial that DNS works properly. If the name
bankwithallmymoney.com 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
bankwithallmymoney.com's, but which isn't and he could perhaps
steal my password ... and then my money.
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:
There are SSH clients for Windows, for example
which is freely available.
ssh username@hostname, e.g.
You'll be prompted for a password, and assuming you give the
right one, you have a shell on the remote machine
(mint.cs.usna.edu 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
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
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
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
It's really important to come to the following understanding:
- SMTP - Simple Mail Transfer Protocol, for sending e-mails.
- IMAP - Internet Message Access Protocol, for e-mail
clients to manage e-mail held on servers
- IRC - Internet Relay Chat, real-time chat
- FTP - File Transfer Protocol (not secure!)
- WHOIS - used by system administrators to get contact
information for IP address assignments or domain name
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
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 doesn't use the transport layer, so there's no associated port
|"ping", check if node is alive
|World Wide Web
|Secure Remote Shell
|Remote Desktop (Windows)
||rdesktop (a Unix tool)
|Secure Remote File Transfer
|Dynamic Host Configuration***
||builtin Windows DHCP client, dhclient
|Network file & printer sharing
||the file browser's "map network drive"
** 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
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