Securing an internet facing linux box

Khannie

Anyone got any good bookmarks for securing an internet facing linux box? Or even recommend a decent book?

croo

Well I didn't have a lot of network experience so I found it a really heavy reading but Linux Firewalls by Robert L. Ziegler I thought was excellent.

ntlbell

Can you try and be a bit more specific?

Blowfish

http://www.netfilter.org/

Decent place to start, there's a few 'How To's' on there.

Khannie

ntlbell wrote: »

Can you try and be a bit more specific?

I'm looking for general guidelines on steps to take to help secure a linux box which has port 22 open, runs multiple web servers, forums, that kind of jazz. I need to learn a bit more about securing a linux box in general. Because my home and work boxes are nat'd and behind a company firewall respectively I've never been too concerned about them.

Y2J_MUFC

IPtables and SELinux should do what your after. You should be able to find decent tutorials on them.

FruitLover

Khannie wrote: »

a linux box which has port 22 open

Use certificate-based authentication for SSH instead of password login. Mightn't be a bad idea to use a port other than 22 as well; check your logs and I bet you get multiple scans or connection attempts to port 22. You don't want to get caught out with a 0-day.

Khannie wrote: »

work boxes are nat'd and behind a company firewall respectively I've never been too concerned about them.

Is your company also running an IPS or application-layer filtering?

PogMoThoin

A few usefull tips I was given for my own setup were to;

-Restrict outside access to, say Irish IP addresses only
http://bugsplatter.id.au/cc2ip/
-Stop ssh listening for pre version 2 protocols
-Denyhosts is a great script to run if you have ssh from the outside enabled. A few attempts, then their IP gets automatically blacklisted for a week, this prevents bruteforce dictionary attacks. Another good thing about using denyhosts is that the IP's that get blacklisted can be shared in a global database
http://www.freesoftwaremagazine.com/articles/protect_your_server_with_deny_host

towel401

+1 for non-standard SSH port

get lots of muppets trying to log in, of course it never works but better safe than sorry

ntlbell

Khannie wrote: »

I'm looking for general guidelines on steps to take to help secure a linux box which has port 22 open, runs multiple web servers, forums, that kind of jazz. I need to learn a bit more about securing a linux box in general. Because my home and work boxes are nat'd and behind a company firewall respectively I've never been too concerned about them.

This book is a bit old now but all of the fundamentals are the same

The vast majority of break ins is sys admins not doing the basics.

keeping boxes up to date and patched.

running services that are not needed.

Once the box starts offering services such as forum's etc your problems are not "linux" problems any more, it'll be poorly written code in your choice of software that runs the forum, poorly configured php.ini's etc etc

changing ports that applications run on is a pretty pointless exercise and you start going down the route of security via obscurity.

You should start working on a custom baseline install removing anything not required so the bare bones no cups, no bind, no sendmail etc etc.

so you have a secure starting point for each server.

then you will have to look into each application.

so if it's apache for example consider chrooting in a jail so if apache does get compromised the attacker can't get access to the whole file system

Doing things like this can be a lot of work and if not done right will break other aspects of the system.

in a lot of cases what your trying to protect is not worth the effort and you enter the mind numbingly boring side of risk analysis etc.

Khannie

Thanks for the replies.

ntlbell wrote: »

You should start working on a custom baseline install removing anything not required so the bare bones no cups, no bind, no sendmail etc etc.

so you have a secure starting point for each server.

This sounds prudent. I'm gonna look into hardened gentoo (and others) because its baseline install really is a baseline.

Khannie

ntlbell wrote: »

This book is a bit old now but all of the fundamentals are the same

Yikes! That is old! Still gonna give it a read. Play.com has some reasonably priced books too.

Orion

Gentoo is a lot of work. How about Backtrack

ntlbell

Khannie wrote: »

Yikes! That is old! Still gonna give it a read. Play.com has some reasonably priced books too.

Yup it is, but it's the only decent book I could think of _and_ have read that covers a fairly broad range of concepts and you will see as you're reading it that the vast majority of it is still relevant today.

especially for what you're trying to do.

Khannie

Macros42 wrote: »

Gentoo is a lot of work.

Only if you're a gentoo virgin and only to get it set up. Once it's up and running, portage is actually a lovely package manager.

johnmd

You can actually secure the box fairly easily,we use centos/red hat but the same should apply for most distros.

A few quick items spring to mind.
1.Iptables for firewalling. apf firewall/shorewall with webmin or similar,very easy to use and flexible.
2. BFD brute force detection,adds failed logons onto the iptables drop list automatically.
3. Install snort on the box and customise the rulesets to march the actual services that you are running.
4.Chown the lynx,rcp,wget etc to 0600 to stop them being called by non root users.
5. Install chkrootkit and run via cron daily.
6. install apache with suexec to ensure scripts execute with owners (uid gid) permissions
7. install php with phpsuexec (same)
make /tmp non executable permissions if possible
8.turn off all un needed services.
9.chroot ftp users to their home folders
10.Daily backups offsite via rsync/tar/cpio etc etc
11.Install tripwire on the box and MD5 checksum all of the files.

Badly written php and cgi scripts are a very common way to allow attackers to use sql injection,or escaping to the shell to upload scripts to the /tmp or similar,then these scripts open ports back out and allow them access,once in they can hide and use rootkits,trojaned binaries,lkms and loads more.If this happens and you have tripwire installed you can at least get to see what has changed.


Thanks

stereo_steve

if you wanted to get really fancy you could use port knocking to hide your open ssh port

Jonathan

If you combine Port Knocking and cert based SSH, you are laughing really.

Attackers first need to guess the secret knock for to open your firewall, and then have the correct auth cert for the SSH login.

ntlbell

Jonathan wrote: »

If you combine Port Knocking and cert based SSH, you are laughing really.

Attackers first need to guess the secret knock for to open your firewall, and then have the correct auth cert for the SSH login.

again it's more of the security through obscurity.

It also adds a fairly complex layer but you're not getting much more for that layer.

and that layer can be easily got around via replay attacks etc.

You also make the box more vulnerable to to DDOS attacks.

so yes it might put of the average "script kiddy" or whatever name they have these days but the complexity for the sys admin and of the users that have to use the system etc that outweighs any benefit I can see.

Khannie

Interesting concept though. It might be handy for people with shell access.

FruitLover

ntlbell wrote: »

changing ports that applications run on is a pretty pointless exercise

If it puts you out of the reach of some skiddie scanning around on port 22 with a 0-day ready to go, then it's far from pointless. Security through obscurity is only a bad thing when it's your only form of 'security'.

Macros42 wrote: »

Gentoo is a lot of work

Only initially. Once you're up and running, it's a savage distro.

johnmd wrote: »

10.Daily backups offsite via rsync/tar/cpio etc etc

I'd like to add a couple of cents to this: backups should be a pull, not a push. Look what happened to astalavista recently.

ntlbell

FruitLover wrote: »

If it puts you out of the reach of some skiddie scanning around on port 22 with a 0-day ready to go, then it's far from pointless. Security through obscurity is only a bad thing when it's your only form of 'security'.

Nonsense, I'm not going to keep going over old ground I have this with every intern we ever get in.

If things are done right then there's no need for security through obscurity.

If they're not done right then security through obscurity won't help.

I'm sure if one looks very hard they might find _some_ situations where it might help but in general, breaking standards is bad, it's time consuming, it costs to teach others about your bad practices, it doesn't really _add_ anything.

I put it in the box with the genius's who disable users inserting USB sticks, disabling ICMP echo replies and one khannie will understand

doing sit up's to spot reduce belly fat

SouperComputer

Some basics that you likely have already done.

Remove dev tools along with a package/service purge.
Disable login to SSH as root, ie sudo only.
Set a maximum amount of login attempts.

Naikon

SSH certificate based authentication is a must for remote access.

boars.ie

Quite typical set of useless advices: change ssh port, use snort or tripwire, other
flowery techniques (strange enough, read-only partitions etc, were skipped).
Three the most important rules:

1. Keep your stuff up to date!
2. Keep your stuff up to date!
3. Keep your stuff up to date!

After them:

4. Password handling. It's the 21st century and still in ridiculous amount of companies
I see things like passwords same as logins or trivial changes like: e->3, a->4, or one
password giving access everywhere, or yellow stickers hanging around with passwords
written on, or just passwords being sent onto mailing lists or through open channels
and stuff like that.

5. "hacking" very often takes on a form of a simple change on the front page.
Which, taking into account omnipresence of web frameworks and databases
standing behind them is very often achieved by an attack on the underlying
framework or database itself. No number of iptables, snorts, tripwires, port
knockings and similar crap installed along the way will stop this kind of attack,
and once successfully attacked, your website from external world's point of view
is just compromised, regardless other parts of the system have been broken into
or not. So again, we are back at rules 1, 2, 3 - keeping your web frameworks and
databases engines up to date, but here you have to take a closer look at the code
of your webapps as well. Also, simple privilege separation may work miracles.
Again, in the 21st century, countless web servers still run from the same user
account their content or binaries are installed from, thus a vulnerable server
is free to change it's content and so forth. Consider "privilege separation" in wider
view, not only as preventing httpd from writing to index.html - this includes running
services on dedicated accounts for instance, on dedicated machines, VM's or sandboxes, fine grained access to resources for different accounts and so on.
These are basics described in virtually any security related text, and yet people tend
to overlook them and spend time and money on super-duper intrusion detection
systems instead.

The list goes on, but in general, first things first, don't even bother cosmetic
or ultra-sophisticated things, until you don't secure the basic ones. Good luck.

Khannie

Well....hardened gentoo was picked in the end. It has pax and grsecurity to help with the script kiddies. I'll be implementing a bunch of the suggestions in this thread. Thanks everyone.

edit: One thing I like about hardened gentoo is that it has absolutely nothing that you don't absolutely need. Total win. With all necessary daemons running it's using only 83M of ram. Animal.

ntlbell

Khannie wrote: »

Well....hardened gentoo was picked in the end. It has pax and grsecurity to help with the script kiddies. I'll be implementing a bunch of the suggestions in this thread. Thanks everyone.

edit: One thing I like about hardened gentoo is that it has absolutely nothing that you don't absolutely need. Total win. With all necessary daemons running it's using only 83M of ram. Animal.

You could reduce that memory footprint by using FreeBSD :pac:

Khannie

ntlbell wrote: »

You could reduce that memory footprint by using FreeBSD :pac:

Yeah....it's a pity it's so sh!t. :pac:

Naikon

Khannie wrote: »

Yeah....it's a pity it's so sh!t. :pac:

Why the BSD hate?:(:D

I don't think FreeBSD is any better or worse than Linux distro just little
perks and differences. I consider both bery similar because of POSIX.

I have to admit, Linux is far ahead of freebsd in some respects, and
on the server side, it is nice and reliable. Most development power
and influence are injected into GPL stuff. Linux has superior driver support.

The FreeBSD framebuffer is not as good as the Linux framebuffer, SDL
output on mplayer is dodgy on the console aswell. I do like the simpler
system initialization over sysV. No runlevels in BSD is really nice.

Also, putting everything(inc service scripts) not related to the core
system under /usr/local/* is nice,

Linux /etc can be a bit cluttered if you have alot of services.
PF is a really nice packet filter, I wish they would port it to Linux soon.

My TLS ldap box runs freebsd very happily, and I also have a Slackware
box doing windows shares with samba. Both are rock solid.

Without having this turn into a flamefest, I think both Linux and *BSD
can learn alot from each other. We aren't M$ folk remember;)

It all comes down to preference, no one system is 'better'
except maybe under questionable lab conditions.

Long live both systems!

Khannie

Ah sure I was only trying to get a rise. To be honest I have close to zero FreeBSD experience. I'd be more than willing to give it a lash, but I'd rather become a proper linux geek first.

ntlbell

Khannie wrote: »

Yeah....it's a pity it's so sh!t. :pac:

fun roll ricer :rolleyes::P:pac:

Khannie

LOL. Rice that sh!t up!

Naikon

Khannie wrote: »

Ah sure I was only trying to get a rise. To be honest I have close to zero FreeBSD experience. I'd be more than willing to give it a lash, but I'd rather become a proper linux geek first.

Ah fair enough:)
You should be ok, considering you are a Gentoo user:D

Gentoo to this day, apart from LFS, has the most intimidating install
of any *Nix I have used. FreeBSD handles partitions a little different.

Khannie

Naikon wrote: »

Gentoo to this day, apart from LFS, has the most intimidating install
of any *Nix I have used.

100% agree with that. I learned loads doing it though. Even reading the LFS manual taught me loads.