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

Re: large amounts of disconnects

Expand Messages
  • Tony Earnshaw
    ... Not the volume you describe, but we do get that occasionally. We turn away (refuse subnets) 3-400 bots a day. We analyzed the OSes on the machines
    Message 1 of 10 , Jan 1, 2007
    • 0 Attachment
      Roman Novak - roman.novak@... wrote:

      > In last 2 weeks i am noticing enormous amounts of strange connections
      > to mail server from all over the world. An example from logs:
      >
      > Jan 1 13:09:03 mercury postfix/smtpd[22974]: connect from
      > 157.Red-81-33-236.dynamicIP.rima-tde.net[81.33.236.157]
      > Jan 1 13:09:03 mercury postfix/smtpd[22974]: lost connection after EHLO
      > from 157.Red-81-33-236.dynamicIP.rima-tde.net[81.33.236.157]
      > Jan 1 13:09:03 mercury postfix/smtpd[22974]: disconnect from
      > 157.Red-81-33-236.dynamicIP.rima-tde.net[81.33.236.157]
      >
      >
      > Transcript of session follows.
      >
      > Out: 220 mercury.mydomain.net ESMTP something
      > In: EHLO
      > Out: 501 Syntax: EHLO hostname
      >
      > Session aborted, reason: lost connection
      >
      >
      > Right now it is just filling my logs, but the amount is 2-3 times larger
      > than normal volume of spam probes.
      >
      > Is anybody else getting this?

      Not the volume you describe, but we do get that occasionally. We turn
      away (refuse subnets) 3-400 bots a day. We analyzed the OSes on the
      machines connecting to port 25 on our MTA using p0f and they are around
      95% Windows XP/2000. I read the transactions regularly and it's obvious
      that there are a number of different spammer software versions knocking
      around - which do different things.

      > Is this some new spam/malware going around and probing mail servers or
      > can this be some mis-configuration or performance problem?

      Looks like broken bot software to me. Spammer grandi rent out subnets of
      bots and mugs install their own spammer software on them - that could be
      subnets and bots anywhere in the world. rima-tde.net is one of the ISPs
      we block completely.

      --Tonni

      --
      Tony Earnshaw
      Email: tonni at hetnet.nl
    • Michael Wang
      ... Never mind that, I was misinterpreting the docs. Peter Matulis mentioned the same problem in a thread from a few days ago titled double-bounce problem so
      Message 2 of 10 , Jan 1, 2007
      • 0 Attachment
        Roman Novak - roman.novak@... wrote:
        >>> Transcript of session follows.
        >>>
        >>> Out: 220 mercury.mydomain.net ESMTP something
        >>> In: EHLO
        >>> Out: 501 Syntax: EHLO hostname
        >>>
        >>> Session aborted, reason: lost connection
        >>
        >> Do you have reject_invalid_helo_hostname or reject_invalid_hostname
        >> somewhere in your main.cf file?
        >
        > No, i don't have these parameters in main.cf

        Never mind that, I was misinterpreting the docs.

        Peter Matulis mentioned the same problem in a thread from a few days ago
        titled "double-bounce problem" so like Tony said (and Peter said in the
        earlier thread) it's probably a broken spambot.


        --
        Michael Wang
      • Len Conrad
        ... lost connection after is perfectly normal for us. eg, for Sunday: mx1# zegrep : lost connection after /var/log/maillog.[0].gz | awk {print $9} |
        Message 3 of 10 , Jan 1, 2007
        • 0 Attachment
          >In last 2 weeks i am noticing enormous amounts of strange
          >connections to mail server from all over the world. An example from logs:

          "lost connection after" is perfectly normal for us. eg, for Sunday:

          mx1# zegrep ": lost connection after " /var/log/maillog.[0].gz | awk
          '{print $9}' | sort -f | uniq -ic | sort -rfgn | less
          394391 RCPT
          129629 EHLO
          68807 CONNECT
          2599 HELO
          1820 DATA
          1687 MAIL
          519 RSET
          102 NOOP
          24 UNKNOWN
          1 VRFY
          1 QUIT

          and for a weekday last week:

          mx1# zegrep ": lost connection after " /var/log/maillog.[5].gz | awk
          '{print $9}' | sort -f | uniq -ic | sort -rfgn | less
          818589 RCPT
          114880 CONNECT
          100362 EHLO
          2783 DATA
          2195 HELO
          2182 MAIL
          522 RSET
          159 NOOP
          23 UNKNOWN
          2 VRFY
          1 QUIT

          and for the 5.gz day:

          mx1# zegrep -ic ": connect from" /var/log/maillog.[5].gz
          2906441

          mx1# zegrep -ic ": disconnect from" /var/log/maillog.[5].gz
          2899136

          Len
        • Tony Earnshaw
          ... In fact, OP s transaction specifically showed the MTA objecting to the client issuing a HELO without data, after which OP s server (quite rightly) gave a
          Message 4 of 10 , Jan 1, 2007
          • 0 Attachment
            Len Conrad wrote:

            >> In last 2 weeks i am noticing enormous amounts of strange connections
            >> to mail server from all over the world. An example from logs:
            >
            > "lost connection after" is perfectly normal for us. eg, for Sunday:
            >
            > mx1# zegrep ": lost connection after " /var/log/maillog.[0].gz | awk
            > '{print $9}' | sort -f | uniq -ic | sort -rfgn | less
            > 394391 RCPT
            > 129629 EHLO
            > 68807 CONNECT
            > 2599 HELO
            > 1820 DATA
            > 1687 MAIL
            > 519 RSET
            > 102 NOOP
            > 24 UNKNOWN
            > 1 VRFY
            > 1 QUIT
            >
            > and for a weekday last week:
            >
            > mx1# zegrep ": lost connection after " /var/log/maillog.[5].gz | awk
            > '{print $9}' | sort -f | uniq -ic | sort -rfgn | less
            > 818589 RCPT
            > 114880 CONNECT
            > 100362 EHLO
            > 2783 DATA
            > 2195 HELO
            > 2182 MAIL
            > 522 RSET
            > 159 NOOP
            > 23 UNKNOWN
            > 2 VRFY
            > 1 QUIT
            >
            > and for the 5.gz day:
            >
            > mx1# zegrep -ic ": connect from" /var/log/maillog.[5].gz
            > 2906441
            >
            > mx1# zegrep -ic ": disconnect from" /var/log/maillog.[5].gz
            > 2899136

            In fact, OP's transaction specifically showed the MTA objecting to the
            client issuing a HELO without data, after which OP's server (quite
            rightly) gave a syntax error after the client went on to give a MAIL FROM:

            The bot software was left in confusion and borked.

            It isn't so much a "lost connection" problem as a specific b0rked bot
            HELO problem.

            --Tonni

            --
            Tony Earnshaw
            Email: tonni at hetnet.nl
          • Peter Matulis
            ... [...] ... Remove protocol from the above setting. From the docs: protocol Send the postmaster a transcript of the SMTP session in case of client or
            Message 5 of 10 , Jan 1, 2007
            • 0 Attachment
              --- "Roman Novak - roman.novak@..."
              <roman.novak@...> wrote:

              >
              > Michael Wang wrote:
              > > Roman Novak - roman.novak@... wrote:
              > >> Michael Wang wrote:
              > >>> Roman Novak wrote:
              > >>>> Transcript of session follows.
              > >>>>
              > >>>> Out: 220 mercury.mydomain.net ESMTP something
              > >>>> In: EHLO
              > >>>> Out: 501 Syntax: EHLO hostname
              > >>>>
              > >>>> Session aborted, reason: lost connection
              > >>>
              > >>> Do you have reject_invalid_helo_hostname or
              > reject_invalid_hostname
              > >>> somewhere in your main.cf file?
              > >>
              > >> No, i don't have these parameters in main.cf
              > >
              > > Show us your postconf -n output.
              > >
              >
              > [root@mercury ~]# postconf -n

              [...]

              > notify_classes = delay, protocol, resource, software


              Remove 'protocol' from the above setting.

              From the docs:

              protocol
              Send the postmaster a transcript of the SMTP session in case of client
              or server protocol errors.

              The bot is committing a protocol error.

              Peter

              __________________________________________________
              Do You Yahoo!?
              Tired of spam? Yahoo! Mail has the best spam protection around
              http://mail.yahoo.com
            Your message has been successfully submitted and would be delivered to recipients shortly.