Application Armor. I’m sure you can imagine what this little utility does but allow me to elaborate a bit and explain why configuring and using AppArmor has become Part III of our little series. First let’s quickly look at what we have so far if you’ve gone through Quick Secure Setup Part I and Quick Secure Setup Part II. From the security standpoint your server has every non-essential port turned off. Only applications you explicitly care about have their ports open through your firewall. You are getting security updates within 24 hours and are reviewing the logs for anomalies. For the ports that are open, fail2ban is checking the logs for errors and banning the offending IPs. So what’s left? Well a whole lot actually but we won’t concern ourselves with every little aspect of security. We are securing the main attack vectors to a standard server sitting out on the internet and there is one attack left that will help you sleep better at night if you have a defense against it.
The zero day exploit. You’ve done all this to your server and it’s locked down nice and tight. Along comes a new exploit to apache, ntp, postfix, ssh, vsftpd, etcetera, ports you need open to run your services and before any security updates can be released to address the issue, the black hats out there have a tool ready to take advantage. It might be an exploit that allows someone to crash the exploited service so, for example your web site would go down but no real compromise has taken place, all the way to something allowing them to escalate to superuser privileges. You’ve gone to bed confident and secure and woke up with your server in some not happy place and you following right behind. How do we alleviate this? It’s the next most common thing that could happen that we’ve yet to address. Oh, wait, you’ll skip this Part? Exploits aren’t that common? You might want to look at the US-CERT Cyber Security Bulletins and subscribe to their RSS feed. Keep in mind despite all the efforts we take here you won’t be left with an impenetrable fortress. There’d be much more to do for that. What you will be left with however, is a server that would require someone to target it explicitly, with motivation, to find a way to compromise it. Keep in mind, YOU will potentially be one of the weak links for your server’s security. On a sufficiently secured server it may be much easier for an attacker to leverage social engineering tactics to gain some sort of access so be careful about the type of information you divulge on those social applications, chats, forums, etcetera.
Now lets get on with business, we have zero day exploits and application bugs to defend against. Welcome AppArmor.
Useful AppArmor Links
- Novell AppArmor site – Great overview, chart comparison to SELinux, official maintenance and support.
- Ubuntu AppArmor Wiki – Nice overview, great follow-up links within.
- Ubuntu Community AppArmor page – Nice summary of commands to get started.
Peruse the links above so you can start familiarizing yourself with what AppArmor does but let me explain in completely non-technical terms. The applications on your system serve some function for you, the user. Just as say a user will use a car to go from point A to point B. Imagine the user has many options for getting from point A to point B just as an application may be able to do its job in different ways. The best way might be for the user to take the highway arriving in great time and this might be the way programmed into the application. But the user could drive the car on local roads or even off-road. When the user does this they could be affecting other things not intended within the “system”. For example the user could take the car onto private roads not intended for its traffic, or crash into a mailbox on its way. All this would be bad and an exploited application could do the same type of things, going places it was never intended or affecting another process on your system it otherwise wouldn’t. Now if we create an effective AppArmor profile for this application it’s like we’ve built a railroad directly from point A to point B. The application, now a locomotive instead of a car, cannot leave the rails. It has one allowed path it is now restricted to and its the path we defined by either laying down the rails or configuring the AppArmor profile. So even if the application is exploited and wants to leave the rails to drive elsewhere, it simply can’t, it is contained. This won’t be a step by step guide at building AppArmor profiles. I’ll give you a good overview and pointers but the best thing to do is read and most importantly in this case experiment for yourself. One of the better guides on AppArmor profiles I’ve found is Introduction to AppArmor by bodhi.zazen
First step, you should identify the applications or processes you would like to define an AppArmor profile for. You could run a command like
netstat -tulpn and take a look at the output. Anything that lists the Local Address as 127.0.0.1 isn’t listening from the outside world but anything else is a candidate to AppArmor. Or you could look at
ufw status verbose and see the ports you have open to the outside world. Any application listed there is a great candidate to AppArmor. The first thing to run is
apparmor_status. It will print out a nice listing of the default profiles on your server and tell you the profiles defined that are in enforce mode. On one of my servers just mysqld and ntpd are in enforce mode by default. There are two other main processes running that have external ports open, apache2 and sshd. So lets work on the steps required to create a profile for apache2, then you can follow that same framework for any other processes you want to AppArmor on your server. First we run
aa-genprof /usr/sbin/apache2 to start creating/editing the profile for apache. Now with the later ubuntu versions there is a generic, very permissive profile already in place so it would build off of that. Finish the genprof and run
aa-complain /etc/apparmor.d/usr.lib.apache2.mpm-prefork.apache2. This puts apache2 in complain mode. Now run your site for a while and do everything you normally do with it. You can also just leave apache in complain mode for a day or two as your site goes through its normal usage. Once you’ve done enough run
aa-logprof and any “complaints” apache had regarding its profile you can now step through the wizard and add to the profile. To enforce the apache profile its simply
aa-enforce /etc/apparmor.d/usr.lib.apache2.mpm-prefork.apache2. Apache is a special case with apparmor as there is an apparmor module you can enable
a2enmod apparmor which then will enable you to lock down your virtual hosts correctly via AAHats. So for this site I went into the <Directory /var/www/mysite> area and added
AAHatName blog.vigilcode.com, restarted apache and ran aa-logprof again and it stepped through new things to add to the profile and more specifically the new Hat. You can find more detail on this process here.
Apache is more challenging to AppArmor because of the child processes is spawns and with virtualhosts each being another “server” in essence there is more to do and follow. When learning and getting familiar with AppArmor I think the best first step is to use your desktop and create an AppArmor profile for your web browser. It’s something you use all the time so can leave in complain mode for a while, then throw it in enforce and get accustomed to debugging issues by putting back in complain mode and either manually looking over the log or running aa-logprof to see what else came up.
This is definitely the least “quick” part of the Quick Secure Setup series but if you can take your time and master a few good profiles for your servers with the other steps taken so far then you won’t have many security worries.
Future: I’m currently keeping my eye on Tomoyo Linux as an AppArmor competitor so you might want to take a gander over there if for nothing else but for the knowledge.