4

My mailq is getting filled with reports about email been sent (to for example freshsamuel2009@yahoo.com) by non existing local user (for example jeanne_cox@localdomains.tld)

mailq example:

8F979561A3     1440 Thu Aug 25 13:54:32  jeanne_cox@localdomains.tld
(delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused)
                                         freshsamuel2009@yahoo.com

How can I stop it?

my main.cf is:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = /usr/share/doc/postfix

# TLS parameters
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = faster2.jbmd.com
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
alias_database = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
myorigin = /etc/mailname
mydestination =  localhost, localhost.localdomain
relayhost = 
mynetworks = 127.0.0.0/8 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
html_directory = /usr/share/doc/postfix/html
virtual_alias_domains = 
virtual_alias_maps = hash:/var/lib/mailman/data/virtual-mailman, proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, proxy:mysql:/etc/postfix/mysql-virtual_email2email.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /var/vmail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
inet_protocols = all
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf
smtpd_tls_security_level = may
transport_maps = hash:/var/lib/mailman/data/transport-mailman, proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
relay_domains = mysql:/etc/postfix/mysql-virtual_relaydomains.cf
relay_recipient_maps = mysql:/etc/postfix/mysql-virtual_relayrecipientmaps.cf
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unlisted_sender,  reject_unknown_sender_domain,check_sender_access regexp:/etc/postfix/tag_as_originating.re, permit_mynetworks, permit_sasl_authenticated, check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf, check_sender_access regexp:/etc/postfix/tag_as_foreign.re 
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_client_hostname, check_client_access mysql:/etc/postfix/mysql-virtual_client.cf reject_rbl_client cbl.abuseat.org,  reject_rbl_client b.barracudacentral.org
smtpd_client_message_rate_limit = 100
maildrop_destination_concurrency_limit = 1
maildrop_destination_recipient_limit = 1
virtual_transport = dovecot
header_checks = regexp:/etc/postfix/header_checks
mime_header_checks = regexp:/etc/postfix/mime_header_checks
nested_header_checks = regexp:/etc/postfix/nested_header_checks
body_checks = regexp:/etc/postfix/body_checks
owner_request_special = no
smtp_tls_security_level = may
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3
dovecot_destination_recipient_limit = 1
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
content_filter = amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings
message_size_limit = 0
default_process_limit = 150
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
0
3

In the best of the scenarios, one or more of your users is compromised e.g. bad actors guessed/phished the password.

Since you allow sending email from authenticated users, they are most probably faking the From field to avoid detection.

Editing the full body of a couple of relevant messages will give you a hint of which user(s) you have compromised.

As a starting point I would advise restricting the From field to known users, have a look at this thread. Postfix: prevent users from changing the real e-mail address

As the middle scenario, you can have an exploit of some page/cgi in a web server if the postfix server is running Apache.

As the worst scenario, you can have a compromised box.

Have a look at postfix and Apache access logs (if you have Apache), it will give you a more reasonable idea of what it is happening.

EDIT: After @P.Masher posted an example of the deferred message:

The relevant line to pay attention is:

X-PHP-Originating-Script: 5015:alias.php(1944) : eval()'d code

What it says it that you have a script name alias.php, possibly planted in a less secure directory accessible to your web server (Apache?), that is the culprit for sending the emails.

The script will have to be deleted, and the directory and any other possible way in (old wordpress, SQL injection, old webmail interface) the spammers have used to plant this script will have to be closed.

A temporary solution may be stopping the web server altogether.

I would also collect web server logs of the access to alias.php and would send them to the local CERT. (if you have one that you usually work with )

As for more security considerations, the fact they are executing code through an eval() means they basically have access to any file the user that is running the vhost/Apache has access. i.e. it is the same as having a remote shell account in the server.

If the server is old/has no updates, they might as well have leveraged privileges to root level in the worst scenario; in the best scenario, they only have access equivalent to the web server non-privileged user, but may have already tried to leverage passwords from HTML/PHP files, and might as well have collected the hashed passwords of your postfix users.

I would advise to:

1) Reinstall the server if it is too old or has no security updates;
2) Change DB/root passwords;
3) Advise the postfix users to change their passwords just in case.

1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – terdon
    Aug 26 '16 at 8:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.