-
SendMail/SMTP issues
I have some very strange activity going on with one of my SendMail servers and was hoping that someone here might know what is going on with it.
This morning my CFO, CIO and CEO all got the same email (SPAM) which is not so unusual. What IS unusual is the addresses it was sent to. They are coming from one of my SendMail servers that doesn't resolve to the outside world using email addresses that don't exist. I looked at the extended headers in the email and they are showing the addresses being sent to as [email protected] [email protected] and [email protected] .... but a look in the SendMail logs show they are actually going to [email protected] [email protected] and [email protected]. The From address is not spoofed in either the headers or the SendMail log, at least as far as I can tell.
So I'm wondering how they are suppressing the actual email addy, even in the headers, and also how they are sending to my server that isn't seen from the outside. Now this IS an older version of SendMail, (sun version) 8.11.6 running on Solaris 7 and it will be replaced in the next couple of days with the latest SendMail version and Solaris 9. But since this involved the higher ups in the company it's become a bit of a "hot" item and they want me to figure out why it's happening like this and if there is anything we can do to stop it in the meantime.
I can provide more detailed logs and headers if requested, but I will have to edit them to remove actual names, etc. as I'm a little wary of giving this information out to everyone ;)
Thanks in advance for any information you folks can provide on this.
-
Posting the actual email headers (filter out your IP and domain with something obvious) would be very helpful in seeing exactly what you are talking about. Also, you really should apply the solaris patch to your sendmail server. The latest version 8.11.7 and it should be trivial to apply the patch...If memory serves that patch fixed some pretty serious security flaws in sendmail.
Looking forward to seeing the headers,
/nebulus
-
lets have a look at the header
-
Ok, here is a copy of both the SendMail log and the headers from the email. I've replaced the machine names and domain names with something fairly obvious. Also I edited out the first three octets of the IP addresses, but left the last one in place so you can track which machines are which. I didn't edit out the message ID, as I don't think there is anything of interest in there but I could be mistaken.
Also, about the patch. I think I remember seeing that 8.11.7 required an OS upgrade to at least solaris 8, but it's been a while since I messed with the sendmail stuff here. I think that was the reason a new machine was built on solaris 9 with the latest sendmail in the first place.
Code:
Sendmail Log:
Jun 5 07:33:14 SMTP1 sendmail[27426]: h55EXA227426: from=<[email protected]>, size=5663, class=0, nrcpts=
2, msgid=<[email protected]>, proto=SMTP, daemon=MTA, relay=x-x-x-170.dsl.telesp.net.br [x.x.x.170]
Jun 5 07:33:14 SMTP1 sendmail[27430]: h55EXA227426: to=<[email protected]>,<[email protected]>, delay=00:00:04, xdelay=00:00:00,
mailer=smtp, pri=155663, relay=[x.x.x.29] [x.x.x.29], dsn=2.0.0, stat=Sent (2.0.0 h55EUnO11251 Message accepted for delivery)
Message header:
Received: from SMTP2.mycompany.com (SMTP2.mycompany.com [x.x.x.29]) by internal-exchange-server.mycompany.com with SMTP
(Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
id ZDMQYVZV; Thu, 5 Jun 2003 07:30:48 -0700
Received: from SMTP1.mycompany.com (SMTP1 [x.x.x.6])
by SMTP2.mycompany.com (8.11.6+Sun/8.11.6) with SMTP id h55EUnO11251;
Thu, 5 Jun 2003 07:30:49 -0700 (PDT)
Received: from excite.com (x-x-x-170.dsl.telesp.net.br [x.x.x.170])
by SMTP1.mycompany.com (8.11.6+Sun/8.11.6) with SMTP id h55EXA227426;
Thu, 5 Jun 2003 07:33:10 -0700 (PDT)
Message-ID: <[email protected] <mailto:[email protected]>>
From: "Meds: Hair Removal, Cold Sores, Herpes ..." <[email protected] <mailto:[email protected]>>
To: RE: [email protected] <mailto:[email protected]>, [email protected] <mailto:[email protected]>,
[email protected] <mailto:[email protected]>
Subject: RE: Sexual, Weight Loss, Depression ... 0444izsd6-540vquR3309FbAX9-8-26
Date: Thu, 05 Jun 2003 13:26:46 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_00C0_42E74E2B.E0066E30"
X-Priority: 3
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Importance: Normal
-
Just curoius, if an address dosn't exist at your company who dose it resolve to....any address that dosn't exist here shoots off to a dummy account to collect spam.
Is SMTP1 live to the world (I am assumeing yes) in which case it may have been compromised as that version of sendmail is riddled with holes. Or is the exchange server live to the outside (I am hopeing no) if so it has been compromised as it is riddeled with holes.
If redirects where set up inside the mail server it would go to the chosen addressies without showing in the email headers.
-
-
Ok, I'm not real sure where bogus email addys are resolving as I'm not the normal mail admin I'm just covering for him this week.
SMTP1 should not resolve to the outside world, at least according to everything I have been able to uncover about it. The exchange server definately doesn't talk to the outside world, it relays through one of two other SMTP relay boxes that do talk to the outside world.
Now my thinking is that SMTP1 is indeed live to the outside world. It shouldn't be, but just looking at those logs shows me that it is, since it's receiving email directly from 'excite'. I'll go log in to that box and see if it is, and then work from there.
So this could just be a simple redirect on a compromised server then. I'll look in to that too.
-
SMTP1 clearly took the connection.
Received: from excite.com (x-x-x-170.dsl.telesp.net.br [x.x.x.170])
This is the key...it says excite.com, but obviously isn't. (unless you changed it).
This is easily done in to an improperly configured mail server, upon making the connection to the mail server, you would just say:
HELO excite.com
Lovely how no checking, huh? :) I am not sure if you can configure sendmail to do this or not, I would assume you can, but I know some servers can be setup to do a reverse lookup on the IP connecting, and then compare the two and if they don't match, reject the connection.
The only thing that really bothers me about the header that indicates something more might be up is that you don't see the HELO in there...I would have expected to see that...and I would have expected to see it on the aforementioned line. If you didn't accidentally delete it, it is possible that all of the headers are forged, which is harder to do, but is possible. If I had to guess, I would say that your mail server is setup to allow relay (default for older versions).
Check your /etc/mail/sendmail.cf for:
Fw/etc/mail/local-host-names
and
FR-o /etc/mail/relay-domains
Then check those filenames. On all the boxes I have setup, I don't have relay-domains set, so there isn't anyone that should be able to use my server this way. Your needs may vary. The local-hosts-names will allow the machine itself to send the mail. When you combine this with the relay-domains, it shouldn't allow anyone to do this anymore...
/nebulus
-
I didn't change the excite.com part other than the persons name. Any time I see something from a free email address that is spam I'm always a bit wary about it.
I haven't had a chance to look at the box directly yet, but I'll go look in the areas that you pointed me to nebulus. Thanks a lot guys, and I guess this means it's time for me to brush up on sendmail and SMTP a bit.
