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.

;)