Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 9 replies
  • Subscribers 0 subscribers
  • Views 3404 views
  • Users 0 members are here
Options
Suggested

[7.250] Snort rule false positive with specific POP3 server [NOTABUG]

RFCat_vk_01
Hi,
I suspect this will more than likely be a pattern update issue.

For the last 2 days when I start my PC it causes IM/P2P to show attacks from Apple Quicktime exploit. I use itunes to listen to webradio. This has worked without causing logs lkie this for a number of weeks.


Also the firewall notification e-mail is not being delivered. I can see it being sent from the smtp log and labeled delivered, but it is not returning to me as pop3 e-mail. Might have ISP problems with e-mail on this account, because when I forwarded th emessage it didn't arrive. It arrives in the hotmail account without a problem. No, it will not be a password issue because I would not be able to access the internet.

Ian M

Reviewing the report on my external e-mail site it would appear that the pop3 e-mail coming from one of my accounts with the ISP has been declared an Apple Quicktime attack as per the attached jpeg. I have 2 accounts and my family have 2 more accounts and only one is showing this problem.
Parents
  • 0
    I've seen this error before at one customer's site... just disable that IPS rule, it's a false positive. It was the same scenario, traffic from their ISPs POP3 Server was occasionally being flagged this way, though there was nothing going on.  That rule is basically worthless... and it's a problem in previous versions too, not just 7.250.

    As to the email not being delivered... make sure the sending email address the Astaro uses is a legit email address on the ISPs domain... in other words, if your personal POP3 accounts are yourname@yourisp.net, make sure the sending email address for reports, notifications, etc. is using a real email address on the yourisp.net domain (I use the same account as the admin user for POP3 users).  I assume you're also using the new Notification option to point your ASG at the ISP's SMTP server for notifications; if not, you'll need to do that.  I'm testing 7.250 using a similar setup, these features are all working fine.
  • 0 in reply to BrucekConvergent
    Hi Bruce,
    I have been using the ASG for a number of years now, occasionally I would get a strange block on an odd function but never on one site.

    2 or 3 days ago a new IPS rule must have been released that has decided that my ISPs pop3 address is attacking my firewall. It only affected one ISP, I have 2 accounts on one ISP and 2 on another.

    I even installed mail on the development linux box in an attempt to prove whether it was the ASG or a MS outlook update for Vista. Proved it to be the ASG.

    I have disabled rule 12741 and now all my missing e-mail has arrived.

    Forgot to mention I have the pop3 proxy and prefetch enabled.

    Ian M
Reply
  • 0 in reply to BrucekConvergent
    Hi Bruce,
    I have been using the ASG for a number of years now, occasionally I would get a strange block on an odd function but never on one site.

    2 or 3 days ago a new IPS rule must have been released that has decided that my ISPs pop3 address is attacking my firewall. It only affected one ISP, I have 2 accounts on one ISP and 2 on another.

    I even installed mail on the development linux box in an attempt to prove whether it was the ASG or a MS outlook update for Vista. Proved it to be the ASG.

    I have disabled rule 12741 and now all my missing e-mail has arrived.

    Forgot to mention I have the pop3 proxy and prefetch enabled.

    Ian M
Children
  • 0 in reply to RFCat_vk_01
    That specific rule started causing issues at a customer's site of mine over a month and half ago; it isn't new.  They are using POP3 the same way you are, no POP3 Proxy (they didn't buy the Email security option).... by any chance are your email servers with "megamail" or TW Telecom?  That's who this customer uses with the same problem.  99% of my customers have their own inhouse SMTP Servers, so this is the only customer I've seen this at... I imagine if I had more customers that used POP3, I probably would be seeing it more often.  Anyhow, glad disabling the rule worked for you.
  • 0 in reply to BrucekConvergent
    Hi Bruce,
    the ISP is iinet an Australian company. I don't have a problem with the other ISP I use, bigpond.com.

    A point of interest is that my wife has an account with iinet and her pop3 mail doesn't get a re-action from the ASG. Strange. I hadn't changed my configuration regarding pop3 mail for quite a while, iinet provides facilities to block or tag spam, scan e-mail for all the nasties etc and these were all enabled on all accounts.

    Ian M
  • 0 in reply to RFCat_vk_01
    It's probably a product of the POP3 mail server software that your ISP and the customer that I have that has the same problem... something in the communication stream is triggering it.  It never triggers with a POP3 provider I use for home email... so go figure.  The HELO string I get from the troublesome one is "Bigfoot v 1.0" ... I've never heard of it.
  • 0 in reply to BrucekConvergent
    I'm not labelling this is a bug since the fuzziness in Snort rules is more or less by design. I'd also recommend to disable the rule ... [;)]
  • 0 in reply to tom_01
    Hi Tom,
    I think you miss a bit of the point. It was working fine and then bingo total rejection for one e-mail address.

    I have disabled the rule.

    Ian M
  • 0 in reply to RFCat_vk_01
    I guess something in an email message triggered this. Does it work again (with rule enabled) when the server mailbox was flushed?
  • 0 in reply to tom_01
    Tom, my customer that had this same issue with 7.104 / 7.201 would sporadically have this rule trigger... if he cleared the mailbox via the ISP's webmail option, it would work for an undetermined amount of time (sometimes hours, sometimes days, sometimes a week) until it got triggered again.  Attachments seemed to cause it... and these were random attachments; sometimes tiff files, a lot of .dwg (Autocad) files, etc.  That rule is simply too flakey to trust if someone's running POP3 through the Astaro... not a big deal, it's part of a list of 6 rules or so that I disable on every Astaro I configure which are always false positive issue generators.