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

Outbound RBL

Expand Messages
  • list@airstreamcomm.net
    We run a small cluster of postfix servers that are dedicated outbound relayhosts for our customers. Beyond the outbound postfix cluster we have another
    Message 1 of 8 , Jan 31, 2012
    • 0 Attachment
      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.
    • Noel Jones
      ... Most people address this with sender rate limits using a policy service such as policyd or postfwd, possibly combined with outbound virus/spam scanning.
      Message 2 of 8 , Jan 31, 2012
      • 0 Attachment
        On 1/31/2012 8:03 PM, list@... wrote:
        > 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.
        >

        Most people address this with sender rate limits using a policy
        service such as policyd or postfwd, possibly combined with outbound
        virus/spam scanning.
        http://www.postfix.org/addon.html#policy

        Once the rate limit (or outbound virus/spam limit) is tripped, the
        account is flagged for an admin to check further, and maybe
        temporarily disabled depending on site policy.

        I'm not quite sure how an RBL would be useful here.


        -- Noel Jones
      • list@airstreamcomm.net
        On Tue, 31 Jan 2012 20:18:14 -0600, Noel Jones ... senders ... What we were thinking was using RBLs to dynamically block known
        Message 3 of 8 , Jan 31, 2012
        • 0 Attachment
          On Tue, 31 Jan 2012 20:18:14 -0600, Noel Jones <njones@...>
          wrote:
          > On 1/31/2012 8:03 PM, list@... wrote:
          >> 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.
          >>
          >
          > Most people address this with sender rate limits using a policy
          > service such as policyd or postfwd, possibly combined with outbound
          > virus/spam scanning.
          > http://www.postfix.org/addon.html#policy
          >
          > Once the rate limit (or outbound virus/spam limit) is tripped, the
          > account is flagged for an admin to check further, and maybe
          > temporarily disabled depending on site policy.
          >
          > I'm not quite sure how an RBL would be useful here.
          >
          >
          > -- Noel Jones

          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.
        • Noel Jones
          ... 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
          Message 4 of 8 , Jan 31, 2012
          • 0 Attachment
            On 1/31/2012 8:30 PM, list@... wrote:
            > On Tue, 31 Jan 2012 20:18:14 -0600, Noel Jones <njones@...>
            > wrote:
            >> On 1/31/2012 8:03 PM, list@... wrote:
            >>> 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.
            >>>
            >>
            >> Most people address this with sender rate limits using a policy
            >> service such as policyd or postfwd, possibly combined with outbound
            >> virus/spam scanning.
            >> http://www.postfix.org/addon.html#policy
            >>
            >> Once the rate limit (or outbound virus/spam limit) is tripped, the
            >> account is flagged for an admin to check further, and maybe
            >> temporarily disabled depending on site policy.
            >>
            >> I'm not quite sure how an RBL would be useful here.
            >>
            >>
            >> -- Noel Jones
            >
            > 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.

            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.)



            -- Noel Jones
          • /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 5 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 6 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 7 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 8 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.