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 131.122.88.7
PING 131.122.88.7 (131.122.88.7) 56(84) bytes of data.
64 bytes from 131.122.88.7: icmp_seq=1 ttl=255 time=0.269 ms
64 bytes from 131.122.88.7: icmp_seq=2 ttl=255 time=0.363 ms
64 bytes from 131.122.88.7: icmp_seq=3 ttl=255 time=0.229 ms
64 bytes from 131.122.88.7: icmp_seq=4 ttl=255 time=0.243 ms
^C
--- 131.122.88.7 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 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/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
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
Server: Apache
Connection: close
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.
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 webserver.
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
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 ginger.cs.usna.edu
Server: 131.122.88.2
Address: 131.122.88.2#53
ginger.cs.usna.edu canonical name = mich316csd05d.cs.usna.edu.
Name: mich316csd05d.cs.usna.edu
Address: 131.122.89.155
This tells us that ginger's address is 131.122.89.155, 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
Server: ns1.usna.edu
Address: 131.122.220.1#53
ginger.cs.usna.edu canonical name = mich316csd05d.cs.usna.edu.
Name: mich316csd05d.cs.usna.edu
Address: 131.122.89.155
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
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 m159999@mint.cs.usna.edu.
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
as ssh rona.cs.usna.edu,
the client resolves the name rona.cs.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.exe m15xxxx@server.usna.edu
RDP
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.
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 and extension of SSH. So the "secure" in SFTP comes
from the fact that traffic is encrypted, so folks 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.
Other Services/Protocols
- 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
administrators.
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.
| 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" |
* 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
|