Securing a Linux server

I would like to write an article soon on securing a Linux server. Here are the points I've come up with so far (with thanks to nebulus for his kind advice on a few):

- Tripwire
- Bastille Linux
- ClamAV (cron - run daily, at midnight GMT+6)
- Chkrootkit and rkhunter (cron - every, say, 6 hours)
- Firewall (iptables)
- Hardware firewall/behind router with DMZ to the server on port 80 if wanted for added security
- Turning off remaining unnecessary daemons which have not been by Bastille

Is there anything I've missed? Nebulus also suggested something about sudo usage, but I'm not sure if he meant to remove the server user from the sudoers file.. :)

Thanks,

-jk

More important than the software you have mentioned is file permissions, user permissions, and general security policies.

And you may not really need the AV, depending on what the server is used for.

Sorry, I forgot to specify - a webserver. So you're right, an AV would be quite pointless - the server would not be used for anything other than serving, and it is not acting as a gateway to Windows machines either.

By user/file permissions - are there any specific ones you recommend, or should I disallow access to anything and everything that is not needed by the server?

For security policies, would SE Linux be enough, or should I focus on creating my own to make it do only what is needed?

Thanks,

-jk ;)

SE Linux is enough IMHO.

You have to tailor the policies to fit the machine and the purpose.

If it is purely a webserver... the only things that should be running are Apache, FTP, and possibly ssh. And of course the syslog daemon.

Disalow access to everything not needed by the server, of course.

But there is another thing you have to consider... Apache or whatever webserver... You need to make sure Apache and the site(s) it serves are secured. If Apache is compromised... the system is easy to compromise.

How about permissions? How about /etc/securetty being set to only /dev/tty1 so root can only log in from the first console and isn't allowed to use X ?

You may want to edit how you have Clam set up to. This box for example is running SUSE. In YAST2 you tell Clam to run and it can run as either a daemon or when needed and it scans email as it comes in and updates as well. Telling it once a day at 12 AM may not work for everyone, as with this box it scans every time email is downloaded.

Running chkrootkit every 6 hours on a machine you're using as a server is going to REALLY make a load to high. That one I'd say switch to maybe every 12 hours.

As for the firewall, most distros come with something to set up IPTables in an easier manner.

Back to permissions:

SUSE has a module for that too where you can set easy, secure, or paranoid.

Sudo is only needed when you don't want to run as root, or use su. You type sudo, a command, and then it asks for the root password.

Another thing you don't have defined as of yet is what TYPE of server. You wouldn't do the same thing to a web server you'd do to a mail server or file server.

Oh and here is a GOOD one that can cost a lot but makes the box almost immpossible to crack:

Linux gives you source code for the whole system. Hire a Kernel programmer to hack a web server right into the Kernel and discard ANYTHING that doesn't have anything to do with web traffic. All traffic not in the web server criteria is discarded.

I've heard of some porn sites doing this and never even needing to update anything. And they've never been broken into or defaced because if it's not HTTP traffic from a web browser, the traffic is discarded. Some people maybe can't afford to hire someone with that kind of skill, but if they can it sure makes break ins rare.

Some of the most common problems on Unix based servers are permissions as I've pointed out you should look into more than just bastille. And read up on umask.


Another thing:

File Systems:

If you're using Ext2 or EXT3.... Well then you can play with more permissions:

In addition to modifying a file's permissions, a user can modify a file's attributes. These are changed with the chattr command and you can list them with lsattr.

If a set of data is VERY sensitive, you may want to change them so that even root can't modify them. Yes this is possible. And you don't want to back these up with dump. Dump backs it up, but you'd then be able to take the media and read what's on it.

Advanced file system attributes liuke -i which is immutable, prevents a file from being modified, deleted, renamed, or linked. And when you do a back up and you don't want it there.... Well -s makes it so the thing is forced to be deleted / whiped when it's deleted. And if you worry about power outtages, -S (Capitol S) makes it so this file is written to disk immediatley instead of being put in a buffer.

Chmod is like the attributes command I just told you about, and you use + to add one and - to remove one.

chattr +s file.txt

Oh and you may want to make services run on another port. Like Web traffic not running on port 80 and so on. And chroot services you DO have.

TURN OFF THE SUID AND SGID BIT

SUSE comes with stackgaurd.

Read up on : http://www.immunix.org/formatguard.html

I'm not sure that link works right now because Novell bought that too and guess what product it's being put into? ;)

Oh and for bastille, check out SUSE again for "harden_suse".

Next, and very important. Set up logging to be more aggressive than by default, and you may want it to be emailed to you each night.

On this box SUSE has a prog on the DVD that does it for you. Each night security scripts are ran and the results + log files get emailed to you at any email accountt hat you want.

d0ppy - Thanks. It will be Apache, and I'll stress the point about keeping it up to date, as well as validating any user input that could be used maliciously (especially when PHP and SQL databases are being used - and if they are, separate points about making them more secure than out-of-the-box).

Quote:

---

Originally posted here by gore
How about permissions? How about /etc/securetty being set to only /dev/tty1 so root can only log in from the first console and isn't allowed to use X ?

---

Thanks - I didn't know about that.

Quote:

---

Running chkrootkit every 6 hours on a machine you're using as a server is going to REALLY make a load to high. That one I'd say switch to maybe every 12 hours.

---

Ok - 12 hours it is. I wasn't sure how heavy chkrootkit is on the system (which is why I put 6 hours) - I usually leave my chkrootkit'ing to the night :D

Quote:

---

As for the firewall, most distros come with something to set up IPTables in an easier manner.

---

Like guarddog, Firestarter, etc.. So you would recommend using one of those rather than setting up iptables manually?

Quote:

---

SUSE has a module for that too where you can set easy, secure, or paranoid.

Sudo is only needed when you don't want to run as root, or use su. You type sudo, a command, and then it asks for the root password.

---

Quite a few of the popular distros bring security level configuration, I think. And I knew about sudo - I just thought that maybe I should remove the server user from sudoers because then even if the box was compromised, the cracker wouldn't be able to get root without some form of privilege escalation (although that's probably what they'd do anyway).

Quote:

---

Linux gives you source code for the whole system. Hire a Kernel programmer to hack a web server right into the Kernel and discard ANYTHING that doesn't have anything to do with web traffic. All traffic not in the web server criteria is discarded.
[..]

---

That costs quite a lot though - I'm not sure that most of the readers of my tutorial would go for this option, but I'll propose it in case they are interested. :)

Quote:

---

In addition to modifying a file's permissions, a user can modify a file's attributes. These are changed with the chattr command and you can list them with lsattr.
[..]
Advanced file system attributes liuke -i which is immutable, prevents a file from being modified, deleted, renamed, or linked. And when you do a back up and you don't want it there.... Well -s makes it so the thing is forced to be deleted / whiped when it's deleted. And if you worry about power outtages, -S (Capitol S) makes it so this file is written to disk immediatley instead of being put in a buffer.

---

chattr is the one 'ch-' command I've never understood the purpose of - although now I realise its importance. Thank you.

Quote:

---

And you don't want to back these up with dump. Dump backs it up, but you'd then be able to take the media and read what's on it.

---

If there another machine on the same network as it, I might implement the backing up process described here: click and click.

Quote:

---

Oh and you may want to make services run on another port. Like Web traffic not running on port 80 and so on. And chroot services you DO have.

---

Got the first bit - any particular reason why? I know it will not be expected.. 'chroot services you DO have' - as in creating a chroot 'jail', in a sense? Any specific place you recommend, or will a '. ' directory in the home folder do fine?

Quote:

---

TURN OFF THE SUID AND SGID BIT

---

My memory fails me - is that done by adding 'nosuid' and 'nosgid' parameters to the partition's mount line in /etc/fstab?

Quote:

---

SUSE comes with stackgaurd.

Read up on : http://www.immunix.org/formatguard.html

I'm not sure that link works right now because Novell bought that too and guess what product it's being put into?

Oh and for bastille, check out SUSE again for "harden_suse".

---

Aye - Immunix is down. I'll look into it as soon as it's up though. I'm guessing it's something to be excited about, so I'm glad it's being incorporated into SUSE. Hehe.. harden_suse sounds very interesting - would I use it in conjunction with Bastille or not?

Quote:

---

Next, and very important. Set up logging to be more aggressive than by default, and you may want it to be emailed to you each night.

On this box SUSE has a prog on the DVD that does it for you. Each night security scripts are ran and the results + log files get emailed to you at any email accountt hat you want.

---

Ok. Do you mean kernel message logging, Apache logging, or in general? Also - is that SUSE Pro (if so which version?) or OpenSUSE which brings the log emailing inbuilt?

I was also wondering whether the server should run a minimal WM like Fluxbox, or whether it should all be done via the CLI. Which do you suggest?

Wow - that was a lot of info ;)

Cheers,

-jk

Lol damn it why did you have to quote now I have to work harder to reply lol.

OK, I see that it's going to be an Apache web server. First off regaurdless of what ANYONE tells you, it DOES need root privs for the main daemon. The rest can run as the apache user or whatever it is, but that first one does need root.

As for IPTables, this is more preference. If you can do them WELL by hand, do so, otherwise it's much easier to just use a GUI or text mode client that does it. SUSEFirewall2 for example is amazing at setting up a good IPTables firewall.

The command you're learning about right now, just remember a few things: First it only works on Ext2 and Ext3, and even over NFS those permissions stay the same.

For chroot, yes I mean in a jail. Like for example /usr/local/folsomprison ;)


For harden_suse I'd say look at that and Bastille, and see which one looks best for your particular environment. they do similar things to the system but this one is up to you ;)

Every version I've used has that program that checks everything and emails logs so it should work fine. If you have SUSE installed anywhere just open YAST2 and install or remove programs, and go to search, type "security" and hit enter, it should show up in there. It's secchk or something like that. I never stare at it long enough as I just install it by default.

I have a floppy disk for my boxes here with custom installs based on what I want the box to do, I load a floppy and the programs I loaded on it last time I did what I want it to do are loaded. Like if you do a custom install and don't want to have to go through all those packages again just pop a floppy in and export the selections to it. That's what I do.



Don't use X at all. X and Window Managers add to complexity and they themselves can need security updates, so don't even use one. And besides a server should use resources for serving, not looking pretty.

Lol - no quoting this time ;)

Apache needs root - damn it. Ok, so that's one app which needs root..

I'm no professional with iptables, so maybe I better stick with something like SUSEFirewall2. I liked str34m3r's tut on it though (which he wrote almost 4 years ago :P).

Got that about chattr - and about chroot. If I do end up using SUSE (which you've somehow made seem like a very convincing option), then I'd probably go for harden_suse - it's made specifically for it; although they do both do similar things.

I usually do backup package choices to floppy disk - it makes it much easier to install the distro on another computer, because there's no need to go through custom selection all over again (which is highly tedious - especially on CLI installers).

I wasn't going to use X, but I assumed you meant I should because you told me to configure root as only being allowed to login to tty1 and not use X.

Ok - now to make a list of everything I've managed to gather from here :D

If there are any more pointers, I'd appreciate them (as always). Thanks a lot for everything!

Cheers,

-jk ;)

Is this possible to include PAM? Because i was reading on PAM and find it quite interesting and powerful.

Ok, let me preface this with 2 points...

#1, I've just skimmed this whole thread, not read every word of every post
#2, I *did* read all of J_K9's original post.

While it sounds like you've gone out and read a lot of posts and books on Linux hardening...you seem to have a lot of things tripping over themselves, in your plan.

If I'm off base, d0pp and gore, my apologies. You both made solid and good points, but I can't help wondering...

- If you are using Tripwire, why do you need Chkrootkit and rkhunter?
- If this is a dedicated webserver with no functions or means for Windows files to be copied to it, why do you need Clam AV?

d0pp said something about 'user and file permissions' and SELinux. that is some of the best advice. SELinux, if done properly, will provide about the highest level of protection from many exploits and attack vectors a cracker will use. They may crack Apache, but even if Apache runs as "root", with SELinux, if the apache labeled processes and executables don't have the right system label, they can't modify critical files and processes.

Bastille will do a pretty good job of fixing many of the default settings that are left 'open' on most systems...default permissions, services, setuid/setgid files, etc. It's a good starting point. 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.

;)

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.

Quote:

---

[...] 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 :D

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.

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.

Quote:

---

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

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.

Quote:

---

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

Quote:

---

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