Cannot Find Spammer Entrance

[KrazyBob]

I have a server running Virtuozzo 3.x with Plesk 8.3 for Linux. I have many IPs accessing port 25 to apparently send spam. I have been searching all day trying to find where they are coming in and have failed. It does appear that one deddicated IP assigned to the server is part ofg the problem, but even turning off mail for that domain fails to stop the problem. I have installed the sendmail mod and that does not reveal a php script being used. I have tried grepping the access_log for clues. That hasn't helped. I have checked PID's using lsof -p <PID> and that only shows my the various lib.so.2 etc. being called and confirmins the IP sending.

I am at a complete loss.

Running CentOS 4.5 Final

Here is a sample:


tcp 0 0 65.44.220.71:25 190.26.8.59:2569 ESTABLISHED 18760/qmail-smtpd
tcp 0 0 65.44.220.71:25 201.208.96.72:2603 TIME_WAIT -
tcp 0 0 65.44.220.71:25 216.9.248.50:46787 TIME_WAIT -
tcp 0 0 65.44.220.71:25 222.106.28.131:10243 ESTABLISHED 25493/rblsmtpd
tcp 0 0 65.44.220.71:35255 209.191.88.239:25 ESTABLISHED 16755/qmail-remote.
tcp 0 0 65.44.220.79:25 190.166.73.196:55757 TIME_WAIT -
tcp 0 0 65.44.220.82:25 221.225.48.73:1027 ESTABLISHED 19267/qmail-smtpd
tcp 0 0 65.44.220.83:25 190.22.136.241:3677 TIME_WAIT -
tcp 0 0 65.44.220.83:25 61.60.62.166:4127 ESTABLISHED 25482/qmail-smtpd
tcp 0 0 65.44.220.88:25 84.127.134.57:1543 TIME_WAIT -
tcp 0 0 65.44.220.88:25 85.71.34.43:3044 TIME_WAIT -
tcp 0 30 65.44.220.71:25 84.76.143.132:50481 ESTABLISHED 18631/qmail-smtpd
tcp 0 142 65.44.220.71:25 89.1.184.138:59833 ESTABLISHED 25483/qmail-smtpd

No sooner do I blick the IPs than another is used. At this point I have blocked all of Nigeria

 

[atomicturtle]

Probably its someone using a compromised user account, or if you've enabled pop locking, through a whitelisted proxy server. Check your mail logs for smtp_auth, or fire up a sniffer on port 25 and capture some of the traffic coming through the box.

 

[KrazyBob]

I am getting relaylocks but it isn't telling me anything more useful:

Jun 5 08:32:38 abb01 relaylock: /var/qmail/bin/relaylock: mail from 87.207.108.200:51039 (chello087207108200.chello.pl)
Jun 5 08:32:39 abb01 relaylock: /var/qmail/bin/relaylock: mail from 221.236.113.38:51760 (38.113.236.221.broad.yb.sc.dynamic.163data.com.cn)
Jun 5 08:32:39 abb01 relaylock: /var/qmail/bin/relaylock: mail from 85.216.104.12:4416 (hsi-kbw-085-216-104-012.hsi.kabelbw.de)
Jun 5 08:32:40 abb01 relaylock: /var/qmail/bin/relaylock: mail from 85.216.104.12:4418 (hsi-kbw-085-216-104-012.hsi.kabelbw.de)
Jun 5 08:32:41 abb01 relaylock: /var/qmail/bin/relaylock: mail from 24.232.136.193:56689 (ol193-136.fibertel.com.ar)
Jun 5 08:32:41 abb01 relaylock: /var/qmail/bin/relaylock: mail from 213.163.59.202:3002 (not defined)

 

[atomicturtle]

Try turning poplocking off, looks like they're spamming you through whitelisted proxies.

 

[KrazyBob]

That seemed to stop users from sending at all when I switched to closed relay. Otherwise, the server was set for SMTP AUTH but not poplock.

The server is now listed at Senderbase and I cannot find out what is going on.

 

[KrazyBob]

The moment I turn SMTP back on the attack begins from many, many IPs. I cannot locate the solution Googling.

-bash-3.00# tail -f /var/log/secure
Jun 6 00:17:21 abb01 xinetd[13752]: START: smtp pid=19814 from=209.11.164.183
Jun 6 00:17:22 abb01 xinetd[13752]: START: smtp pid=19856 from=200.56.250.193
Jun 6 00:17:23 abb01 xinetd[13752]: START: smtp pid=19886 from=148.240.195.194
Jun 6 00:17:23 abb01 xinetd[13752]: START: smtp pid=19895 from=213.197.155.129
Jun 6 00:17:24 abb01 xinetd[19912]: START: smtp pid=19935 from=71.49.171.69
Jun 6 00:17:25 abb01 xinetd[19912]: START: smtp pid=19962 from=71.49.171.69
Jun 6 00:17:25 abb01 xinetd[19912]: START: smtp pid=20007 from=127.0.0.1
Jun 6 00:17:25 abb01 xinetd[19912]: START: smtp pid=20045 from=201.240.45.213
Jun 6 00:17:26 abb01 xinetd[19912]: START: smtp pid=20055 from=58.8.157.19
Jun 6 00:17:28 abb01 xinetd[19912]: START: smtp pid=20080 from=201.214.122.195
Jun 6 00:17:31 abb01 xinetd[19912]: START: smtp pid=20089 from=58.9.143.213
Jun 6 00:17:32 abb01 xinetd[19912]: START: smtp pid=20092 from=219.128.36.190
Jun 6 00:17:33 abb01 xinetd[19912]: START: smtp pid=20100 from=190.68.33.89
Jun 6 00:17:33 abb01 xinetd[19912]: START: smtp pid=20101 from=190.87.102.150
Jun 6 00:17:33 abb01 xinetd[19912]: START: smtp pid=20104 from=190.68.33.89
Jun 6 00:17:33 abb01 xinetd[19912]: START: smtp pid=20106 from=194.54.78.80
Jun 6 00:17:34 abb01 xinetd[19912]: START: smtp pid=20111 from=190.87.102.150
Jun 6 00:17:35 abb01 xinetd[19912]: START: smtp pid=20119 from=202.143.164.12
Jun 6 00:17:36 abb01 xinetd[19912]: START: smtp pid=20123 from=71.165.154.176
Jun 6 00:17:36 abb01 xinetd[19912]: START: smtp pid=20127 from=66.168.92.94
Jun 6 00:17:38 abb01 xinetd[19912]: START: smtp pid=20138 from=190.40.116.161
Jun 6 00:17:38 abb01 xinetd[19912]: START: smtp pid=20139 from=190.40.116.161
Jun 6 00:17:38 abb01 xinetd[19912]: START: smtp pid=20148 from=83.111.179.212
Jun 6 00:17:39 abb01 xinetd[19912]: START: smtp pid=20154 from=201.229.130.88
Jun 6 00:17:40 abb01 xinetd[19912]: START: smtp pid=20158 from=200.44.209.3
Jun 6 00:17:41 abb01 xinetd[19912]: START: smtp pid=20165 from=190.65.83.200
Jun 6 00:17:41 abb01 xinetd[19912]: START: smtp pid=20167 from=200.38.7.104

 

[KrazyBob]

After paying Parallels for Per Incident Support, they took my money and replied that nothing was wrong, and that port 25 was closed at the firewall. How did they figure this out? By trying to Telnet to SMTP Server (Qmail) that I had turned off to stop the attack. Then they told me that the task was for a System Administrator. Um, that would be me... I don't want to bash Plesk Support, but gimme a break.

I am stumped here.

 

[KrazyBob]

When I trace the UID down from the maillog after using qmail-read:

-bash-3.00# grep 2020 /etc/passwd
alias:x:2021:2020:Qmail User:/var/qmail/alias:/sbin/nologin
qmaild:x:2020:2020:Qmail User:/var/qmail/:/sbin/nologin
qmaill:x:2022:2020:Qmail User:/var/qmail/:/sbin/nologin
qmailp:x:2023:2020:Qmail User:/var/qmail/:/sbin/nologin
-bash-3.00# grep 2020 /etc/group
nofiles:x:2020:drweb

But this does not help me.

 

[shoggy24]

maybe this thread can help
http://forum.swsoft.com/showthread.php?t=16774&page=2
did you scan for rootkits?

You are also better off paying Art to take a look at it for you than throwin money away with swsoft.

 

[KrazyBob]

Yes, the scan was clear.

Art who?

 

[shoggy24]

atomicturtle, the poster that replied to you first. website is here www.atomicrocketturtle.com

 

[KrazyBob]

Ya know, I knew that as soon as I asked I'm tired. Listed on Senderbase. Damn.

 

[atomicturtle]

Yup, you need to turn poplocking off, and get your users configured to use smtp_auth. What is happening is that one or more of your users is coming from a proxy server, when they get their mail from pop, that proxy server is whitelisted. Any spammers using that proxy server can now send spam through your mail server.

 

[KrazyBob]

I am confused with your reply because SMTP AUTH has always been on, just not poplocking. Do I understand correctly that you think both need to be on? Our customers have always been required to set My Server Requires Authenication.

 

[atomicturtle]

You dont want to use poplocking. What could be happening is that someone has compromised a users account and are spamming through that.

 

[KrazyBob]

Kewl. We're in agreement! But I have been unable to locate that account. I use qmail-read to get the message number that I then grep in the maillog to locate the UID. I then grep that in /etc/passwd and it tells me 2020 --DrWeb Antivirus.

 

[shall]

Try disabling antivirus scanning and see if you get different results. I suspect you'll have more accurate user accounts represented when it's not being passed through DrWeb.

 

[KrazyBob]

Disabling AV made no difference. SW-Soft was useless but kept my money. I finally located the site and after disabling it and changing all of the user passwords the SPAM stopped. The two clues where qmail-read and then grepping the message number in the maillog. qmHandle helped to reveal the actual message and confirmed my findings. I learned the hard way how to find the spammer this time. Better prepared for next time, but disappointed with Support Staff. I still don't know why the UID was reporting as Dr.Web. I'll get over it.