Network Security Hacks [Electronic resources] نسخه متنی

Hack 53 Share Files Securely in Unix

Use SFS to help secure your remote
filesystems.

If you are using Unix systems and
sharing files on your network, you are most likely using

NFS. However, there are a lot of
security problems, not only with individual implementations, but also
with the design of the protocol itself. For instance, if a user can
spoof an IP address and mount an NFS share that is only meant for a
certain computer, she essentially has root access to all the files on
that share. In addition, NFS employs secret file handles that are
used with each file request. Since NFS does not encrypt its traffic,
this makes it very easy for attackers to guess these file handles. If
they guess correctly, they essentially get total root access to the
remote filesystem.

SFS (http://www.fs.net), the
Self-certifying
File System, fixes
all of these problems by employing a drastically different design
philosophy. NFS was created with the notion that you can (and should)
trust your network. SFS has been designed from the beginning with the
idea that no network should ever be trusted until it can definitively
prove its identity. To accomplish this, SFS makes use of public keys
on both the client and server ends. It uses these keys to verify the
identity of servers and clients, and also provides access control on
the server side. One particularly
nice side effect of such strong encryption is that SFS provides a
much finer grained level of access control than NFS. With NFS, you
are limited to specifying which hosts can or cannot connect to a
given exported filesystem. In order to access an SFS server, a user
must create a key pair and then authorizes the key by logging into
the SFS server and registering the key manually.

Building SFS can take up quite a lot of disk space. Before you
attempt to build SFS, make sure you have at least 550MB of disk space
available on the filesystem on which you''ll be
compiling SFS. You will also need to make sure that you have


GMP
(http://www.swox.com/gmp/), the
GNU multiple precision math library, installed. Before you begin to
build SFS, you will also need to create a user and group for
SFS''s daemons. By default, these are both called
sfs. If you want to use a different user or group,
you can do this by passing options to the configure script.

Once your system is ready, you can build SFS by simply typing this
command:

$ ./configure && make

Once that process is finished, become root and type make
install.

If you want to use a user and group other than
sfs, you can specify these with the
--with-sfsuser and
--with-sfsgroup options:

$ ./configure --with-sfsuser=nobody --with-sfsgroup=nobody

Building SFS can take quite a bit of time, so you may want to take
the opportunity to enjoy a cup of coffee, a snack, or maybe even a
full meal, depending on the speed of your machine and the amount of
memory it has.

After SFS has finished building and you have installed it, you can
test it out by connecting to the SFS project''s
public server. You can do this by starting the SFS client daemon,
sfscd, and then changing to the directory
that the SFS server will be mounted under:

# sfscd
# cd /sfs/@sfs.fs.net,uzwadtctbjb3dg596waiyru8cx5kb4an
# ls
CONGRATULATIONS  cvs  pi0  reddy  sfswww
# cat CONGRATULATIONS
You have set up a working SFS client.
#

sfscd automatically creates the
/sfs directory and the directory for the SFS
server. Note that SFS relies on the operating
system''s portmap daemon and NFS mounter;
you''ll need to have those running before running the
client.

To set up an SFS server, first log into your server and generate a
public and private key pair:

# mkdir /etc/sfs
# sfskey gen -P /etc/sfs/sfs_host_key

sfskey will then ask you to bang on the keys for
a little while in order to gather entropy for the random number
generator.

Now you will need to create a configuration file for
sfssd, the SFS server daemon. To do this, create
a file in /etc/sfs called
sfsrwsd_config, which is where you configure the
filesystem namespace that SFS will export to other hosts.

If you wanted to export the /home filesystem,
you would create a configuration file like this:

Export /var/sfs/root /
Export /home /home

Then you would need to create the /var/sfs/root
and /var/sfs/home directories. After that, you
would create NFS exports so that the /home
filesystem could be mounted under
/var/sfs/root/home. These are then reexported by
sfssd. The NFS exports need only to allow
mounting from localhost.

Here''s what /etc/exports looks
like for exporting /home:

/var/sfs/root    localhost(rw)
/home        localhost(rw)

This exports file is for Linux. If you are
running the SFS server on another operating system (such as Solaris
or OpenBSD), consult your operating system''s
mountd manpage for the proper way to add these
shares.

Now start your operating system''s NFS server. Once
NFS has started, you can then start sfssd. After
attempting to connect to the sfssd server, you
should see some messages in your logs like these:

Dec 12 12:29:14 colossus : sfssd: version 0.7.2, pid 3503
Dec 12 12:29:14 colossus : rexd: version 0.7.2, pid 3505
Dec 12 12:29:14 colossus : sfsauthd: version 0.7.2, pid 3506
Dec 12 12:29:14 colossus : rexd: serving @colossus.nnc,fd82m36
uwxj6m3q8tawp56ztgsvu7g77
Dec 12 12:29:14 colossus : rexd: spawning /usr/local/lib/sfs-0.7.2/ptyd
Dec 12 12:29:15 colossus rpc.mountd: authenticated mount request from 
localhost.localdomain:715 for /var/sfs/root (/var/sfs/root) 
Dec 12 12:29:15 colossus rpc.mountd: authenticated mount request from 
localhost.localdomain:715 for /home (/home) 
Dec 12 12:29:15 colossus : sfsauthd: serving 
@colossus.nnc,fd82m36uwxj6m3q8tawp56ztgsvu7g77
Dec 12 12:29:16 colossus : sfsrwsd: version 0.7.2, pid 3507
Dec 12 12:29:16 colossus : sfsrwsd: serving 
/sfs/@colossus.nnc,fd82m36uwxj6m3q8tawp56ztgsvu7g77

The last log entry shows the path that users can use to mount your
filesystem. Before mounting any filesystems on your server, users
will have to create a key pair and register it with your server. They
can do this by logging into your server and running the
sfskey command:

$ sfskey register
sfskey: /home/andrew/.sfs/random_seed: No such file or directory
sfskey: creating directory /home/andrew/.sfs
sfskey: creating directory /home/andrew/.sfs/authkeys
/var/sfs/sockets/agent.sock: No such file or directory
sfskey: sfscd not running, limiting sources of entropy
Creating new key: andrew@colossus.nnc#1 (Rabin)
Key Label: andrew@colossus.nnc#1
Enter passphrase: 
Again: 
sfskey needs secret bits with which to seed the random number generator.
Please type some random or unguessable text until you hear a beep:
DONE            
UNIX password: 
colossus.nnc: New SRP key: andrew@colossus.nnc/1024
wrote key: /home/andrew/.sfs/authkeys/andrew@colossus.nnc#1

Alternatively, if you already have an existing key pair on another
server, you can type sfskey
user@otherserver
instead. This will retrieve the key from the remote machine and
register it with the server you are currently logged into.

Now that you have registered a key with the server, you can log into
the SFS server from another machine. This is also done with the
sfskey program:

$ sfskey login andrew@colossus.nnc
Passphrase for andrew@colossus.nnc/1024: 
SFS Login as andrew@colossus.nnc

Now try to access the remote server:

$ cd /sfs/@colossus.nnc,fd82m36uwxj6m3q8tawp56ztgsvu7g77
$ ls
home

As you can see, SFS is a very powerful tool for sharing files across
a network, and even across the Internet. Not only does it provide
security, but it also provides a unique and universal method for
referencing a remote host and its exported filesystems. You can even
put your home directory on an SFS server, simply by linking the
universal pathname of the exported filesystem
/home.