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

Re: Is this an attack?

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