Looks like there's a new spam bot out there – not sure if its script kiddies running it or a bot net but what ever it is is its really crap.
So far Fail2ban has blocked about 40 IP addresses and they're all doing exactly the same thing – any even vaguely configured email server should be rejecting the messages … .here's the reject my server sent to mail.blackriverhealthcare.org which tried to use my server to spend spam :
Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Google+: View post on Google+
Post imported by Google+Blog. Created By Daniel Treadwell.
I can attest to this as well. I’m starting to build an IP list of this guy because it’s becoming more and more annoying.
My assumption is he scanned for open SMTP servers and is running a script through them… Even if they don’t work..
Out: 554 5.7.1 : Relay access denied
82 new messages like that in the last day or so. sheesh.
The thing that gets me is that the HELO is so obviously crap that any mail server that accepts it deserves to be blacklisted on things like SpamCop
I suspect this is part of the same botnet that's been trying to relay to $RANDOM@6@yahoo.com.tw since about Sep 4 – some of the same dynamic IP ranges just hit my server last night around midnight trying to deliver to the same address you're seeing.
I suspect this is part of the same botnet that's been trying to relay to $RANDOM@6@yahoo.com.tw since about Sep 4 – some of the same dynamic IP ranges just hit my server last night around midnight trying to deliver to the same address you're seeing.
Oh probably – is the HELO as totally stupid?
Oh probably – is the HELO as totally stupid?
Running a moderately tweaked sendmail at loglevel 12 – no HELO data logged for relay refusals, but it wouldn't surprise me.
Running a moderately tweaked sendmail at loglevel 12 – no HELO data logged for relay refusals, but it wouldn't surprise me.
I'm running Postfix and its screwed down really tightly on the HELO handshaking along with other things.
I'm running Postfix and its screwed down really tightly on the HELO handshaking along with other things.
Running exim here. For the past two months I've seen this, in spurts. IPs typically belong to various residential ISP customers [or business customers on DSL/cable], but not always.
Typical entry for exim:
2012-10-31 14:20:21 courier_login authenticator failed for static-141-149-219-31.syr.east.verizon.net ([192.168.2.33]) [141.149.219.31]:45695 I=[xxx.yyy.zzz.aaa]:25: 535 Incorrect authentication data (set_id=reception)
It is definitely botnet related, since I could go a day without seeing anything and then suddenly have my servers start temp-blocking a couple dozen offending IPs at once.
I managed to get a hold of an admin at a .edu whose connecting was generating this traffic, and he tracked it back to a Windows server generating the spewage. He said he logged into his Windows server and noticed a couple new NT users with admin privs — so obviously that box was rooted. He said CPU was spiked. He ended up taking it off the network to further check it out, but so far he hasn't indicated that he found the actual running program that was doing the brute forcing. I wish I had the chance to investigate the server firsthand, but I neither had the time or authority to do so.
the 192.168.2.33 HELO is the main characteristic of this sucker.
What annoys me is that NO email server should ever accept any of those emails because of the totally crap HELO
Any changes or updates to this? It's driving my server crazy with 1500-2000 attempts a day. It'll happen for a day or 2 and then stop for as many and then come back trying again. The originating ip is random and changes about every 10 attempts.
As I run Fail2Ban which firewalls abusive attempts to use my email server all I've ended up with is a very long set of rules in my iptables configuration. I'm hardly seeing anything from this spamming system in my logs now.. I'd seriously recommend looking at Fail2Ban if you can run it on your servers.
It's nice to know that I'm not the only admin who's had to deal with this puke. Example- https://jetfirenetworks.com/abuse/lmaoHELO.txt
I then built up an Ubuntu virtual machine with a vanilla MTA install (on a completely different node) and it was hit in under 24 hours, example- http://avalon.jetfirenetworks.com/abuse/dovecot1031.txt
Stopped the activity by tuning up the firewall even more, and added blackhole routes to the offending /24s. Haven't seen a single attempt on my production equipment since then. Hoping my VPS clients make the same adjustments I did!
Thanks for posting about this!
John Edel, Jetfire Networks
https://jfnllc.com/jfnportal
If you 404'd while checking the logs in my link, I apologize – I'd moved them out of the web root accidentally. They should work now.
Hi I've seen the same thing on a sendmail server and a zimbra server for the last several months. I was doing a bit of port scanning this morning on some of the ip addresses. One interesting thing I noticed is all the IP addresses scanned have 3389 ms-term-serv open. Interesting!
Indeed, very interesting. Let's face it, there have been a ton of RDP holes over the years. I think one very significant earlier this year alone. If you ask me, nobody in their right mind should have RDP open to the world. It's just asking for trouble. Thanks for sharing that though. I suspected this traffic was from compromised Windows machines, but I don't port scan other people's networks. I depend on guys like you to do that 🙂
I know I probably shouldn't but I figure the IP is fair game if they're trying to relay mail through my servers… no?
Well, you're probably right. In the case of the traffic [and characteristics of the traffic] that we are talking about, it's obvious that the owners of the machines aren't maliciously doing it themselves — and obvious that they aren't paying much attention to their machines. After you posted that, I called back another IT guy I talked to just yesterday about odd traffic coming from his client's LAN. He investigated a little last night. When I mentioned to him RDP, he said "come to think of it, I did see strange logins to RDP when reviewing Event Viewer logs". Whether or not RDP is the original attack port, it's obvious that enough access is being gained so that RDP can be used.
I did some contract work for a doctors office a few years back. The Doc took over a practice where the old Doc had died. The already setup windows 2003 server was behind a firewall but many services were forwarded through to it and open directly onto the public internet with no filtering. VNC and RDP among them. I'm guessing this was due to lazy / ignorant IT folks who wanted easy access to the server for support needs et cetera. I doubt this is an isolated case and I agree that the owners of the machines probably have nothing to do with these relay attempts. Ah well, what is there to be done but watch the fail2ban logs and shake our fists into the air?
After about nearly a week of no activity seen from all of these IPs, the traffic started up this afternoon just like it never stopped. Nearly every IP so far has been recognizable as an offender in the past month. I've emailed the ISPs of each one of these multiple times in the past, just to see if any of them gave a damned. Not surprising, none of them appear to have done anything about their customers' spewage. Comcast, ATT, Knology, Cox, RR — every IP that I"ve reported to those companies in the past month is still generating this traffic. Put the shoe on the other foot and throw that kind of traffic at one of thier customers and watch how fast they shoot off hatemail to your ISP rofl. Gotta love it.
After a couple of weeks of nothing I got 23 messages from Fail2ban yesterday – all related to this botnet. I wondered if it was just that addresses had aged out of the fail2ban list but I guess not..
It annoys me that the ISPs do nothing about anything like this but what I find worrying is that I'm seeing what look like email servers apparently running this bot – last time it was blackriverhealthcare.com, this time its marcelinc.com who seem to contaminated.
As this bot is still running with such a badly flawed HELO all I can assume is that there are a huge number of incompetent mail server admins out there because there is NO way that HELO should ever be accepted.
Indeed I recognize marcelinc / blackriverhealthcare. Also comes to mind is mail.jccofrockland.org. There are many other though. Some of the current list is below. If this "pollutes" too much, just delete it 🙂 At least 70% of these have been doing this for a month now, and I've reported every one of the ones in the US.
Although a lot of them look like mail servers, what I think is more likely is that each one of them is running behind a firewall with (a) RDP open and (b) obviously a windows box behind them somewhere. And some of them might have rDNS as a mailserver name simply because they are running Exchange or something else internally . But I'm not confident that every infected machine happens to be running a mail server. I don't think in any case that it's actual spewage from a mailserver daemon. The stuff may be running on a mailserver, but I dont think it has anything to do with whatever flavor of mailserver is running on those machines.
23.24.12.243
23.25.216.129
24.96.212.163
24.123.56.246
37.209.31.239
37.221.168.142
50.34.10.50
64.56.122.66
66.64.6.154
67.52.184.130
68.213.103.27
72.89.191.60
74.84.111.214
75.127.236.194
75.151.109.166
79.144.190.144
80.33.151.18
82.221.99.226
89.87.130.233
90.184.114.13
95.225.148.31
98.174.235.103
108.64.133.67
108.162.17.130
120.146.193.153
173.162.251.81
209.194.1.171
213.153.47.1
216.136.80.206
66.64.240.218
95.241.100.18
I did wonder if it was rDNS "lying" or people using their email gateway server as a proxy server for internet access
Yeah. I suspect in many cases its an SBS server proxying for them, with RDP open and possibly other services running on it [whether or not those services are exposed to the internet]. In the two instances where I was actually able to contact somebody at one of the companies, the traffic finally stopped [so they did indeed find the compromise point and fixed things up in some way]. In one of those cases it was an SBS server… not sure about the other.
This is what is in my logs – I fail2ban after a single failed attempt for mail relay:
Dec 2 15:00:41 kodaly postfix/smtpd[32364]: NOQUEUE: reject: RCPT from unknown[216.1.42.19]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 15:10:28 kodaly postfix/smtpd[2127]: NOQUEUE: reject: RCPT from unknown[66.64.6.154]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 15:15:22 kodaly postfix/smtpd[2291]: NOQUEUE: reject: RCPT from wsip-98-189-122-23.oc.oc.cox.net[98.189.122.23]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 15:20:26 kodaly postfix/smtpd[2545]: NOQUEUE: reject: RCPT from host31-148-static.225-95-b.business.telecomitalia.it[95.225.148.31]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 15:35:02 kodaly postfix/smtpd[8027]: NOQUEUE: reject: RCPT from CPE-120-146-193-153.static.vic.bigpond.net.au[120.146.193.153]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 15:39:56 kodaly postfix/smtpd[8496]: NOQUEUE: reject: RCPT from unknown[24.96.212.163]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 15:45:11 kodaly postfix/smtpd[8692]: NOQUEUE: reject: RCPT from 18.Red-80-33-151.staticIP.rima-tde.net[80.33.151.18]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 15:50:30 kodaly postfix/smtpd[9158]: NOQUEUE: reject: RCPT from 144.Red-79-144-190.dynamicIP.rima-tde.net[79.144.190.144]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 16:00:54 kodaly postfix/smtpd[9998]: NOQUEUE: reject: RCPT from 173-162-251-81-NewEngland.hfc.comcastbusiness.net[173.162.251.81]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 16:06:12 kodaly postfix/smtpd[10483]: NOQUEUE: reject: RCPT from mail2.servicesfuneraires.fr[89.87.130.233]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 16:11:44 kodaly postfix/smtpd[10761]: NOQUEUE: reject: RCPT from ool-6ca21182.static.optonline.net[108.162.17.130]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 16:17:07 kodaly postfix/smtpd[10960]: NOQUEUE: reject: RCPT from rrcs-50-84-168-222.sw.biz.rr.com[50.84.168.222]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 16:22:46 kodaly postfix/smtpd[11148]: NOQUEUE: reject: RCPT from 23-25-216-129-static.hfc.comcastbusiness.net[23.25.216.129]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 16:28:25 kodaly postfix/smtpd[11363]: NOQUEUE: reject: RCPT from unknown[98.174.235.103]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 16:34:24 kodaly postfix/smtpd[11844]: NOQUEUE: reject: RCPT from HSI-KBW-37-209-31-239.hsi15.kabel-badenwuerttemberg.de[37.209.31.239]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 16:40:25 kodaly postfix/smtpd[12921]: NOQUEUE: reject: RCPT from static-50-39-90-242.bvtn.or.frontiernet.net[50.39.90.242]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 18:42:17 kodaly postfix/smtpd[21407]: NOQUEUE: reject: RCPT from unknown[74.11.126.243]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 19:43:14 kodaly postfix/smtpd[25431]: NOQUEUE: reject: RCPT from ool-4b7fecc2.static.optonline.net[75.127.236.194]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 20:08:59 kodaly postfix/smtpd[27424]: NOQUEUE: reject: RCPT from 108-64-133-67.lightspeed.dctril.sbcglobal.net[108.64.133.67]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 20:22:11 kodaly postfix/smtpd[29301]: NOQUEUE: reject: RCPT from rrcs-24-123-56-246.central.biz.rr.com[24.123.56.246]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 20:49:05 kodaly postfix/smtpd[31070]: NOQUEUE: reject: RCPT from host100-107-static.224-95-b.business.telecomitalia.it[95.224.107.100]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 2 22:19:24 kodaly postfix/smtpd[5565]: NOQUEUE: reject: RCPT from mail.jccyofrockland.org[72.89.191.60]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 3 00:27:05 kodaly postfix/smtpd[12691]: NOQUEUE: reject: RCPT from static-50-34-10-50.evrt.wa.frontiernet.net[50.34.10.50]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 3 00:34:11 kodaly postfix/smtpd[12895]: NOQUEUE: reject: RCPT from sacrtt6.lnk.telstra.net[203.45.134.40]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 3 01:23:39 kodaly postfix/smtpd[15195]: NOQUEUE: reject: RCPT from 213-153-47-1.stat.salzburg-online.at[213.153.47.1]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 3 03:07:01 kodaly postfix/smtpd[21160]: NOQUEUE: reject: RCPT from 70.43.109.131.nw.nuvox.net[70.43.109.131]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 3 03:28:16 kodaly postfix/smtpd[22105]: NOQUEUE: reject: RCPT from 74-84-111-214.client.mchsi.com[74.84.111.214]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 3 11:41:45 kodaly postfix/smtpd[15077]: NOQUEUE: reject: RCPT from 66.64.240.218.nw.nuvox.net[66.64.240.218]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 3 14:05:34 kodaly postfix/smtpd[25258]: NOQUEUE: reject: RCPT from 96-31-63-212.pool.dsl.scrtc.com[96.31.63.212]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 3 14:27:37 kodaly postfix/smtpd[26418]: NOQUEUE: reject: RCPT from 23-24-12-243-static.hfc.comcastbusiness.net[23.24.12.243]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 3 14:58:39 kodaly postfix/smtpd[29931]: NOQUEUE: reject: RCPT from 75-149-2-246-Pennsylvania.hfc.comcastbusiness.net[75.149.2.246]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 3 15:39:13 kodaly postfix/smtpd[1443]: NOQUEUE: reject: RCPT from 75-151-109-166-Washington.hfc.comcastbusiness.net[75.151.109.166]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
Dec 3 16:27:05 kodaly postfix/smtpd[4124]: NOQUEUE: reject: RCPT from adsl-068-213-103-027.sip.jan.bellsouth.net[68.213.103.27]: 554 5.7.1 <therichsheickc@yahoo.com>: Relay access denied; from=<test@live.com> to=<therichsheickc@yahoo.com> proto=ESMTP helo=<[192.168.2.33]>
I have been in communication with the ISP abuse department handling 66.64.6.154. Thus far, they blocked traffic from their customer to my server only, since that's the only report they got. I just sent them a link to this thread so that they can see it's targetting a wider range of IPs.
Incidentally, I have to give the folks at that abuse dept a lot of credit. They are the only ones doing a damned thing with my abuse complaint. Granted, none of this traffic is harming me. It's getting blocked. I'd just like to see more than 1 abuse department out of 35 or so give a damn.
Most of the time I've reported stuff to ISPs I either get an automated response and then nothing happens or I get a person at the other end and things get fixed.
Do you only ever see this one address combination being used? If so then I guess it could be the first one in a longer list and used to check that the server is an open relay. I have NO intention of removing my Fail2ban checking / changing my firewall rules just to see what happens
That's how it usually works for me. The "big" ISPs are useless. I guess they figure they have bigger fish to fry, or nobody knows what to do with the complaints.
I can't say what email addresses they attempt to forge in the FROM or set in the TO fields. My server drops the connection prior to that data being sent.
And in all cases, the ones HELOing with 192.168.2.33 are trying to authenticate with only the user portion of the email address (i.e. ricardo, not ricardo@somedomain.com). So if your mail server is configured like mine to handle mail for multiple domains on one IP, the full email address would be required for valid authentication.
My email server is rather strict about HELO:
smtpd_helo_required = yes
smtpd_helo_restrictions =
warn_if_reject,
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_hostname,
reject_invalid_hostname,
permit
and I handle multiple domains using mydestination options and virtual domain mapping
And now its gone quiet again……. just the usual crap from the usual suspects….
Are you saying you aren't receiving any 192.168.2.33 bot stuff for a number of hours? Still going on here as recently as a few minutes ago.
I'll check when I get home but when I checked this morning there was nothing new from after I'd posted last night.
I hadn't realized you posted that so many hours ago. It may have been dormant during that period here as well.
😉
nothing more from it – so either its stopped or its running off a very small set of IP addresses and I've firewalled them all
Oh, that's quite possible. I have about 45 or so ips firewalled and nothing is happening. But I can look at the access list and see the number of hits are increasing on all of the usual IPs. So I think you're right, you just happen to have them all firewalled at the moment.