Notes on securing small networks (2007)

It is time for us to configure our home network, and the machines that support our digital life. We need to do this as the children leave home, we use more Macintoshes, and Windows becomes less important in our personal and profession lives. Also, our video and audio lives are progressing farther from the traditonal TV (we use none) and stereo systems, and into housewide and even worldwide media distribution.

This effort includes a reassessment of some of the connectivity and security assumptions and tools, and the way we live our digital lives.

Windows access to the master Unix system

We have used samba on our master file server to offer access to Windows machines on an internal network. I don't trust samba to general Internet access: it is too big and full-featured, and not sandboxed. Also, we'd like access to most of the files on the server, so chroot would not be useful.

The safest access is something based on ssh, since we already have our security eggs in the ssh basket. A failure there is a common-mode failure for our whole setup. sshfs would be nice, but there doesn't seem to be a Windows implementation.

WINSCP seems to be a suitably safe answer. Of course, it doesn't supply connectivity at the file system level. One can't run an editor on remote files from the Window system, nor have iTunes play stuff directly off the remote system. Things have to be dragged onto the local system. (BTW, dragging is broken at this time on 64-bit machines for the latest version of WINSCP, 4.0.5. Seems to work fine at the older 3.8.x level). WINSCP is not bad for occasional use, and I think we are going to use this. A Windows user can still fire up X and ssh to the server, editing that way, and that also works for Macs and Unicies.

NFS would be a possibility. I mistrust the server end of NFS for public access, though that fear might be a bit dated. Certainly NFS v4 is a big improvement, but not available of FreeBSD last I heard. NFS is available for Windows Professional, but not Windows Home. Also, it brings UID matching issues, which I don't need. AFS needs NFS.

Summary of needed services and their security

ServiceNetwork serviceSafe?
Mail storage and access IMAP4 No (OK if limited to authorized clients)
SMTP Yes
File sharing ssh Yes
NFS No
CVS master ssh Yes
X10 - Yes (hardwired RS232 access
Home TTS - Yes (audio output only)
Home STT - Yes (audio input only)
web video monitoring - Yes (protected web service)
safe backup ssh/rsync Yes
VPN IP/SEC Yes
IPv6 V4/V6 gateway Yes

Host requirements

The crown jewels are the family files. They must survive deletion or modification attacks. Unauthorized read access is serious, but somewhat less than file loss.

Fewer machines are better than many: maintenance and power minimized.

Dangerous services must be isolated by effective sandboxes, or placed in separate machines. Their compromise must not threaten the family files.

All family files must be backed up on a separate machine with minimum functionality, other than backup. That machine should be on site. A second complete backup is needed offsite.

Support file systems (/, /var, /usr) are dumped and mirrored weekly. Mirroring may be to another partition on the same machine. At least one copy of the latest backup dumps must be stored off-machine.

Archive copies of dumps should be kept weekly for a month, monthly for a year, and yearly forever.

Active family file directories (not the photos and music) need daily incremental dump or mirroring to recover from fat-fingering. Another copy should be off-machine.

Access schemes

All remote terminal and file access is through ssh, if possible.

IMAP4 access is through IMAPS, and client certificates are required and matched. Client certificates should be protected with a strong pass-phrase on the client.

Alternate IMAP access is permitted through appropriate VPNs. Again, VPN clients must present a known client certificate, protected by a pass-phrase in case of client loss.

Routine accesses should be logged and reviewed daily, if only briefly.