Lecture 13

Announcements

Don't telnet to a grove account then ssh in as root to your machine. All keystrokes on your telnet session can be snarfed by someone (and have been). Make your first link the most secure link!
If you *ever* telnet to your machine as root from anywhere, get a hard line to the machine and then change your root password.

Daemons

inetd handles starting up servers for specific tasks associated with requests from the network such as ftp, finger, etc. Configuration appears in the file /etc/inetd.conf
named provides name service (translates internet machine names into IP addresses and vice versa). Replaces the static routing capability achieved with the /etc/hosts file.
routed, gated provide routine information to let you figure out where to transfer data for nonlocal hosts.
timed makes sure systems clocks on a network are synchronized.
rwhod broadcasts information to other hosts on the network telling sho is logged in, how long the systems, been up, etc.

Disabling faulty daemons

This is achieved by commenting or removing the appropriate lines out of whichever file spawns the daemon (inittab, /etc/rc.??, and so forth).

Services that must be removed are telnet, rexd, rsh, rlogin, rcp. Ftp *should* be removed as well. Why?

Tcpwrappers is a program that lets you decide who can get which services.

TCP Wrappers (pg. 625 in Frisch)

TCP Wrappers (available from the CIAC and from the Bull freeware site) is a freely-available facility to provide better control over inetd controlled programs.

You change inetd.conf lines from something like this:

#service socket  protocol wait?  user    program                arguments
ftp      stream  tcp6    nowait  root    /usr/sbin/ftpd         ftpd
telnet   stream  tcp6    nowait  root    /usr/sbin/telnetd      telnetd -a

To something more like this:

#service socket  protocol wait?  user    program                arguments
ftp      stream  tcp6    nowait  root    /usr/local/tcpd        ftpd
telnet   stream  tcp6    nowait  root    /usr/local/tcpd        telnetd -a

Then, rather than inet execing a process directly, it will exec the process tcpd with the appropriate argument (which is the daemon to run). If the daemon is named by a relative path, tcpd looks for the daemon in a specific location compiled into it (usually /usr/sbin).

The special thing tcpd does is that it consults two files to determine

whether or not to allow the access to the requesting host
what other actions (like logging attempted access) to take

These functions are accomplished by configurations specified in the files hosts.allow and hosts.deny.

Before execing a daemon, tcpd determines if it's allowed to as follows:

If /etc/hosts.allow authorizes the services, it is accepted.
Otherwise, if /etc/hosts.deny denies the service, the request is denied.
Otherwise, the service is allowed.

This may seem strange, but the convention is as follows:

Put any service you want to generally deny in /etc/hosts.deny.
Put any override to denail in /etc/hosts.allow.

The entries in the hosts.allow and hosts.deny files look like the following:

From hosts.allow:

telnetd         : LOCAL
ftpd            : .cise.ufl.edu
fingerd         : elgin

This means that telnetd is allowed to be connected to from any machine on the local network. The ftp daemon can be reached from any host in the domain cise.ufl.edu. An fingerd is accessible only from the machine elgin.

From hosts.deny:

ALL             : ALL

tftpd           :  ALL : (/usr/sbin/safe_finger -l @%h | \
                          /usr/bin/mail -s %d-%h root) &

The first example should be your starting point (deny all services to anyone). On the other hand, you can deny a particular service and even associate an action to perform if an attempt to connect to that service is made. The tftpd example shows you you can use safe_finger to try to determine who initiated the connection, then mail the results to root. Using system logging is another appropriate mechanism to report such connections.

Adding a New Host

Steps required:

Install network software.
Physically connect the hardware. Make sure you use the right interface and it is enabled.
Assign a hostname and network address to the system, or determine a method by which a hostname will be diwscovered.
Decide on name service and routing strategies.
Make sure the network interface is configured and the network daemons start at boottime.
Reboot the system and test the network connection (with ping, for example).

Network interfaces are usually configured with ifconfig. You must generally specify the interface name, protocol, IP address, netmask, and broadcast address.

Name Service Options

The easiest kind of name resolution to do is to use static name resolution. Using this method, a special file (/etc/hosts contains the IP Address to Name correspondence for the local network. Here's an example

127.0.0.1       loopback localhost
128.227.170.68  titan
128.227.170.69  timex
128.227.170.70  cartier
128.227.170.71  omega
128.227.170.72  nikewatch
128.227.170.73  olympian
128.227.170.74  starck-uhren
128.227.170.75  gshock
128.227.170.76  zenith
128.227.170.77  swatch
128.227.170.78  seagull
128.227.170.79  casio
128.227.170.80  movado
128.227.170.81  gucci
128.227.170.82  citizen

128.227.170.83  elgin  elgin.unix-ippd.cise.ufl.edu

More complex (but robust) is the use of named. Frisch skirts around the issues associated with named saying, in effect, ``Buy the Book.'' The book I used was DNS and BIND by Paul Albitz and Cricket Liu. Even with the book in hand, the first time I tried to use DNS, I made some mistakes (surprise).