0

I'd like to run a web server to experiment with. I'm going to to use Mongoose because it looks lightweight and simple enough to understand everything that it is doing.

I have a Debian box to run it on.

My questions are

  • Is it advisable to run a web server as root? If not, why not? (How can a non-privileged accounts listen on ports 80,443?)

  • Is there a standard directory to put the "site root" to be served? Does it matter where this is as far as security considerations go?

xyz
  • 501
  • 1
  • 7
  • 13

8 Answers8

8

A webserver is usually started as root. A good webserver will then change the user under which the indivual processes are run. That way you get to use the standard ports.

Where to put your document root isn't really important. Of course, you need write-access to that directory (without being root). You can often find the default document root under /var/www or /srv/www.

PS: I'd recommend Apache, light-weight or not. There is a vast amount of information easily available for its configuration and its configuration files are not at all hard to understand.

innaM
  • 1,428
  • 9
  • 9
  • +1 for the Apache recommendation. Using a practically unknown web server, which I'm sure is many years behind the development put into the major players, is risky at best. While the Apache default config looks huge it is mostly comments. – John Gardeniers Aug 11 '09 at 00:41
3

Repeat after me:

NEVER run a web server as root.

NEVER run a web server as root.

NEVER run a web server as root.

NEVER run a web server as root.

Its like leaving your house unlocked and going on vacation for 6 months.

As to where to put your web root. I recommend somewhere that makes sense to you. I am a big fan of putting it somewhere NON-STANDARD simply because it helps defend against all the various script kiddies out there. (Still doesn't make you safe, but it helps.)

KPWINC
  • 11,274
  • 3
  • 36
  • 44
  • 2
    How would a non-standard document root help against script kiddies? Either your server is secure or it isn't. – innaM Aug 10 '09 at 18:24
  • 2
    Sure, but if I put my unsecure scripts into "123scripts" instead of cgi-bin the SCRIPT KIDDIES are less likely to find them. I specified "script kiddies" specifically, not hackers. Most script kiddies don't even bother to LEARN from the scripts they run... they just prey on default configs, default passwords, and... you get the idea. I said "it helps defend" not that it made you safe. – KPWINC Aug 10 '09 at 18:50
  • 1
    Agreed with KPWINC. A script kiddy is using a program someone else wrote, that probably has very few options, and none that they will understand. It'll be designed to hit a default install, with default options. While you should never rely on Security Through Obscurity, it can another obstacle to overcoming, helping with a defense in depth model. – Dentrasi Aug 10 '09 at 19:32
  • 5
    Saying "Never run a web server as root" in such a condesending manner, without bothering to explain that you need to start the server as root, and ensure it is configured to run as a seperate user is pretty useless advice. – theotherreceive Aug 10 '09 at 23:05
  • 1
    My apologies if you found it offensive. It was intended to be humorous. That being said, the question was "Is it advisable to RUN a web server as root? If not, why not?" – KPWINC Aug 10 '09 at 23:16
1

As said by someone else, never run a web server under the root account. Fortunately, most web servers will drop privs to a non-root account immediately after binding to port 80.

Another way to handle this is to run the web server program on a port over 1024 and use a front-end (such as varnish or nginx) to listen to port 80 and forward to the back-end web server.

Geoff Fritz
  • 1,717
  • 9
  • 11
1

The default version of apache2 in Debian’s repository starts as root but spawns the actual Apache processes as user www-data.

I’d recommend running your experimental server as a virtual machine under Xen or KVM. This way you start off with a totally clean environment that you can safely nuke if you have problems. You can also change system-wide settings or install software for testing purposes in the VM, without messing up your real system.

Nate
  • 2,316
  • 4
  • 21
  • 24
1

Like others have said, you shouldn't run a web server as root. Unfortunatly, no matter how secure your server or applications are, there is always a (good) chance that there is a security risk. A break-in with an unprivileged account is bad enough — allowing root access is deadly.

When you start a server, you generally escalate to root permissions with sudo (sudo apache2ctl start) and then Apache binds to specified ports and then returns to lower permissions.

Because of my Mac background, and my love for human-readability, my sites are located in /var/WebServer. Inside I have default and many other sites running as virtual hosts.

Apache is widely talked about and TONS of documentation is available, the best and easiest of which is provided (in my opinion), by Slicehost (it's not VPS specific though). I'd consult their articles to see how to setup Apache quickly and securely.

arbales
  • 497
  • 1
  • 4
  • 16
1

I must agree with Manni on this, apache is your best bet to start with.

  • It has the most amount of documentation & help for new users.
  • It's comes with sensible defaults and packages from Debian, which they maintain well and ensure get security upgrades out quickly.
  • Most people use some apache somewhere, so knowing the basics can be very helpful
  • Apache is pretty much the swiss-army knife web server, most of the others are designed to run in specific circumstances and/or be very good at running with less resources. Imo, that's a reason to learn it before the others, but some may disagree.

As for the specific questions you asked:

  • You must start your webserver as root in order for it to bind to port 80. Generally you configure the server to drop these privlidges and run as a different user once it's bound to the port (on debian apache this user is www-user, and this is setup by default). Programs which run their own web servers for specific applications which lack this functionality are usually proxied through a larger web server such as apache or nginx.
  • /var/www is the default location on Debian for the website root. This should be fine for whatever web server you choose.
theotherreceive
  • 8,235
  • 1
  • 30
  • 44
0

Version 1:

  • create another user on the system, without too many privileges (no logon even)
  • in the startup script of the web server do su my.web.server.sh (just as example)
  • create a folder (e.g. under the new user's home folder) and chown it to the newly created user
  • grant yourself write permissions to that folder
  • set this new folder as the web root

Version 2: (my favorite)

  • sudo apt-get install apache2/httpd
  • you have /var/www/[html] as the web root This should take care of everything for you - create the user, the correct permissions on folders, etc

With the risk of repeating everyone else above: NEVER RUN AS ROOT :)

-1

Here's how you learn.

Step 1. Install the server with the defaults.. Don't put ANYTHING of value on it.

Step 2. Plug it in to the network.

Step 3. Wait 15 minutes

Step 4. See how much damage was done to it.

========

Next, wipe it clean with a full reinstall. Then find an appropriate security guideline for your OS and web server. Do what it says, plug it in and wait an hour. If it's still up and hasn't been jacked with then you are good. For awhile. ;)

Security is an ongoing dance. Keep up and your foot won't get stepped on.

Luck to you. ;)

NotMe
  • 3,772
  • 7
  • 30
  • 43
  • Just because it hasn't been hacked in an hour means nothing. What if the attack doesn't come until the 61st or 65th minute? You've proven absolutely nothing but given yourself a very false sense of security. – John Gardeniers Aug 11 '09 at 02:46
  • It takes about an hour for your site to be probed and hit by the script kiddies. That time is simply to get past the common, easily run, attack attempts. Beyond that you will need to continously keep up with service packs, and possibly monitor the server(s) with an IDS. My entire point was not a full lesson in security. Rather it was to give the OP a small exercise so that he can understand the basics of how easily an insecure site can be pwnd. – NotMe Aug 14 '09 at 01:37