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

["Ademar Gonzalez" <ademar.gonzalez () gmail com>]

In our network we simply forbid php function mail() , nobody sends
without authenticating through our mail server. There is more than one
way of doing authenticaded SMTP in php, it shouldn't be a problem for
your resellers to fix a line of code. Give them a notice.

It is the only way you can keep up with them spammers, we provision
hosting accounts immediately upon order, so these dudes they order
with fraudulent cc's and and they find your php mail wide open and in
less than the blink of an eye you have relayed a million spam, the
dude made the day.It doesn't matter you find and shut them down (which
will be quite difficult if they ain't authenticating), by now your
outgoing mail server is in every black list out there. About 20
minutes later you start getting calls from your legitimate clients.

Do not relay unauthenticated clients.

On 4/14/06, Rainer Duffner <rainer () ultra-secure de> wrote:
> 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

saludos.

ademar