Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: torrestech on September 13, 2007, 11:56:56 PM
-
Started happening the last day or two. Now it has really picked up the pace. I am sending huge amounts of spam. I am running the latest updates and this is what i have been able to gather.
uid 400 is sending heaps... This is qmail?
The rejected emails say from pc-00242.torrestech.com.au (HELO [203.196.46.230]) (192.168.241.242)
None of these IP addresses exist and pc-00242 is non-existant. the ip 192.168.241.* is correct for my domain but i cannot ping 192.168.241.242.
Last night i turned off all the computers connected to the domain but the spam kept flowing. I am hosting a number of websites. Perhaps there is a form somewhere???? still does not explain this mysterious pc-00242.torrestech.com.au.
I have ssh enabled but pptp is set to 0.
I need help as the spam is killing my productivity and i do not know how to stop it.
Below is a summary of the logs.
Adam
mess bytes sbytes rbytes recips tries xdelay uid
2 3204 3204 3204 2 2 0.250630 0
2 122218 122218 122218 2 2 0.098233 10
3611 23893593 23893593 23893593 3611 3611 204.760055 101
9374 62461311 62461311 62461311 9374 9374 396.357321 400
3915 24965680 23332990 24965680 3915 3915 5098.502407 406
1090 7099566 7144124 7144124 1106 1106 85.647658 453
969 6744390 6744390 6744390 969 969 78.313397 5017
2 122720 122720 122720 2 2 0.434942 5027
---------------------------------
A snippet from the qmail log
2007-06-15 02:23:12.475293500 tcpsvd: info: pid 27539 from 66.232.96.139
2007-06-15 02:23:12.475417500 tcpsvd: info: concurrency 27539 66.232.96.139 1/4
2007-06-15 02:23:12.475419500 tcpsvd: info: start 27539 0:203.196.46.230 ::66.232.96.139:47317 ./peers/0
2007-06-15 02:23:14.295555500 tcpsvd: info: end 27539 exit 0
2007-06-15 02:23:14.295559500 tcpsvd: info: status 0/40
2007-06-15 02:23:14.906953500 tcpsvd: info: status 1/40
2007-06-15 02:23:14.906958500 tcpsvd: info: pid 27540 from 66.232.96.139
2007-06-15 02:23:14.906959500 tcpsvd: info: concurrency 27540 66.232.96.139 1/4
2007-06-15 02:23:14.906961500 tcpsvd: info: start 27540 0:203.196.46.230 ::66.232.96.139:47884 ./peers/0
2007-06-15 02:23:16.725552500 tcpsvd: info: end 27540 exit 0
2007-06-15 02:23:16.725557500 tcpsvd: info: status 0/40
----------------------------------------------------------------------------------------
-
Is there any chance that the spam sent while all workstations were off was just waiting in the queue already? (If so, perhaps one of your workstations has been hijacked somehow).
Have you created any 'local networks' in server-manager? (A 'local network' of '0.0.0.0' / '0.0.0.0' might open your SME as a relay).
If all of the spam says HELO [203.196.46.230]) (192.168.241.242) perhaps you could block all traffic from 203.196.46.230?
On my SME 7.2 (upgraded from 7.0) server, UID 400 is 'alias' (at least, the line in /etc/passwd for id 400 starts with 'alias').
iptraf comes w/ SME (I think), and will let you monitor active connections.
You might try this on your local network:
ping 192.168.241.242
Wait for it to fail, then run this:
arp -a
If arp shows a MAC address for 192.168.241.242 then there really is a host on your network with that IP, even though it doesn't respond to ping. A non-existent host will result in an ARP table entry with a MAC address of 00-00-00-00-00-00...
Are you running v7.2?
Have you reset your yum repository configuration?
http://wiki.contribs.org/Updating_to_SME_7.2#Ensuring_the_correct_yum_repository_configuration
-
Thanks for the reply.
There is no chance the spam was sent whilst the workstations were offline. I turned them off all night. Spam just kept flowing.
No local Networks are created in Server manager
I do not know how to block all traffic from 203.196.46.230, and it still wont fix future problems.
When i do the arp -a i get pc-00242.torrestech.com.au (192.168.241.242) at <incomplete> on eth0
only problem is that there is no host pc-00242.torrestech.com.au on my local network.
Have you reset your yum repository configuration? ------- What???????
I did not do this. Ok! All done now and the spam has stopped!!!!!!!!!!!!!!
mmccarn you are a Genious, a legend and i am sure i can think of other praises.
Adam
-
I'd be interested to see the modules that were updated after you re-configured yum... You could get this list from /var/log/yum/yum.log
-
A snippet from the qmail log
No, that's your qpsmtpd log. Your qpsmtpd log will also show where any SMTP mail originated (and you've shown some connections from 203.196.46.230), and will show what "helo" hostname was used, and what from and to addresses were used for the mail.
-
No, that's your qpsmtpd log.
Sorry, no, that's likely to be your sqpsmtpd log. Or your imap or imaps log. But not your qmail log.
-
There is no chance the spam was sent whilst the workstations were offline. I turned them off all night. Spam just kept flowing.
Your SME server would continue to send spam long after the workstations were off-line. The SME server has a very large queue. Spam flowing out of your SME server when workstations are turned off is not evidence that the spam did not originate from a workstation. You need to study and understand your qpsmtpd and qmail logs to learn where and when the spam arrived at your SME server and when it left your SME server.
If your SME server or some other system on your network had an open mail relay, you must learn where that was and correct it.
I do not suspect a problem with SME server software, but I do not wish to take a chance. Please post a fully detailed bug report to the bug tracker, and make sure that you tick the "Security" checkbox.
-
No Good. I am still sending huge amounts of spam. thought things were solved for a little while.
I am sending this to the bug tracker. IMAP log shows a lot of the following and 80.218.108.233 is not from my network.
2007-09-16 14:18:35.245204500 tcpsvd: info: pid 27406 from 80.218.108.233
2007-09-16 14:18:35.245205500 tcpsvd: info: concurrency 27406 80.218.108.233 1/6
2007-09-16 14:18:35.245206500 tcpsvd: info: start 27406 0:203.196.46.230 ::80.218.108.233:54620 ./peers/0
2007-09-16 14:18:35.247280500 imapfront-auth[27407]: * OK imapfront ready.
2007-09-16 14:18:35.251049500 2007.09.16 04:18:35 LOG5[27406:3086292672]: Using 'imap' as tcpwrapper service name
2007-09-16 14:18:35.256139500 2007.09.16 04:18:35 LOG5[27406:3086292672]: stunnel 3.22 on i686-redhat-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.7a Feb 19 2003
2007-09-16 14:18:35.256365500 2007.09.16 04:18:35 LOG5[27406:3086292672]: imap connected from 80.218.108.233:54620
2007-09-16 14:18:40.242494500 2007.09.16 04:18:40 LOG3[27406:3086292672]: Unexpected socket close (fdgets)
2007-09-16 14:18:40.242499500 2007.09.16 04:18:40 LOG3[27406:3086292672]: Protocol negotiations failed
2007-09-16 14:18:40.243117500 tcpsvd: info: end 27406 exit 0
2007-09-16 14:18:40.243120500 tcpsvd: info: status 0/400
2007-09-16 14:18:40.669695500 tcpsvd: info: status 1/400
2007-09-16 14:18:40.669700500 tcpsvd: info: pid 27412 from 80.218.108.233
2007-09-16 14:18:40.669701500 tcpsvd: info: concurrency 27412 80.218.108.233 1/6
2007-09-16 14:18:40.669702500 tcpsvd: info: start 27412 0:203.196.46.230 ::80.218.108.233:54634 ./peers/0
2007-09-16 14:18:40.672800500 2007.09.16 04:18:40 LOG5[27412:3086714560]: Using 'imap' as tcpwrapper service name
2007-09-16 14:18:40.677995500 2007.09.16 04:18:40 LOG5[27412:3086714560]: stunnel 3.22 on i686-redhat-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.7a Feb 19 2003
2007-09-16 14:18:40.678312500 2007.09.16 04:18:40 LOG5[27412:3086714560]: imap connected from 80.218.108.233:54634
2007-09-16 14:18:40.679202500 imapfront-auth[27413]: * OK imapfront ready.
2007-09-16 14:18:40.679785500 imapfront-auth[27413]: < BAD Unimplemented command
2007-09-16 14:18:45.667449500 tcpsvd: info: end 27412 exit 0
-
No Good. I am still sending huge amounts of spam. thought things were solved for a little while.
I am sending this to the bug tracker.
Please do it soon.
IMAP log shows a lot of the following and 80.218.108.233 is not from my network.
IMAP has nothing to do with sending email. IMAP only allows access to messages in email folders.
If you enable public access to IMAP, you can expect to have unauthorised connections. If you don't want unauthorised connections, don't enable public access to IMAP.
-
My imap setting says Allow both IMAP and IMAPS
There are other options below that say Allow private and
Allow provate and Public (secure somethign).
Anyhow a bug has been posted http://bugs.contribs.org/show_bug.cgi?id=3395 with a more verbose description of things.
Thanks for all the help.
Adam
-
My imap setting says Allow both IMAP and IMAPS
There are other options below that say Allow private and
Allow provate and Public (secure somethign).
I think you would be wise to set that ONLY to:
Allow private and public (secure IMAPS)
-
Your server has most likely been upgraded from a VERSION 6? In this days, you could set IMAP (or pop3 for that matter) to BOTH secured and unsecured. In version 7, you have only the choice of private or secured. From memory, once you select secured only, you will not be able to revert to secure AND unsecured.
-
I also have had some spam relaying happening on my 7.2 system, starting around the 15th or 16th Sept. Evidenced by many hundreds of bounces coming back at me from one sender in my domain. I tried to interpret the logs, and look through qmail configuration, but it all got too hard. I'm using SMEServer in a home situation. I got around the problem by changing the ISP Smarthost setting, and setting all my PCs to send mail directly to my ISP, rather than through the SMEServer. The SPAM bounces immediately dropped off in rate. After a few days, I am now getting only the occasional notification like "still trying after 4 days".
I registered on bugzilla, but don't have permission to access #3395.
Cheers,
Mark
-
I also have had some spam relaying happening on my 7.2 system, starting around the 15th or 16th Sept. Evidenced by many hundreds of bounces coming back at me from one sender in my domain. ...
Bounce messages only mean that some mail messages which claim to have been sent by someone in your domain were undeliverable. Virtually all spam has forged sender addresses, so if your server was used to send spam, you would not see the bounce messages.
However, since you suspect an SME server problem, please report the details of your issue to Bugzilla.
-
I have seen bounces from bogus sender addresses before. The volume on this occasion was greater by a factor of around 100 times. The bounces stopped (dramatically slowed) when I disabled sending from my SMEServer.
I get permission denied when trying to view bugzilla #3395.
Should I open a new bug?
I will be looking for suggestions on what logs to send & configs to check.
Cheers,
Mark
-
I have seen bounces from bogus sender addresses before. The volume on this occasion was greater by a factor of around 100 times. The bounces stopped (dramatically slowed) when I disabled sending from my SMEServer.
So the bounces didn't stop.
The frequency with which you receive bounce messages will vary depending on how frequently spammers are forging your user's addresses as sending addresses, if that is what is happening.
Receiving bounce messages is not evidence that your system sent spam, unless the messages themselves contain evidence that your system actually handled them.
Should I open a new bug?
Of course.