Active SpamBots...

[SorenR]

What are people seeing?

Up until last weekend I was hit by mails from e.g. "magnetophoneg.datinginformer2.ru". The common theme for the HELO here was "(*.datinginformer(**.ru" where (* is almost a real word and (** is a number and this was also the [From:] domain in the mails.
There was a small deviation from the above where HELO would be "(*" and match part of the [From:] domain.

Code: Select all

"171.207.237.145"	"SENT: 220 mx.acme.inc ESMTP"
"171.207.237.145"	"RECEIVED: HELO magnetophoneg.datinginformer2.ru"
"171.207.237.145"	"SENT: 250 Hello."
"171.207.237.145"	"RECEIVED: MAIL FROM:<bedmakerp@magnetophoneg.datinginformer2.ru>"
"171.207.237.145"	"SENT: 250 OK"
"171.207.237.145"	"RECEIVED: RCPT TO:<xyz@acme.inc>"
"171.207.237.145"	"SENT: 451 Please try again later."
"171.207.237.145"	"RECEIVED: QUIT"
"171.207.237.145"	"SENT: 221 goodbye"

"84.215.146.232"	"SENT: 220 mx.acme.inc ESMTP"
"84.215.146.232"	"RECEIVED: HELO invalidishw"
"84.215.146.232"	"SENT: 250 Hello."
"84.215.146.232"	"RECEIVED: MAIL FROM:<bearabley@invalidishw.datinginformer2.ru>"
"84.215.146.232"	"SENT: 250 OK"
"84.215.146.232"	"RECEIVED: RCPT TO:<xyz@acme.inc>"
"84.215.146.232"	"SENT: 451 Please try again later."
"84.215.146.232"	"RECEIVED: QUIT"
"84.215.146.232"	"SENT: 221 goodbye"

Also up until last weekend I saw a lot of connections from EHLO vnnic.net.vn, adsl.viettel.vn, vnnic.net.vn, vdc.com.vn, dynamic.vdc.vn, you get the point.

Code: Select all

"171.248.203.30"	"SENT: 220 mx.acme.inc ESMTP"
"171.248.203.30"	"RECEIVED: EHLO vnnic.net.vn"
"171.248.203.30"	"SENT: 250-mx.acme.inc[nl]250 SIZE"
"171.248.203.30"	"RECEIVED: MAIL From:<zutuzje@vnnic.net.vn>"
"171.248.203.30"	"SENT: 250 OK"
"171.248.203.30"	"RECEIVED: RCPT To:<xyz@acme.inc>"
"171.248.203.30"	"SENT: 451 Please try again later."

Besides the above I'm still seeing EHLO/HELO "ylmf-pc", "User" and one where my external IP address is listed like

Code: Select all

"118.161.240.104"	"SENT: 220 mx.acme.inc ESMTP"
"118.161.240.104"	"RECEIVED: HELO 87.58.176.150"
"118.161.240.104"	"SENT: 250 Hello."
"118.161.240.104"	"RECEIVED: MAIL FROM: <z2007tw@yahoo.com.tw>"
"118.161.240.104"	"SENT: 250 OK"
"118.161.240.104"	"RECEIVED: RCPT TO: <gk49fawn@yahoo.com.tw>"
"118.161.240.104"	"SENT: 550 Delivery is not allowed to this address."

Yesterday I started seeing what appears to be a spawn off of the "datinginformer"...

Code: Select all

"118.101.61.187"	"SENT: 220 mx.acme.inc ESMTP"
"118.101.61.187"	"RECEIVED: HELO foragersx"
"118.101.61.187"	"SENT: 250 Hello."
"118.101.61.187"	"RECEIVED: MAIL FROM:<scrutablet@foragersx.newmsgforyou4.net>"
"118.101.61.187"	"SENT: 250 OK"
"118.101.61.187"	"RECEIVED: RCPT TO:<xyz@acme.inc>"
"118.101.61.187"	"SENT: 451 4.7.1 Service unavailable - try again later."
"118.101.61.187"	"RECEIVED: QUIT"
"118.101.61.187"	"SENT: 221 goodbye"

Almost 90% of the FQDN's used in EHLO/HELO returned NO rDNS and the rest did not match.

#####

You may notice some changes in my logs - it's a work in progress, currently on version 5.4.2.

I have added a trigger "Sub OnHELO(oClient)" which is called right after HELO/EHLO is received from sender and should help me clean up my logfiles

Code: Select all

   Sub AutoBan(sIPAddress, sReason, iDuration, sType)
      Dim oApp
      Set oApp = CreateObject("hMailServer.Application")
      Call oApp.Authenticate( #ADMIN# , #PASSWD# )
      With oApp.Settings.SecurityRanges.Add
         .Name = "(" & sReason & ") " & sIPAddress
         .LowerIP = sIPAddress
         .UpperIP = sIPAddress
         .Priority = 20
         .Expires = True
         .ExpiresTime = DateAdd(sType, iDuration, Now())
         .Save
      End With
      EventLog.Write(sIPAddress & Chr(34) & vbTab & Chr(34) & sReason)
   End Sub

   Sub OnHELO(oClient)
      If (Left(oClient.IPAddress, 9) = "192.168.0") Then Exit Sub
      Dim BanIP : BanIP = False
      If        oClient.HELO = "87.58.176.150"       Then BanIP = True
      If (InStr(oClient.HELO, "datinginformer") > 0) Then BanIP = True
      If (InStr(oClient.HELO, "newmsgforyou") > 0)   Then BanIP = True
      If (InStr(oClient.HELO, ".") = 0)              Then BanIP = True
      If (Right(oClient.HELO, 3) = ".vn")            Then BanIP = True
      If BanIP Then Call AutoBan(oClient.IPAddress, oClient.HELO, 1, "ww")
   End Sub

   Sub OnSMTPData(oClient, oMessage)
      If (InStr(oMessage.FromAddress, "datinginformer") > 0) Then Call AutoBan(oClient.IPAddress, oClient.HELO, 1, "ww")
      If (InStr(oMessage.FromAddress, "newmsgforyou") > 0) Then Call AutoBan(oClient.IPAddress, oClient.HELO, 1, "ww")
   End Sub

The "ww" used in the AutoBan call is from VBScript function DateAdd, "ww" = week, "w" = weekday, etc..

[tochi]

Is this new to you? Our server receives many these probes everyday. Probably they are spammer and trying to collect valid recipients. Maybe they will try to hack into those valid accounts and send spam emails using those accounts. Of course you can write scripts to block them. But they are smart enough not to try too many at once to avoid autoban. If your rules are strict, valid senders might be blocked as well. I just use the built-n autoban feature and probably implement daily sending limit later. There's little we can do about it.

[SorenR]

Is this new to you? Our server receives many these probes everyday. Probably they are spammer and trying to collect valid recipients. Maybe they will try to hack into those valid accounts and send spam emails using those accounts. Of course you can write scripts to block them. But they are smart enough not to try too many at once to avoid autoban. If your rules are strict, valid senders might be blocked as well. I just use the built-n autoban feature and probably implement daily sending limit later. There's little we can do about it.

Not new... Just curious... Been using this for just over 10 days now and two days ago everything went quiet... I do have a failsafe

I have a second MX (backup MX if you will) that the sender will connect to if primary MX do not respond. Valid senders will do that... So far none have come through that way without first being denied by GreyListing
Oh and... Port 25 do not accept login in any way.

What I was curious about was if the bots/botnets that I mentioned above have vanished from your servers too, that must mean someone shut them down.

[tochi]

No. There's no activities from the IP/ domain you specified at all. There are so many smtp servers on the net. Maybe our server has not been hit by them. Or maybe our server had been hit by them already long time ago.
I'm curious how effective by not allowing authentication on port 25. Don't hackers know to use port 587? If you setup your port other than 587 it will make client configuration more difficult.

[SorenR]

No. There's no activities from the IP/ domain you specified at all. There are so many smtp servers on the net. Maybe our server has not been hit by them. Or maybe our server had been hit by them already long time ago.

Most of the ones I listed will not (or rarely) get past GreyListing so they are not a frequent visitor of someone's inbox - they do however contribute with a lot of "white noise" in the logfiles.

Since I started this test on my server, I have reduced my logfiles with almost 50%. Less information to browse through every morning

I get maybe 1 or 2 attempts per week on port 587, that is all. AutoBan is set for 2 attempts in 24 hours and banned for 1 week.

[tochi]

Port 25 do not accept login in any way.

How did you do that? Does it require scripts?

[SorenR]

Port 25 do not accept login in any way.

How did you do that? Does it require scripts?

https://www.hmailserver.com/changelog?p ... sion=5.6.3

I'm using a hybrid version that I have changed myself.

[SorenR]

Interesting development...

After I made the Sub OnHELO trigger in my 5.4.2 hMailServer, I have been playing with different settings to get rid of spambots...

There is one sure way to annoy spammers - target their money. Everybody know "time is money" so if I can delay their servers, they will loose money, if I cause them to loose money then they don't want to "talk" to me ...

So... Please welcome the 30 second delay

Code: Select all

"2015-08-27 18:05:56.784"	"74.75.27.4"	"SENT: 220 mx.acme.inc ESMTP"
"2015-08-27 18:05:57.143"	"74.75.27.4"	"RECEIVED: HELO notocentrume.newmsgforyou342.net"
"2015-08-27 18:05:57.143"	"74.75.27.4"	*** 30 second sleep ***
"2015-08-27 18:06:07.440"	"50.73.4.139"	"SENT: 220 mx.acme.inc ESMTP"
"2015-08-27 18:06:07.846"	"50.73.4.139"	"RECEIVED: HELO parageneticu.newmsgforyou342.net"
"2015-08-27 18:06:07.846"	"50.73.4.139"	*** 30 second sleep ***
"2015-08-27 18:06:15.081"	"109.86.12.238"	"SENT: 220 mx.acme.inc ESMTP"
"2015-08-27 18:06:15.253"	"109.86.12.238"	"RECEIVED: HELO disregardeds.newmsgforyou342.net"
"2015-08-27 18:06:15.253"	"109.86.12.238"	*** 30 second sleep ***
"2015-08-27 18:06:45.268"	"109.86.12.238"	"SENT: 250 Hello."
"2015-08-27 18:06:45.268"	"50.73.4.139"	"SENT: 250 Hello."
"2015-08-27 18:06:45.268"	"74.75.27.4"	"SENT: 250 Hello."
"2015-08-27 18:06:45.268"	"109.86.12.238"	"RECEIVED: QUIT"
"2015-08-27 18:06:45.268"	"50.73.4.139"	"RECEIVED: QUIT"
"2015-08-27 18:06:45.268"	"74.75.27.4"	"RECEIVED: QUIT"
"2015-08-27 18:06:45.268"	"109.86.12.238"	"SENT: 221 goodbye"
"2015-08-27 18:06:45.268"	"50.73.4.139"	"SENT: 221 goodbye"
"2015-08-27 18:06:45.268"	"74.75.27.4"	"SENT: 221 goodbye"
"2015-08-27 18:16:50.389"	"104.236.197.100"	"SENT: 220 mx.acme.inc ESMTP"
"2015-08-27 18:16:50.577"	"104.236.197.100"	"RECEIVED: HELO 87.58.176.150"
"2015-08-27 18:16:50.577"	"104.236.197.100"	*** 30 second sleep ***
"2015-08-27 18:17:20.639"	"104.236.197.100"	"SENT: 250 Hello."
"2015-08-27 18:18:12.092"	"93.45.242.64"	"SENT: 220 mx.acme.inc ESMTP"
"2015-08-27 18:18:12.186"	"93.45.242.64"	"RECEIVED: EHLO 93-45-242-64.ip104.fastwebnet.it"
"2015-08-27 18:18:12.186"	"93.45.242.64"	*** 30 second sleep ***
"2015-08-27 18:18:42.201"	"93.45.242.64"	"SENT: 250-mx.acme.inc[nl]250 SIZE"

Code: Select all

   Function WaitX(sec, low) 
   ' (30,0) wait 30 seconds or (3000,1) random wait 0-3 second
      Randomize
      With CreateObject("WScript.Shell")
         If Low = 0 Then
            .Run "sleep -m " & Int(sec * 1000), 0, True
         Else
            .Run "sleep -m " & Int((sec - low + 1) * Rnd + low), 0, True
         End If
      End With
   End Function

   Sub OnHELO(oClient)

      If (Left(oClient.IPAddress, 9) = "192.168.0") Then Exit Sub
      If (Left(oClient.IPAddress, 9) = "80.160.77") Then Exit Sub

      Call WaitX(30, 0)

   End Sub

For obvious reasons Sub OnHELO will not work with your servers so I will at some point try the 30 second delay in the Sub OnClientConnect and see if that will make a difference.

[jimimaseye]

How does this stop spam bots though? A spambot pc, deliberate or otherwise, often send out their sh1te for delivery using whatever smtp transport they have access too and often those servers are genuine ones (ISP smtp servers for example), and not necessarily using their own 'direct smtp server'. Putting the delay only serves to hold up those genuine servers - in particular the last smtp in the relay which is last in the link trying to pass to you and often will then become a victim of the spamming itself (taking up their resources). So isnt it more likely that this 'time is money' attack is hitting the genuine businesses (ISP smtp servers) and not the spammers in this case? (Discuss.)

[SorenR]

How does this stop spam bots though? A spambot pc, deliberate or otherwise, often send out their sh1te for delivery using whatever smtp transport they have access too and often those servers are genuine ones (ISP smtp servers for example), and not necessarily using their own 'direct smtp server'. Putting the delay only serves to hold up those genuine servers - in particular the last smtp in the relay which is last in the link trying to pass to you and often will then become a victim of the spamming itself (taking up their resources). So isnt it more likely that this 'time is money' attack is hitting the genuine businesses (ISP smtp servers) and not the spammers in this case? (Discuss.)

Primary objective for me is to keep them out of my server.

My local users (LAN) and backup-MX (ISP) are exempt from this delay.

The IP addresses that are affected by this delay are the same that never passes Greylisting - Well, a few of them, for some reason, get past Greylisting.

Getting sorted from the rest via Greylisting only take milliseconds so it has no implication on BOT performance - and they'll keep it coming - all the time. The theory I am testing here is; IF I delay delivery will "they" take me off the list? I don't think I'm wrong in thinking that the networked BOT's are running off a shared list somewhere.

Initially emails were NOT ment to be "real-time", same with cellphone messages (SMS/MMS) but somehow they are now regarded as "real-time" and used as instant messaging.

[jimimaseye]

The theory I am testing here is; IF I delay delivery will "they" take me off the list? I don't think I'm wrong in thinking that the networked BOT's are running off a shared list somewhere.

I think the flaw is here. I dont think the people that operate these 'spam lists' are in the business of doing housekeeping and removing addresses; the more addresses they have, they more chances of a 'hit'. Often these lists are populated by web page skimming (or other methods of email address sniffing) and done by automated bots and would be one way (ie, address found go IN to the list, and not in the business of taking things OFF the list). And of course we already know they dont care about naff addresses...because they spoof the sender to avoid undeliverables (so its not their problem).

You might be right, you might have a slight degree of success but I doubt it.

In the interest of education for myself, I am keen to know if you are on to something. Will you keep us informed of your test results?

[SorenR]

The theory I am testing here is; IF I delay delivery will "they" take me off the list? I don't think I'm wrong in thinking that the networked BOT's are running off a shared list somewhere.

I think the flaw is here. I dont think the people that operate these 'spam lists' are in the business of doing housekeeping and removing addresses; the more addresses they have, they more chances of a 'hit'. Often these lists are populated by web page skimming (or other methods of email address sniffing) and done by automated bots and would be one way (ie, address found go IN to the list, and not in the business of taking things OFF the list). And of course we already know they dont care about naff addresses...because they spoof the sender to avoid undeliverables (so its not their problem).

You might be right, you might have a slight degree of success but I doubt it.

In the interest of education for myself, I am keen to know if you are on to something. Will you keep us informed of your test results?

Sure will....

I base my theory loosely on this;

Greeting delay
A greeting delay is a deliberate pause introduced by an SMTP server before it sends the SMTP greeting banner to the client. The client is required to wait until it has received this banner before it sends any data to the server. (per RFC 5321 3.2). Many spam-sending applications do not wait to receive this banner, and instead start sending data as soon as the TCP connection is established. The server can detect this, and drop the connection.

There are some legitimate sites[clarification needed] that play "fast and loose" with the SMTP specifications, and may be caught by this mechanism. It also has a tendency to interact badly with sites that perform callback verification, as common callback verification systems have timeouts that are much shorter than those mandated by RFC 5321 4.5.3.2.

https://en.wikipedia.org/wiki/Anti-spam ... ting_delay

My theory: "If I constantly delay transactions they will kick me off the list for waisting their time."

That is the theory that I have and which is mine, and what it is too.

[SorenR]

Interesting observation today, I have 83 entries in my hm_greylisting_triplets table. Usually I would have 4-700 entries.

Of these 83 entries, only 6 are marked as "Delayed" (viewtopic.php?t=6698).

I see two causes for this; first is my 30 seconds delay that make the offending server disconnect before getting to the greylist check AND secondly, I modified my greylisting parameters...

My greylisting parameters:
4 minutes to defer delivery attempts
4 hours before removing unused records (**
32 days before removing used records

(** Yes, 4 hours. The GUI says minimum 1 day but when I checked the hm_settings table in the database it said 24, so 1 day = 24 hours
You can change it directly in the database or change the GUI and recompile it - search for "* 24" and "/ 24"

hMailServer.ini also needs modifying.
In [Settings] add GreylistingRecordExpirationInterval=30, default is 240 minutes (4 hours).

[jimimaseye]

Do you have an explanation as to why it is the combination of both that makes the difference?

So the next thing to do is pin point the cause of this to see if it is one OR the other that makes the difference. If you revert one of your changes (either the 30 second delay OR the 4hour triplet removal) and see if you get the same results. (Of course, if not swap over and see).

What do you think?

[SorenR]

Do you have an explanation as to why it is the combination of both that makes the difference?

So the next thing to do is pin point the cause of this to see if it is one OR the other that makes the difference. If you revert one of your changes (either the 30 second delay OR the 4hour triplet removal) and see if you get the same results. (Of course, if not swap over and see).

What do you think?

The 30 second delay is by far the biggest contributor to the reduced number of sessions. The modified Greylisting parameters simply make housekeeping more effective. Faster lookups for slow databases for whenever a session make it through.

The danger to this type of testing, that I do, is that the amount of SPAM drop ... This on the other hand support my first theory.

My theory number two, which is the second theory that I have. This theory...

SPAM is a funny thing, sometimes you get tons of it and sometimes it's quiet... And if it's quiet for too long then either they caught the buggers or they are planning something big.

[SorenR]

Todays totals totally unscientific values

1 domain, 5 users (8 accounts).
inbound connections: 137
dropped connections: 69 (30 second delay - Sub OnClientConnect)
greylisted connections: 27
accepted connections: 41 (16 via Backup-MX circumventing greylisting)

SPAM by SpamAssassin: 15 (6 via Backup-MX )
SPAM by rule: +1

The "+1"... Found a new sender that I need to keep my eye on

Thanks to my daily training of SpamAssassin, Spamassassin will eventually learn and catch the ones I make rules for, and when that happen, I can remove the rule