postfix & csf problem?

Hi,

I tried installing csf (I think it has to do with this), but I saw an error in virtualmin whenever I try to “open” any server. In the left column, in stead of the normal options, I now see:

Failed to query Postfix config command to get the current value of parameter sender_dependent_default_transport_maps:

I’ve set csf to testing again, but that didn’t help.

What am I to do?

Thanks!

Howdy,

What is the output of this command:

postconf -n

Also, are you using CentOS? If so, what is the output of this commands:

rpm -qa | grep postfix

Hmmm,

I’m in real trouble now. As soon as I logged in over SSH, I get max. 5 seconds before being disconnected. I don’t know who is doing it (csf has been set to testing mode again) but it doesn’t look very good. There’s no way for me to enter the server via SSH now. Virtualmin and all the websites are still online though.

Server load is really high, up to 20.

The message when it disconnects me: “Network error: Software caused connection abort.”

KVM access that the hosting company offers me just shows “No signal”, and “No signal, power down” (which is not true, the sites are online)

I guess I’m in real trouble now.

Any ideas are appreciated. I’m mailing the company that hosts the dedicated server now as well…

Thanks!

I managed to reboot the server in the 2 seconds that I got with a quick login and a shutdown -r now

That seems to have solved the original (postfix) problem.

The SSH problem remains. My server had been compromised, so I’m now worrying that someone has set a script to disconnect all ssh connections… As stated, I did install CSF but I did set that to testing mode again after I had a problem.

Everything seems to work fine again, except for that SSH problem and the high load. (It’s still over 20, but without an obvious causing process.) I get to look at the ‘top’ results for more or less 2 seconds before being disconnected…

Hmm, my suspicion is that you may be dealing with some sort of process or resource limit that’s bring reached, and causing you to be disconnected.

It’s rare that there’s a root compromise… most likely, someone broke into a website or email account, and is doing something within that account. They’re not likely intentionally logging you out of your SSH session.

How many emails are in the mail queue? You can determine that with this command:

mailq | tail -1

Or, you can go into Webmin -> Servers -> Postfix -> Mail Queue to determine that.

Sometimes, a high amount of email in the mail queue can cause the symptoms you’re seeing.

-Eric

Thanks Eric!

This morning, SSH is normal again, and the load of the server is normal too.

Mail queue shows: >36000 messages.

All those messages are spam stuff. (see attached file) (can’t attach the screenshot, produces an error).

I’ve deleted all messages in the queue. (sudo postsuper -d ALL)

Now I have to see if I can find out what script or whatever was sending them, no?

postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
home_mailbox = Maildir/
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
message_size_limit = 20480000
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
readme_directory = no
recipient_delimiter = +
sender_bcc_maps = hash:/etc/postfix/bcc
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_security_options = noanonymous
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_maps = hash:/etc/postfix/virtual

But when I send mail to a virtualmin user, on any domain, it never arrives…

Looking at the headers in the postfix mail queue i found a script, ns-blog.php that was sending the spam. I’ve deleted it, and will search for more.
Mail for normal users still doesn’t work (they don’t receive anything, will try sending now)

Are you seeing any errors in your email client when you try to send mail? Anything in the syslog or mail.log or procmail.log at the time of delivery attempt?

About the PHP script that was sending spam: Did that belong to a customer’s webspace? If so, it stands to reason that their account was compromised; you might want to change their administrative user password, and check the FTP logs for uploads of that script.

I’d also recommend using a software like LMD (Linux Malware Detect) and let it scan your customers’ webspace folders regularly.

Thanks Locutus!

No, no errors, and in the last minutes the mails that I sent as a test over an hour ago have been arriving. But, I had to unlist the ip here:

http://www.spamhaus.org/query/bl?ip=88.208.193.145

which might have to do with the mail not being delivered problem…

php was in a website with an old version of joomla. I’ve checked the components and disabled a few old ones that were on joomla’s vulnerable extensions list (http://vel.joomla.org/).

Cleaned up more .php scripts that shouldn’t be there in several folders.

I’ll see if I can find ftp logs.

I did install csf and maldetect yesterday or the day before.

Ah, yes, since your system was abused to send spam, you’d get listed on blacklists rather quickly. But that listing should apply only to outgoing mails, when other mailservers check your IP, it should not influence receiving mails.

I use this site here for checking multiple RBL lists for an IP address:

http://www.anti-abuse.org/multi-rbl-check/

Unfortunately, it appears as if your IP is on about 7 of them at the moment.

Many of those will clear out automatically over time, but you can often work with the various RBL’s in order to speed that process up.

-Eric

Oh, are you still receiving this error you mentioned initially:

Failed to query Postfix config command to get the current value of parameter sender_dependent_default_transport_maps:

Hi Andreychek,

no, that message is gone, virtualmin works well again.

Thanks for the anti abuse link, I’m checking it out now.

maldet found quite a few scripts, it’s good to be cleaning up.

With the old insecure components deleted from the old joomla versions, I’m curious to see if the malware returns soon.

Thanks everybody for your attention and time, really appreciated!