a little spam/relay help?

Protollix

Verified User
Joined
Apr 24, 2004
Messages
54
Hello all,
I don't claim to be a email expert and I could use some help with this.

One customer has been letting me know he is getting chinese spam emails with my hostname as the from address. This is normal I guess, since the "from" is easily forged. However, the Received headers are making me think this email is actually being sent through my server. Here is the email header, inclusive all the way to the last "Received" entry. I blanked out the envelope-to to protect the email of my customer.

Code:
Return-path: <[email protected]>
Envelope-to: XXXXXXXXXXXXXX
Delivery-date: Wed, 06 Oct 2004 23:18:13 -0500
Received: from mail by enlil.protollix.com with spam-scanned (Exim 4.31)
	id 1CFPjJ-0007zM-LD; Wed, 06 Oct 2004 23:18:13 -0500
Received: from localhost by enlil.protollix.com
	with SpamAssassin (2.63 2004-01-11);
	Wed, 06 Oct 2004 23:18:13 -0500

It looks to me like this was sent FROM my server. If I am reading this right, this was the path it took:

1. connection to exim from localhost. By a script or PHP page maybe?
2. passed from Spamassassin back to exim on the same server

I notice in my mainlog exim log that I have a ton of connections coming in and failed sends:

Code:
2004-10-07 14:59:25 SMTP connection from [67.173.47.186] (TCP/IP connection count = 1)
2004-10-07 14:59:31 H=c-67-173-47-186.client.comcast.net (67.173.47.186) [67.173.47.186] F=<[email protected]> rejected RCPT <[email protected]>: 
2004-10-07 14:59:33 H=c-67-173-47-186.client.comcast.net (67.173.47.186) [67.173.47.186] F=<[email protected]> rejected RCPT <[email protected]>: 
2004-10-07 14:59:34 H=c-67-173-47-186.client.comcast.net (67.173.47.186) [67.173.47.186] F=<[email protected]> rejected RCPT <[email protected]>: 
2004-10-07 14:59:35 H=c-67-173-47-186.client.comcast.net (67.173.47.186) [67.173.47.186] F=<[email protected]> rejected RCPT <[email protected]>: 
2004-10-07 14:59:36 H=c-67-173-47-186.client.comcast.net (67.173.47.186) [67.173.47.186] F=<[email protected]> rejected RCPT <[email protected]>: 
2004-10-07 14:59:36 H=c-67-173-47-186.client.comcast.net (67.173.47.186) [67.173.47.186] incomplete transaction (RSET) from <[email protected]>
2004-10-07 14:59:39 H=c-67-173-47-186.client.comcast.net (67.173.47.186) [67.173.47.186] F=<[email protected]> rejected RCPT <[email protected]>: 
2004-10-07 14:59:39 H=c-67-173-47-186.client.comcast.net (67.173.47.186) [67.173.47.186] F=<[email protected]> rejected RCPT <[email protected]>: 
2004-10-07 14:59:40 H=c-67-173-47-186.client.comcast.net (67.173.47.186) [67.173.47.186] F=<[email protected]> rejected RCPT <[email protected]>:

Exim can be rather cryptic to me. But this looks like someone connected to port 25 on my machine and proceeded to attempt to send to a long list of non-existant email addresses. I should not, oasisuo.com is a domain that is hosted on this server...

Any ideas?
 
Protollix said:
However, the Received headers are making me think this email is actually being sent through my server. Here is the email header, inclusive all the way to the last "Received" entry.
If these are all the received headers, then the spam is originating on your account.
It looks to me like this was sent FROM my server. If I am reading this right, this was the path it took:

1. connection to exim from localhost. By a script or PHP page maybe?
2. passed from Spamassassin back to exim on the same server
Right on both counts.
[/quote]I notice in my mainlog exim log that I have a ton of connections coming in and failed sends:[/quote]
These don't appear to have anything to do with the headers you posted, though I can't be sure because you didn't give us the "To" name of the email in the headers.
2004-10-07 14:59:25 SMTP connection from [67.173.47.186] (TCP/IP connection count = 1)
2004-10-07 14:59:31 H=c-67-173-47-186.client.comcast.net (67.173.47.186) [67.173.47.186] F=<[email protected]> rejected RCPT <[email protected]>:
This indicates someone at that comcast.net address (probably a compromised desktop system) is trying to send email to [email protected]. That IP# is listed on a lot of blocklists. If you're running SpamBlock, then that might be why that email was rejected.
Exim can be rather cryptic to me. But this looks like someone connected to port 25 on my machine and proceeded to attempt to send to a long list of non-existant email addresses.
Perhaps. Or perhaps a spam-server knows enough to log into the mx for each address it's delivering.

A thorough study of the logs looking for similar messages to the one who's headers you posted might be able to help you figure it out.

Your system may be compromised. What does running the latest copy of chkrootkit show you?

Jeff
 
Re: Re: a little spam/relay help?

After further review:

1. the reject messages are from using SpamBlocker. Not sure if this is someone logging directly into our mailserver, or them just sending the emails and then the emails getting rejected when they hit our server.

2. The set of headers posted are from an email that was sent to a totally different domain/account than the list of failed sends.

Delving into the logs and looking at the message id (for the email I posted headers for) we have this (users domain is blanked, but email name left intact):

Code:
2004-10-06 23:18:13 1CFPj6-0007yw-EL <= [email][email protected][/email] H=(220.234.58.244) [220.234.58.244] P=smtp S=13144 [email protected] T="3.99/Month 800M$
2004-10-06 23:18:13 1CFPjJ-0007zM-LD <= [email][email protected][/email] U=mail P=spam-scanned S=16412 [email protected] T="3.99/Month 800M Web Hosting, 1.99/Mo$
2004-10-06 23:18:13 1CFPjJ-0007zM-LD => writer <[email protected]> F=<[email protected]> R=virtual_user T=virtual_localdelivery S=16582
2004-10-06 23:18:13 1CFPjJ-0007zM-LD => newlands <[email protected]> F=<[email protected]> R=virtual_user T=virtual_localdelivery S=16584
2004-10-06 23:18:13 1CFPjJ-0007zM-LD Completed
2004-10-06 23:18:13 1CFPj6-0007yw-EL => writer <[email protected]> F=<[email protected]> R=spamcheck_director T=spamcheck S=16336
2004-10-06 23:18:13 1CFPj6-0007yw-EL -> newlands <[email protected]> F=<[email protected]> R=spamcheck_director T=spamcheck S=16336
2004-10-06 23:18:13 1CFPj6-0007yw-EL Completed

that is the exim log for the email that appeared to be coming from my system. The IP address listed though makes me think it was not sent FROM our server.

I have become somewhat tight with security in the last year (and this server is only 3 months old). So I run chkrootkit (amongst several other utils/checks) every night. Chkrootkit comes back clean every time.

I am starting to think maybe this is indeed harmless. I just don't have the experience in tracking down spam to know 100% for sure.
 
actually, did a little testing and it does seem that whoever sent that first email could have actually just connected to port 25 and sent it.

I guess the SpamBlocker exim config (and probably even the default DA exim config) doesn't limit who can send through SMTP properly.

I telneted to port 25 from another server of mine and could send fine, even though this server's IP is not the pophosts file.

Is there a way to keep joe-anybody from telnetting to my server and sending emails like this? Or is this how SMTP operates (another mail server connects to port 25, sends HELO and proceeds to send the email that way)?

Luckily, relaying is prevented though.
 
Protollix said:
actually, did a little testing and it does seem that whoever sent that first email could have actually just connected to port 25 and sent it.
People (spammers), viruses, and corrupted systems try sending email through your server all the time. If they're listed on blocklists then SpamBlocker will block them and you'll get log entries such as the first ones you showed us.
I guess the SpamBlocker exim config (and probably even the default DA exim config) doesn't limit who can send through SMTP properly.
DA has been using the SpamBlocker config for several months now. And yes, by default both SpamBlocker and the original exim.conf supplied with old versions of DA, do block third party email relaying; that is third parties cannot use your server to send email to another third party. Anyone can connect through port 25 and deliver email that belongs to an account on your server, and anyone with an account on your server can authenticate and then send email through your server to any third party, but that's it.
I telneted to port 25 from another server of mine and could send fine, even though this server's IP is not the pophosts file.
Probably because you're continuing to accept mail from the server, so you're getting popb4smtp verification.
Is there a way to keep joe-anybody from telnetting to my server and sending emails like this? Or is this how SMTP operates (another mail server connects to port 25, sends HELO and proceeds to send the email that way)?
Unless you've accidentally or intentionally changed your /etc/exim.conf file third party relaying is disallowed.
Luckily, relaying is prevented though.
Unless I've misunderstood you, what you're writing about is third-party relaying.

Jeff
 
actually third part relaying is indeed disallowed (ie: someone telnets to port 25, attempts to send email to [email protected])

But as you stated, if someone telnets to port 25 and attempts to send mail to someone *on that same machine* it does indeed allow this.

I don't see how popb4smtp is allowing another server of mine to connect. That server never "POPs" in, and is not listed in the pophosts file.

It seems my only problem, and I guess this not something I can stop, is someone connecting to my SMTP server and spamming clients on that server.
 
Today, chkrootkit is coming back with "Possible slapper worm installed".

Investigating this now, though from what I can see, Slapper doesn't spam.

Not sure how this would have been installed though

Edit The reason it is detecting this is because my home machine is connected to IMAP (port 143). This didn't trigger it, but the port my home machine called out from is (port 1978). So I am guessing this is nothing to worry about, as I do indeed have a mail client running on that machine using nothing but IMAP...
 
Last edited:
Back
Top