File Serving Security Concerns

Serving files is an extremely important function for many Linux systems. Both file-transfer servers and file sharing servers are very popular and play vital roles on many networks. Unfortunately, these server types necessarily give clients fairly broad access to your server computer. The ability to read and, often, write arbitrary files, even within a limited set of directories, can be abused if your configuration is sloppy or if the server contains a bug. For this reason, you should be very cautious when configuring your file server.

Whenever possible, apply multiple layers of protections based on hostnames and IP addresses. You can use packet-filter firewalls, TCP Wrappers, xinetd, or server-based restrictions. Chapter 20 describes most of these techniques. The idea is to limit access to the server to individuals who have legitimate reasons to interact with it. Thinking out these restrictions is particularly important in the case of NFS servers, which have no other access-control tools. Of course, some servers, such as anonymous FTP servers on the Internet as a whole, shouldn't be restricted in this way. Their exposure is part of the risk of running such servers.

You should always be very cautious about what directories you make available through file servers. You should never share critical directories such as /etc through a file server. Even read-only access to such a directory could be risky. If miscreants can read your configuration files, they can better plan an attack against you based on problems they might find in your configurations, even of servers other than the file server. Limit users to read-only access whenever possible. By its nature, FTP normally gives users access to any directory on the computer, within limits imposed by normal Linux ownership and permissions rules. Most FTP servers use chroot jails to limit this access for anonymous users, but such limits for authenticated user logins are rarer. You may want to use a server, such as vsftpd, that can lock users into chroot jails in their own home directories. Of course, if users can log in through other means, they may be able to use those logins to do damage, as well, so using chroot jails for ordinary users may be pointless.

FTP sends passwords in unencrypted form over the network, which can be a huge security risk for authenticated user logins. For this reason, I recommend limiting authenticated FTP access to your local network. You may want to consider eliminating the FTP server altogether and instead using secure protocols. For instance, the Secure Shell (SSH), described in Chapter 26, "Providing Remote Login Access," provides encrypted file-transfer tools. Specifically, the scp client can copy files between a client computer and a server running SSH. A handful of FTP client programs, such as gFTP (http://gftp.seul.org), can connect to an SSH server and perform transfers just as they would using an FTP server. An SSH client known as sftp also provides FTP-like access via SSH. If you can use such clients, SSH makes a superior replacement for FTP.

Although most Windows networks now use encrypted passwords for SMB/CIFS transfers, nonpassword data pass over these networks in unencrypted form. As such traffic is usually local and passwords are usually encrypted, the security risks are lower than they are with FTP or Internet transfers, but nonetheless you should exercise diligence with Samba passwords and encryption.

Team LIB

1 previous

0 0

Post a comment