Networking → [Servers] Setting up a home web/file server

Hey guys. I have been around the forums awhile and I lurk through several places. I have a (not-so-quick) quick question. I have setup a home file/webserver that is running a website using Apache2 on Debian Linux. Do you guys have any advice on hardening the system? You guys can test it out at www.chaoticconfused.com to see if anyone can find things I may have missed in the setup. I have used back-ends through a few webhosting sites in the past, but this is my first time doing it from the ground up. No, I am not trying to shamelessly plug anything, it would just be nice to get a few pointers.

Ideally you do not want your publicly exposed web server to also be your home file server (at minimum your web server could be a virtual machine running on the same host). Since you are running this on a UNIX-like system, I also recommend Apache be chrooted if not already and if possible (read up on this if you are not familiar with it).

I agree with Bink. A home file server is a trusted machine, while a public-facing web server is untrusted. My approach would be to create separate servers as virtual machines and place them in separate local networks. Your firewall would then prevent the web server from accessing local networks (and possibly the internet as well, depending on your needs).

I will definitely see what I can do to try to implement your suggestions. Is this true even if the file server requires user authentication for access? I am also using nonstandard ports for all services (SSH, FTP, and etc).

From a systems perspective, the standard ones are :

- run system with least priviledge credentials / ID
- change default passwords
- use strong passwords and rotate on a regular basis
- keep system patches up to date
- install AV / anti-X and keep up to date
- maintain syslogs on and off device, review regularly

2nd Bink and clarknova about segmenting this system from the rest of your network if possible -- put simply,
_IF_ someone were to compromise it, they could not only affect the web/fileserver itself, but use it as a jumpoff point
to attack other hosts within your LAN.

This book also may be worth looking into getting as well as a general reading resourceESPECIALLY if it uses authentication -- look into what the concept of "Authentication, Authorization and Accounting" is
from a computing perspective. It's not enough that we authenticate who you are, we also need to know IF you're authorized
to do that, WHAT you did and WHEN you did it (accounting).

My 00000010bits

Regards

Those are good measures. It's still wise to keep untrusted machines on untrusted networks, and trusted machines on trusted networks. Defense in depth.

The problem with computer security is that nothing is air tight. You can't eliminate the risk of somebody compromising your passwords, your operating system, your network, the locks on your house, your wife's ability to keep a secret, etc. So the approach is to minimize the risk of each of these measures failing individually, and use multiple measures so that the probability of multiple security breaches is even less.

Additionally, if there is a compromise of one component, the other components still maintain their integrity. So for example, if somebody manages to exploit a flaw in your web server and gains shell access to your system, proper file permissions and a strong root password helps to ensure that they don't have access to privileged system files. Keeping your file server on a separate machine or virtual machine ensures that even if they manage to escalate privileges on the web server, they still don't have access to the file shares. Suppose there is a flaw in ssh or the way you set up ssh, keeping the trusted machine on another subnet means the attacker doesn't have the opportunity to exploit other machines without first penetrating your firewall.

This is defense in depth and a principle of best practice. Do these things well and you'll already ahead of all the corporations like Sony and Best Buy that you have read about in the past years who had customer data stolen by remote attackers.

Yes. If the daemon/application responsible for your web site is compromised, it is possible an attacker can circumvent authentication and have full access to the system running this.

Thanks for the suggestions guys. I went through and disabled/deleted all users that were not used (there were like 2, with only about 13 total users on the system). I also disabled telnet.

I have fail2ban, rkhunter, fwsnort, psad, snort, and logwatch on the system. I also have the system setup to email me whenever someone logs in (the system is set to expressly pay attention to /var/log/auth.log). I will need to sit down again and figure out how to run at least apache inside a VM (and make it work correctly). Thanks for all the great advice.