Re: [Exim] Blocking sobig.f

Góra strony
Delete this message
Reply to this message
Autor: Harald Meland
Data:  
Dla: Alan J. Flavell
CC: Exim users list
Temat: Re: [Exim] Blocking sobig.f
[Alan J. Flavell]

> Problem is, we'd noticed that hosts infested with the problem were
> going HELO with an unqualified name (i.e matched ^[-A-Z0-9]+$ ) but
> that just a tiny number of bona fide hosts were sending us mail with
> a HELO which was an unqualified name. However, the sobigs were all
> in upper case, whereas the bona fides were in lower case.


Over here, we've started blocking hosts that doesn't include at least
one dot in $sender_helo_name (except on connections from our own IP
ranges, due to MUA crappiness).

If I've understood RFC 2821 correctly, it says that the HELO/EHLO
argument must be either a FQDN or an address literal -- and hence must
include at least one dot.


Additionally, we're blocking W32/Sobig.F with the following DATA ACL:

  # Don't accept Sobig.F messages.
  deny    message       = "\
    By our heuristics this message looks like the W32/Sobig.F\n\
    worm, which we'd like to keep out of our system.\n\
    Contact <postmaster@???> if you think our heuristics\n\
    are wrong about this."
          condition     = ${if and \
   {\
    {match {$header_subject:}\
           {\N^(Thank you!|Your details|\
                Re: (Approved|Details|Re: My details|Thank you!|That movie|\
                     Wicked screensaver|Your application))$\N}}\
    {match {$message_body}\
           {\N(See|Please see) the attached file for details\
            .*\
            filename="(movie0045\.pif|wicked_scr\.scr|application\.pif|\
                       document_9446\.pif|details\.pif|your_details\.pif|\
                       thank_you\.pif|document_all\.pif|your_document\.pif)" \
            .*\
            AAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZS ?\
            BydW4gaW4g\N}}\
   }{true}}


(which seems to work with message_body_visible set as low as 600).

The Sobig heuristic check have rejected over 11000 messages for us in
the nearly 6 hours it's been active.

The reason we're rejecting instead of dropping is that the test really
is only heuristics; if we've gotten them wrong, somehow, it would be
bad to silently drop messages on the floor.

Additionally, we're using the following idiom for having mail to
postmaster bypass the heuristics:

In the RCPT ACL:

  accept  local_parts   = postmaster
          domains       = +local_domains


  # Add all other (non-<postmaster@local_domains>) recipients to
  # acl_m0, for use in the DATA ACL.  Note that the 'warn' verb here
  # will not actually do anything, as there are no modifiers.
  warn    set acl_m0    = $local_part@$domain:$acl_m0



At the top of the DATA ACL:

  # Accept mail to postmaster in any local domain, without any further
  # DATA checks.
  accept  condition     = ${if !def:acl_m0 {true}}



...so if the test should in fact turn out to produce any false
positives, the sender will get a bounce that hopefully includes our
message, and can then easily get in touch with us.
--
Harald