Loading ...
Sorry, an error occurred while loading the content.

Re: Outbound RBL

Expand Messages
  • /dev/rob0
    ... Even a locally-maintained private DNSBL is the wrong approach. When spam is detected from an authenticated account, revoke the credentials. You have no
    Message 1 of 8 , Jan 31, 2012
    • 0 Attachment
      On Tue, Jan 31, 2012 at 08:54:33PM -0600, Noel Jones wrote:
      > On 1/31/2012 8:30 PM, list@... wrote:
      > > What we were thinking was using RBLs to dynamically block known
      > > malicious IPs before allowing SMTP Auth to occur, hopefully
      > > seeing a decrease in spam. Not sure if this would have
      > > unintended consequences, which is why I am consulting the list.
      >
      > That would probably cause a huge number of false positives; a
      > support desk nightmare.
      >
      > Many "consumer" IPs are listed on the popular RBLs. As a
      > consequence, legit users may be unable to send mail because their
      > dynamic IP was used by a spambot at some point in the past.
      >
      > I don't know of any RBLs that would be useful on incoming
      > authenticated mail.

      Even a locally-maintained private DNSBL is the wrong approach. When
      spam is detected from an authenticated account, revoke the
      credentials. You have no other good choice. Even after the user's
      system is purged of the ratware, you cannot be sure that these
      credentials were not forwarded to the botnet's control node[s].

      Detection of a spamming account is done as Noel suggested, through
      rate limiting (and possibly behavioral monitoring) policy daemons.
      Content filtering of user-submitted mail is also important. Most
      malware will spew mail containing positive URIBL/SURBL hits.
      SpamAssassin can do this (I recommend using SA from amavisd-new.)

      > You can test this yourself by inserting "warn_if_reject
      > reject_rbl_client zen.spamhaus.org" just before
      > permit_sasl_authenticated. Then watch your logs for
      > reject_warning: from legit connections. (this is a
      > logging-only function; the client is not rejected and
      > sees no additional messages.)

      Perhaps a slightly less insane ;) test would be to check
      xbl.spamhaus.org at that point. But hotels and public hotspots are
      often listed there. You might catch a few bad users, but you will
      *not* have reasonable protection for clean users.
      --
      http://rob0.nodns4.us/ -- system administration and consulting
      Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
    • Gábor Lénárt
      ... Yes, however in our practice, there is good reasons to block the IP too (if it s not our IP, then of course we have the chance to solve the situation
      Message 2 of 8 , Feb 1, 2012
      • 0 Attachment
        On Tue, Jan 31, 2012 at 09:44:22PM -0600, /dev/rob0 wrote:
        > On Tue, Jan 31, 2012 at 08:54:33PM -0600, Noel Jones wrote:
        > > On 1/31/2012 8:30 PM, list@... wrote:
        > > > What we were thinking was using RBLs to dynamically block known
        > > > malicious IPs before allowing SMTP Auth to occur, hopefully
        > > > seeing a decrease in spam. Not sure if this would have
        > > > unintended consequences, which is why I am consulting the list.
        > >
        > > That would probably cause a huge number of false positives; a
        > > support desk nightmare.
        > >
        > > Many "consumer" IPs are listed on the popular RBLs. As a
        > > consequence, legit users may be unable to send mail because their
        > > dynamic IP was used by a spambot at some point in the past.
        > >
        > > I don't know of any RBLs that would be useful on incoming
        > > authenticated mail.
        >
        > Even a locally-maintained private DNSBL is the wrong approach. When
        > spam is detected from an authenticated account, revoke the
        > credentials. You have no other good choice. Even after the user's
        > system is purged of the ratware, you cannot be sure that these
        > credentials were not forwarded to the botnet's control node[s].

        Yes, however in our practice, there is good reasons to "block" the IP too
        (if it's not our IP, then of course we have the chance to solve the
        situation better with contacting the current user of the IP - anyway,
        "not our IP pool" is quite a good sign that smtp username/passwd is
        used illegally from there; for sure not always, but there is a good chance
        for that):

        * it's fairly common that the IP tries to abuse another smtp user of ours
        then in the future
        * it helps decrease the load of the submit server: even if revoke user's
        crendentials, it has the cost (which is maybe more than using a locally
        stored mail submission IP blacklist like stuff) that user must be
        checked, etc. The "evil" IP still tries to send mail for hours (or even
        days - in our practice again) even after revokation of user's
        credentials, which can consume resources of the submit server.
        [that was the reason I thought about using postscreen for mail submission
        but only for BL features and using a "local" BL, so postfix smtpd
        processes, smtp auth stuffs etc are not under load because of these
        abusers/spammers]

        We usually revoke submit user's credentials (of course), we inform the user
        about the problem, and we block (with a locally stored list) of the IP which
        abused the mail account, _if_ the IP does not seems to be part of our IP
        pool, and either not the IP of "neighbour ISPs" in our country (which is
        quite common that users use different local ISPs using the same ISP's mail
        submission service though) and also seems to be a dynamic IP pool somewhere
        or no PTR record, etc etc.

        For sure, it's quite a "manual" work, and not always done just in extreme
        cases when the IP does "really evil things".

        > > You can test this yourself by inserting "warn_if_reject
        > > reject_rbl_client zen.spamhaus.org" just before
        > > permit_sasl_authenticated. Then watch your logs for
        > > reject_warning: from legit connections. (this is a
        > > logging-only function; the client is not rejected and
        > > sees no additional messages.)
        >
        > Perhaps a slightly less insane ;) test would be to check
        > xbl.spamhaus.org at that point. But hotels and public hotspots are
        > often listed there. You might catch a few bad users, but you will
        > *not* have reasonable protection for clean users.

        Of course I only wrote about a "local RBL" which is maintained by ourselves
        for this purpose, not a general-purpose public BL.
      • Noel Jones
        ... A local RBL would make some sense; you didn t mention that earlier. That s not a whole lot different than maintaining a local blacklist or firewall rules.
        Message 3 of 8 , Feb 1, 2012
        • 0 Attachment
          On 2/1/2012 3:43 AM, Gábor Lénárt wrote:
          > Of course I only wrote about a "local RBL" which is maintained by ourselves
          > for this purpose, not a general-purpose public BL.

          A local RBL would make some sense; you didn't mention that earlier.
          That's not a whole lot different than maintaining a local blacklist
          or firewall rules. Once you identify IPs you don't want sending
          mail, there are multiple choices to block them -- a local RBL makes
          sharing a blacklist within a farm very easy.

          This is relatively lightweight; client connects, postfix does a DNS
          lookup, client is rejected. As long as the client isn't making
          DoS-level connections this is reasonably efficient. Postscreen
          could do this with "before 220 tests", but is likely overkill.

          At some point you may want to do something more complex than the
          standard "reject_rbl_client ...", such as "this username can't
          connect from this range" or "don't ever block this user". You can
          do the more complex queries by using a policy service that consults
          the RBL and can also consider the IP and username used. This still
          allows the client to AUTH and adds that overhead, but is far more
          flexible. This could be combined with Fail2Ban or similar built
          into your policy service to temporarily firewall IPs that exceed
          some level of bad behavior.


          HTH...



          -- Noel Jones
        • Robert Schetterer
          ... i wouldnt do it with rbl in this case, i see no sense in it you may use clamav-milter with sanesecurity sigs and simply get hold mails for human
          Message 4 of 8 , Feb 1, 2012
          • 0 Attachment
            Am 01.02.2012 03:03, schrieb list@...:
            > We run a small cluster of postfix servers that are dedicated outbound
            > relayhosts for our customers. Beyond the outbound postfix cluster we have
            > another cluster of mail filtering appliances that have served their purpose
            > very well, but we are starting to get more compromised account due to
            > phishing attempts and some of the spam is getting through the outbound
            > filters due to the volume of new spam messages.
            >
            > I am looking for advice on how to limit our exposure to malicious senders
            > that have access to a users credentials. One method we have zero
            > experience in is using RBLs, which I am hoping to learn more about.
            >

            i wouldnt do it with rbl in this case, i see no sense in it
            you may use clamav-milter with sanesecurity sigs and simply get hold mails
            for human inspection, or use amavis etc
            once find a hacked or compromised account, delete it ,or infom the user
            etc, or build some reject access list for them ( perhaps you can call
            this a local rbl )

            outbound spam is a problem ever

            --
            Best Regards

            MfG Robert Schetterer

            Germany/Munich/Bavaria
          Your message has been successfully submitted and would be delivered to recipients shortly.