Suggestions for Expansion, Please

[amandler]

Spamdyke notes

Some things that might be helpful to others who decide to get spamdyke running with Plesk:

Be sure that spamdyke compiles with TLS. When you run ./configure, you need to read the output carefully and check that it found openssl and will include TLS in the compile. On my system, I had to apt-get install openssl-dev first to get all the libraries on there that spamdyke wanted.

To check whether the executable has TLS support, type
# spamdyke -v
You should see: spamdyke 4.0.4+TLS+CONFIGTEST+DEBUG (C)2008 Sam Clippinger, samc (at) silence (dot) org
or similar. Note the presence of TLS.

To check your spamdyke.conf file, use:
# spamdyke -f /etc/spamdyke.conf --config-test /var/qmail/bin/qmail-smtpd

This will let you know that your conf files and directories are in the right place and readable. You will get an error related to SMTP AUTH, since qmail uses relaylock, not smtpd, to do AUTH.

 

[Felix Buenemann]

Note also that for the inetd line/xinetd config file that runs the SMTPS (SMTP over SSL service) you should add --tls-level smtps to spamdyke's commandline or it won't work correctly.

@amandler: You seem to be mixing up reverse dns and sender adress blocking. t-dialin.net isn't used for e-mail-addresses, it should be blocked as a dialup host from either blacklist_keywords or blacklist_senders with an entry like ".t-dialin.net". (Using blacklist_keywords additionally checks for the ip adress in the reverse dns, which is hex encoded in the t-dialin.net case.)

 

[Felix Buenemann]

That was the problem. Thanks. All good now (except for the mysterious icon problem in Plesk). Many thanks to all of you!

Check the output of /path/to/psa/admin/bin/mailmng -s it should output "is running", otherwise strace the process to see whats wrong.

 

[amandler]

SMTP Authorization Confusion

This is a bit off topic, but I've really appreciated the knowledge of the participants in this thread, and this issue has me stumped.

A spammer is managing to inject messages into my queue using smtp authorization, but I can't figure out how. Here's an example of the spamdyke log entry:

Sep 23 14:07:54 host0 spamdyke[29826]: ALLOWED from: service@bankofamerica.com to: 2@yahoo.com origin_ip: 75.147.110.137 origin_rdns: 75-147-110-137-philadelphia.hfc.comcastbusiness.net auth: backup

The auth name used here is "backup", but I deleted that user from my system last week when this happened (I checked, and the user has not be recreated). Does SMTP use some other authorization list other than the Linux users? What is it? How is this message getting authorization?

I blocked the IP in my router to stop the messages, but I'm really confused about how this message is permitted.

Thanks for any insight. -- Art

 

[amandler]

In answer to my own question, it appears I was suffering from the security flaw that Felix mentioned here:
http://seclists.org/bugtraq/2008/Sep/0001.html
I had not correctly removed short names from my config.

 

[Ragefast]

amandler,

First of all, the security hole Felix mentioned is so far narrowed down to OpenSUSE OS, since me and a couple other forum users attempted without success reproduce the whole thing, on RHEL and CentoOS. Don't know about Debian/Ubuntu. See here for a somewhat heated discussion:
http://forum.swsoft.com/showthread.php?t=55221

As for the spammer still using the backup account, when you have shortnames enabled, you can have more than one mail account called 'backup', for example, backup@domain1.com, backup@domain2.com, backup@domain3.com will all use the login 'backup', and spamdyke will only log messages from the 'backup' user.

Just think about you suddenly changing short and long names on a 10k mail account server to only long names and then no one being able to login anymore... It would be a pretty neat chaos.

But from what I understand from your previous post, the user 'backup' you deleted was a system user, not a mail account, so it should still be possible for the spammer to use it. Here's a quick'n'dirty sql query to find mail logins on the psa database (theres plenty more correct queries around in this forum, i just use this because it works):

select concat(mail_name,"@",name," ",password) from mail,domains,accounts where mail.dom_id = domains.id and mail.account_id = accounts.id and mail.mail_name = 'suporte';

 

[amandler]

Thanks for your help, Ragefast. I had already checked for both system users AND email accounts called "backup". The only one that existed was the default Linux system user, which I deleted last week. I rechecked just now using your sql query, and confirmed there is no user "backup" on any domain.

So, clearly there is some other issue here. Since I generally instruct my users to use long names, making the change not to allow short names is not too egregious, and I've done it. I will keep this thread posted on my success in stopping this spammer.

 

[Ragefast]

Oh, btw, I hope you noticed, but I pasted the query with my test user, so you probably need to change that to 'backup' else it won't work... =/

Also, I found this tool from Plesk that spits all mail logins just about like what that query does, so I'd like to hear from you if the same result is true after running it (no backup account):
/usr/local/psa/admin/bin/mail_auth_view

 

[amandler]

Looking for Mr. Backup

Yes, I edited your query to search for "backup". I also tested it with several email names I know exist so I'm confident it was working. I used mail_auth_view to triple check (I had earlier run a query similar to yours), and there is no user "backup" on my system in any domain.

I can find no other explanation than the security flaw previously discussed.

Since I have now limited logins to long names only, we will see if any further injections of emails occur in the next week or two.

Thanks for all your help.

Art

 

[Felix Buenemann]

I have posted some clarification on the security issue posted over in the thread RageFast mentioned:

http://forum.swsoft.com/showthread.php?p=215349#post215349

It seems to be indeed OS related.

I have also edited my sample blacklist_keywords posted in this thread on Sep 15th, because it was using an incorrect syntax.