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