Re: How to determine which PHP-script allows spamming?

Kari Asikainen wrote:
> Kurt Seifried wrote:
>>> The culprit turned out to be  some guy who, instead of creating 
>>> links to his web-pages decided to include them.
>>> This happened in the form of http://domain/index.php?p=/bla/data.html
>>> Of course, "p" could be overwritten and some guy was loading a 
>>> php-mailer from various geocities and yahoo pages, which our server 
>>> dutifully parsed...
>>> We could only shake our heads in disbelieve. This had cost us 
>>> countless hours of (until now) fruitless work.
>>
>> One relatively easy way to prevent this type of problem is to 
>> disallow your web server from making outgoing connections to port 80 
>> TCP (i.e. do not allow it to request things). If you want to be 
>> really anal simply disallow any outgoing connection attempts for TCP 
>> SYN, this will prevent all sorts of naughtiness from your webserver. 
>> Plus when you do see blocked outgoing connections you will know 
>> something is up and can correlate it with web logs/etc.
>
> That is a nice and clean global solution.
>
> With PHP you can also turn off fopen-wrappers which will disallow 
> including remote content. IMHO that should be the default, and 
> allowing it would be strictly per-virtualhost basis after auditing the 
> security of the code in question...
>
> -ka
>


I agree.

But we (or a reseller) certainly have some sites that "require" it and 
historically, it probably wasn't a big problem.
Until now.
But that's difficult to explain to the customer.

Just today, we had another "incident" where some "user" (replace with an 
expletive) had created a custom 404-handler as PHP-script that included 
some other files, one of them non-existant. This sent the whole cluster 
into a "noop"-loop.
I guess we'll have to re-evaluate what a single shared-hosting domain is 
actually allowed to do and what not - even though, we don't allow that 
much already.




cheers,
Rainer