Forum archive
Suggested extra security measures for LAMP appliance...
I would like to make a security suggestion to the excelent turkey team.. I advise the following security settings.
In the httpd.conf file, making the following entry default upon install:
expose_php = Off
I would also suggest the team include the fail2ban app, enabled and working by default. Also hardened for the type of enviroment you made turnkey LAMP as. Securing against ssh, webmin, phpmysql manager, webshell and even apache as examples..
I also just noticed that the webmin is also advertising it is 1.590 when I issue the HEAD / HTTP/1.0 via telnet.. No idea how to turn that off, any help?
I don't see the benefit of advertising version numbers to the public..
Replies (4)
Not currently...
Reply 1Is fail2ban scheduled to be
Reply 2Is fail2ban scheduled to be added? I'm a bit surprised it's not already in TKL.
My 2c...
Reply 3However I suspect that it would make your server less of a "low hanging fruit" for unsophisticated attacks by less organised hackers looking for opportunities.
IMO the best defence against attackers though is configuration...
Disabling services that you don't use is a great start (reduces attack vectors). Not allowing SSH login using a password (i.e. only allowing keys) is a really easy way to massively reduce the chance of someone hacking into the root (or any other) account of your server.
Also where possible only allow connection to limited IPs (i.e. limit connections to the IPs you and people you permit). Obviously that won't be a valid option for a webserver, but it might be for other services...
But probably one of the biggest ones is making sure that where and when you do use passwords, make them REALLY good ones! 8 chars bare minimum (the more the better) and include at least 3 of the 4: lower-case, upper-case, numbers, special characters. From what I have read, actually using a sentence (or phrase) as your password is not a bad way to go (it's long and by nature includes a mix of character types and is often easier to remember).
Thanks for the response. I
Reply 4Thanks for the response.
I didn't find any great how-to-install at the time. I have fail2ban installed, but it doesn't seem to work. It also gives occasional errors from it. I suspect I just installed it wrong.
If not pre-installed, full docs would be great. I'd offer to write one, if I knew what I was doing :)
What about fail2ban for specific appliances that would most likely benefit?
My understanding is that it leverages IPTables to enforce it's bans. Assuming that my understanding is right (please correct me if I'm wrong); considering that IPTables is disabled by default it adds very little OOTB (IMO).
The only way to make it generically useful is to also pre-enable IPTables. But that is where it starts getting tricky. Some of our build formats do not include a kernel (e.g. OpenVZ). So IPTables won't work. Although TBH I'm not sure whether it would just fail gracefully or throw a big fat error. Also AWS instances use Amazon's security profile (and not IPTables). So if fail2ban were used AWS users would need to configure both AWS security profile AND IPTables. I can guarantee that would lead to many frustrated users and a rise in support requests...
So I'm certainly not saying don't use it. I'm just saying that I'm not sure that including it by default is a good idea. Instead let's document it's setup config and usage. Despite IPTables not being enabled by default it is configured so enabling it (on systems that support it) is super easy. And apparently fail2ban defaults are pretty sensible and install is fairly straight forward (even more so in the upcoming v14.0 - it's in the Jessie repos).
FWIW the docs are a wiki and you should be able to add a new child page to the tutorial/how to section.
Thoughts?