Securing a Linux server

[J_K9]

mmkhan - I'm not sure how useful it would be in this case. Nobody should have physical access to the box, all users should have long and complex passwords, and if I follow what has been mentioned by zencoder and gore then I shouldn't have a need for this. My apologies if you think otherwise

zencoder - Thank you for correcting that. With Tripwire there, any rootkits would be found because the file change would be logged and reported to the admin user.. sorry about that, I seem to have missed it.

I took ClamAV off the list as well - it's not needed, as you and d0pp said.

I'll also look into further configuration of SELinux - I'm not fully in touch with the deeper side of it.

[...] If you want true security, I would go so far as to not only disable unessential services, but remove the executables, the library objects, and the compilers and man pages. Take EVERYTHING off the box that isn't needed. Stripped bare. Then get tripwire running properly, and everything tracked via syslog...and you might just have a nearly secure box. maybe.

Really? Even the compilers? It could be a bit tricky if I deleted a library which was required by a certain app. Sounds like a challenge though - I'll see if I can do it without removing any dependancies on Sunday, when I can download openSUSE 10

I was also thinking of CentOS as a server distro, but openSUSE sounds quite suitable for the task, so I may just stick with that. Also, another app that I have thought of is PortSentry, which detects port scans and such. Should I install that as well, or is it unnecessary?

Thanks,

-jk

[MS_Security]

this is a very poor approach at securing a system. before you pick the tools you must decide what the system must do and must protect at what cost. i think you will have a much clearer picture of what is needed and what the best path is if you start with a risk assessment before worrying about mitigation. otherwise you are trying to mitigate undefined risks to protect undefined assets.

once you know what you have and how well it needs to be protected then and only then should you move on to selecting the actual technical and administrative controls to meet those goals.

be sure to carefully consider the products you use to secure your system. is selinux a good choice for you? maybe or maybe not. if your system is only providing the single service of http hosting then the complexities of selinuxs powerful access control architecture is most likely not the best choice for you. (do not forget that selinux is based off of a secure computing corporation patent. true scc says they have no plans to interfere with selinux however scc is in poor financial shape lately and has suffered a rather high executive turn over recently making its future perhaps too unstable for some installations.) the point is do your homework.

my advice to you is to sit down and define what this system will do and the environment it will do it in. from there identify attack vectors and the assets they will effect. once this is done you will be prepared to prioritize your risks and mitigate them systematically instead of this approach of firing a shotgun into a dark room with the hope of hitting everything.

the end result will be a more secure and cost effective system that will go live more quickly with fewer oversights and be simpler to maintain.

ps. i realize this is just for an article but if this approach is not taken all you will end up with is a step down from a list of links to various linux security product home pages.

[d0pp]

I agree completely.

One thing I have noticed is a trend to try to solve security issues with tools, instead of the system itself. Good practices and configuration are the best tools you'll ever have.

[J_K9]

my advice to you is to sit down and define what this system will do and the environment it will do it in. from there identify attack vectors and the assets they will effect. once this is done you will be prepared to prioritize your risks and mitigate them systematically instead of this approach of firing a shotgun into a dark room with the hope of hitting everything.

What the system will do - host a website using Apache.
Environment - either directly connected to the internet, or possibly behind a router with a DMZ to port 80 to it.
Risks - exposed to the internet, so obviously all the risks associated with that. None from within the network (if there is one), because the only other computer on it would be a backing up one.

My article is not meant to be aimed at securing websites like validating all human input in scripts to make sure that no XSS or SQL injection attacks are possible, or encrypting plain-text passwords so that they cannot be sniffed on their way from the computer to the webserver. That is not the point of the article. Rather, it is to lock down the webserver so that the only reasonable way for an attacker to get in is improper coding in the website itself.

I have done my homework, and I have tried to sum up all the possible risks and identify solutions to them. I asked for help here because I knew that there were far more ways to lock down the server, but through all my research I had not come across any more - and if I had I was unaware of their practical uses in what I am trying to achieve.

Good configuration will make the server more secure - but I've only got my own experience and what I've read in a few articles to help me do so. If there's something you think I've overlooked, please don't tell me that what I'm thinking of doing is wrong and that there are better ways of doing so - instead, give me examples of how to achieve what I'm aiming for, or even send me to a couple of articles so that I can improve my knowledge of the topic.

My approach to securing a server is a bad one - alright, I stand corrected. So let me know how you would do it then; I'm all ears.



-jk

[d0pp]

Risks - exposed to the internet, so obviously all the risks associated with that. None from within the network (if there is one), because the only other computer on it would be a backing up one.


this is not always a riks


if apache is the onlyl external service the something or other is status qou.

[J_K9]

this is not always a riks

But it is a potential risk. How would I be attacked other than from the internet in this case? (Physical access to the box is not possible, and neither is an attack from within the network).

It is not possible to evaluate every single risk relating to the OS, a daemon or and application - I couldn't count them on all the bones in my body

MS_Security - I have seen SELinux implemented in quite a few servers, and articles suggesting to do so - when all that is being set up is Apache on the server.

I'll read anything you have - if you have a link to an article which might help me, please don't be afraid to post it here or send me a PM; I would really appreciate it.

Thanks,

-jk

[alleyCat]

Originally posted here by J_K9
But it is a potential risk. How would I be attacked other than from the internet in this case? (Physical access to the box is not possible, and neither is an attack from within the network).

If this system is only going to be serving HTTP and will be firewalled/DMZ'd, then your only attack points are that HTTP port(on whichever network layer...), or within the network.

I wouldn't be too quick to say that an attack within the network won't happen, unless it has its own zone... even then there is always the network devices/firewalls...

The network is only as secure as the weakest link... if someone elses webserver is not locked down and yours is too, and their web app is compromised... your box might go down with the ship.

aL