john's picture

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:


ServerTokens ProductOnly
ServerSignature Off
This will prevent broadcasting to the world what version of linux and apache you have. The less we inform the hackers, the better I guess.
We should hide the PHP version of X-Powered-By message by changing the php.ini file:

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..

RChadwick's picture

Is fail2ban scheduled to be added? I'm a bit surprised it's not already in TKL.

Jeremy Davis's picture

And TBH while it is definitely a cool thing; I think that documenting how to install and configure this sort of thing is probably better than just including it.

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.


RChadwick's picture

Thanks 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? 

Jeremy Davis's picture

With the current state of play I doubt that fail2ban alone would make a significant improvement if someone were specifically targeting you and/or your server. It would just slow them down by increasing the time that it takes them to hack you. Also an attacker with a botnet could easily side step fail2ban with a distributed attack (i.e. the same attacker coming at you from multiple IPs).

However 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).

Add new comment