Sending Spam Email

Help! (Home for newbies)
1
SYSTEM INFORMATION
OS type and version Debian GNU/Linux 11 (bullseye)
Virtualmin version 7.7
Webmin version 2.021
Usermin version 1.861

Good evening,
as the title suggests, I would like to try to address the problem from another perspective, ie starting from the problem I’m sure of and that is that there are several IPs that are sending spam from my server.

To begin the analysis, I am attaching what I think is the most sensible log, namely the analysis of a queued email, from which various details can be deduced.

It should be noted that the root@luigidonato.it user does not exist.

*** ENVELOPE RECORDS deferred/A/A9526241100 ***
message_size: 4961 839 2 0 4961 0
message_arrival_time: Tue May 9 23:03:11 2023
create_time: Tue May 9 23:03:11 2023
named_attribute: log_ident=A9526241100
named_attribute: rewrite_context=remote
named_attribute: sasl_method=PLAIN
named_attribute: sasl_username=root
sender: root@luigidonato.it
named_attribute: log_client_name=unknown
named_attribute: log_client_address=85.114.97.18
named_attribute: log_client_port=46528
named_attribute: log_message_origin=unknown[85.114.97.18]
named_attribute: log_helo_name=[127.0.0.1]
named_attribute: log_protocol_name=ESMTP
named_attribute: client_name=unknown
named_attribute: reverse_client_name=unknown
named_attribute: client_address=85.114.97.18
named_attribute: client_port=46528
named_attribute: server_address=75.119.152.130
named_attribute: server_port=25
named_attribute: helo_name=[127.0.0.1]
named_attribute: protocol_name=ESMTP
named_attribute: client_address_type=2
named_attribute: dsn_orig_rcpt=rfc822;terryfranklin078@gmail.com
original_recipient: terryfranklin078@gmail.com
done_recipient: terryfranklin078@gmail.com
named_attribute: dsn_orig_rcpt=rfc822;a.schmitz-1@web.de
original_recipient: a.schmitz-1@web.de
recipient: a.schmitz-1@web.de
*** MESSAGE CONTENTS deferred/A/A9526241100 ***
Received: from [127.0.0.1] (unknown [85.114.97.18])
by mail.donagest.com (Postfix) with ESMTPA id A9526241100;
Tue, 9 May 2023 23:03:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=luigidonato.it;
s=202208; t=1683666192;
bh=rjv8sckOj99DP7+VVrJDCrwifp/hH2xVmFAonbBoJv8=;
h=Date:Subject:From:To:From;
b=acjdHPADKUAPPkx9HHPVdY2WN0b3ejV8PjiB2dcQqw88wrx3khFSvYQYFYh1OPsDN
DbolN/s/nCfKzOBP83ZVxUZHcJIm9uuroh7ScJlXeabp5KI1Tk6cdW1GE467wDVjh0
o0JuCht3wU1njTvRAsQQkBNmJx4I9Ho+VGp96bFMt95VvEY/LDr+1uV864zh/aoKT2
8dCqAJ99KKz1ogLihiFk7pLvtTbMazITREyHYmz4N/d9xhNrjqgSazLZBfwWjRwNuM
bnuu2c+4xZQcCBRfYBi4owutlvJ1xoTaiS7Yr36K+OPWLUY27uJiQ6mOI2e7F/yHee
Wbeg43+sUu3og==
Date: Tue, 9 May 2023 14:03:11 -0700
Subject: Hi teedog New message from CassidyButterBabe
From: root@luigidonato.it
To: terryfranklin078@gmail.com, a.schmitz-1@web.de
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=“–_com.android.email_55883954208226”
Message-ID: x4tprlj-injlhs-5B@luigidonato.it

This is a multi-part message in MIME format

----_com.android.email_55883954208226
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Meet Someone
New Today
Do not be lonely tonight! Dozens of hot ladies want you!:kissing_heart:
I hope you’re not shy :wink: because I’m DYING to swap sexy pics with you!=
=2E… Just tell me what you want me to take off…

https://spamm.er/link
:point_up:You=E2=80=99re receiving this email because you signed up for o=
ur product newsletter or newsletter of our business partner. If you=E2=
=80=99d like to be removed from our mailing list please click https://spamm.er/link

----_com.android.email_55883954208226
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=20

body{display:flex !important;flex-direction:c= olumn !important;margin:0 !important;} New message from
Meet Someone
New Today
=

<span style=3D"font-size:33px; font-style: italic;“>Do not be lonely t=
onight! Dozens of hot ladies want you! <span style=3D"font-style: norm=
al;”>😘

I hope you're not shy ;) because I'm DYING to swap sexy pics with you!= =2E.. Just tell me what you want me to take off....
You=E2=80=99re receiving this email because you signed up for= our product newsletter or newsletter of our business partner. If you=E2= =80=99d like to be removed from our mailing list please click here

----_com.android.email_55883954208226–

*** HEADER EXTRACTED deferred/A/A9526241100 ***
*** MESSAGE FILE END deferred/A/A9526241100 ***

2

So, luigidonato.it is a domain on your server, yes?

I can’t figure out what I’m looking at in your quoted text. There’s email headers there (which is useful and what I want to see), but some other stuff that’s confusing me. I need to see the log entries related to this specific email, and to get that we need to know the ID postfix assigned to the email. Maybe it’s this? A9526241100 Search your mail.log for that ID and post the lines that reference it (and any related lines immediately above or below it, use your best judgement for whether they’re related).

But, I will mention that someone else had recently posted about their root user having password set to “none required” (which is wildly dangerous), but would maybe explain what you’re seeing.

Check that. We’ve removed the ability to even set that option in Webmin, but I think the version in our repos will still show it. So, check in Webmin->System->Users and Groups->root to make sure you aren’t allowing anyone to login as root without a password (if you are, spam is maybe the least of your concerns).

3

Sender from “FROM:” header is irelevant. This mail is sended from client system 85.114.97.18, by local system account "root " that enabled after SASL authentication:

named_attribute: sasl_method=PLAIN
named_attribute: sasl_username=root
4

this sorts of sums that ip address up

image
image502×532 21.7 KB

5

This is first. After root password change. Disable remote root login with password. Download debsums from debian - do not use from system if installed. Verify MD5 sums of all installed packages. Because if someone logged in as root and the real root doesn’t know about it, the system is very likely compromised.

6

Yes, luigidonato.it is 1 of 5/6 virtual domains.

image
image1319×864 61.8 KB

About the mail ID, yes it is and it is related to the logins on mail.log, but this is just an example, every day dozens of IPs connect and send spam emails.

Ok, I saw that they have a GitHub channel but there’s no one else mentioning them on the web I think… So I don’t think it’s helpful

7

So they’re just brute force until they can get in. I think we’re back to the previous problem, something should block them after X attempts but apparently it doesn’t.

8

Ok, I ran a:
sudo debsums --all --changed
And this is the output:

/etc/apache2/conf-available/security.conf
/etc/apache2/mods-available/ssl.conf
/etc/apache2/ports.conf
/etc/apache2/apache2.conf
/etc/apache2/suexec/www-data
/etc/cron.d/awstats
/etc/bind/named.conf.local
/etc/fail2ban/jail.conf
/etc/logrotate.conf
/etc/mysql/mariadb.conf.d/50-server.cnf
/etc/init.d/milter-greylist
/etc/milter-greylist/greylist.conf
/etc/opendkim.conf
/etc/default/opendkim
/etc/sysctl.conf
/etc/default/saslauthd
/etc/default/spamassassin
9

It is sad to say that once a security breach is found on an IP it is passed around to other bad minded folk. That is why if the root access is open it usually the end of that IP’s useful life. Closing the stable door after the horse has bolted is usually a waste of time.

1 Like
10

Drama is not needed at this moment, useful information is needed to solve the problem, let’s avoid superfluous comments so as not to end up like in the other topic

11

My apologies @LuigiMdg that you see this as a “superfluous comment” but many years of experience and having seen this before has informed me that you are trying to achieve the impossible. It is a simple fact that if you have a server where the root user has been accessed you are wasting your time trying to fix it. I’ll add nothing else to this or that other confused topic. Good luck.

1 Like
12

I didn’t ask about others. I wanted to see specific log entries. If you want to solve the problem, you need to understand the series of events that is happening. You can’t do that by looking at a thousand log entries and going, “Oh, wow, that’s a lot.” You look at one interaction, which will explain exactly what events took place. Without understanding the problem, I can’t give useful advice (and nobody else can either). We can only guess.

1 Like
13

Maybe this needs to be a two person thread? Maybe all irrelevant posts need to be deleted. Even those by the OP. Focus has been a real issue here.

1 Like
14

Ok, but they do not differ from those already published:

May  9 23:03:11 panel postfix/smtpd[1455816]: A9526241100: client=unknown[85.114.97.18], sasl_method=PLAIN, sasl_username=root
May  9 23:03:12 panel postfix/cleanup[1455820]: A9526241100: message-id=<x4tprlj-injlhs-5B@luigidonato.it>
May  9 23:03:12 panel opendkim[541]: A9526241100: DKIM-Signature field added (s=202208, d=luigidonato.it)
May  9 23:03:12 panel postfix/qmgr[1124059]: A9526241100: from=<root@luigidonato.it>, size=4961, nrcpt=2 (queue active)
May  9 23:03:12 panel postfix/smtp[1455830]: A9526241100: host mx-ha03.web.de[212.227.15.17] refused to talk to me: 554-web.de (mxweb004) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record. 554 For explanation visit https://web.de/email/senderguidelines?ip=75.119.152.130&c=rdns
May  9 23:03:12 panel postfix/smtp[1455830]: A9526241100: to=<a.schmitz-1@web.de>, relay=mx-ha02.web.de[212.227.17.8]:25, delay=1.1, delays=0.91/0/0.23/0, dsn=4.0.0, status=deferred (host mx-ha02.web.de[212.227.17.8] refused to talk to me: 554-web.de (mxweb102) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record. 554 For explanation visit https://web.de/email/senderguidelines?ip=75.119.152.130&c=rdns)
May  9 23:03:12 panel postfix/smtp[1455831]: A9526241100: to=<terryfranklin078@gmail.com>, relay=gmail-smtp-in.l.google.com[108.177.15.27]:25, delay=1.4, delays=0.91/0/0.13/0.36, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[108.177.15.27] said: 550-5.7.1 [75.119.152.130      12] Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked. Please visit 550-5.7.1  https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1  for more information. bl13-20020adfe24d000000b00306475da27csi6606956wrb.552 - gsmtp (in reply to end of DATA command))
May  9 23:03:12 panel postfix/bounce[1455822]: A9526241100: sender non-delivery notification: E16CE2414C3
May  9 23:09:28 panel postfix/qmgr[1124059]: A9526241100: from=<root@luigidonato.it>, size=4961, nrcpt=2 (queue active)
May  9 23:09:28 panel postfix/smtp[1456464]: A9526241100: host mx-ha03.web.de[212.227.15.17] refused to talk to me: 554-web.de (mxweb013) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record. 554 For explanation visit https://web.de/email/senderguidelines?ip=75.119.152.130&c=rdns
May  9 23:09:28 panel postfix/smtp[1456464]: A9526241100: to=<a.schmitz-1@web.de>, relay=mx-ha02.web.de[212.227.17.8]:25, delay=377, delays=377/0.04/0.09/0, dsn=4.0.0, status=deferred (host mx-ha02.web.de[212.227.17.8] refused to talk to me: 554-web.de (mxweb105) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record. 554 For explanation visit https://web.de/email/senderguidelines?ip=75.119.152.130&c=rdns)
May  9 23:19:28 panel postfix/qmgr[1124059]: A9526241100: from=<root@luigidonato.it>, size=4961, nrcpt=2 (queue active)
May  9 23:19:28 panel postfix/smtp[1457591]: A9526241100: host mx-ha03.web.de[212.227.15.17] refused to talk to me: 554-web.de (mxweb004) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record. 554 For explanation visit https://web.de/email/senderguidelines?ip=75.119.152.130&c=rdns
May  9 23:19:29 panel postfix/smtp[1457591]: A9526241100: to=<a.schmitz-1@web.de>, relay=mx-ha02.web.de[212.227.17.8]:25, delay=978, delays=977/0.02/0.2/0, dsn=4.0.0, status=deferred (host mx-ha02.web.de[212.227.17.8] refused to talk to me: 554-web.de (mxweb104) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record. 554 For explanation visit https://web.de/email/senderguidelines?ip=75.119.152.130&c=rdns)

That was another topic.

15

OK, so this look like a normal SMTP login for user root. Which means your root password has been compromised, which is disastrous.

Have you changed the root password at some point during this process? If so, and the attacker changed it again (or otherwise continues to be able to login, which indicates either a configuration change or a software change to open a back door for them), you have to assume your system has been rooted and can never be trusted again.

The debsums output above it what I would expect, but that doesn’t really tell us the config files haven’t been modified in ways that could open up the server to continuing abuse.

Here’s what I recommend as the next set of troubleshooting steps:

  1. Stop postfix. You aren’t achieving reasonable delivery in this condition anyway, and you’re just going to burn your IP for even more destinations if you keep sending out a slew of spam. You can turn it back on when you sort out the problems. This will also give you a clue about how deep the problem goes (you may have a rooted system…seems likely, even, in which case you can never trust it again and would need to start fresh).
  2. Change the root password.
  3. Disable root login in /etc/ssh/sshd_config. Set PermitRootLogin to no and restart ssh. I’m assuming, of course, you have a non-root user with sudo privileges you can use to perform your administrative tasks without having to login directly as root (if not, you need to do that before).
  4. Disable password-based logins in ssh. Set PasswordAuthentication to no in /etc/ssh/sshd_config. This assumes you already have key-based ssh setup and you know it works (you can login without typing in a password, only your ssh key pass phrase, if you have one). Don’t make this change until you know you can login to ssh without a password (i.e. only with your key).
  5. Check /root/.ssh/authorized_keys for any unrecognized keys. If you see one, and it is not one that belongs your hosting provider (though even that is suspect), your system has been rooted and you cannot trust it. You need to reinstall and restore your domains and data from backups.
  6. Check any sudo capable user’s ~/.ssh/authorized_keys for unrecognized keys. If you see one, your system has been rooted. Same as 5.
  7. Update your system with apt update; apt dist-upgrade

After all that, watch the system closely. See what it’s doing.

Does the mail.log continue to get new postfix/smtp or postfix/qmgr entries, etc.? It shouldn’t, you stopped postfix. If it does, it means something on the system started back up, which proves your system has been rooted and you have to reinstall and restore from backups.

If you don’t see new entries after stopping postfix and shutting down all the ways the attacker might get in, you still might be rooted (absence of evidence is not evidence of absence), but you might not be.

Check w to see what login sessions are active and lastlog to see if there are any logins you don’t recognize, especially of root or sudo capable users.

Honestly, the fact that someone had your root password is probably sufficient to say you need to blow away this system and start fresh. I would.

The story that tells is an extremely alarming one. There aren’t a lot of “easy” ways to get that. I mean, we don’t panic when a PHP app, like some sloppy WordPress plugin, gets exploited. That happens all the time. That’s usually how spam gets sent from web hosting systems. But, logging in as root? That’s a huge deal. Really, the more I think about it, the more I think we’re wasting our time trying to fix it. A rooted system can never be trusted because you can never know what they modified. Your debsums command above could have been modified to hide the nefarious changes. There are off-the-shelf rootkits that do all the heavy lifting for hiding things. The only reason I think there might not be a rootkit installed is that you can actually see these entries in the mail.log. A smart attacker with root could easily hide that from you!

1 Like
16

Yes, it’s true. But it is very likely that the system binaries have not been changed. Therefore, with them, you can make a reasonable backup of virtualmin and domains and reinstall the system. This is only one good way. All others are way to “hell”.

17

Did that root User Details in the image above just show Password Changed 08/25/2021 ?

18

So what was the use of analysis with debsums?
It went well and you advise me to reinstall everything, as if this would completely solve the problem…

What if it was compromised? You would have said to reinstall everything anyway…

However I checked all the accesses from SSH, but from the auth.log as the suggested commands did not result in anything and an IP appears to have connected 2 weeks ago.

I would like to proceed by disabling root access, changing the password and setting an access key to a user with equal privileges, obviously I have already banned the IP.

Also I want to share the Postfix configuration files, to verify that there are no vulnerabilities, consider that I always use ports 465/587.

PS: /root/.ssh not exist.

main.cf

# 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 = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2



# TLS parameters
smtpd_tls_cert_file = /etc/letsencrypt/live/donagest.com/cert.pem
smtpd_tls_key_file = /etc/letsencrypt/live/donagest.com/privkey.pem
smtpd_tls_security_level = may

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.donagest.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, vmi1010884.contaboserver.net, mail.donagest.com, localhost.donagest.com, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
virtual_alias_maps = hash:/etc/postfix/virtual
sender_bcc_maps = hash:/etc/postfix/bcc
sender_dependent_default_transport_maps = hash:/etc/postfix/dependent
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
allow_percent_hack = no
tls_server_sni_maps = hash:/etc/postfix/sni_map
milter_default_action = accept
smtpd_milters = inet:localhost:8891,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
non_smtpd_milters = inet:localhost:8891,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
smtpd_tls_CAfile = /etc/letsencrypt/live/donagest.com/fullchain.pem
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

master.cf

#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master" or
# on-line: http://www.postfix.org/master.5.html).
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (no)    (never) (100)
# ==========================================================================
smtp	inet	n	-	y	-	-	smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may
#smtp      inet  n       -       y       -       1       postscreen
#smtpd     pass  -       -       y       -       -       smtpd
#dnsblog   unix  -       -       y       -       0       dnsblog
#tlsproxy  unix  -       -       y       -       0       tlsproxy
#submission inet n       -       y       -       -       smtpd
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_tls_auth_only=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=
#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#smtps     inet  n       -       y       -       -       smtpd
#  -o syslog_name=postfix/smtps
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=
#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#628       inet  n       -       y       -       -       qmqpd
pickup    unix  n       -       y       60      1       pickup
cleanup   unix  n       -       y       -       0       cleanup
qmgr      unix  n       -       n       300     1       qmgr
#qmgr     unix  n       -       n       300     1       oqmgr
tlsmgr    unix  -       -       y       1000?   1       tlsmgr
rewrite   unix  -       -       y       -       -       trivial-rewrite
bounce    unix  -       -       y       -       0       bounce
defer     unix  -       -       y       -       0       bounce
trace     unix  -       -       y       -       0       bounce
verify    unix  -       -       y       -       1       verify
flush     unix  n       -       y       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
proxywrite unix -       -       n       -       1       proxymap
smtp      unix  -       -       y       -       -       smtp
relay     unix  -       -       y       -       -       smtp
        -o syslog_name=postfix/$service_name
#       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq     unix  n       -       y       -       -       showq
error     unix  -       -       y       -       -       error
retry     unix  -       -       y       -       -       error
discard   unix  -       -       y       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       y       -       -       lmtp
anvil     unix  -       -       y       -       1       anvil
scache    unix  -       -       y       -       1       scache
postlog   unix-dgram n  -       n       -       1       postlogd
#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent.  See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop  unix  -       n       n       -       -       pipe
  flags=DRXhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
#
# ====================================================================
#
# Recent Cyrus versions can use the existing "lmtp" master.cf entry.
#
# Specify in cyrus.conf:
#   lmtp    cmd="lmtpd -a" listen="localhost:lmtp" proto=tcp4
#
# Specify in main.cf one or more of the following:
#  mailbox_transport = lmtp:inet:localhost
#  virtual_transport = lmtp:inet:localhost
#
# ====================================================================
#
# Cyrus 2.1.5 (Amos Gouaux)
# Also specify in main.cf: cyrus_destination_recipient_limit=1
#
#cyrus     unix  -       n       n       -       -       pipe
#  flags=DRX user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user}
#
# ====================================================================
# Old example of delivery via Cyrus.
#
#old-cyrus unix  -       n       n       -       -       pipe
#  flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user}
#
# ====================================================================
#
# See the Postfix UUCP_README file for configuration details.
#
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
#
# Other external delivery methods.
#
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix -       n       n       -       2       pipe
  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
mailman   unix  -       n       n       -       -       pipe
  flags=FRX user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop} ${user}
submission	inet	n	-	y	-	-	smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may
smtps	inet	n	-	y	-	-	smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may -o smtpd_tls_wrappermode=yes
19

I didn’t ask you to do that, another user did. But it is not a bad idea to do, if you think your system might be compromised. As I said, it is not proof you are not compromised, because a competent attacker could hide their exploits. If a competent attacker has root, they can completely hide from anyone on the system itself…only outside observation (or observation from a boot from alternate media like a rescue USB key) would reveal their existence.

But, if it had returned something interesting, it would be proof that you were compromised, which is also very useful information!

I’m telling you that if an attacker had the ability to log in to your system as root, your system is fucked. That’s not my fault. I’m just telling you the reality of security of a system on the internet. I’m sorry the news is bad, but I didn’t do it.

I understand you don’t like that news. It’s definitely bad news. You can do whatever you want; if you don’t want to reinstall, I told you what to do. But, I also told you that I would reinstall, if I were in your shoes, unless I could figure out some explanation for how the attacker was able to login to Postfix and send mail as root without also having root access to the system in other ways (like via Webmin or ssh).

What IP? One you don’t recognize?

If the attacker had a username (root, in this case) and the password for that user, then Postfix configuration is irrelevant. A user with a password can send mail through your server; that’s how it’s supposed to work. That’s what appears to have happened, based on the logs.

I don’t see anything unusual in your postfix configuration. It seems reasonable, I think, at first glance. But, once again, the problem you’re facing seems unrelated to configuration; a user with a password is supposed to be able to send mail. So, the problem to worry about is how a user got your root password. A postfix misconfiguration wouldn’t reveal the password, and I don’t think there’s any way a successful authentication log entry would show you without a successful authentication (meaning password was entered correctly).

2 Likes
20

For now I solved by creating the email address used and limiting it.
So I changed root password and for now there are only attempts, without success.
We’ll see how the situation develops in the next few days, so I’ll evaluate what to do.
For now, I just wanted to share this ‘solution’ with anyone running into the same problem.

1 Like