TurnKey Linux Virtual Appliance Library

Out of the box security on TurnKey LAMP (and other appliances)

Hello all,

I am new to linux and I was wondering how secure the TurnKey LAMP setup is.

Would it be secure out of the box or am I required to secure it myself?

 

Thank you

Liraz Siri's picture

Security isn't a binary value, it's a continuum

TurnKey takes security very seriously. For example:

1) Only the minimum components required to satisfy an appliance's usage scenario are installed. That reduces the attack surface. In other words, there are less pieces of software to exploit.

2) Security updates are applied when you install the appliance and every day subsequently after that.

3) There's built-in support for firewalling.

4) SSL support is configured for web applications that need it, etc.

5) Daemons are bound to the localhost interface so that you can't access them from the network if they don't need to be accessed for the network for that usage scenario.

6) The developers come from a security background and are less likely than the average user to accidentally open up a security vulnerability via a configuration mistake.

So it definitely isn't vulnerable out of the box. But security isn't binary. It's not an on or off thing. New vulnerabilities are always being discovered. An attacker may exploit a vulnerability before a security update comes out. We may have made a mistake somewhere. Your passphrase may be guessed. Etc.

The main thing I would recommend you do if you are concerned about security is after everything is working, turn off all the services you don't use. For example, if you don't use Webmin or Webshell, turn them off. If you want to go the extra mile, uninstall all the software components you don't need. So if you only need PHP support in LAMP, remove the Perl and Python support. Test continually that you don't break the functionality you need. If you don't need to allow people to access a service from outside your LAN, limit access to that service through the firewall.

If you do all that you'll quickly discover there is tradeoff between security and convenience / functionality. How much of an effort you are willing to put in to tighten the screws is up to you and depends on the risks and usage scenario. Back when I was working on classified systems I would go to pretty insane lengths to protect against a hypothetical time traveler that travels from 5 years into the future into the present and knows about all the techniques and vulnerabilities that may lurk in the software but we don't know about. The only way you can protect against that is by adding layer after layer of redundancy. None of my systems were connected to the Internet. Inside the classified network different segments were strictly separated and firewalled off. You had special security software monitoring for unusual network activity. And the servers were in a room full of laser beams only a ninja could get past, but first they had to pluck your eyeball out to beat the biometrics. And the mean looking armed guards of course.

Security Issues with TKL Lamp

We are planning to install TKL HUB for new Drupal web application on EC2.

Can you please address the concerns raised here.

http://secnut.blogspot.com/2010/08/lamp-security-case-study-of-lamp.html

Jeremy's picture

Hope you're ready for an essay! :)

In addition to (and in places, repetion of) Liraz's post above here is my 2c on it all...

Firstly, I should probably preface my comments with the disclaimer that I am not an IT security guru and most of my linux server experience has been gained during my 3 years playing with TKL servers and providing front line TKL support here on the forums (I'm a community volunteer). I do have some practical experience too though (as the IT guy at my work) but no history in IT security. However both Alon and Liraz (the 2 core TKL devs) have significant experience working with military IT security.

Keep in mind that the review is of the old v2009.x TKL, although in fairness many of the points raised may transfer across to the current TKL appliance range. I should also remind you that the author of that review was testing a live environment. IMO that is not adequite for a proper review (although at least he mentions that). IMO installation should be part of any proper review, partially because it's part of the user experience, but also because it's rarely a true indication of a distro (and seriously what's so hard about installing to a VM!?).

Ok on to the specific points raised:

  1. The root user is still used as the default user account in TKL v11.x, but passwords are configured on firstboot. Even back on the v2009.x lineup (as reviewed) the root password was set during install (blank passwords when running live). All the apps have their passwords set on first boot (or within the Hub prior to boot when launched to AWS). There are no default passwords and certainly no blank ones!
    As for usage of the root user; IMO it is definately bad practice on a desktop, but not such an issue on a server. The reality is that if you don't use the root user you still need to use a sudo-user (ie a 'normal user' that can gain root rights - so you can admin your server), and a hacked sudo user account is no less powerful than the root user! I guess the only factor is that a hacker could easily guess the account name off the bat. But really, security by obscurity may be worth it for some as an additional defense, it's not really much security in and of itself. To a seasoned hacker, it's just one more minor hurdle to cross.
    BTW default setup via the Hub is with key-pairs and a random root password is set (although you can set one if you want).
    Note that all the running software runs in non-priviledged user accounts - which have login disabled (ie you can't log in say as the webserver user).
     
  2. Versions of software - As the author correctly points out, the software are not the current relase (although the version included in the current v11.x is php v5.3). But there is a fundamental difference when comparing the way Ubuntu/Debian do things to the way things are on Windows (and some other Linux 'rolling' distros). Whilst the version reports as being old, new security bugs have their fixes backported to that version and is no longer vulnerable to the exploit. So whilst the version will report as old, the security bugs that relate to that specific version are patched for the life of the OS.
    The reason for doing things this way is that it maximises security and while also decreasing the risk of your server or your website breaking. The downside is that any (non-security) bugs remain and any new features are not available (ie the patches are only for security vulnerabilities). When these backported security fixes become available (generally very soon after the upstream developer releases them) are auto applied to your TKL instance daily (ie it silently checks every day and installs when they are available). So I would argue that a TKL server is actually more secure in that sense than a server with newer, but static versions installed (like say Windows) that requires manual checking (for new releases of software) and manual update. And more stable than a 'rolling' Linux distro which includes latest versions of software (and generally still require manual intervention anyway). It also significantly reduces maintenance overheads, so you don't need an admin constantly checking,updating and testing software to ensure that the updates don't break your site or server.
     
  3. Hiding the info that the server provides to outside is again 'security by obscurity' and won't be any match for someone who is intent on malicious activity. From my reading online, it seems that most serious attacks these days use sophisticated and automated tools that more often than not; run from high performance cloud computers. So to someone intent on breaking into your site, not having that info easily available means perhaps an extra 10 minutes! Although, in fairness it may reduce the chances of a 'script-kiddies' (ie generally young, inexperienced hackers using other people's code and tools that they don't fully understand, often seeking notoriety) trying to attack you just for the hell of it.
     
  4. Further points:
    1. Re phpMyAdmin version - same applies to above re backported security fixes.
    2. Firewall is available (via Webmin) but disabled by default. It is easy to set up. However when using AWS a security profile (ie AWS firewall) is preconfigured and automatically applied.
    3. See above point re root user acount usage.
    4. See above point re firstboot passwords (this includes MySQL root user).

Some of the points have a degree of validity and for the paranoid there is definately food for thought. But the thing to remember is that Turnkey Linux is not necessarily intended as an 'end point' but rather a 'start point'. IMO the reality of security is that it's almost always a trade off against usability. Seriously; if you want to have the ultimately secure server, you'll need to disconnect it from the net and physically secure it in a safe  - hardly a recipe for a great webserver!! - But it'd be totally secure! :)

So TKL is not built, nor intended to be a high security, harderned distro. Some users will find it adequite as it is, others will choose to modify it. TKL is designed to be a good base system. It aims to lower the bar for entry into the wonderful world of linux servers. It attempts to make a reasonable balance of having adequite security measures in place, whilst minimising complexity and maximising accessability, usability and flexability. Personally I think the devs do a pretty good job of balancing all that stuff.

Maybe you think that the mix isn't quite right for you and your usage scenario!? That's fine. The beauty of open source software is that you are in control! You can still use it as a base but if you want to create a new user and disable root you can! If you want to create firewall rules and apply them, you can! If you want to reconfigure Apache to give less info about itself, you can do that too! Most of the software used is 'mainstream' open source and generally widely used. In my experience, it is all pretty well documented (although not here on the TKL website unfortunately and sometimes it takes a little hunting and a bit of trial and error).

I think the area of documentation is one where TKL could definately do better. Ideally I think that we should have something in the docs about system hardening. But as I say, the info is out there and often a bit of googling will result in more than enough info to bend your TKL server to your desires.

And a final comment; in the 3 years of my involvement here on the TKL forums I don't recall any confirmed reports of a TKL server being compromised. I'm not saying it hasn't happened; but I would assume that if TKL was particularly vulnerable, then I'm sure I would have heard plenty about it!

Thanks

Jeremy - Thanks a lot! I like the way you concluded the article, saying that, TKL is a good start, It is upto the wish and will of customer to fine tune the environment according to the business needs. We look forward to proceed with TKL Hub solution.

Post new comment

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account, used to display your avatar.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <strike> <caption>

More information about formatting options

Leave this field empty. It's part of a security mechanism.
(Dear spammers: moderators are notified of all new posts. Spam is deleted immediately)