Lab 7 - Networked Services
Overview
Networking is key to many services because it allows processes and computers to
communicate with each other. In this lab, we’ll work with a couple different
types of services and set up a service of your own from scratch!
Make sure, as always, that you are doing all of these steps on your provided
DigitalOcean VM (available at yourusername@yourusername.decal.xcf.sh), as we
have provided some resources for you to use for this lab that are only
accessible from your student VMs.
Which networked services are already running?
Connect to your VM using SSH, and then run sudo netstat -plunt (or sudo
netstat -peanut if you’d prefer) to show the services running on your VM
already. You should see something like this:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 789/sshd
tcp6 0 0 :::22 :::* LISTEN 789/sshd
udp 0 0 10.138.132.55:123 0.0.0.0:* 792/ntpd
udp 0 0 10.46.0.38:123 0.0.0.0:* 792/ntpd
udp 0 0 159.65.76.196:123 0.0.0.0:* 792/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 792/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 792/ntpd
udp6 0 0 fe80::b0a7:c1ff:fef:123 :::* 792/ntpd
udp6 0 0 fe80::38c5:f3ff:fe0:123 :::* 792/ntpd
udp6 0 0 ::1:123 :::* 792/ntpd
udp6 0 0 :::123 :::* 792/ntpd
Why are there so many services already running? We haven’t even really done
anything yet! Well, to start off with, sshd must have been running already,
otherwise how would you have connected to the machine in the first place using
SSH? However, the other service (ntpd) is a bit more mysterious. Let’s check
it out!
Note: If you’ve done lab 6 already, you might have some other services running
here, like nginx or your toy service, but we’ll skip those for this lab.
$ man ntpd
DESCRIPTION
The ntpd program is an operating system daemon which sets and maintains the
system time of day in synchronism with Internet standard time servers. It is a
complete implementation of the Network Time Protocol (NTP) version 4, but also
retains compatibility with version 3, as defined by RFC-1305, and version 1 and
2, as defined by RFC-1059 and RFC-1119, respectively. ntpd does most
computations in 64-bit floating-point arithmetic and does relatively clumsy
64-bit fixed-point operations only when necessary to preserve the ultimate
precision, about 232 picoseconds. While the ultimate precision is not
achievable with ordinary workstations and networks of today, it may be required
with future gigahertz CPU clocks and gigabit LANs.
The last sentence of this description snippet above is pretty funny, because
gigahertz CPU clocks and gigabit LANs are both pretty common these days!
Anyway, as mentioned in the lecture and in the manpage description above, NTP
is used for time synchronization on a computer using network time servers, so
it would make sense for this to already be running to allow your VM to always
have the correct system time. This is especially important for VMs compared to
using unix on a physical system. VMs can often be quite far off in terms of
system time if NTP is not running (if they are suspended and then later resumed
for example, or if the host for the virtual machine is under heavy load).
Here’s a pretty awesome post with a list of falsehoods that
programmers believe about time, there’s a surprising number of them.
/etc/services
One tip that might help when trying to find what a service does is to look at
which port it is listening on. For instance, from above, ntpd is listening on
port 123. If you open the file /etc/services on most unix machines, you
will get a list of protocols and the ports they typically use. Here are the
lines for the port that ntpd is using:
ntp 123/tcp
ntp 123/udp # Network Time Protocol
This helps make it clearer that ntpd is most likely doing something with the
Network Time Protocol, which in this case was pretty clear, however, if you
have not seen the service before then /etc/services can be more useful. Keep
in mind that any port can be used by any service but by convention they follow
the mapping in /etc/services. Also keep in mind that for higher numbered
ports (above 1024), that they can be used by any user if a service is not
running on the port already, so this can be a security risk if you do not
properly secure these ports. That being said, most people follow convention if
possible to make their services easier to maintain, so checking /etc/services
is a good first step if trying to figure out what a specific port/service is
for.
Questions
To submit the lab, answer the questions in this Google form.
NFS
We have provided a NFS server for you to connect to at staff with two
different directories, one read-only and one read-write. First install the
nfs-common package so that you can mount directories over NFS. Then, use the
mount command (remember to look at the man pages or search online if you do
not recognize a command) to mount from staff:/opt/lab7/public (the remote
directory) to your local directory at /opt/lab7/read-only. Once you do this,
you should see a file with a secret inside it in /opt/lab7/read-only. You can
tell if you are connected or not by running df and checking if there is
something that looks like staff:/opt/lab7/public present in the list. What is
the secret in the file? If NFS takes a excessive time to mount or you cannot
read the file because it hangs while doing so, please let us know. Try creating
a file in the read-only directory (note that you will want to try with sudo,
otherwise you will get a permission denied error because root owns the
directory mounted over NFS)
If you’d like to disconnect again, make sure you are not in the directory
that has the file (otherwise it is unable to disconnect because it is still
loaded and you will get an error message like umount.nfs4:
/opt/lab7/read-only: device is busy). Then use umount to disconnect from
NFS. If you run df, you should see that the entry that was present before has
now disappeared.
Next, mount the directory at staff:/opt/lab7/private/<your username> to
/opt/lab7/read-write using mount in a similar way to before. What do you
see in /opt/lab7/read-write now? Follow the instructions in the file given
there, note that you will have to use sudo here too to create a new file
since the directory mounted over NFS is owned by root, not your user.
Again, if NFS takes an excessive time to mount during any of this or you cannot
read files because it hands while doing so, please let us know on Piazza or by
email (or at office hours if you’d prefer). We’ve had some problems in the past
with NFS being very slow to mount/read and needing a restart.
DNS
In this section we are going to be setting up our own DNS server! Remember that
DNS is the system that maps from a domain like ocf.berkeley.edu to an IP like
169.229.226.23 (and 2607:f140:8801::1:23 for IPv6) so that computers know
how to send information over the network to servers without people having to
remember a bunch of numbers to connnect to everything. A more thorough
description of this is in Lab 5 if you’d like a refresher or want
more information.
First, install the bind9 package on your VM to set up a DNS server. By
default, the service is not running yet. What is the systemctl command to
show if the bind9 service is running or not?
In the output of the systemctl command, you should see that the bind9
service is not running (yet) and has a unit file at
/lib/systemd/system/bind9.service. If you print that file, you should see
something like this:
[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target
Wants=nss-lookup.target
Before=nss-lookup.target
[Service]
EnvironmentFile=/etc/default/bind9
ExecStart=/usr/sbin/named -f $OPTIONS
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop
[Install]
WantedBy=multi-user.target
This should look pretty familiar to you by now after doing lab 6! Don’t worry
if it doesn’t all look familiar since there are some options you haven’t seen
yet in here, but you should at least recognize some of the options used.
If you now run dig ocf.berkeley.edu @localhost from your VM, you should see
that the command eventually times out after trying to run for about 15 seconds.
If you’d rather stop the command before then, just type Ctrl+C (in general this
is a good way to try to stop a command that is running longer than you want it
to).
The previous command failed because the DNS server was not started yet. Try
starting the DNS server using the relevant systemctl command. If you check
the status of the bind9 service after starting it, you should see the status
has changed to say that the service is active and running.
If you now run dig ocf.berkeley.edu @localhost from your VM, you should now
see a response containing the correct IP (169.229.226.23)!
Now to the exciting part, the configuration. Edit (using sudo since it is
owned by root) /etc/bind/named.conf.local with your favorite text editor
(nano is a good choice to start out with if you haven’t used terminal-based
text editors before, vim or emacs are good for more experienced users or if
you want more features than what nano offers). Inside this file, it should be
empty apart from a few comments at the top because you haven’t done any local
configuration yet. Add a new zone in this file for example.com with these
contents:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};
Then, create a file /etc/bind/db.example.com to contain the responses to give
if anyone sends requests to your DNS server for example.com. The easiest way
to do this is generally to copy an existing config and then make changes from
there to get what you want for your config instead of having to start from
scratch. To make this easier, we’ve provided a valid config at
/opt/lab7/db.example.com that you can copy in place at
/etc/bind/db.example.com. It is prefilled with your VM’s IP, and includes a
subdomain that does not usually exist, named test.example.com. Please add
couple more records of your choice. Try to add one A record and one other type
of record (CNAME, SRV, TXT, etc.). Make sure to reload the bind9 service
after changing anything in /etc/bind9, since you want the running service to
change its configuration.
If you now run the dig commands below, you should see that your VM’s domain
name (<username>.decal.xcf.sh) is returned for the first result, for the
second result (example.com) your VM’s IP address should be returned, and for
test.example.com you should see 93.184.216.34 as the result. Also make
sure to test the records you added and make sure they work! What commands did
you use to query for your added records?
$ dig NS example.com @localhost
$ dig A example.com @localhost
$ dig A test.example.com @localhost
Make sure to run these commands from your VM, or if you want to run them from
your laptop or from an OCF computer, substitute localhost in the commands
with your VM’s domain name (it’ll be in the format <username>.decal.xcf.sh).
Also make sure to do this from inside the Berkeley network so you don’t get
blocked by the firewall.
Once you have set up your DNS server, try changing your laptop’s settings to
use your VM as a DNS server and navigate to http://example.com:5000 and you
should see the toy service you set up in lab 6. Also try navigating to
test.example.com. What type of error do you see? Why do you think that this
causes a error and does not display the page that http://example.com normally
shows even though example.com resolves to the IP that you used
(93.184.216.34)?
Also note that your DNS server is set up to only accept queries, especially
recursive queries, from within Berkeley networks. If you try to use it
off-campus somewhere, you will not be able to make queries to your DNS server.
This is because open relays are a security
problem that can be abused by attackers, so we’ve restricted your DNS server to
only accept queries from specific IP ranges that are more likely to be safe.
Again, the form for getting this lab checked off can be found
here.