When serving up web pages on an NFS server, where multiple web servers have access to the pages, who should own the pages?

The NFS server by default owns them as nfsnobody which I know is a user in Linux. The web servers are started as apache.apache however so is there trouble waiting here?

Should I change the httpd.conf to start as nfsnobody.nfsnobody on every server or try to change the default owner on the NFS server?

Thanks for any help you can provide.

Mike

Hi,

Assuming you just want to read content from the NFS mounted filesystems, I don't see any problem with leaving this as it is. At a basic level, Apache usually needs read privileges on .html files, and would need execute to list directories or run scripts.

Obviously you haven't given a huge amount of detail about what you're doing so what makes you think there is a problem with the current set up?

Cheers,
Steve

>Obviously you haven't given a huge amount of detail about what you're >doing so what makes you think there is a problem with the current set up?

True, sorry about that.

The pages are static, it's a LAMP setup so the servers running apache/php are for the most part, reading files from the NFS file server.

There is some writing of media files and such which go on separate storage but since users are uploading using through apache/php, I just want to know what I should be looking for in terms of potential hack problems at the ownership level of the setup.

Mike

Hi Mike,

Well, as Apache is only serving static pages from the NFS mounted filesystem and doesn't need to write to those areas, why not export them to your webserver clients as read-only? Then you have given this data a pretty reasonable amount of protection if one of the clients does get compromised.

I would not change Apache to run as nfsnobody - if the filesystem was mounted read/write and all the files were owned by nfsnobody, then if Apache gets compromised in some way (or far more likely in my opinion, one of the PHP scripts) you will likely have the cracker running code with the permissions of the user that owns all the data you are trying to protect. If the filesytem is exported read-only though, the NFS server should simply prevent any writes from the clients regardless. Unless there's a hole in the NFS implementation on your system....

From a security perspective, and I'm assuming you don't allow users shell access here, I would say the biggest security issue is probably PHP or more likely, the PHP scripts you are using to upload data and manipulate content. The best thing I think you can do on that front is make sure that you get any security patches for PHP on ASAP (hopefully that is obvious) and also go through the php.ini configuration file with the documentation, and turn off any functionality you don't need, for example register globals.

I think that would make a pretty good start towards securing your machines. Don't forget though that security is an ongoing process, it is never "finished". You must keep reviewing what is on the system, what new vulnerabilities have been released, etc, and you should periodically review the log files if possible to see what attempts crackers may have made on your systems

Cheers,
Steve

Hi Steve,

Thanks for the input.

>Well, as Apache is only serving static pages from the NFS mounted >filesystem and doesn't need to write to those areas, why not export >them to your webserver clients as read-only?

The pages are indeed static but media needs to be allowed to upload. I do have separate storage for large media but some directories must still allow smaller media such as personal profile images, things of that nature.

>I would not change Apache to run as nfsnobody - if the filesystem was >mounted read/write and all the files were owned by nfsnobody, then if

>have the cracker running code with the permissions of the user that >owns all the data you are trying to protect.

The default owner seems to be nfsnobody initially.
It is read/write because we need to push updates to the file server.
Though, when we do that, we make sure to rewrite all of the permissions and ownership to apache.apache to be safer.

>From a security perspective, and I'm assuming you don't allow users >shell access here, I would say the biggest security issue is probably >PHP or more likely, the PHP scripts you are using to upload data and >manipulate content.

Updates are done directly onto the storage, not the web servers.
The web servers don't have many tools on them, just what they need to serve up apache/php and some video manipulation functions. They get their NFS share from central NFS servers which serve up the pages and media storage. So, no ftp or webmaster tools.

>I think that would make a pretty good start towards securing your >machines. Don't forget though that security is an ongoing process, it >is never "finished". You must keep reviewing what is on the system, >what new vulnerabilities have been released, etc, and you should >periodically review the log files if possible to see what attempts >crackers may have made on your systems

All good advise and I definitely do all of the above.
I just had to wonder about the seemingly mismatch of ownership.

Thanks so much for the input.

Mike