Security for a home server

[Gullible Jones]

If I were to set up a home web server in my firewall's DMZ, what would be a reasonably secure setup I could use? Specifically if I wanted to set up a web forum?

Distros

Anything mainstream with GPG signed packages should do, I think, as long as I don't install X. Main ones I'm thinking of are

- Slackware: Very easy to set up. Not really secure by default. Comes with a compiler and headers for everything, which in this case is a security risk. No automatic updates.

- Ubuntu LTS: Probably harder setup. Using a custom kernel might be annoying. Much better default security, plus automatic updates and a larger dev team.

Kernels

Custom GrSecurity kernel seems like the way to go. GrSec is very easy to set up (and on a server I can enable mprotect() restriction, woo).

I do wonder about drivers though. Would it make sense to disable drivers that aren't used on a server, e.g. the graphics card and sound drivers? Any code is attack surface, after all...

Software Firewall

It is very easy to write iptables rules, but not so easy to decide what should and should not be logged. What's recommended for a server? I am thinking it would be good to log all connections, both accepted and denied, and label them as clearly as possible. (And put /var/log on a separate partition of course.)

Access Control

At the moment think it would be best to put the web server daemon in a chroot, instead of relying on complicated MAC systems. GrSec does a lot of chroot hardening stuff. I could be convinced otherwise though.

Intrusion Detection

UNIX IDS with an encrypted database? I think Open Source Tripwire should do. Don't want something too confusingly featureful.

Backups

This is where it starts getting beyond my experience level. What's a sane way to do backups of a website? Maybe I could use Git?

Website Security

Because I don't want my website defaced and used to spread malware, which can be done even if the machine isn't rooted... And code injection attacks can't be defeated by GrSec.

I suspect the best way to handle this would be to use a web application framework that is known to be fairly secure. Unfortunately all FOSS forum softwares I know of are based on PHP, which from what I've heard has... problems. So maybe it would make sense to build a forum using a web application framework, like Django or Ruby on Rails? How much time would that take?

What BBS software, web application frameworks, etc. are generally recognized as being fairly secure against code injection attacks?

Hardware Firewall

My current "hardware firewall" is actually an old laptop running IPFire. IPFire has a nice web interface, but I think it may not be up to snuff for this - the kernel is a (minimal) vanilla 3.x one that may be suscpetible to network attacks.

Are there better firewall distros out there? Would it make sense to build my own firewall system, again with a custom GrSec kernel and all?

Attitude

Or, "am I overthinking this?"

On the one hand, Linux on the desktop is mainly secure through lack of widespread use. Linux servers get hacked all the time.

On the other hand, I do have a life, and have stuff to do other than babysitting my own Linux systems. So anything that requires too much time maintaining it is a liability.

What security measures make sense for a home-hosted forum, and won't eat up too much time after it's all set up?

Thanks in advance...

[Mindovermaster Moderator]

I think CentOS or Arch are better secure than Slackware or Ubuntu.

[articuno1au]

I am inclined to say avoid Ubuntu. Debian/Arch/CentOS etc are all good choices. I'm a particular fan of Debian.

Git would be good for distributed backups >.< I run my own SVN server and push all my work onto that.

RSync would be good for rolling backups of your server, but there might be better solutions out there, I'm more of a Windows guy >.<

You are DEFINITELY over thinking this. Following best practices should keep you pretty secure. Beyond that you're entering overkill territory. The hardened kernel can't hurt :)

I don't think there is any inherent downside to using PHP if you do it properly. I'd also be inclined to say your hard firewall should be fine, just reduce the attack surface on your server if you want to be cautious >.<

[Brian M. Veteran]

The best distro to use is the one you have the most experience with. Any differences in easiest to install, etc, will be negated when things go wrong - it's easiest to fix things if you know your way around the distro ;).

Personally, all of my servers use Debian.

[Karl L.]

I think CentOS or Arch are better secure than Slackware or Ubuntu.

Arch and Slackware both seem like insane choices for a server distro. They each have their advantages, but fast rolling releases and extreme source-level customization are not often goals for a server. Servers often aim for security and stability above all else. CentOS is certainly a good candidate considering the excellent enterprise quality packages and security features (particularly SELinux). Ubuntu server (LTS) is also a good choice if you need commercial support, otherwise Debian is probably a better choice for a server because of its larger archive, extreme focus on stability, and faster security updates.

[Gullible Jones]

I think CentOS or Arch are better secure than Slackware or Ubuntu.

CentOS -> probably, it is enterprise stuff. OTOH I can't be bothered to mess with SELinux.

Arch -> no IMO, it's a great OS but it's basically for customized desktops.

Ubuntu, not sure how it compares with Debian; it just happens to have automatic updates, so I figured why not?

Slackware is actually pretty good about userland updates, it's just that they never update the kernel in stable - you're expected to compile your own. Also it doesn't ship with any firewall configured (but that is easy to remedy).

I am inclined to say avoid Ubuntu. Debian/Arch/CentOS etc are all good choices. I'm a particular fan of Debian.

Noted. I'm also a Debian fan, just thought some aspects of Ubuntu might be better automated.

Git would be good for distributed backups >.< I run my own SVN server and push all my work onto that.

RSync would be good for rolling backups of your server, but there might be better solutions out there, I'm more of a Windows guy >.<

Not sure about distributed. My thought was basically to have a cron job that does regular git commits of the website, and then rsyncs the whole git repo to a (relatively) safe directory; from whence I could back it up to external media.

You are DEFINITELY over thinking this. Following best practices should keep you pretty secure. Beyond that you're entering overkill territory. The hardened kernel can't hurt :)

No it can't. :) But part of the issue is that I don't have much sysadmin experience, so I'm not entirely familiar with "best practices."

I don't think there is any inherent downside to using PHP if you do it properly. I'd also be inclined to say your hard firewall should be fine, just reduce the attack surface on your server if you want to be cautious >.<

The problem as I understand it is that

- Using PHP properly is harder than it looks

- A lot of BBS softwares therefore don't use it properly

I certainly hope you're right re the hard firewall.

Edit: I need to stop with the quoting...

@Brian M - Fortunately I'm familiar with all the major distros...

@xorangekiller - Arch would be insane. Slackware, maybe. I think it would mostly depend on the average time between unmitigated vulnerabilities in the GrSecurity kernel, since recompiling the kernel regularly would be a pain.

[articuno1au]

I'm a huge fan of Debian for servers.

EDIT::

You can have a cron job on your desktop/laptop that auto syncs Git onto your machine. Thus you have it on Git/Server/Desktop and or Laptop. That's how I ensure the safety of my SVN. I might lose the delta changes if I lose my server and backups, but I'll always have the final files :)

Best practices are pretty much common sense. Don't CHMOD 777 stuff >.>

With regards to PHP, that's a question of the forum I guess. I'm running IPB on my server (as is Neowin) and I've found it quite reliable. Only issue I have with it is the occasional spammer.

I'm also running it in an IIS instance which might make it a little harder to attack O.o

[Karl L.]

I'm not going to respond to every one of your points, but I have a few thoughts. Most of my experience comes from administering CentOS/RHEL and Debian servers, so I probably have somewhat of a bias in that direction.

Distros

Anything mainstream with GPG signed packages should do, I think, as long as I don't install X. Main ones I'm thinking of are

- Slackware: Very easy to set up. Not really secure by default. Comes with a compiler and headers for everything, which in this case is a security risk. No automatic updates.

- Ubuntu LTS: Probably harder setup. Using a custom kernel might be annoying. Much better default security, plus automatic updates and a larger dev team.

I responded to this point in my last post (where I quoted Mindovermaster). Summary: I would probably choose Debian in your scenario.

Kernels

Custom GrSecurity kernel seems like the way to go. GrSec is very easy to set up (and on a server I can enable mprotect() restriction, woo).

I do wonder about drivers though. Would it make sense to disable drivers that aren't used on a server, e.g. the graphics card and sound drivers? Any code is attack surface, after all...

I know of the GrSecurity kernels, but I have never used them in a production environment. They potentially provide additional security, but it's probably overkill for your simple web server. Vendors like RedHat and Debian generally do an excellent job providing security updates to their stable kernels in a timely manner. If you are actively interested in the security of your server I recommend that you subscribe to your distribution's security mailing list. You can subscribe to either RedHat's Enterprise Watch List or Debian's Security Announcements Mailing List to keep up with the latest security news for your respective distribution.

Software Firewall

It is very easy to write iptables rules, but not so easy to decide what should and should not be logged. What's recommended for a server? I am thinking it would be good to log all connections, both accepted and denied, and label them as clearly as possible. (And put /var/log on a separate partition of course.)

iptables is the standard firewall. Make sure that you set it up to deny all inbound, outbound, and forwarded connections by default (not default in RHEL or Debian) and explicitly allow services and routes if you are really paranoid about security. This will probably do you more good than trying anything with kernel hardening since the system's firewall is your first line of defense when your server is in a DMZ. (If you're running Debian you will also want to install the iptables-persistent package so that your iptables rules are applied automatically on boot. RHEL has this functionality integrated by default.)

Access Control

At the moment think it would be best to put the web server daemon in a chroot, instead of relying on complicated MAC systems. GrSec does a lot of chroot hardening stuff. I could be convinced otherwise though.

I don't think chrooting your web server is really going to help you in any significant capacity. Chroot is not designed to be a security measure! Read this post on the FreeBSD mailing list and this summary of an old kernel mailing list thread for more information on exactly why. Steve Friedl's Best Practices for chroot() Operations is an excellent guide on what to do and what to avoid when using chroots.

My recommendation for locking down your web server is to run the daemon as its own user with extremely limited privileges. If you are careful with the permissions you assign it you can effectively limit the scope of any breach that might occur. The security problems inherent in many web server installations is due to the lax security setup people apply because they want the server to "just work". The fact that you are seriously considering the security implications of running a web server already means you are unlikely to make the same mistake.

Intrusion Detection

UNIX IDS with an encrypted database? I think Open Source Tripwire should do. Don't want something too confusingly featureful.

Tripwire is a little bit of a pain to maintain (since you need to update the database when you make legitimate configuration changes), but it is an indispensable security measure for production systems in my opinion. Although they are not strictly related, I often use it in conjunction with fail2ban, which I also highly recommend.

Backups

This is where it starts getting beyond my experience level. What's a sane way to do backups of a website? Maybe I could use Git?

There are many ways to do backups, but I automated it using rsync and cron. If you ever get more than one server and want to have a single backup location, then you can setup an rsync daemon on one server and have the others backup to that one. Rsync scales very well. Theoretically you can have the same sort of setup with git, but I have never used that as a backup solution before. (It is definitely my favorite source control system though.)

Hardware Firewall

My current "hardware firewall" is actually an old laptop running IPFire. IPFire has a nice web interface, but I think it may not be up to snuff for this - the kernel is a (minimal) vanilla 3.x one that may be suscpetible to network attacks.

Are there better firewall distros out there? Would it make sense to build my own firewall system, again with a custom GrSec kernel and all?

There are a few good open-source firewall distros out there. If you strictly want a Linux based firewall, then Untangle is an excellent choice. If you don't mind a FreeBSD base, then I definitely recommend pfSense, which is currently my favorite. Both have excellent commercial support options available should you ever need it.

Attitude

Or, "am I overthinking this?"

On the one hand, Linux on the desktop is mainly secure through lack of widespread use. Linux servers get hacked all the time.

On the other hand, I do have a life, and have stuff to do other than babysitting my own Linux systems. So anything that requires too much time maintaining it is a liability.

What security measures make sense for a home-hosted forum, and won't eat up too much time after it's all set up?

Thanks in advance...

It is definitely very good that you are trying to think through the security of your web server rather than rushing something sub-par into production without much thought. I commend you for that. You are already starting far ahead of where most people would be. Overall your thoughts on security sound fairly reasonable, but don't stress yourself over trying to implement enterprise-grade security. Implement reasonable security measures - like I suggested above - as you can, and work from there as your website grows.

[xxxxxx.xxxxxx]

I'l just add my $0.02 -

A linux server is only as secure as you make it. My best suggestion would be if you are going to choose linux for your server environment choose Debian (if you want to try out BSD FreeBSD/OpenBSD are best choices). The reason for my choice is simple. I currently run three servers from home all run Debian, I also have a 2u colo server running Debian. In the approx. 4 years I have run these various systems I have had hundreds of thousands of attempts to break in via different methods (check your logs or have them mailed to you periodically to check for malicious activity), all these attempts have been in vain and my setup is a generally default setup with no fancy hacks/code/patches other than the many security improvement measures found all over the internet.

Debian uses tried and tested software rather than bleeding edge which means security flaws are generally patched already and those that the community are aware of are patched as soon as possible. Talking of communities Debian has an astounding community, so any questions about securing Debian in different ways there is always a Debian geek available :)

[n_K]

All my *nix servers are arch based.

Just because arch is a fast rolling release does not mean you have to update all the packages or use the versions on the web, most server orientated packages are compiled and packaged by me, including the kernel.

[Mindovermaster Moderator]

There is a BSD version of Debian, too, can't remember link though.

[xxxxxx.xxxxxx]

There is a BSD version of Debian, too, can't remember link though.

I think you are thinking of kFreeBSD :) Never used it so really can't comment.

[Mindovermaster Moderator]

Yeah, that was it: http://wiki.debian.o...NU/kFreeBSD_why

[cybertimber2008]

Another good security tool is 'Denyhosts', and automated tool which monitors login attempts among other things and after a number of failed attempts (http, ftp, SSH, etc) it blocks the IP for a number of days. Connect it to the online database submitted by thousands of servers and you're protected from things that haven't targeted you yet.

[fusi0n]

This is an interesting thread..

[Karl L.]

OTOH I can't be bothered to mess with SELinux.

That is a very common sentiment. Although SELinux is a very powerful security tool in the right hands, it is also a bit of a pain to setup and one of the things most often disabled on Red Hat distros. Although I currently have SELinux enabled and using carefully crafted security policies on all of the RHEL/CentOS servers I administer, it has taken significant time investment to wrangle SELinux into doing what I want. I have never had any serious security breaches on any of my Red Hat or Debian machines, so I'm not convinced that SELinux is actually worth the effort.

Noted. I'm also a Debian fan, just thought some aspects of Ubuntu might be better automated.

As far as I know there is nothing in Ubuntu server that is particularly better automated than Debian. Most of Canonical's work for Ubuntu server has been in commercial support (and Landscape). If you are thinking "automated" as in automatic updates (which was what I originally thought you were referring to), you can configure automatic updates in Debian fairly easily. Automatic updates are not enabled by default in Debian for a good reason - most system administrators prefer to tightly control updates so that they can meet their uptime quotas.

All my *nix servers are arch based.

Just because arch is a fast rolling release does not mean you have to update all the packages or use the versions on the web, most server orientated packages are compiled and packaged by me, including the kernel.

I believe that I called your choice insane a few posts up. Are you running Arch on servers in a production environment, is this a testing/development environment, or is it just your personal server?

[n_K]

I believe that I called your choice insane a few posts up. Are you running Arch on servers in a production environment, is this a testing/development environment, or is it just your personal server?

One is home server, one is production server, one is a dedicated firewall/IDS and one is a development/testing/compilation server.

Here's the production;

top - 09:50:33 up 42 days, 19:55, 1 user, load average: 0.00, 0.01, 0.05

Tasks: 112 total, 1 running, 111 sleeping, 0 stopped, 0 zombie

%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem: 3086264 total, 1954816 used, 1131448 free, 215900 buffers

KiB Swap: 1955240 total, 0 used, 1955240 free, 1000288 cached

Linux H3K-FP 3.8.2-1-grsec-selinux #1 SMP Mon Mar 4 18:43:02 GMT 2013 x86_64 GNU/Linux

No problems ;)