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
VM, as we have provided some resources for you to use that means they will not
work the same elsewhere.
Which networked services are already running?
Connect to your VM using SSH, and then run sudo netstat -plunt 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:111 0.0.0.0:* LISTEN 15337/rpcbind
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 9242/sshd
tcp6 0 0 :::111 :::* LISTEN 15337/rpcbind
tcp6 0 0 :::22 :::* LISTEN 9242/sshd
udp 0 0 0.0.0.0:111 0.0.0.0:* 15337/rpcbind
udp 0 0 0.0.0.0:673 0.0.0.0:* 15337/rpcbind
udp 0 0 0.0.0.0:68 0.0.0.0:* 28659/dhclient
udp6 0 0 :::111 :::* 15337/rpcbind
udp6 0 0 :::673 :::* 15337/rpcbind
udp6 0 0 fe80::6a:26ff:fe35::546 :::* 28671/dhclient
Why are there so many services already running? We haven’t even 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 two services are a bit more mysterious. Let’s check them
out!
Note: If you’ve done lab 6 already, you might have some other services running
here, like Apache, but we’ll skip that for this lab.
$ man dhclient
The Internet Systems Consortium DHCP Client, dhclient, provides a means for
configuring one or more network interfaces using the Dynamic Host Configuration
Protocol, BOOTP protocol, or if these protocols fail, by statically assigning
an address.
The DHCP protocol allows a host to contact a central server which maintains a
list of IP addresses which may be assigned on one or more subnets. A DHCP
client may request an address from this pool, and then use it on a temporary
basis for communication on network. The DHCP protocol also provides a mechanism
whereby a client can learn important details about the net‐work to which it is
attached, such as the location of a default router, the location of a name
server, and so on.
Alright, so it looks like dhclient is used for DHCP (described in more detail
in lab 5). Cool! What about the
rpcbind service?
$ man rpcbind
The rpcbind utility is a server that converts RPC program numbers into
universal addresses. It must be running on the host to be able to make RPC
calls on a server on that machine.
When an RPC service is started, it tells rpcbind the address at which it is
listening, and the RPC program numbers it is prepared to serve. When a client
wishes to make an RPC call to a given program number, it first contacts rpcbind
on the server machine to determine the address where RPC requests should be
sent.
Huh, so it looks like this is some kind of service that maps “RPC program
numbers” to addresses, whatever that means. Well, the manpage isn’t quite as
helpful on this one, so let’s look it up online! (This Unix stack exchange
post is pretty helpful) Alright,
looks like it’s some kind of service that can map some predefined protocol
numbers for common protocols like NFS and then map that to a port they are
running on. Try running sudo rpcinfo to see what the mapping is on your VM.
You should see that the only service available is one named portmapper, which
is the RPC service itself. Well, makes sense since there’s not much else that’s
running currently.
/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, dhclient is
listening on ports 68 and 546 (on IPv6). 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 two ports dhclient is
using:
bootpc 68/tcp # BOOTP client
bootpc 68/udp
[...]
dhcpv6-client 546/tcp
dhcpv6-client 546/udp
This helps make it clearer that whatever dhclient is, it probably uses the
BOOTP protocol and is a DHCPv6 client. Keep in mind that for higher numbered
ports (above 1024), that they can be used by any service and even for lowered
numbered ports, they can be used by a service that doesn’t correspond in
/etc/services, but /etc/services is a good first place to check to see what
protocols might be used by a service.
Questions
NFS
We have provided a NFS server for you to connect to at staff with two
different file locations, one read-only and one read-write. If you use the
mount command and run sudo mount staff:/opt/lab7/public /opt/lab7/read-only
and then use cd to go to the /opt/lab7/read-only directory, you should see
a file with a secret inside it. 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 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 run sudo umount /opt/lab7/read-only. 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.
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 so that computers know how to send information over the
network to servers. A more thorough description of this is in Lab 5 if
you’d like a refresher or want more information.
The bind9 package has already been installed on your VM, but 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 (and in general
this is how 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 systemctl. 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 /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). 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 google.example.com. Please add
couple more subdomains of your choice. Try to add one A record and one CNAME
(alias) record. Make sure to restart 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
google.example.com you should see 216.58.195.238 as the result. Also make
sure to test the subdomains you added and make sure they work!
$ dig NS example.com @localhost
$ dig A example.com @localhost
$ dig A google.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.
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 example.com:8000 and you should
see the service you set up in lab 6. Also try navigating to
google.example.com. Why do you think that this causes an error and does not
display a familiar Google homepage as you have seen before?
Also note that your DNS server is set up to only accept recursive queries from
within Berkeley networks, so if you try to use it off-campus somewhere, you
will only be able to query for the domains you specifically added. This is
because open relays are a security problem
that can be abused by attackers, so we’ve restricted your DNS servers to only
accept queries from specific IP ranges that are more likely to be safe.