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

postfix rejecting botnet mail as intended -- is this a reasonable server load, or is there more config to do?

Expand Messages
  • grantksupport@...
    Hello, I routinely see pulses of the following traffic, from myriad IPs around the planet, hitting my mailservers postfix front-ends: ... May 15 09:02:12 mx
    Message 1 of 9 , May 17, 2014
      Hello,

      I routinely see 'pulses' of the following traffic, from myriad IPs
      around the planet, hitting my mailservers' postfix front-ends:

      ...
      May 15 09:02:12 mx postfix/smtpd[26321]: connect from
      unknown[69.198.138.134]
      May 15 09:02:12 mx postfix/smtpd[26321]: NOQUEUE: reject: RCPT from
      unknown[69.198.138.134]: 554 5.7.1 Service unavailable; Client host
      [69.198.138.134] blocked using b.barracudacentral.org;
      from=<quarriesypa40@...> to=<badmail1@...> proto=ESMTP
      helo=<iGateway>
      May 15 09:02:12 mx postfix/smtpd[26321]: NOQUEUE: reject: RCPT from
      unknown[69.198.138.134]: 554 5.7.1 <badmail2@...>: Recipient
      address rejected: 554 5.7.1 Service unavailable;
      from=<quarriesypa40@...> to=<badmail2@...> proto=ESMTP
      helo=<iGateway>
      May 15 09:02:12 mx postfix/smtpd[26321]: NOQUEUE: reject: RCPT from
      unknown[69.198.138.134]: 554 5.7.1 <badmail3@...>: Recipient
      address rejected: 554 5.7.1 Service unavailable;
      from=<quarriesypa40@...> to=<badmail3@...> proto=ESMTP
      helo=<iGateway>
      May 15 09:02:12 mx postfix/smtpd[26321]: NOQUEUE: reject: RCPT from
      unknown[69.198.138.134]: 554 5.7.1 <badmail4@...>: Recipient
      address rejected: 554 5.7.1 Service unavailable;
      from=<quarriesypa40@...> to=<badmail4@...> proto=ESMTP
      helo=<iGateway>
      May 15 09:02:12 mx postfix/smtpd[26321]: NOQUEUE: reject: RCPT from
      unknown[69.198.138.134]: 554 5.7.1 <badmail5@...>: Recipient
      address rejected: 554 5.7.1 Service unavailable;
      from=<quarriesypa40@...> to=<badmail5@...> proto=ESMTP
      helo=<iGateway>
      May 15 09:02:12 mx postfix/smtpd[26321]: NOQUEUE: reject: RCPT from
      unknown[69.198.138.134]: 554 5.7.1 <badmail6@...>: Recipient
      address rejected: 554 5.7.1 Service unavailable;
      from=<quarriesypa40@...> to=<badmail6@...> proto=ESMTP
      helo=<iGateway>
      May 15 09:02:12 mx postfix/smtpd[26321]: NOQUEUE: reject: RCPT from
      unknown[69.198.138.134]: 554 5.7.1 Service unavailable; Client host
      [69.198.138.134] blocked using b.barracudacentral.org;
      from=<quarriesypa40@...> to=<badmail7@...> proto=ESMTP
      helo=<iGateway>
      May 15 09:02:12 mx postfix/smtpd[26321]: NOQUEUE: reject: RCPT from
      unknown[69.198.138.134]: 554 5.7.1 <badmail8@...>: Recipient
      address rejected: 554 5.7.1 Service unavailable;
      from=<quarriesypa40@...> to=<badmail8@...> proto=ESMTP
      helo=<iGateway>
      May 15 09:02:12 mx postfix/smtpd[26321]: NOQUEUE: reject: RCPT from
      unknown[69.198.138.134]: 554 5.7.1 <badmail9@...>: Recipient
      address rejected: 554 5.7.1 Service unavailable;
      from=<quarriesypa40@...> to=<badmail9@...> proto=ESMTP
      helo=<iGateway>
      May 15 09:02:12 mx postfix/smtpd[26321]: lost connection after DATA from
      unknown[69.198.138.134]
      May 15 09:02:12 mx postfix/smtpd[26321]: disconnect from
      unknown[69.198.138.134]
      ...

      I understand this is likely botnet-generated traffic. They occur all
      day long, typically ~1-10 times/minute.

      I understand that postfix is doing the job I intend in rejecting this
      traffic.

      Iiuc, postfix caches some IP, DNS, etc data to keep performance
      efficient in such cases, but I do NOT understand enough about it to know
      if these 'pulses' of ~10 connections per 1-2 seconds represent a load on
      the system that's unreasonable, and should be further limited.

      I'd appreciate some additional insight as to whether this ^^^ is
      considered normal/typical load, and if not, any recommendation as to
      what additional protection methods to read about & employ.

      Thanks,

      Grant
    • lists@rhsoft.net
      ... typical noise ... rejected pre-queue, fine ... there is not much to limit in the case above you can set reject_non_fqdn_helo_hostname before the RBL in
      Message 2 of 9 , May 17, 2014
        Am 17.05.2014 18:13, schrieb grantksupport@...:
        > I routinely see 'pulses' of the following traffic, from myriad IPs
        > around the planet, hitting my mailservers' postfix front-ends:

        typical noise

        > May 15 09:02:12 mx postfix/smtpd[26321]: NOQUEUE: reject: RCPT from
        > unknown[69.198.138.134]: 554 5.7.1 <badmail8@...>: Recipient
        > address rejected: 554 5.7.1 Service unavailable;
        > from=<quarriesypa40@...> to=<badmail8@...> proto=ESMTP
        > helo=<iGateway>

        rejected pre-queue, fine

        > Iiuc, postfix caches some IP, DNS, etc data to keep performance
        > efficient in such cases, but I do NOT understand enough about it to know
        > if these 'pulses' of ~10 connections per 1-2 seconds represent a load on
        > the system that's unreasonable, and should be further limited.

        there is not much to limit

        in the case above you can set "reject_non_fqdn_helo_hostname"
        before the RBL in your restrictions which needs also change
        "smtpd_helo_required " to yes to be effective

        keep in mind restrictions are always processed in their
        order and so you should have the cheapest one at the begin
      • Viktor Dukhovni
        ... Typical input capacity of a Postfix mail server is over 100 messages per second (sometimes 10s of messages per second if performing CPU- intensive content
        Message 3 of 9 , May 17, 2014
          On Sat, May 17, 2014 at 09:13:08AM -0700, grantksupport@... wrote:

          > I understand this is likely botnet-generated traffic. They occur all
          > day long, typically ~1-10 times/minute.

          Typical input capacity of a Postfix mail server is over 100 messages
          per second (sometimes 10s of messages per second if performing CPU-
          intensive content filtering). This includes the cost of writing
          the message to disk, and related processing.

          The cost of rejecting 1-10 messages per minute is negligible.

          --
          Viktor.
        • grantksupport@...
          Hello ... I m pretty sure I already have that set correctly. I ll read-up and re-check. ... That s understood. Thanks! Grant
          Message 4 of 9 , May 17, 2014
            Hello
            On Sat, May 17, 2014, at 09:21 AM, lists@... wrote:
            > in the case above you can set "reject_non_fqdn_helo_hostname"
            > before the RBL in your restrictions which needs also change
            > "smtpd_helo_required " to yes to be effective

            I'm pretty sure I already have that set correctly. I'll read-up and
            re-check.

            > keep in mind restrictions are always processed in their
            > order and so you should have the cheapest one at the begin

            That's understood. Thanks!

            Grant
          • grantksupport@...
            Hello ... I think I was unclear. Just to be sure, by typically ~1-10 times/minute I meant 1-10 of these *bursts* per minute; i.e. up to ~100 messages
            Message 5 of 9 , May 17, 2014
              Hello

              On Sat, May 17, 2014, at 09:23 AM, Viktor Dukhovni wrote:
              > > I understand this is likely botnet-generated traffic. They occur all
              > > day long, typically ~1-10 times/minute.
              >
              > Typical input capacity of a Postfix mail server is over 100 messages
              > per second (sometimes 10s of messages per second if performing CPU-
              > intensive content filtering). This includes the cost of writing
              > the message to disk, and related processing.
              >
              > The cost of rejecting 1-10 messages per minute is negligible.

              I think I was unclear. Just to be sure, by

              "typically ~1-10 times/minute"

              I meant 1-10 of these *bursts* per minute; i.e. up to ~100 messages
              attempted per minute.

              Not that it makes any difference -- from your comment, that's still well
              within postfix's capabilities.

              Thanks!

              Grant
            • lists@rhsoft.net
              ... peaks of 100 rejected messages per minute is *nothing* frankly you can receive 100 messages per minute with no real load we have days with 1200000 rejected
              Message 6 of 9 , May 17, 2014
                Am 17.05.2014 18:30, schrieb grantksupport@...:
                > On Sat, May 17, 2014, at 09:23 AM, Viktor Dukhovni wrote:
                >>> I understand this is likely botnet-generated traffic. They occur all
                >>> day long, typically ~1-10 times/minute.
                >>
                >> Typical input capacity of a Postfix mail server is over 100 messages
                >> per second (sometimes 10s of messages per second if performing CPU-
                >> intensive content filtering). This includes the cost of writing
                >> the message to disk, and related processing.
                >>
                >> The cost of rejecting 1-10 messages per minute is negligible.
                >
                > I think I was unclear. Just to be sure, by
                >
                > "typically ~1-10 times/minute"
                >
                > I meant 1-10 of these *bursts* per minute; i.e. up to ~100 messages
                > attempted per minute.

                peaks of 100 rejected messages per minute is *nothing*
                frankly you can receive 100 messages per minute with no real load

                we have days with 1200000 rejected messages on a Barracuda appliance
                which in many cases even reveice and store the complete message for
                analyzes while reject at end-of-data, postfix usually don't receive
                a message it rejects and "hangs up" before message data

                120000 in 24 hours = 120000 / 1440 = 833 per minute as average and
                you see peaks of 5000 rejected messages per minute on such days
              • grantksupport@...
                Hello, ... Ok, it s pretty clear -- I should stop worrying. There s no problem here. Thanks! ... As I started looking I realize that I don t understand
                Message 7 of 9 , May 17, 2014
                  Hello,

                  On Sat, May 17, 2014, at 09:37 AM, lists@... wrote:
                  > peaks of 100 rejected messages per minute is *nothing*
                  > frankly you can receive 100 messages per minute with no real load
                  >
                  > we have days with 1200000 rejected messages on a Barracuda appliance
                  > which in many cases even reveice and store the complete message for
                  > analyzes while reject at end-of-data, postfix usually don't receive
                  > a message it rejects and "hangs up" before message data
                  >
                  > 120000 in 24 hours = 120000 / 1440 = 833 per minute as average and
                  > you see peaks of 5000 rejected messages per minute on such days

                  Ok, it's pretty clear -- I should stop worrying. There's no 'problem'
                  here. Thanks!


                  > keep in mind restrictions are always processed in their
                  > order and so you should have the cheapest one at the begin

                  As I started looking I realize that I don't understand enough about
                  what's cheap, and wha't not so cheap. So I have to get back to some
                  reading.

                  As a first check with you, though, from this server I have from

                  postconf smtpd_recipient_restrictions

                  the following current order

                  check_recipient_access hash:/usr/local/etc/postfix/conf/traps
                  reject_non_fqdn_recipient
                  permit_sasl_authenticated
                  permit_mynetworks
                  reject_unlisted_recipient
                  reject_non_fqdn_sender
                  reject_unknown_sender_domain
                  reject_rbl_client b.barracudacentral.org
                  reject_rbl_client zen.spamhaus.org
                  check_policy_service unix:private/policy
                  permit

                  which I've tried to keep from server to server. I get that it's a naive
                  copy, and I'll do my homework.

                  Is there any GLARING problem in the order above?

                  Thanks.

                  Grant
                • lists@rhsoft.net
                  ... looks fine, i would place the following on top! reject_non_fqdn_recipient reject_non_fqdn_sender reject_unlisted_sender you usually don t want
                  Message 8 of 9 , May 17, 2014
                    Am 17.05.2014 18:51, schrieb grantksupport@...:
                    > As a first check with you, though, from this server I have from
                    >
                    > postconf smtpd_recipient_restrictions
                    >
                    > the following current order
                    >
                    > check_recipient_access hash:/usr/local/etc/postfix/conf/traps
                    > reject_non_fqdn_recipient
                    > permit_sasl_authenticated
                    > permit_mynetworks
                    > reject_unlisted_recipient
                    > reject_non_fqdn_sender
                    > reject_unknown_sender_domain
                    > reject_rbl_client b.barracudacentral.org
                    > reject_rbl_client zen.spamhaus.org
                    > check_policy_service unix:private/policy
                    > permit
                    >
                    > which I've tried to keep from server to server. I get that it's a naive
                    > copy, and I'll do my homework.
                    >
                    > Is there any GLARING problem in the order above?

                    looks fine, i would place the following on top!

                    reject_non_fqdn_recipient
                    reject_non_fqdn_sender
                    reject_unlisted_sender

                    you usually don't want non-full-qualified addresses or invalid senders
                    even in case of authenticated users or from trusted machines and for
                    cron-mails and such things smtpd-restrictions don't apply at all because
                    they are using the sendmail-binary/pickup

                    be careful that "check_recipient_access" never says "OK" or you get a open relay
                  • grantksupport@...
                    ... I ve reordered those, ADDING the reject_unlisted_sender which I did not have. Reading about it at postconf.5.html your comments certainly make sense to
                    Message 9 of 9 , May 17, 2014
                      On Sat, May 17, 2014, at 09:58 AM, lists@... wrote:
                      > looks fine, i would place the following on top!
                      >
                      > reject_non_fqdn_recipient
                      > reject_non_fqdn_sender
                      > reject_unlisted_sender
                      >
                      > you usually don't want non-full-qualified addresses or invalid senders
                      > even in case of authenticated users or from trusted machines and for
                      > cron-mails and such things smtpd-restrictions don't apply at all because
                      > they are using the sendmail-binary/pickup

                      I've reordered those, ADDING the " reject_unlisted_sender" which I did
                      not have.

                      Reading about it at postconf.5.html your comments certainly make sense
                      to me.

                      I have a vague recollection that I did, long ago, and caused myself some
                      sort of problem, but I can't find it in my notes.

                      > be careful that "check_recipient_access" never says "OK" or you get a
                      > open relay

                      Yes. It ONLY contains REJECTS, no OKs.

                      Thanks for the advice!

                      Grant
                    Your message has been successfully submitted and would be delivered to recipients shortly.