Securing servers

Revision as of 22:41, 28 September 2004

Eventually we'll need sections or subarticles on various different security contexts:

Security in a local user context

(cover common gotchas and SNAFUs concerning local security; ie preventing valid shell users from obtaining privileges they aren't supposed to have or doing damage they shouldn't be able to do. sudo is clearly a must with this one, as is some discussion of running daemons under special user accounts, and the dangers of overusing "nobody" to run daemons. a quick rundown of system files that permissions should be double-checked on, like /etc/passwd, /etc/master.passwd, /etc/group, and the databases associated with them should also be covered.)

Security in an internet context

Login banners are useful sometimes, but since you'll likely already know what system you're logging into and what you're going to be using it for, will probably be unnecessary, and any extraneous information that they give when you login will usually be worthless to you but potentially useful to an attacker. If you want to change it (or remove it,) you'll need to edit /etc/motd.

We'll want to know what ports are open and listening. If you installed IPv6 support when you installed the system, you'll want to check for IPv6 sockets as well as IPv4; become root and run sockstat with -46 as an argument; this will let you know the socket status for both IPv4 and IPv6 sockets (in this context, a socket = port + protocol):

dave@samizdata:~% su -
Password:
samizdata# sockstat -46
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
dave     sshd       12230 5  tcp4   10.10.1.208:22        10.10.1.108:4095
root     sshd       12226 5  tcp4   10.10.1.208:22        10.10.1.108:4095
root     ssh        95269 3  tcp4   10.10.1.208:49847     10.10.0.251:22
dave     sshd       92858 5  tcp4   10.10.1.208:22        10.10.1.108:2716
root     sshd       92855 5  tcp4   10.10.1.208:22        10.10.1.108:2716
root     inetd      87064 4  tcp4   *:21                  *:*
root     sendmail   59172 3  tcp4   *:25                  *:*
root     ntpd       33328 4  udp4   *:123                 *:*
root     ntpd       33328 5  udp4   10.10.1.208:123       *:*
root     ntpd       33328 6  udp4   127.0.0.1:123         *:*
root     sshd       366   3  tcp6   *:22                  *:*
root     sshd       366   4  tcp4   *:22                  *:*
root     amd        309   4  udp4   *:1023                *:*
root     amd        309   5  tcp4   *:1023                *:*
root     amd        309   6  udp4   *:1021                *:*
root     amd        309   7  udp4   *:1020                *:*
root     rpcbind    228   4  udp6   *:*                   *:*
root     rpcbind    228   6  udp6   *:111                 *:*
root     rpcbind    228   7  udp6   *:1023                *:*
root     rpcbind    228   8  tcp6   *:111                 *:*
root     rpcbind    228   9  udp4   *:111                 *:*
root     rpcbind    228   10 udp4   *:1022                *:*
root     rpcbind    228   11 tcp4   *:111                 *:*
root     syslogd    213   4  udp6   *:514                 *:*
root     syslogd    213   5  udp4   *:514                 *:*
samizdata#

Well, that's a lot of stuff. There are a few ways to minimize the ports available; one simple way is to put the machine behind a firewall (or run the built-in ipfw) and block connections you don't want. This is effective, but doesn't stop the real problem: open connections. If your firewall fails for whatever reason, those ports are still open and listening. So let's do it right, and stop the services listening and then we can wrap the machine in ipfw love.

The output above is from a server, which I am running headless, so there's no X11 ports showing, since I'm not running X. If I were, you'd also see a bunch of ports in the 6000 range open. Even if you 'want' to run X over the network, there are better ways to do this than by letting X play directly with the network (think about using an ssh tunnel and piping X through 'that').

I don't want to run the automounter daemon, I have no use for NFS stuff on this machine right now and I won't be doing networkable syslog, so I'm going to turn those off. To do that, I'll need to edit /etc/rc.conf and change or add a few lines.

Editing /etc/rc.conf by either changing these entries to these values (or adding entries with these values) will disable NFS (those port 111 entries), portmap (you only really need it if you're doing NFS,) and networked syslog (the -ss flag).

nfs_server_enable="NO"
nfs_client_enable="NO"
portmap_enable="NO"
syslogd_enable="YES"
syslogd_flags="-ss" 

(firewalls, ssh security gotchas, choosing secure daemons, staying up to date with patches, etc.)

how your server presents itself to the world -- banners, firewall stuff

authentication, encryption and you -- switching to blowfish

keeping your machine updated -- general, OS and programs

keeping your machine updated -- security patches

Security in a local area network context

(probably the shortest of the categories - specific things to watch for in an un-firewalled and extremely-high-bandwidth mostly-trusted environment.)

Security through better logging

(keeping time up to date with ntpd or regularly scheduled ntpdate - and it's worth noting that I've NEVER personally been able to get ntpd to actually update the damn system time, all it seems to do is maintain a drift file for me - but anyway, importance of keeping system time precise down to milliseconds for coordination of system logs with logs at ISPs and other servers involved in network attacks, use of tripwire or built-in daily root emails to monitor for changes in important system files, and also the benefits of either maintaining a separate log server or REGULARLY moving logs off-system to a machine that doesn't trust the server it's getting the logs from one damn bit. this topic may actually need to be moved to its own separate subarticle.)

Of course, each of these sections can themselves spawn entire new subsections / subarticles of their own. There's a reason entire books have been published on computer security! =)

Try to remember, when writing these articles, that "short and sweet" is best, when it comes to a single article. If at all possible, try to limit the scope of any given article to a page or two of text; if you need to refer to something that is going to run a few pages all by itself, consider writing a separate article for that topic and hyperlinking it for people who need it. For example, obviously firewalls need discussion in any internet-context security article, but instead of trying to go over setting one up in the midst of the internet security article itself, it's better to write one article about firewalls and another about the big picture, and just link them.