Re: [OT] Need a new feature: Listing of CGI-enabled directories.

[Zac Stevens <zt...@cryptocracy.com>]

Hi Ron,

Thanks for your detailed response to my post, I'll reply later this
evening off list.

I do want to jump in on this, though..

On Fri, May 31, 2002 at 12:24:30AM -0700, Ronald F. Guilmette wrote:
> In the case of FormMail scripts, if the big web hosting companies can
> just scan all of their CGI directories for them every night and then
> simply `rm' or `chmod 0000' anything found by the scans of the previous
> night every morning, then that will be about 99.9% sufficent to eliminate
> the problem.

To provide you with a bit of context, my comments come after having run a
Solaris/Apache-based virtual hosting service in Australia for approximately
5000 sites on around 200GB of disk (on a Network Appliance filer.)  I'm
security conscious, but I'm also pragmatic - as you yourself seem to be
aware, commercial realities do put a stop to best practices some of the
time.

I have tried, and failed, in attempts to correct bad user behaviour in the
means you have described above.  In addition to removing execute
permissions and chown'ing files to root, I have attempted to leave messages 
by way of conspicuously-named files in the relevant directories.

None of this was met with much success.  Typically, the user would
re-upload the script, or delete and re-upload the entire site, and the
problem would begin anew.  Naturally this probably could have been stopped
with more fascist permissioning, but this really isn't the sort of thing
most companies are comfortable doing to their paying customers.

The problem is that none of these things alerts the user to the problem -
it just creates a new problem to grab their attention.  In sites where
valid contact e-mail addresses are available for every customer, this can
be a more effective form of resolving the issue.


In the aforementioned web hosting environment, we did two things to
minimise the amount of spam mail originating from CGI scripts on our
system.

1) Supplied a formmail equivalent as standard.  Our script added a few
   extra niceties, but essentially it was just a safe formmail.

The existance of this script and clear instructions on how to use it were
supplied to every customer when their site was setup.  The support staff
were trained in using the script and diagnosing problems.  Combined with
the fact that support was not offered for 3rd-party scripts (although they
were permitted), this resulted in a high usage rate for our custom script.

2) The sendmail binary was replaced with a script which did sanity checking
   and added identifying details.

This is a simple and extremely effective way to put an end to the problem
of spam mail originating from virtual-hosted customers.  Perhaps due to the
nature of our business (And the fact we supplied a safe CGI mailer), the
majority of our problems came from developers who had written their own PHP
or CGI scripts.  Many did not understand the need to write secure code, nor
knew how to.  By applying checks on the mail leaving the system, you catch
all the problem scripts - not just those you already know about.


> And that's a lot better than doing nothing.

Anything is better than nothing - it's an issue of getting the best result
from the most acceptable expenditure of effort.  Perhaps we merely differ
in our opinions of where that effort is best spent.

Cheers,


Zac