This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Recent Increase In SPAM

Hi All,

We have an ASG 220 and since about mid December, we have seen an increase in SPAM getting through the filter. Here are the things I've tried. The owners used to get maybe 1-2 every couple of days. Now they get between 15-20 daily

1) Country Blocking - This works OK, but most of our SPAM is coming from the US. And so does our legitimate email...

2) RBLs - I currently have "Recommended" checked with bl.spamcop.net and b.barracudacentral.org in the list. I've checked the IPs of mail getting through against a multi RBL lookup site and the IPs either aren't listed or are only listed in one of the servers, and never the same one consistently enough to add it to my RBL check list. I have also found several IPs that CommTouch identifies as high risk yet these messages get through with no problem

3) Advanced Anti-Spam Options - everything is checked except Strict RDNS checks.

4) Log Analysis - I've spent several hours analyzing the SMTP proxy logs for SPAMing networks, domains, etc. While I've found some and blocked them, the issue is the SPAMers use these IP networks and domain names once or twice and then switch to something else.

5) Doing things like Regular Expressions is useless because they may send 4-5 emails that day using the same keywords, but then it stops and switches to something else. In other words, by the time I would have added them to the SPAM filter they've moved onto another campaign. One day it's Ellen Degeneres, the next day it's Weight Loss Spray, the next it's Term Life coverage.

6) Submitting SPAM to Sophos - I've added a button to the users' Outlook that sends an email to the is-spam address at sophos with the SPAM message as an attachment with the headers in tact. They have been doing this since Mid December.

7) Called support today - got nowhere. They logged in to look at my settings and all they could ell me is "your setup looks good, you're doing the right things by submitting messages to us but we have no answer for you on how to block these obvious SPAM messages."

To me it feels like the content scanning is utterly broken and useless. And me blocking IPs and regex expressions is a total waste of time because it will change within a day or so. If I go to the Mail Manager and only display messages that are SPAM there are no results. The only rejected messages are RBL or RDNS/HELO related. And the messages that are quarantined are only messages matching keywords we have manually added. Nothing from the Sophos pattern stuff.

Does anyone have any ideas to tighten this thing down?

Thanks!

This thread was automatically locked due to age.

Parents

0 BAlfson over 10 years ago
AND: That RDNS works at it's best you should use strict mode for it - a huge number of drops are usually due invalid RDNS, which is only tested in strict mode. You may loose lot of RDNS checks effectiveness here by not checking this small checkbox.

Sascha, when did you start using the strict mode?  When it was first offered, every client with Email Protection complained, so I changed everyone to NOT strict.  Maybe there's better compliance out there now?

b/c it was a blacklisted domain or IP address

In that case, the UTM would now catch these.

EVERY message I have submitted has passed the SPF check saying the IP is allowed to send mail for he domain. Is it just me or is this check almost useless?

Usually, amateur spammers won't take the time to create a valid domain with an SPF record.  Here are our stats for the last 24 hours:
RBL rejects: 56.1%
RDNS/HELO rejects: 33%
Spam quarantined/rejected: 7.6%
Address Verification rejects: 2.8%
SPF rejects: 0.5%
BATV rejects: 0%
Malware quarantined/rejected: 0%
Blacklist rejects: 0%

The sending IP from your first list is 162.221.192.92 is on seven blacklists in addition to cbl.abuseat.org.  The second one is not.  The spam-identification method used by CommTouch has problems with these sophisticated spams as it does with advance-fee fraud spams sent from Gmail, Yahoo, etc.  If you're using Outlook, I would recommend SpamBayes for those that have an issue with having to delete such spams.

Cheers - Bob
Sophos UTM Community Moderator
Sophos Certified Architect - UTM
Sophos Certified Engineer - XG
Gold Solution Partner since 2005

MediaSoft, Inc. USA
Cancel
Vote Up 0 Vote Down

Cancel
0 SouperGrover over 10 years ago in reply to BAlfson

Sascha, when did you start using the strict mode? When it was first offered, every client with Email Protection complained, so I changed everyone to NOT strict. Maybe there's better compliance out there now?

I had heard the same thing and have not checked this yet. I couldn't really get a straight answer out of the Sophos tech I talked to as to what it does. Bob, can you elaborate?

b/c it was a blacklisted domain or IP address

In that case, the UTM would now catch these.

The thing that blacklisted it was a different piece of software - not the UTM.

The sending IP from your first list is 162.221.192.92 is on seven blacklists in addition to cbl.abuseat.org. The second one is not. The spam-identification method used by CommTouch has problems with these sophisticated spams as it does with advance-fee fraud spams sent from Gmail, Yahoo, etc. If you're using Outlook, I would recommend SpamBayes for those that have an issue with having to delete such spams.

None of the spam is coming for major providers like Gmail, Yahoo or Hotmail.

I'm guessing that cbl.abuseat.org is one of the "Recommended" filters that Sophos is using in the back end? I've seen it pop up in the Mail Manager before and it's not in my list of manualy added servers. So, if that is the case and the RBL is working correctly (and I have no reason to believe otherwise), then the IP is listed now and was not listed at the time the message hit our UTM.

I've added in zen.spamhaus.org and dbl.dnsbl.sorbs.net as these were two (for spamhaus it was dbl. and sbl.) of the RBLs in the other utility that were flagging things as black listed. I've been watching the mail monitor and haven't seen any spam using them yet, but nothing is getting through either.

Question. Just want to make sure I have this right. The UTM passes the IP address of the connection through all RBLs until it finds a match, and then if no match is found the IP passes the check, right? Why do we care about the order they are in the list?
Cancel
Vote Up 0 Vote Down

Cancel
0 SouperGrover over 10 years ago in reply to SouperGrover

I'm starting ot notice a trend, but not sure of the Sophos will be able to do anything about it.

What I've been doing is taking all the SPAM that makes it through and running it in the Xeams Spam Simulator to see what it gets. MOST of the messages have blacklisted URIs in their messages that are listed with SURBL. Can the UTM be configured to check with these somehow?
Cancel
Vote Up 0 Vote Down

Cancel
0 Sascha Paris over 10 years ago in reply to SouperGrover

I had heard the same thing and have not checked this yet. I couldn't really get a straight answer out of the Sophos tech I talked to as to what it does. Bob, can you elaborate?

Hello Bob and SouperGrover

Yes, I remeber that...the change in RDNS was implemented 2 or 3 years ago, and the first implementation bricked that feature due lots of false positives. If I remeber right, the first implementation used a RFC conform method (I guess it was the one described here RFC 7001 - Message Header Field for Indicating Message Authentication Status ), which resolved the connection MTA / sender IP per RDNS back to a FQN, and checked, if that name matched to the helo name. This has led to lots of fales, because many companies didn't had a matching Reverse DNS entry, as usually customers are in control of the own forward DNS entries, bur Reverse DNS is property and maintained by your ISP, unless you own your own ip block / AS, and can not always be easily modified to your requirements.

After that the separation RDNS check and "strict" RDNS check method was introduced.

While RDNS simply checks, if you get a resolveable FQN in the helo string at all, this method is very limited, as it only drops things like "helo localhost" or "helo pppp".

The strict option does verify, that a given, valid FQN in the helo string also resolves back to the connecting sender IP (FCrDNS as described here Anti-spam techniques - Wikipedia, the free encyclopedia ). I assume, that's also the reason, why the HELO/RDNS check aren't two separated antispam features in UTM, as UTM doesn't make a complete FCrDNS because of the abve mentioned issues with missing "real" rever DNS entries from the ISP's, but makes a DNS lookup of the given FQN in the helo string.

So I personally expect the strict RDNS feature as "safe" with - from my experience - very low false positives due some misconfigured MTA's.

Against at least one of the two given spam samples you posted, the strict option would have helped:

Not helped for the first sample:

Received: from [173.236.118.136] (port=41418 helo=match.sulasobby.com)

$ nslookup match.sulasobby.com
Server: 127.0.1.1
Address: 127.0.1.1#53

Non-authoritative answer:
Name: match.sulasobby.com
Address: 173.236.118.136

But it would have blocked the second one

Received: from [162.221.192.92] (port=28880 helo=ship.bramagruys.com)

$ nslookup ship.bramagruys.com
Server: 127.0.1.1
Address: 127.0.1.1#53

Non-authoritative answer:
Name: ship.bramagruys.com
Address: 66.35.77.34

I personally always suggest to use the strict option, as it's quite effective. I recommend that since two or three years, and only seldom had issues due RDNS (usually SPF makes more headache [;)] )

Hope that explanation helps...
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 Sascha Paris over 10 years ago in reply to SouperGrover

I had heard the same thing and have not checked this yet. I couldn't really get a straight answer out of the Sophos tech I talked to as to what it does. Bob, can you elaborate?

Hello Bob and SouperGrover

Yes, I remeber that...the change in RDNS was implemented 2 or 3 years ago, and the first implementation bricked that feature due lots of false positives. If I remeber right, the first implementation used a RFC conform method (I guess it was the one described here RFC 7001 - Message Header Field for Indicating Message Authentication Status ), which resolved the connection MTA / sender IP per RDNS back to a FQN, and checked, if that name matched to the helo name. This has led to lots of fales, because many companies didn't had a matching Reverse DNS entry, as usually customers are in control of the own forward DNS entries, bur Reverse DNS is property and maintained by your ISP, unless you own your own ip block / AS, and can not always be easily modified to your requirements.

After that the separation RDNS check and "strict" RDNS check method was introduced.

While RDNS simply checks, if you get a resolveable FQN in the helo string at all, this method is very limited, as it only drops things like "helo localhost" or "helo pppp".

The strict option does verify, that a given, valid FQN in the helo string also resolves back to the connecting sender IP (FCrDNS as described here Anti-spam techniques - Wikipedia, the free encyclopedia ). I assume, that's also the reason, why the HELO/RDNS check aren't two separated antispam features in UTM, as UTM doesn't make a complete FCrDNS because of the abve mentioned issues with missing "real" rever DNS entries from the ISP's, but makes a DNS lookup of the given FQN in the helo string.

So I personally expect the strict RDNS feature as "safe" with - from my experience - very low false positives due some misconfigured MTA's.

Against at least one of the two given spam samples you posted, the strict option would have helped:

Not helped for the first sample:

Received: from [173.236.118.136] (port=41418 helo=match.sulasobby.com)

$ nslookup match.sulasobby.com
Server: 127.0.1.1
Address: 127.0.1.1#53

Non-authoritative answer:
Name: match.sulasobby.com
Address: 173.236.118.136

But it would have blocked the second one

Received: from [162.221.192.92] (port=28880 helo=ship.bramagruys.com)

$ nslookup ship.bramagruys.com
Server: 127.0.1.1
Address: 127.0.1.1#53

Non-authoritative answer:
Name: ship.bramagruys.com
Address: 66.35.77.34

I personally always suggest to use the strict option, as it's quite effective. I recommend that since two or three years, and only seldom had issues due RDNS (usually SPF makes more headache [;)] )

Hope that explanation helps...
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data