On Mon, Jun 07, 2010 at 02:34:23PM -0700, Brian Dunning wrote:
> I think I must have misstated the problem. Thanks to everyone for the
> replies, but the question is not how to fix it, it's how to find the script
> being attacked. Many different admins manage many different sites on this
> serv
On Mon, 2010-06-07 at 17:29 -0700, Brian Dunning wrote:
> I'm currently geotargeting all the IPs in the log, and focusing on the hits
> from Russia (the majority of these apache@ spams seem to be Russian). I've
> got a much shorter list of scripts to look at now. Hopefully I'll find some
> that
I'm currently geotargeting all the IPs in the log, and focusing on the hits
from Russia (the majority of these apache@ spams seem to be Russian). I've got
a much shorter list of scripts to look at now. Hopefully I'll find some that
just use mail() with no scrubbing.
--
PHP General Mailing List (
Brian Dunning wrote:
> I think I must have misstated the problem. Thanks to everyone for the
> replies, but the question is not how to fix it, it's how to find the script
> being attacked. Many different admins manage many different sites on this
> server, and I can't even begin to guess how man
Well you coud do just that but after you turn it back on. Set up a
fresh error log based on the reset of the mail server. You then have
some kind of script monitoring the in and out of your server.
Disconnecting the mail server momentarily and maybe a pass reset for
your users would stunt t
On Mon, 2010-06-07 at 14:34 -0700, Brian Dunning wrote:
> I think I must have misstated the problem. Thanks to everyone for the
> replies, but the question is not how to fix it, it's how to find the script
> being attacked. Many different admins manage many different sites on this
> server, and
I think I must have misstated the problem. Thanks to everyone for the replies,
but the question is not how to fix it, it's how to find the script being
attacked. Many different admins manage many different sites on this server, and
I can't even begin to guess how many mail forms are on there fro
Brian Dunning wrote:
Agreed that's a great overall strategy but what I need now is a way to track
down the offending script, within the next few days if possible.
On Jun 7, 2010, at 1:35 PM, Jim Lucas wrote:
Change all the forms to use a single
processing script and then you won't have such a
Agreed that's a great overall strategy but what I need now is a way to track
down the offending script, within the next few days if possible.
On Jun 7, 2010, at 1:35 PM, Jim Lucas wrote:
> Change all the forms to use a single
> processing script and then you won't have such a big problem trackin
On Mon, Jun 07, 2010 at 01:25:28PM -0700, Brian Dunning wrote:
> Hey - It looks like a PHP form on my server is insecure and is being used to
> send spam. This is Rackspace's best guess. The problem is there are SO MANY
> forms on all the web sites on this server that it would be a nightmare tas
Brian Dunning wrote:
> Hey - It looks like a PHP form on my server is insecure and is being used to
> send spam. This is Rackspace's best guess. The problem is there are SO MANY
> forms on all the web sites on this server that it would be a nightmare task
> to try and look at them all to be sure
On 7 June 2010 22:25, Brian Dunning wrote:
> Hey - It looks like a PHP form on my server is insecure and is being used to
> send spam. This is Rackspace's best guess. The problem is there are SO MANY
> forms on all the web sites on this server that it would be a nightmare task
> to try and look
Hey - It looks like a PHP form on my server is insecure and is being used to
send spam. This is Rackspace's best guess. The problem is there are SO MANY
forms on all the web sites on this server that it would be a nightmare task to
try and look at them all to be sure they're properly secured.
I
13 matches
Mail list logo
