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

Re: Is this an attack?

Expand Messages
  • Birta Levente
    ... All of this should be rejected by 5xx, am I wrong? And I think this temporary lookup failure is not ok.... Show some log... Levi
    Message 1 of 14 , Jun 19, 2013
    • 0 Attachment
      On 19/06/2013 14:37, lst_hoe02@... wrote:
      >
      > Zitat von Andreas Kasenides <andreas@...>:
      >
      >> One of my mail servers (postfix 2.6) has been target of what seems to
      >> me to be an attack.
      >> The attacker tried to deliver messages to a non-existent user names
      >> formed as a long hex
      >> string. It only happened once from one particular client and kept
      >> going for some time.
      >> SMTP sessions were coming in one every second with three delivery
      >> attampts each.
      >> Here is a fragment of one single session:
      >>
      >> Out: 220 prot.xxxx.eu ESMTP Postfix
      >> In: EHLO xxxxxxxxxx
      >> Out: 250-prot.xxxx.eu
      >> Out: 250-PIPELINING
      >> Out: 250-SIZE 10240000
      >> Out: 250-VRFY
      >> Out: 250-ETRN
      >> Out: 250-ENHANCEDSTATUSCODES
      >> Out: 250-8BITMIME
      >> Out: 250 DSN
      >> In: MAIL FROM:<xxxx@...> SIZE=2881 BODY=7BIT
      >> Out: 250 2.1.0 Ok
      >> In: RCPT TO:<35150aa4c74ba30f04ede17ca25f18cd@...
      >> Out: 451 4.3.0 <35150aa4c74ba30f04ede17ca25f18cd@...>: Temporary
      >> lookup
      >> failure
      >> In: RCPT TO:<357f21a54e272af6a629ff7657eae27c@...>
      >> Out: 451 4.3.0 <357f21a54e272af6a629ff7657eae27c@...>: Temporary
      >> lookup
      >> failure
      >> In: RSET
      >> Out: 250 2.0.0 Ok
      >> In: MAIL FROM:<xxxxx@...> SIZE=2881 BODY=7BIT
      >> Out: 250 2.1.0 Ok
      >> In: RCPT TO:<947a7c9627f3977247586a4fca58bc67@...>
      >> Out: 451 4.3.0 <947a7c9627f3977247586a4fca58bc67@...>: Temporary
      >> lookup
      >> failure
      >> In: QUIT
      >> Out: 221 2.0.0 Bye
      >>
      >> Is this an attack of some sort?
      >
      > The address harvester of the spammers sometimes collect everything which
      > has a "@" in it and therefore even use message-ids in their spamlist.
      >
      > Nothing to worry about


      All of this should be rejected by 5xx, am I wrong?
      And I think this temporary lookup failure is not ok....

      Show some log...

      Levi
    • Jeroen Geilman
      ... You really don t want to enable VRFY on a public mailserver; it only enables more spammers to abuse you. Set disable_vrfy_command = yes in main.cf to
      Message 2 of 14 , Jun 19, 2013
      • 0 Attachment
        On 06/19/2013 02:33 PM, Birta Levente wrote:
        > On 19/06/2013 14:37, lst_hoe02@... wrote:
        >>
        >> Zitat von Andreas Kasenides <andreas@...>:
        >>
        >>> One of my mail servers (postfix 2.6) has been target of what seems to
        >>> me to be an attack.
        >>> The attacker tried to deliver messages to a non-existent user names
        >>> formed as a long hex
        >>> string. It only happened once from one particular client and kept
        >>> going for some time.
        >>> SMTP sessions were coming in one every second with three delivery
        >>> attampts each.
        >>> Here is a fragment of one single session:
        >>>
        >>> Out: 220 prot.xxxx.eu ESMTP Postfix
        >>> In: EHLO xxxxxxxxxx
        >>> Out: 250-prot.xxxx.eu
        >>> Out: 250-PIPELINING
        >>> Out: 250-SIZE 10240000
        >>> Out: 250-VRFY

        You really don't want to enable VRFY on a public mailserver; it only
        enables more spammers to abuse you.
        Set 'disable_vrfy_command = yes' in main.cf to globally disable it.

        >>> Out: 250-ETRN
        >>> Out: 250-ENHANCEDSTATUSCODES
        >>> Out: 250-8BITMIME
        >>> Out: 250 DSN
        >>> In: MAIL FROM:<xxxx@...> SIZE=2881 BODY=7BIT
        >>> Out: 250 2.1.0 Ok
        >>> In: RCPT TO:<35150aa4c74ba30f04ede17ca25f18cd@...
        >>> Out: 451 4.3.0 <35150aa4c74ba30f04ede17ca25f18cd@...>: Temporary
        >>> lookup
        >>> failure

        This means postfix attempted to verify if the recipient is valid, but
        failed to do so.
        Something is broken in your setup; either you have a broken non-hashed
        map, or you're misaddressing a networked service like LDAP or SQL.

        If *you* never come across this error normally, this is probably a later
        entry, for fallback, which you never reach with valid recipients.

        As instructed when you joined this list, provide non-verbose logs of one
        message, and the output of postconf -n.

        > All of this should be rejected by 5xx, am I wrong?

        By default, yes - IF postfix ever got that far. This is either a name
        lookup failure (indicating a problem with DNS), or a map failure,
        indicating one of the above.

        > And I think this temporary lookup failure is not ok....
        >
        > Show some log...

        Yes he should...


        --
        J...
      • Ansgar Wiechers
        ... Not really. Aside the fact that there are other ways to verify an address, I get a single VRFY every other month on my mail server. In my experience most
        Message 3 of 14 , Jun 19, 2013
        • 0 Attachment
          On 2013-06-19 Jeroen Geilman wrote:
          >>> Zitat von Andreas Kasenides <andreas@...>:
          >>>> Out: 250-VRFY
          >
          > You really don't want to enable VRFY on a public mailserver; it only
          > enables more spammers to abuse you.
          > Set 'disable_vrfy_command = yes' in main.cf to globally disable it.

          Not really. Aside the fact that there are other ways to verify an
          address, I get a single VRFY every other month on my mail server.

          In my experience most spammers don't actually care if an address is
          valid or not and blindly throw their crap at everything that looks at
          least remotely like a mail address.

          Regards
          Ansgar Wiechers
          --
          "Abstractions save us time working, but they don't save us time learning."
          --Joel Spolsky
        • Wietse Venema
          ... I agree. Technically, VRFY is implemented as RCPT TO without all the baggage of a mail transaction. The difference is that
          Message 4 of 14 , Jun 19, 2013
          • 0 Attachment
            Ansgar Wiechers:
            > On 2013-06-19 Jeroen Geilman wrote:
            > >>> Zitat von Andreas Kasenides <andreas@...>:
            > >>>> Out: 250-VRFY
            > >
            > > You really don't want to enable VRFY on a public mailserver; it only
            > > enables more spammers to abuse you.
            > > Set 'disable_vrfy_command = yes' in main.cf to globally disable it.
            >
            > Not really. Aside the fact that there are other ways to verify an
            > address, I get a single VRFY every other month on my mail server.
            >
            > In my experience most spammers don't actually care if an address is
            > valid or not and blindly throw their crap at everything that looks at
            > least remotely like a mail address.

            I agree. Technically, VRFY is implemented as RCPT TO without all
            the baggage of a mail transaction. The difference is that
            smtpd_client_recipient_rate_limit does not apply to VRFY, but that
            is easily fixed (I just copied some code from the RCPT TO handler).

            Wietse
          • Jeroen Geilman
            ... I seem to remember that allowing VRFY meant spammers could brute-force valid recipients; perhaps this was long ago and it is no longer true. -- J.
            Message 5 of 14 , Jun 19, 2013
            • 0 Attachment
              On 06/19/2013 07:32 PM, Wietse Venema wrote:
              > Ansgar Wiechers:
              >> On 2013-06-19 Jeroen Geilman wrote:
              >>>>> Zitat von Andreas Kasenides <andreas@...>:
              >>>>>> Out: 250-VRFY
              >>> You really don't want to enable VRFY on a public mailserver; it only
              >>> enables more spammers to abuse you.
              >>> Set 'disable_vrfy_command = yes' in main.cf to globally disable it.
              >> Not really. Aside the fact that there are other ways to verify an
              >> address, I get a single VRFY every other month on my mail server.
              >>
              >> In my experience most spammers don't actually care if an address is
              >> valid or not and blindly throw their crap at everything that looks at
              >> least remotely like a mail address.
              > I agree. Technically, VRFY is implemented as RCPT TO without all
              > the baggage of a mail transaction. The difference is that
              > smtpd_client_recipient_rate_limit does not apply to VRFY, but that
              > is easily fixed (I just copied some code from the RCPT TO handler).
              >
              > Wietse
              >

              I seem to remember that allowing VRFY meant spammers could brute-force
              valid recipients; perhaps this was long ago and it is no longer true.


              --
              J.
            • Noel Jones
              ... In the old days, spammers used VRFY dictionary attacks to collect valid addresses. Then admins started disabling VRFY and spammers switched to using RCTP
              Message 6 of 14 , Jun 19, 2013
              • 0 Attachment
                On 6/19/2013 12:56 PM, Jeroen Geilman wrote:
                > On 06/19/2013 07:32 PM, Wietse Venema wrote:
                >> Ansgar Wiechers:
                >>> On 2013-06-19 Jeroen Geilman wrote:
                >>>>>> Zitat von Andreas Kasenides <andreas@...>:
                >>>>>>> Out: 250-VRFY
                >>>> You really don't want to enable VRFY on a public mailserver; it
                >>>> only
                >>>> enables more spammers to abuse you.
                >>>> Set 'disable_vrfy_command = yes' in main.cf to globally disable
                >>>> it.
                >>> Not really. Aside the fact that there are other ways to verify an
                >>> address, I get a single VRFY every other month on my mail server.
                >>>
                >>> In my experience most spammers don't actually care if an address is
                >>> valid or not and blindly throw their crap at everything that
                >>> looks at
                >>> least remotely like a mail address.
                >> I agree. Technically, VRFY is implemented as RCPT TO without all
                >> the baggage of a mail transaction. The difference is that
                >> smtpd_client_recipient_rate_limit does not apply to VRFY, but that
                >> is easily fixed (I just copied some code from the RCPT TO handler).
                >>
                >> Wietse
                >>
                >
                > I seem to remember that allowing VRFY meant spammers could
                > brute-force valid recipients; perhaps this was long ago and it is no
                > longer true.
                >
                >


                In the old days, spammers used VRFY dictionary attacks to collect
                valid addresses. Then admins started disabling VRFY and spammers
                switched to using RCTP TO, which gives them the same information.

                My impression is that spammers now collect addresses other ways --
                web harvesting, viruses that steal address books -- and classic
                dictionary attacks are seldom used anymore (with email).

                There is no longer any particular reason to disable VRFY, nor any
                particular reason not to. Disabling it doesn't protect you from
                anything, leaving it on doesn't add anything particularly useful.


                -- Noel Jones
              • Andreas Kasenides
                ... Here is recap/explanation. After looking at this for several days I think I have a possible explanation very similar to the reply above. Apparently we are
                Message 7 of 14 , Jun 20, 2013
                • 0 Attachment
                  On 19-06-2013 14:37, lst_hoe02@... wrote:
                  > Zitat von Andreas Kasenides <andreas@...>:
                  >
                  >> One of my mail servers (postfix 2.6) has been target of what seems
                  >> to me to be an attack.
                  >> The attacker tried to deliver messages to a non-existent user names
                  >> formed as a long hex
                  >> string. It only happened once from one particular client and kept
                  >> going for some time.
                  >> SMTP sessions were coming in one every second with three delivery
                  >> attampts each.
                  >> Here is a fragment of one single session:
                  >>
                  >> Out: 220 prot.xxxx.eu ESMTP Postfix
                  >> In: EHLO xxxxxxxxxx
                  >> Out: 250-prot.xxxx.eu
                  >> Out: 250-PIPELINING
                  >> Out: 250-SIZE 10240000
                  >> Out: 250-VRFY
                  >> Out: 250-ETRN
                  >> Out: 250-ENHANCEDSTATUSCODES
                  >> Out: 250-8BITMIME
                  >> Out: 250 DSN
                  >> In: MAIL FROM:<xxxx@...> SIZE=2881 BODY=7BIT
                  >> Out: 250 2.1.0 Ok
                  >> In: RCPT TO:<35150aa4c74ba30f04ede17ca25f18cd@...
                  >> Out: 451 4.3.0 <35150aa4c74ba30f04ede17ca25f18cd@...>:
                  >> Temporary lookup
                  >> failure
                  >> In: RCPT TO:<357f21a54e272af6a629ff7657eae27c@...>
                  >> Out: 451 4.3.0 <357f21a54e272af6a629ff7657eae27c@...>:
                  >> Temporary lookup
                  >> failure
                  >> In: RSET
                  >> Out: 250 2.0.0 Ok
                  >> In: MAIL FROM:<xxxxx@...> SIZE=2881 BODY=7BIT
                  >> Out: 250 2.1.0 Ok
                  >> In: RCPT TO:<947a7c9627f3977247586a4fca58bc67@...>
                  >> Out: 451 4.3.0 <947a7c9627f3977247586a4fca58bc67@...>:
                  >> Temporary lookup
                  >> failure
                  >> In: QUIT
                  >> Out: 221 2.0.0 Bye
                  >>
                  >> Is this an attack of some sort?
                  >
                  > The address harvester of the spammers sometimes collect everything
                  > which has a "@" in it and therefore even use message-ids in their
                  > spamlist.
                  >
                  > Nothing to worry about
                  >
                  > Regards
                  >
                  > Andreas


                  Here is recap/explanation.
                  After looking at this for several days I think I have a possible
                  explanation very similar to the reply above. Apparently we are
                  dealing with a blind emai address harvester. Note that all user names
                  (string before @) are all 32 hex characters.
                  Going into my log files I noticed that such values appear in the
                  message-id's during SMTP transactions but also as part of the header
                  in the actual messages.
                  Apparently there has been some harvesting going on of mail addresses
                  where everything that has a "@" is picked up. The question is: was
                  this harvesting from our log files or our mail storage - a very serious
                  possibility which would indicate a break in.
                  It turns out that each type SMTP server assigns a slightly different
                  message-id,
                  so checking the logs and quierying a few domains it turns out that 32
                  character
                  long message-id's are assigned by EXIM. Sigh of relief, I ony operate
                  with Postfix.

                  My conclusion is that the harvester is blindly picking usernames and
                  domains
                  from wherever it can (possibly from compromised systems but also from
                  clear text net traffic) and pairing them at random!!

                  Any other ideas?
                  regards
                  Andreas
                • Birta Levente
                  ... I have in my logs these kind of recipients too. So you cannot do anything with this. I suggest you to upgrade to postfix 2.8+ and start using postscreen.
                  Message 8 of 14 , Jun 20, 2013
                  • 0 Attachment
                    On 20/06/2013 13:49, Andreas Kasenides wrote:
                    > On 19-06-2013 14:37, lst_hoe02@... wrote:
                    >> Zitat von Andreas Kasenides <andreas@...>:
                    >>
                    >>> One of my mail servers (postfix 2.6) has been target of what seems to
                    >>> me to be an attack.
                    >>> The attacker tried to deliver messages to a non-existent user names
                    >>> formed as a long hex
                    >>> string. It only happened once from one particular client and kept
                    >>> going for some time.
                    >>> SMTP sessions were coming in one every second with three delivery
                    >>> attampts each.
                    >>> Here is a fragment of one single session:
                    >>>
                    >>> Out: 220 prot.xxxx.eu ESMTP Postfix
                    >>> In: EHLO xxxxxxxxxx
                    >>> Out: 250-prot.xxxx.eu
                    >>> Out: 250-PIPELINING
                    >>> Out: 250-SIZE 10240000
                    >>> Out: 250-VRFY
                    >>> Out: 250-ETRN
                    >>> Out: 250-ENHANCEDSTATUSCODES
                    >>> Out: 250-8BITMIME
                    >>> Out: 250 DSN
                    >>> In: MAIL FROM:<xxxx@...> SIZE=2881 BODY=7BIT
                    >>> Out: 250 2.1.0 Ok
                    >>> In: RCPT TO:<35150aa4c74ba30f04ede17ca25f18cd@...
                    >>> Out: 451 4.3.0 <35150aa4c74ba30f04ede17ca25f18cd@...>: Temporary
                    >>> lookup
                    >>> failure
                    >>> In: RCPT TO:<357f21a54e272af6a629ff7657eae27c@...>
                    >>> Out: 451 4.3.0 <357f21a54e272af6a629ff7657eae27c@...>: Temporary
                    >>> lookup
                    >>> failure
                    >>> In: RSET
                    >>> Out: 250 2.0.0 Ok
                    >>> In: MAIL FROM:<xxxxx@...> SIZE=2881 BODY=7BIT
                    >>> Out: 250 2.1.0 Ok
                    >>> In: RCPT TO:<947a7c9627f3977247586a4fca58bc67@...>
                    >>> Out: 451 4.3.0 <947a7c9627f3977247586a4fca58bc67@...>:
                    >>> Temporary lookup
                    >>> failure
                    >>> In: QUIT
                    >>> Out: 221 2.0.0 Bye
                    >>>
                    >>> Is this an attack of some sort?
                    >>
                    >> The address harvester of the spammers sometimes collect everything
                    >> which has a "@" in it and therefore even use message-ids in their
                    >> spamlist.
                    >>
                    >> Nothing to worry about
                    >>
                    >> Regards
                    >>
                    >> Andreas
                    >
                    >
                    > Here is recap/explanation.
                    > After looking at this for several days I think I have a possible
                    > explanation very similar to the reply above. Apparently we are
                    > dealing with a blind emai address harvester. Note that all user names
                    > (string before @) are all 32 hex characters.
                    > Going into my log files I noticed that such values appear in the
                    > message-id's during SMTP transactions but also as part of the header
                    > in the actual messages.
                    > Apparently there has been some harvesting going on of mail addresses
                    > where everything that has a "@" is picked up. The question is: was
                    > this harvesting from our log files or our mail storage - a very serious
                    > possibility which would indicate a break in.
                    > It turns out that each type SMTP server assigns a slightly different
                    > message-id,
                    > so checking the logs and quierying a few domains it turns out that 32
                    > character
                    > long message-id's are assigned by EXIM. Sigh of relief, I ony operate
                    > with Postfix.
                    >
                    > My conclusion is that the harvester is blindly picking usernames and
                    > domains
                    > from wherever it can (possibly from compromised systems but also from
                    > clear text net traffic) and pairing them at random!!
                    >
                    > Any other ideas?
                    > regards
                    > Andreas
                    >
                    >
                    >


                    I have in my logs these kind of recipients too. So you cannot do
                    anything with this.

                    I suggest you to upgrade to postfix 2.8+ and start using postscreen.
                    Here, a 95%+ of spams is blocked by this.

                    BTW, I think you still have some problems with your mail system because
                    the lookup failure (show logs).


                    Levi
                  • Noel Jones
                    ... The Message-ID is stored as part of the message. Spammers harvest these from web forums, email archives, and other public sources. ... Almost certainly
                    Message 9 of 14 , Jun 20, 2013
                    • 0 Attachment
                      On 6/20/2013 5:49 AM, Andreas Kasenides wrote:

                      > Apparently there has been some harvesting going on of mail addresses
                      > where everything that has a "@" is picked up. The question is: was
                      > this harvesting from our log files or our mail storage - a very serious
                      > possibility which would indicate a break in.

                      The Message-ID is stored as part of the message. Spammers harvest
                      these from web forums, email archives, and other public sources.

                      > My conclusion is that the harvester is blindly picking usernames and
                      > domains
                      > from wherever it can (possibly from compromised systems but also from
                      > clear text net traffic) and pairing them at random!!

                      Almost certainly from harvesting publicly accessible web pages, not
                      from a system compromise.

                      Yes, these are often paired at random. Botnet operators have little
                      incentive to validate their user lists since it requires about the
                      same effort to send a few thousand messages as to send 100M messages.

                      This is more of a nuisance than an actual security issue. Assuming
                      your system properly rejects unknown recipients, it is unlikely to
                      cause any operational problems.

                      You should look into why you're getting temporary lookup failures in
                      your log. While that probably isn't a security issue, it is likely
                      reducing your performance and may also encourage some servers to
                      retry delivery, which multiplies the number of connections you receive.



                      -- Noel Jones
                    • Thomas Harold
                      ... I guarantee that they are pairing them at random. We regularly get delivery attempts for username@domainX where that username only exists on domainY.
                      Message 10 of 14 , Jun 20, 2013
                      • 0 Attachment
                        On 6/20/2013 6:49 AM, Andreas Kasenides wrote:
                        > My conclusion is that the harvester is blindly picking usernames and
                        > domains from wherever it can (possibly from compromised systems but
                        > also from clear text net traffic) and pairing them at random!!
                        >

                        I guarantee that they are pairing them at random. We regularly get
                        delivery attempts for username@domainX where that username only exists
                        on domainY.

                        Including guesses of "first name + last initial" type addresses or
                        "first name + dot + last name" style, when we've never used either of
                        those styles.
                      • Andreas Kasenides
                        ... OK, I hear you, will be upgrading to 2.10 to start using postscreen and look into fixing the temporary failure (4xx) to permanent (5xx) to do away with
                        Message 11 of 14 , Jun 20, 2013
                        • 0 Attachment
                          On 20-06-2013 19:48, Noel Jones wrote:
                          > On 6/20/2013 5:49 AM, Andreas Kasenides wrote:
                          >
                          >> Apparently there has been some harvesting going on of mail addresses
                          >> where everything that has a "@" is picked up. The question is: was
                          >> this harvesting from our log files or our mail storage - a very
                          >> serious
                          >> possibility which would indicate a break in.
                          >
                          > The Message-ID is stored as part of the message. Spammers harvest
                          > these from web forums, email archives, and other public sources.
                          >
                          >> My conclusion is that the harvester is blindly picking usernames and
                          >> domains
                          >> from wherever it can (possibly from compromised systems but also
                          >> from
                          >> clear text net traffic) and pairing them at random!!
                          >
                          > Almost certainly from harvesting publicly accessible web pages, not
                          > from a system compromise.
                          >
                          > Yes, these are often paired at random. Botnet operators have little
                          > incentive to validate their user lists since it requires about the
                          > same effort to send a few thousand messages as to send 100M messages.
                          >
                          > This is more of a nuisance than an actual security issue. Assuming
                          > your system properly rejects unknown recipients, it is unlikely to
                          > cause any operational problems.
                          >
                          > You should look into why you're getting temporary lookup failures in
                          > your log. While that probably isn't a security issue, it is likely
                          > reducing your performance and may also encourage some servers to
                          > retry delivery, which multiplies the number of connections you
                          > receive.
                          >
                          >
                          >
                          > -- Noel Jones

                          OK, I hear you, will be upgrading to 2.10 to start using postscreen and
                          look into fixing the temporary failure (4xx) to permanent (5xx) to do
                          away with repeated connections.

                          thanks
                          regards
                          Andreas
                        • /dev/rob0
                          ... No, you don t seem to understand. (Or maybe you do, but the way you worded that is ambiguous.) The temporary lookup failures are a problem on your system.
                          Message 12 of 14 , Jun 21, 2013
                          • 0 Attachment
                            On Fri, Jun 21, 2013 at 09:46:57AM +0300, Andreas Kasenides wrote:
                            > On 20-06-2013 19:48, Noel Jones wrote:
                            > >You should look into why you're getting temporary lookup
                            > >failures in your log. While that probably isn't a security
                            > >issue, it is likely reducing your performance and may also
                            > >encourage some servers to retry delivery, which multiplies
                            > >the number of connections you receive.
                            >
                            > OK, I hear you, will be upgrading to 2.10 to start using
                            > postscreen and look into fixing the temporary failure (4xx)
                            > to permanent (5xx) to do away with repeated connections.

                            No, you don't seem to understand. (Or maybe you do, but the way you
                            worded that is ambiguous.) The temporary lookup failures are a
                            problem on your system. That fact was referred to several times in
                            this thread, but it was never covered with diagnostic information.

                            Find out which lookup fails, when, and why. postmap(1)'s -q option
                            helps you test your lookups.
                            --
                            http://rob0.nodns4.us/ -- system administration and consulting
                            Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                          Your message has been successfully submitted and would be delivered to recipients shortly.