A bit of background required here, my job title is “System Administrator & Web Developer” for the company I work for. In short my my main responsibilities are ensuring good performance, high reliability and decent security for our customer facing computers.
When I started in this role back in 2003, the two servers we were using back then had applications crashing on a daily basis, telnet on and things like formmail.pl in root cgi directories etc. Slowly but surely I have managed to find a lot of the annoying little problems, and build a network of computers that I can rely on and trust.
However, there are still places where potential holes could arise, for instance there still a lot of key based ssh authentication going on (if one computer is compromised you can consider another one compromised too really because of this).
We purchased some high powered servers back in October, and recently an additional database server. I have been meaning to tighten the configuration and access to these servers for ages, and this week I had an opportunity to start on the new database server.
Grsecurity is a role based access control system that works on the premise that unless explicitly stated, a user/role has no access/permission/control. It can
- Control and audit file access,creation,deletion,modification etc (on top of the actual filesystem permissions)
- Control and audit network access, for instance binding to interfaces/sockets or connecting to certain addresses via tcp/udp (on top of any iptables configuration)
- Control and audit what daemonised programs are allowed to do (so in the unlikely case of sshd being exploited, an exploiter can only access the files that sshd would access normally anyway).
It does lots of other stuff too, but those points are the main things I am interested in. If computer A is compromised and has access to computer B via ssh keys, and computer B has a correctly implemented security policy, then all an intruder can do is the normal day to day commands that computer A asks computer B to perform anyway.
Real world example: User john auto logs in daily from a computer A to the secure computer B using key based authentication and views a log file, the policy on computer B would grant access from the address of computer A, allow role john to run /bin/bash and have an ssh session (quite a few rules required for this), and read the log file - but nothing else.
At the moment the logs are full of errors from various scripts etc that do not have enough permissions to do certain things. The most important programs running on that computer have access, and I will get round to sorting all the others next week.
Potential comedy beginners mistake #1: Always check you can log in using ssh after enabling the policy but before logging out your existing ssh session. I came so close to forgetting to do that and would have locked myself out entirely!