In this lesson we will learn about some of the basic tools and
services/protocols.
ping
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 10.1.83.17
PING 10.1.83.17 (10.1.83.17) 56(84) bytes of data.
64 bytes from 10.1.83.17: icmp_seq=1 ttl=255 time=0.269 ms
64 bytes from 10.1.83.17: icmp_seq=2 ttl=255 time=0.363 ms
64 bytes from 10.1.83.17: icmp_seq=3 ttl=255 time=0.229 ms
64 bytes from 10.1.83.17: icmp_seq=4 ttl=255 time=0.243 ms
^C
--- 10.1.83.17 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 131.122.88.244
PING 131.122.88.244 (131.122.88.244) 56(84) bytes of data.
From 131.122.90.156 icmp_seq=1 Destination Host Unreachable
From 131.122.90.156 icmp_seq=2 Destination Host Unreachable
From 131.122.90.156 icmp_seq=3 Destination Host Unreachable
From 131.122.90.156 icmp_seq=4 Destination Host Unreachable
From 131.122.90.156 icmp_seq=5 Destination Host Unreachable
From 131.122.90.156 icmp_seq=6 Destination Host Unreachable
^C
--- 131.122.88.244 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. 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 (DoS) 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 Layer protocols
that are built on top of the Transport Layer do.
HTTP/HTTPS
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
web server 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
Server: Apache
Connection: close
Content-Type: text/html; charset=ISO-8859-1
This shows that www.usna.edu really is running a web server.
If there isn't a web server 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
web page. The / is the path. Replace stuff like
"/images/foo.jpg" to get particular files.
Like this:
$ nc www.usna.edu 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)
You can see the difference between HTTP and HTTPS quite
clearly if you use netcat to pretend to be a web server.
So the GET request sent by a browser over HTTPS just looks
like scrambled nonsense!
DNS
We've discussed the role of DNS already. The DNS protocol is
an application layer protocol used by DNS resolvers and DNS
name servers 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 byte fields 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 hard to craft by hand.
There are two simple ways to use it:
$ nslookup alice.cs.usna.edu
Server: ns1.usna.edu
Address: 10.1.74.10#53
alice.cs.usna.edu canonical name = michrvmh01.academy.usna.edu.
Name: michrvmh01.academy.usna.edu
Address: 10.1.83.11
This tells us that alice's address is 10.1.83.11, and that it's
canonical name (it's one true name) is
michrvmh01.academy.usna.edu. Run this way, nslookup sends its
query request to whatever name server your system has set as its
default. If you're on the Yard, that'll probably be
ns1.usna.edu (10.1.74.10). The other way to run it is to specify the
name server to query as a second argument:
$ nslookup alice.cs.usna.edu next.usna.edu
Server: next.usna.edu
Address: 10.4.32.10#53
alice.cs.usna.edu canonical name = michrvmh01.academy.usna.edu.
Name: michrvmh01.academy.usna.edu
Address: 10.1.83.11
DNS is a complicated system, with millions of servers spread
out across the earth. Suppose you query your local name server
for www.foo.com. The general scheme works like this:
There are 13 root name servers. If your name server
doesn't know the IP address of www.foo.com, it sends a query
to one of the 13 root name servers. If that server doesn't know
the answer, it at least is able to send you to a name server
that knows about all the .com domains. This .com name server
will send you to the name server for the foo.com domain, and
that name server 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, name servers 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
be fast.
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.
SSH
There are SSH clients for Windows, for example
PuTTY,
which is freely available.
ssh username@hostname, e.g. ssh m179999@flux.academy.usna.edu.
You'll be prompted for a password, and assuming you give the
right one, you have a shell on the remote machine
(flux.academy.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
as ssh rona.academy.usna.edu,
the client resolves the name rona.academy.usna.edu
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
ssh m17xxxx@server.usna.edu
RDP
The "Remote Desktop Protocol" is sort of like the Windows
equivalent of ssh, except that you get 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.
SFTP
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 an extension of SSH. So the "secure" in SFTP comes
from the fact that traffic is encrypted, so an eavesdropper can't snoop in.
DHCP
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.
SMB
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.
SMTP
SMTP (Simple Mail Transfer Protocol) is an application layer protocol
for transporting 'mail' over the Internet. An SMTP client is responsible
for transferring electronic mail (email) messages to one or more SMTP
servers (or reporting failure to do so). Message transfer can occur in
a single connection between the original SMTP-sender and the final
SMTP-recipient, or can occur in a series of hops through intermediary systems.
DNS is used to identify hosts that act as SMTP servers (or relays).
Other Services/Protocols
- FTP (21) - File Transfer Protocol for non-secure transfer of files
(pre-dates SFTP, circa 1971)
- TELNET (23) - provides a non-secure
bi-directional ASCII-text communication connection to a remote host
(pre-dates SSH, circa 1969, i.e., the very early days of the Internet).
- WHOIS (43) - used by system administrators to get contact
information for IP address assignments or domain name
administrators.
- IMAP (143) - Internet Message Access Protocol, for e-mail
clients to manage e-mail held on servers
- IRC (6667) - Internet Relay Chat, real-time chat. Proposed in 1988,
still being used by approx a half-million users and thousands of IRC servers,
at any given time
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 avenue 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.
| Service | Protocol | Port | TCP/UDP | Tools |
|---|
| "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" |
| email |
SMTP |
25 |
TCP |
any email client, e.g.: gmail |
* 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 network "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
|