Be careful using SBRS-based whitelisting

Unanswered Question
Sep 22nd, 2008

We've been using SBRS[6.0:10.0] as the basis for whitelisting for several years now. We just discovered last week that this is no longer a good idea. A host with SBRS +6.3 was sending us phish, which got right past our defenses due to the whitelisting. Ouch. Of course, it is for reasons exactly like this that phishers seek to obtain credentials on reputable mail servers.

Just thought I'd share the good news with others who might be interested...

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Rayman_Jr Tue, 09/23/2008 - 07:46

Yep, we have seen exactly the same. We do the same and SBRS[6.0:10.0] is the same than 'whitelist'. For us it means that this mail flow policy have much more relaxed rules (no rate limiting, no flow control, no DHAP, no sender DNS verification) but it still use SPAM and virus detection.

As an addition there is very, very rarely used 'Bypass SPAM filter' mail policy which is used only when true false positive Spam verdict happens, this will allow those special senders to bypass Spam detection but still obey SBRS and mail flow policies.

Bart_ironport Tue, 09/23/2008 - 15:50

We've been seeing the same thing as well. We used to install devices with a whitelist SBRS[6:10] by default. But over the past year or so, the reputation score of many servers has increased.

A lot of servers that I don't trust now have a score higher than 6. So I have updated our default policy to only whitelist scores higher than 7 and I'm concidering removing SBRS from the whitelist entirely.

Of course, the devices deployed with the old policy are now receiving more spam and I'm getting more and more complaints about this. Thats the problem with devices that "just work" - people forget how to manage them ;)

Rayman_Jr Wed, 09/24/2008 - 12:51

Bart is absolutely right about system that "just work", I haven't touched the mail flow policy levels for a very long time. I wonder what are the IronPort recommendations nowadays ?

I took nice chunk of mail_logs and ran it through 'spamtowho'. There were about 0.5% from accepted messages which had SBRS between +6 to +7 with spam positive verdict.

If you don't have CASE enabled for those sender you sure will get some spam into your mail boxes.

Donald Nash Fri, 09/26/2008 - 17:37

Well well, it just keeps getting better. I've changed our WHITELIST definition to SBRS[8.0:10.0], and that addressed the immediate problem. But now there's a new one. SBRS is one of the factors that CASE considers when making a spam determination, and the sending host has such a high reputation that it's pulling the spam verdict up from "CASE spam positive" to "CASE spam suspect". When the very same spam arrives from another source, it's "spam positive". I've been working with someone inside IronPort, and he's confirmed that this is indeed what's happening. The sending host has a deservedly good reputation because their spam volume overall is small. It's actually phish we're getting from them, most likely via webmail accounts which have themselves been phished.

Anyway, be on the lookout for this, too. It's easy enough to address with a content filter. Make sure your "suspected spam" policy includes tagging the message in some way (we use an X-header), then use a content filter that checks for the tag and for SBRS > 6.0, or whatever threshold is appropriate for you.

meyd45_ironport Wed, 10/01/2008 - 22:18

I found last year that SBRS was given far too much weight by CASE. An IP of -2.0 could have all of its traffic marked spam positive.

There was a request made for an option to force CASE to ignore any SBRS (so that SBRS could would only be used for flow control), but that request has not materialised yet.

Actions

This Discussion