Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm running Apache on Linux and I'm using OpenSSH to provide SFTP access to some customers so they can upload their pages and also look at their respective site logs (access & error). I'm using the new feature in OpenSSH to chroot their SFTP access and so far so good.

My problem is that on the error_log, every reference for "File not found..." is given using the OS filesystem path as opposed to the "Web" path. I'd rather have the web path on the error log in order not to reveal the OS path. Since I'm already chrooting the users, I don't want to reveal WHERE on the OS their files are actually located...

Is it possible to change this behaviour via any directive? I tried looking for it but couldn't find anything :(

Thanks, Craconia

share|improve this question

2 Answers 2

I would consider this stepping into the realm of security through obscurity. If you consider the path being revealed to the local user a risk, I would recommend reconsidering as to whether or not the user having access to the system is a greater risk than the justification for them to have access.

It is also notable that Apache will often disclose riskier data than the file system paths as the result of application errors. If you insist on obfuscating the path in the logs, there is no native support for this in Apache. Nevertheless, you would be able to create this performance by piping Apache logs through a script or potentially sed using Piped Logs.

If you would like to further harden the local system against local users, there is a variety of more tangible methods that could prove to be helpful. The list below is focused on local hardening and is not comprehensive but should be a useful starting point.

  • Removing the SUID bit from most files
  • An audit of any files or directories that are writable to all.
  • Removing code compilation tools.
  • Removing absolutely all software including userland tools that are not integral to the system's role.
  • Configuring packet filtering to limit external access to only that which is justified for the specific purpose of the systems role and operation.
  • Enabling and configuring SELinux
  • Apply and configure an Extended File Attribute policy
  • Using Filesystem ACLs to further refine access to data on the local system

While there has not been a release since 2008, some of the policies applied within Bastille Linux also provide a general baseline for hardening Linux servers.

Many of these things will make the system more difficult to use and administer, which may frustrate users of a multiuser system that have shell access. Nevertheless, if security is the absolute priority, the methods listed will harden your system beyond that of the average multiuser system.

share|improve this answer
1  
Thanks Warner for the information. I want to add that I'm doing security WITH obscurity which is not the same as security THROUGH obscurity. I've already implemented many of the good points you mentioned. I just noticed this the other day and thought that it will obviously be much better not to reveal the OS path. Thanks again. –  Craconia Jun 13 '10 at 17:50

You have to change the LogFormat for the access logs of your users. The variable %U contains theURL path requested, not including any query string, which is probably what you're looking for.

share|improve this answer
    
Hello joschi. AFAI, you can't customize the format of the error log (just the access log) :( –  Craconia Jun 14 '10 at 12:11
1  
@Craconia: Of course you're right. I kind of missed your intention to change the format of your ErrorLog. This is only possible by modifying Apache httpd's source code. You could, however, pipe the ErrorLog through a simple script which replaces or shortens every occurence of the absolute path of the file on your server. This should work relatively performant with sed for example. –  joschi Jun 14 '10 at 15:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.