As it currently stands, tinyfs is
currently open to the world (which is to say, it has no access
control with regard to which machines can connect to the
service). We shall now use TCP-Wrappers to
protect tinyfs, and then look at how
TCP-Wrappers can be used to protect other
services that use libwrap, such as
sshd.
tcpd is a program that is used as an
access-control wrapper to protect services started from
inetd. It grants access based on on two files:
/etc/hosts.allow and
/etc/hosts.deny.
If you were to look at the manual page for tcpd, you might find the following description.
There are two possible modes of operation: execution of
tcpd before a service started by
inetd, or linking a daemon with the
| ||
| --tcpd(8) | ||
TCP-Wrappers will test
/etc/hosts.allow first, and if a match is
found, it will allow the connection. Otherwise, it will test
/etc/hosts.deny, and if a match is found, it
will drop the connection. Otherwise, it will allow the connection,
so if you want to use TCP-Wrappers, you generally always want to
ensure that a suitable deny-by-default rule is in place in
hosts.deny.
Procedure 2. Using TCPd to Protect TinyFS
Start by putting the deny-by-default entry in
/etc/hosts.deny:
… ALL:ALL
Put in place a suitable rule, or set of rules, to allow
the traffic you want. These rules go into
/etc/hosts.allow:
… tinyfs: 127.0.0.1 [::1] 192.168.1.0/24 [fd6b:4104:35ce::]/64
The policy we have put in place here is that the server can access itself (via loopback), and our regular client ranges can access tinyfs also. Note that we haven’t included the Link-Local Addresses, as these should not generally be used for applications.
Note it is useful to pause here, and write down exactly what has effectively been denied entry, based on your testing cases in the previous section.
At this stage, hosts.allow and
hosts.deny will not be consulted, because
inetd has not yet been instructed to use
tcpd. It is tcpd that
checks these files, and if it allows the connection, it will
pass execution (via the exec system call)
to tinyfs. To do this, we change the lines
regarding tinyfs in
inetd.conf to the following:
tinyfs stream tcp4 nowait nobody /usr/sbin/tcpd /usr/local/sbin/tinyfs tinyfs stream tcp6 nowait nobody /usr/sbin/tcpd /usr/local/sbin/tinyfs
Reload inetd to affect the changes
you made in inetd.conf. Check the system
logs to ensure there were no problems, and that you can see
the service with an appropriate invocation of
lsof.
Use nc (or telnet,
which is also useful for this sort of thing) as we have done
previously to connect to the service. Test all cases
that should be allowed. Also test other cases that
should be denied (such as the Link-Local Addresses).
You should use nc on Client1 to try
the case of ip6-server1. Take a
screenshot showing the system logs (in
/var/log/syslog) reporting the actions
taken.
Services can also be protected using
libwrap, but we’ll cover those issues when we
come across the particular services, such as
SSH.
Do not deceive yourself into thinking that tinyfs is ready for production use. There are many features that are still lacking, such as accounting, filtering (eg. sharing only part of the filesystem), authentication (ie. who), access control (ie. who can do what) and privacy (encrypting traffic).