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

Re: Is this an attack?

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.