Re: [mod-security-users] Blocking

[Terry D. <tdo...@na...>]

Gerwin Krist -|- Digitalus Webhosting wrote:
> Guys,
> 
> The things you proposed didn't worked you, 

No, my previous signature filter would have failed, because I made the mistake 
of assuming the matches were case sesnsitive.

SecFilterSelective ARGS_VALUES "\n\s*bcc:"

should work better (and it looks nicer).

>but found out it has to be 
> something like this? 
> 
> SecFilterSelective "POST_PAYLOAD" "\s*bcc:"
> 
> Please tell me that it safe to use this :)

It depends what you mean by safe. It will certainly work in that it will match 
any attempt to put 'bcc:' (possibly preceeded by whitespace) in any input 
field of any form.

Of course, the above paragraph I just typed would match it as well, so a 
perfectly legitimate discussion about mail headers in a forum could end up 
being blocked with a message that would leave the user assuming a server 
fault. If the above rule was all you required to trigger a denial, you could 
end up with a lot of false positives.

I think my initial suggestion may have been too simplistic. Where your case 
differs from my own is that my form is used for only one function and I can be 
certain that any occurrence of a mail header is a spam attempt, whereas you 
have numerous customers using various scripts that could be for any purpose.

Consider a scenario where someone posts full message headers in an input field 
in order to ask for help in anlysing a mailer issue. It's an extreme case, but 
it could be difficult to explain to an irate customer why you've 'broken' 
their forum...

If you can bear allowing the spam to happen a little longer, try just setting 
up an audit log for matching POSTs, rather than denying them immediately. If 
you're seeing a lot of spam, then you should soon have a large enough data set 
to spot an obvious pattern. You can then set up a ruleset (possibly a few 
chained rules) that match the necessary parts. Once the spam script starts to 
fail, it's highly unlikely that the spammer will waste their time trying to 
defeat your measures and they'll simply go away:

Depending on your ruleset, you should be able to enable audits with:

SecAuditEngine RelevantOnly
SecAuditLog <auditlogfile>

and adapt your above rule to cause a match, but pass it through:

SecFilterSelective "POST_PAYLOAD" "\s*bcc:" "log,pass"

 From this, you may well be able to isolate one or two originating IP 
addresses as the source of the spam and block them out at the firewall level.

Terry.

> Is this 
> Regards,
> Gerwin
> On Tuesday 29 November 2005 12:23, Terry Dooher wrote:
> 
>>Gerwin Krist -|- Digitalus Webhosting wrote:
>>
>>>Heya,
>>>
>>>Don't know if you guys see trends, but we see a huge trend of spammers
>>>abusing email forms for sending spam. Is there a way of blocking these,
>>>by blocking POST requests with email addys in it? Any help would be
>>>apreciated!
>>
>>I've seen a few of these attempted on a mail form I've written myself. The
>>form script is a simple PHP mailer that's only there to save us publishing
>>an email address on site.
>>
>>The usual tactic seems to be to fill in any text input fields with <short
>>random string> @ ourdomain.com, then filling the text area field in with an
>>attempt at RFC 2822 headers and the spam message. The hope is that the
>>mailer will simply send the stream as two messages.
>>
>>I've got some preg_match() lines in the PHP for blocking these. They
>>generally revolve around picking out message headers from the assembled
>>body, and sanitising any email address in the fields not marked 'email
>>address'. (I don't block these as legitiamte users can put their email
>>adress in the strangest of places)
>>
>>It's usually a good idea to do this kind of checking in the script, though,
>>as you'll find it easier to report errors to the user with some context
>>without having to use custom rejection rules and ErrorDocuments.
>>
>>That said, to pick the spam out at the mod_security stage, you might want
>>to scan specific ARGS_n values or just all of ARGS_VALUES for the basic
>>headers like "\s*To:", "\s*From:", "\s*Cc:" and "\s*Bcc:". The \s* will
>>match any possible leading whitespace as this can form part of a valid
>>header. You could do this match at the start of a line ("\n\s*To:" for
>>example) if you want to reduce the potential for false positives.
>>
>>Far more crudely, you could just block anything with ':' or '@' anywhere in
>>ARGS_VALUES.
>>
>>Terry.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>files for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>_______________________________________________
>>mod-security-users mailing list
>>mod...@li...
>>https://lists.sourceforge.net/lists/listinfo/mod-security-users
> 
>