mod-security-users

[mod-security-users] modsecurity and spam in OWA

[Jason H. <Jas...@tr...>]

This may sound like a feature instead of a bug, but I thought it might
reflect how complex Web security can actually be...

We use an Apache reverse-proxy to protect a Microsoft Outlook Web Access
(OWA) server, and I have modsecurity-1.9.1 in there doing it's thing.

However, I just found it blocked me from reading some nice Asian spam
someone kindly thought to send me:

GET
/exchange/username/Inbox/%E4%B8%8A%E7%BD%91%E9%A1%BA%E5%B8%A6%E6%8C%A3%E7%BE%8E%E5%85%83.EML?Cmd=open
HTTP/1.1

(OWA creates links to each msg based on the Subject line)

Anyway, I had "SecFilterForceByteRange 32 126" and it blocked that URL
as there was a char 228 in there

Sooo, what should I block instead? Given the fact that the Webapp needs
to present almost any char (i.e. assuming a Subject line could contain
any char), could I do an exclusion list instead? i.e. accept everything
other than NULL, etc? And if so, can someone tell me what "etc" should
actually be? ;-)

Thanks!

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

Re: [mod-security-users] modsecurity and spam in OWA

[Ivan R. <iv...@we...>]

Jason Haar wrote:
> This may sound like a feature instead of a bug, but I thought it might
> reflect how complex Web security can actually be...
> 
> We use an Apache reverse-proxy to protect a Microsoft Outlook Web Access
> (OWA) server, and I have modsecurity-1.9.1 in there doing it's thing.
> 
> However, I just found it blocked me from reading some nice Asian spam
> someone kindly thought to send me:
> 
> GET
> /exchange/username/Inbox/%E4%B8%8A%E7%BD%91%E9%A1%BA%E5%B8%A6%E6%8C%A3%E7%BE%8E%E5%85%83.EML?Cmd=open
> HTTP/1.1
> 
> (OWA creates links to each msg based on the Subject line)
> 
> Anyway, I had "SecFilterForceByteRange 32 126" and it blocked that URL
> as there was a char 228 in there
> 
> Sooo, what should I block instead? Given the fact that the Webapp needs
> to present almost any char (i.e. assuming a Subject line could contain
> any char), could I do an exclusion list instead? i.e. accept everything
> other than NULL, etc? And if so, can someone tell me what "etc" should
> actually be? ;-)

  I've been thinking about that a lot recently. The solution is
  probably in anomaly detection using statistics or neural networks.

  Here's an interesting paper on the subject:
  http://www.cs.ucsb.edu/~vigna/pub/2005_kruegel_vigna_robertson_CN05.pdf

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] modsecurity and spam in OWA

[Tom A. <tan...@oa...>]

Jason Haar wrote:
> Anyway, I had "SecFilterForceByteRange 32 126" and it blocked that URL
> as there was a char 228 in there
> 
> Sooo, what should I block instead? Given the fact that the Webapp needs
> to present almost any char (i.e. assuming a Subject line could contain
> any char), could I do an exclusion list instead? i.e. accept everything
> other than NULL, etc? And if so, can someone tell me what "etc" should
> actually be? ;-)

I've found SecFilterForceByteRange to provide false positives on
anything less than 0-255.  Unless you're running a very simple website,
you just don't know when a user will enter a valid character outside of
your arbitrary range.  As you said, many applications require the use of
almost any character.  I addressed user complaints over a period of
months, slowly expanding the range, until I was left at 0-255 before the
complaints stopped.

As far as blocking certain characters, yes you can, but even NULL may
give false positives.  Whatever that list may be is entirely driven by
what your site needs to process.

Tom

Re: [mod-security-users] modsecurity and spam in OWA

[Ivan R. <iv...@we...>]

Tom Anderson wrote:
> Jason Haar wrote:
> 
>> Anyway, I had "SecFilterForceByteRange 32 126" and it blocked that URL
>> as there was a char 228 in there
>>
>> Sooo, what should I block instead? Given the fact that the Webapp needs
>> to present almost any char (i.e. assuming a Subject line could contain
>> any char), could I do an exclusion list instead? i.e. accept everything
>> other than NULL, etc? And if so, can someone tell me what "etc" should
>> actually be? ;-)
> 
> 
> I've found SecFilterForceByteRange to provide false positives on
> anything less than 0-255.  Unless you're running a very simple website,
> you just don't know when a user will enter a valid character outside of
> your arbitrary range.  As you said, many applications require the use of
> almost any character.  I addressed user complaints over a period of
> months, slowly expanding the range, until I was left at 0-255 before the
> complaints stopped.

  That's probably true if you want to have one configuration for
  all sites on a shared hosting server. But if you are controlling
  your own ModSecurity configuration then you surely now the
  character set you are using. And if you need to include all
  sorts of characters you are much better off using Unicode with
  UTF-8 validation feature.


> As far as blocking certain characters, yes you can, but even NULL may
> give false positives.  Whatever that list may be is entirely driven by
> what your site needs to process.

  I am not aware of any legitimate use of a NULL byte. Can you
  provide an example?

-- 
Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

Re: [mod-security-users] modsecurity and spam in OWA

[Tom A. <tan...@oa...>]

Ivan Ristic wrote:
>   I am not aware of any legitimate use of a NULL byte. Can you
>   provide an example?

I don't recall, but I know I was blocking it and I had to stop for some 
legitimate reason.  The best thing to do is to block it and then see if 
any of your users complain about being blocked.

Tom