Yunohost a Spam-Bot?

Dear readers,

I am worried and a little perplexed. I started YNH 3 months ago.
Now the DNS registrar had set the domain of my VPS to “ServerHold”. The allegation is that the server was involved in abuse processes.

For a week the server was only accessible via its IP.
I had to assure that I am neither a spammer myself, nor that the domain is part of a spam bot network and that it is not my intention to use the server to spread spam mail myself.

How can that be?
Of course, the VPS is as secure as possible. For example, SSH is only possible for one user and only with a certificate. Connections with a password are rejected.

The safety instructions were followed for YNH. For example https://yunohost.org/security?q=%2Fsecurity
All used Passwords are extremely long and should be very secure. Only two users have an email account.

I have not received any information or evidence from the DNS registrar or the provider as to what happened in detail.
So I took a close look at mail.log and auth.log. You can see login attempts that are canceled. Is something going through?

If I see a connection from an illegal IP, I enter this IP in my iptables rules, with DROP. Then all connections from this IP will be rejected. Nevertheless something should have happened ?! I can’t explain to myself.

It can also be an attempt to earn money in order to buy yourself out of a blacklist. But I didn’t have to pay any money. The registrar has now activated again. By the way, it’s a .me domain.

Can postfix be misused via port 25?
Can I trust my YNH? Can I be sure that nothing will happen that I don’t want?

I look forward to tips and advice so that I can regain my trust in YNH.

Well it’s difficult to say much if they don’t provide details ?

If somebody claims you’re a murderer yet doesn’t explain why you are, how do you prove you’re not ?

There are a thousand ways something could have happened happened with your server - it’s not your job to guess which one. If they have some concrete elements, it’s their job to explain what went wrong. Otherwise just change registrar.

2 Likes

Hi, there was a security pentest done a few years ago, but the link all seem dead ?

Sometimes registars will detect and block Spambots accross a whole range of IPs. It happened to me several times. Same for Spamhaus where I had do manually claim a whitelisting since they did block a range of IPs amongst which a spambot and my Yunohost instance. Maybe you could also check that ?

Did you have a look at your /var/mail logs ? If you find something strange you may share it here ?

All the best. I think investigating on your case will benefit both you and the whole YNH community !

1 Like

Thank you Aleks and Limezy,

well I did some modifications of the postfix configuration
/etc/postfix/main.cf

But, first let me show you some entries in
/var/log/mail.log
To be honest, I don’t really know what it all means. Anyway, I will google it.

Maybe, they are rejected!?!?

Feb 28 01:10:32 srv postfix/smtpd[31274]: connect from unknown[45.142.120.52]
Feb 28 01:10:32 srv postfix/smtpd[31274]: disconnect from unknown[45.142.120.52] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Feb 28 01:13:52 srv postfix/anvil[31312]: statistics: max connection rate 1/60s for (smtp:45.142.120.52) at Feb 28 01:10:32
Feb 28 01:13:52 srv postfix/anvil[31312]: statistics: max connection count 1 for (smtp:45.142.120.52) at Feb 28 01:10:32
Feb 28 01:13:52 srv postfix/anvil[31312]: statistics: max cache size 1 at Feb 28 01:10:32
Feb 28 01:56:45 srv postfix/smtpd[9405]: warning: hostname rnd.group-ib.ru does not resolve to address 80.82.70.118
Feb 28 01:56:45 srv postfix/smtpd[9405]: connect from unknown[80.82.70.118]
Feb 28 01:56:45 srv postfix/smtpd[9405]: SSL_accept error from unknown[80.82.70.118]: -1
Feb 28 01:56:45 srv postfix/smtpd[9405]: warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:../ssl/statem/statem_srvr.c:1661:
Feb 28 01:56:45 srv postfix/smtpd[9405]: lost connection after STARTTLS from unknown[80.82.70.118]
Feb 28 01:56:45 srv postfix/smtpd[9405]: disconnect from unknown[80.82.70.118] ehlo=1 starttls=0/1 commands=1/2
Feb 28 01:57:23 srv postfix/smtpd[9405]: connect from unknown[5.8.10.202]
Feb 28 01:57:23 srv postfix/smtpd[9552]: connect from unknown[5.8.10.202]
Feb 28 01:57:23 srv postfix/smtpd[9553]: connect from unknown[5.8.10.202]
Feb 28 01:57:23 srv postfix/smtpd[9552]: lost connection after UNKNOWN from unknown[5.8.10.202]
Feb 28 01:57:23 srv postfix/smtpd[9405]: lost connection after UNKNOWN from unknown[5.8.10.202]
Feb 28 01:57:23 srv postfix/smtpd[9552]: disconnect from unknown[5.8.10.202] unknown=0/2 commands=0/2
Feb 28 01:57:23 srv postfix/smtpd[9405]: disconnect from unknown[5.8.10.202] unknown=0/2 commands=0/2
Feb 28 01:57:24 srv postfix/smtpd[9553]: lost connection after UNKNOWN from unknown[5.8.10.202]
Feb 28 01:57:24 srv postfix/smtpd[9553]: disconnect from unknown[5.8.10.202] unknown=0/2 commands=0/2
Feb 28 01:57:24 srv postfix/smtpd[9552]: connect from unknown[5.8.10.202]
Feb 28 01:57:24 srv postfix/smtpd[9552]: warning: non-SMTP command from unknown[5.8.10.202]: GET /aaa9 HTTP/1.1
Feb 28 01:57:24 srv postfix/smtpd[9552]: disconnect from unknown[5.8.10.202] unknown=0/1 commands=0/1
Feb 28 01:57:24 srv postfix/smtpd[9405]: connect from unknown[5.8.10.202]
Feb 28 01:57:24 srv postfix/smtpd[9405]: lost connection after UNKNOWN from unknown[5.8.10.202]
Feb 28 01:57:24 srv postfix/smtpd[9405]: disconnect from unknown[5.8.10.202] unknown=0/3 commands=0/3
Feb 28 01:57:24 srv postfix/smtpd[9552]: connect from unknown[5.8.10.202]
Feb 28 01:57:24 srv postfix/smtpd[9552]: warning: non-SMTP command from unknown[5.8.10.202]: GET /aab9 HTTP/1.1
Feb 28 01:57:24 srv postfix/smtpd[9552]: disconnect from unknown[5.8.10.202] unknown=0/1 commands=0/1
Feb 28 02:00:44 srv postfix/anvil[9407]: statistics: max connection rate 6/60s for (smtp:5.8.10.202) at Feb 28 01:57:24
Feb 28 02:00:44 srv postfix/anvil[9407]: statistics: max connection count 3 for (smtp:5.8.10.202) at Feb 28 01:57:23
Feb 28 02:00:44 srv postfix/anvil[9407]: statistics: max cache size 2 at Feb 28 01:57:23
Feb 28 03:52:55 srv postfix/smtpd[3359]: connect from unknown[193.107.219.179]
Feb 28 03:52:58 srv postfix/smtpd[3359]: NOQUEUE: reject: RCPT from unknown[193.107.219.179]: 504 5.5.2 <WIN-QTRP24KL69K>: Helo command rejected: need fully-qualified hostname; from=<spameri@tiscali.it> to=<spameri@tiscali.it> proto=ESMTP helo=<WIN-QTRP24KL69K>
Feb 28 03:52:58 srv postfix/smtpd[3359]: disconnect from unknown[193.107.219.179] ehlo=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5
Feb 28 03:56:18 srv postfix/anvil[3361]: statistics: max connection rate 1/60s for (smtp:193.107.219.179) at Feb 28 03:52:55
Feb 28 03:56:18 srv postfix/anvil[3361]: statistics: max connection count 1 for (smtp:193.107.219.179) at Feb 28 03:52:55
Feb 28 03:56:18 srv postfix/anvil[3361]: statistics: max cache size 1 at Feb 28 03:52:55
Feb 28 06:39:25 srv postfix/submission/smtpd[8881]: connect from unknown[23.129.64.226]
Feb 28 06:39:32 srv postfix/submission/smtpd[8881]: Anonymous TLS connection established from unknown[23.129.64.226]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (3072 bits) server-digest SHA256
Feb 28 06:39:32 srv postfix/submission/smtpd[8881]: lost connection after STARTTLS from unknown[23.129.64.226]
Feb 28 06:39:32 srv postfix/submission/smtpd[8881]: disconnect from unknown[23.129.64.226] ehlo=1 starttls=1 commands=2
Feb 28 06:42:52 srv postfix/anvil[8883]: statistics: max connection rate 1/60s for (submission:23.129.64.226) at Feb 28 06:39:25
Feb 28 06:42:52 srv postfix/anvil[8883]: statistics: max connection count 1 for (submission:23.129.64.226) at Feb 28 06:39:25
Feb 28 06:42:52 srv postfix/anvil[8883]: statistics: max cache size 1 at Feb 28 06:39:25

Anonymous TLS connection established from unknown[23.129.64.226]: TLSv1.3 with cipher…

How can this be? It cannot!?!!!

...lost connection after STARTTLS from unknown[23.129.64.226]

That means, kicked out?

What kind of statistics are these?

Mar  3 20:23:12 srv postfix/smtpd[18230]: connect from unknown[77.247.110.165]
Mar  3 20:23:13 srv postfix/smtpd[18230]: disconnect from unknown[77.247.110.165] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Mar  3 20:26:33 srv postfix/anvil[18232]: statistics: max connection rate 1/60s for (smtp:77.247.110.165) at Mar  3 20:23:12
Mar  3 20:26:33 srv postfix/anvil[18232]: statistics: max connection count 1 for (smtp:77.247.110.165) at Mar  3 20:23:12
Mar  3 20:26:33 srv postfix/anvil[18232]: statistics: max cache size 1 at Mar  3 20:23:12
Mar  3 20:35:31 srv postfix/smtpd[20986]: connect from unknown[77.247.110.165]
Mar  3 20:35:31 srv postfix/smtpd[20986]: disconnect from unknown[77.247.110.165] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Mar  3 20:38:51 srv postfix/anvil[20988]: statistics: max connection rate 1/60s for (smtp:77.247.110.165) at Mar  3 20:35:31
Mar  3 20:38:51 srv postfix/anvil[20988]: statistics: max connection count 1 for (smtp:77.247.110.165) at Mar  3 20:35:31
Mar  3 20:38:51 srv postfix/anvil[20988]: statistics: max cache size 1 at Mar  3 20:35:31
Mar  3 20:47:04 srv postfix/smtpd[23625]: connect from unknown[77.247.110.165]
Mar  3 20:47:04 srv postfix/smtpd[23625]: disconnect from unknown[77.247.110.165] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Mar  3 20:50:25 srv postfix/anvil[23627]: statistics: max connection rate 1/60s for (smtp:77.247.110.165) at Mar  3 20:47:04
Mar  3 20:50:25 srv postfix/anvil[23627]: statistics: max connection count 1 for (smtp:77.247.110.165) at Mar  3 20:47:04
Mar  3 20:50:25 srv postfix/anvil[23627]: statistics: max cache size 1 at Mar  3 20:47:04
Mar  3 20:58:43 srv postfix/smtpd[26220]: connect from unknown[77.247.110.165]
Mar  3 20:58:44 srv postfix/smtpd[26220]: disconnect from unknown[77.247.110.165] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Mar  3 21:02:04 srv postfix/anvil[26222]: statistics: max connection rate 1/60s for (smtp:77.247.110.165) at Mar  3 20:58:43
Mar  3 21:02:04 srv postfix/anvil[26222]: statistics: max connection count 1 for (smtp:77.247.110.165) at Mar  3 20:58:43
Mar  3 21:02:04 srv postfix/anvil[26222]: statistics: max cache size 1 at Mar  3 20:58:43

Could 77.247.110.165 sent spam, or was it blocked?

Now I edited the postfix config
/etc/postfix/main.cf

Generally, it seems, this file has proper settings!!

In this area I made some changes as follows.

# Requirements for the connecting server
smtpd_client_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client cbl.abuseat.org,
    reject_rbl_client zen.spamhaus.org,
    permit

# Requirements for the HELO statement
smtpd_helo_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_hostname,
    reject_invalid_hostname,
    reject_unknown_helo_hostname
#    permit

# Requirements for the sender address
smtpd_sender_restrictions =
    reject_sender_login_mismatch,
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    reject_unknown_reverse_client_hostname,
    reject_unknown_client_hostname,
#    permit

# Requirement for the recipient address
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_non_fqdn_sender,
    reject_non_fqdn_recipient,
    reject_unknown_sender_domain,
    reject_unknown_recipient_domain,
    reject_unknown_reverse_client_hostname,
    reject_rhsbl_helo dbl.spamhaus.org,
    reject_rhsbl_reverse_client dbl.spamhaus.org,
    reject_rhsbl_sender dbl.spamhaus.org,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client ix.dnsbl.manitu.net,
    reject_unauth_destination,
    permit

# SRS
...

Now in the mail.log

Mar 10 00:09:55 srv postfix/smtpd[5509]: warning: hostname zg-0226b-316.stretchoid.com does not resolve to address 192.241.228.226: Name or service not known
Mar 10 00:09:55 srv postfix/smtpd[5509]: connect from unknown[192.241.228.226]
Mar 10 00:09:55 srv postfix/smtpd[5509]: disconnect from unknown[192.241.228.226] ehlo=1 quit=1 commands=2

Now emails are rejected, if the client IP address has no PTR record !!??!!??

Well, I keep mail.log open for monitoring…

Honestly I don’t know what you’re doing … yes, the mail log is filled with weird connection, that’s expected because just as bots try to bruteforce ssh, bots also try to brute force or exploit SMTP servers. Many lines like " Anonymous TLS connection established from unknown" sounds weird but are somewhat “normal”.

Same things could apply to other logs : you can quickly go into panic mode if you’re reading some log files (being daemons or system log or whatever) you don’t understand, because some messages sounds suspicious when they’re in fact not that much. Correctly interpreting the mal.log files is hard because they are a mess.

To me it just sounds you still don’t know what you’re looking for exactly because the registrar did not provide any detail. When somebody accuses you to be a murderer without any proof or detail, it’s not your job to prove you’re not, and it’s not your job to guess who is it that you’re being accused to have murdered

1 Like

You are right! Anyway, it’s a rapidly increasing learning curve, because I don’t want to be murdered by my web hoster.

But seriously. After adding the reject__ arguments, I have been watching the log file for hours, days and there are no strange entries to be seen. I see when I send or receive email. Otherwise it’s quiet. It may come again, but for now I am reassured.
Thank you.

2 Likes

Note: if you change a lot of file managed by YunoHost, don’t forget to apply yunohost change when you upgrade the system. If you don’t your current optimization could be worth than just keep the default config.

This command could help you

yunohost tools regen-conf --with-diff --force --dry-run

You can also keep an eyes on your diagnosis.

1 Like

Wow thank you very much! This is a very good and very important note!
I’m afraid I wouldn’t have thought of that anymore!
Thank you.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.