Also consider the use of IPset
1 Like
Thanks both! Okay, now I understand. The dovecot name in the log entries had me confused, as I thought it was related to dovecot and IMAP/POP. But that makes more sense if it’s using the authentication. And given that, I guess it also makes sense NOT to remove/disable Dovecot completely (as I first mentioned), as I assume that would screw up the SMTP/Exim server authentication.
Okay, I think this resolves everyrthing at this point, as you mentioned fail2ban will take care of this. I was actually dealing with this just before I decided to migrate from VESTACP to HestiaCP. I think the reason was because fail2ban was broken on VestaCP and it wasn’t blocking these attempts. I was getting hit every few seconds for more than an hour at a time. I eventually found some fix on the vestaCP forums, but at that point, I figured, it was just time to move on from that abandoned project.
Thanks both of you!!
3 Likes
Oh, one more idea on this. And I know these are not so specific to Hestia, but I think these topics are super helpful for those using Hestia and trying to configure things. Which can only benefit growing the HestiaCP and user base.
I’m a big believer that it was the strong user community of DigitalOcean that helped DigitalOcean to grow and become a great platform for non Enterprise people like us.
Now onto my question.
2021-04-18 13:38:33 dovecot_login authenticator failed for (User) [77.247.110.204]: 535 Incorrect authentication data
I understand now that the above log entries are caused by EXIM authenticating through Dovecot, and that we will always have to deal with some noise/bruteforce attacks with a public mail server, but I’m wondering if I can avoid this if I limit traffic to only Google?
As I mentioned, I forward all emails from my server to my gmail account and I sent outbound emails through my email via the Gmail client. So technically only gmail/google is using my SMTP service as a valid user.
Is it possible to just block all traffic from SMTP server unless it’s from a Google IP address? I think this would solve my problem, right? Then all these annoying bots and hackers would be blocked from even accessing the SMTP port to try authenticating and only Google servers would be able to access is. Is there a problem with my logic? And if not, how would I go about doing this?
Thanks!
We add support in 1.4 for smtp servers like Google, Amazon or any third party
Thanks eris! But what does this mean. You mean in HestiaCP 1.4 you add support for IPset for SMTP severs like Google and Amazon?
Okay, how do I use it or configure it?
Thanks!
Ipset is something different
Go to:
Edit Server (Cogs icon) → Firewall → Manage IP lists → Add Ip list
Then give it a name and select black list
Save
Then go to firewall and add a rule:
Then save the number of attacks should be decreased by a lot is my exceperince…
It still happens but is a lot of less times;
2021-04-20 01:18:54 dovecot_login authenticator failed for (User) [212.70.149.71]: 535 Incorrect authentication data (set_id=abraham@)
2021-04-20 01:18:59 TLS error on connection from (User) [212.70.149.71] (recv): The TLS connection was non-properly terminated.
2021-04-20 01:19:20 dovecot_login authenticator failed for ([31.210.20.155]) [31.210.20.155]: 535 Incorrect authentication data (set_id=egor)
2021-04-20 01:19:28 dovecot_login authenticator failed for ([31.210.20.41]) [31.210.20.41]: 535 Incorrect authentication data (set_id=alan)
2021-04-20 01:20:23 dovecot_login authenticator failed for (User) [141.98.10.235]: 535 Incorrect authentication data (set_id=seng)
4 Likes
You mean in HestiaCP 1.4 you add support for IPset for SMTP severs like Google and Amazon?
I think you (both) need to be careful about not mixing up things… so take it slowly.
for sending mails via smtp - yes, you could think of restricting the IP range for accessing your SMTP server - BUT, and that is a big one, you are misunderstanding how mail at all works.
an SMTP server is not only there for you to login and send away your mails. but of course it is also the service where other mail-servers connect to when they want to deliver mail to you.
to be clear: the whole mail sending/receiving/relaying/forwarding is SMTP. the S is for Simple and not Sending 
so again you need it to send and receive mails. dovecot or any IMAP/POP has nothing to do with that but are rather additional services that act as an entry point for your local mail-client to access the stored mail on your server.
now back to your idea. what happens if you limit the range of IPs allowed to communicate with your SMTP server to those of gmail? right, only gmail might be able to connect and send - AND gmail (addresses) might also become the only one being able to send mails to you…
as this is all inbound, the login as well as an delivery attempt you won’t be able to decide on the firewall level already what’s what. so, in the end that most likely won’t do what you want but effectively block you from receiving mails (other than gmail)
the feature @eris mentioned for the release is something else and means sending/relaying your mails through a third party. so everything outgoing is not send from your server directly put passed through SES or mailcheap and the likes. again this won’t help much getting rid of the noise, at it’s a different thing.
using IP blacklists via ipsets is probably the best way to go, there are few, which help tune it down a bit. and as said for the rest fail2ban will take care of. also regular RBLs to be implemented within exim itself usually help a bit (Hestia offers that per default).
edit: there actually is no ‘receiving’ at all, just sending/relaying. best case something from another mailserver gets sent/relayed into your inbox/mailfolder as final destination though
2 Likes
Got it! Thanks Falzo.
Yes, I overlooked this bit. I guess I was not referring to blocking all traffic other than gmail for the SMTP, but rather blocking all traffic other than gmail for accessing the authentication for SMTP mail. I figured these may be separate things.
For example, you could configure on the server, if a user is attempting to login or authenticate to the SMTP server (in the way that I configure a new “send as” account in gmail), it would block anything other than a gmail/google IP address.
Now, if SMTP doesn’t work this way and the same interface is used to relay messages, then yes, my idea would not work. I don’t know if that’s how it is setup, but if so, then I guess I just need to relay on fail2ban aor IPset to help reduce. However, at that point, I think just better/easier for me to let fail2ban do it’s thing.
Thanks for the insight and ideas.
no problem. as said, I am not aware of a way to do that on a firewall level, because only after the initial connect to exim4 you will know what the incoming request is about.
therefore you can reject from within exim4 but not earlier - maybe check the reject rules section and what options there are.
but this means these attemps will be thrown at you nevertheless, that’s sadly how it is on a server with a public internet connection 
1 Like
Thanks Falzo! I think I will just go with trusting fail2ban to handle the noise of the public internet connection. It has done a fairly good job thus far.
I also suggest enabling the ipset blocklist as it drastically reduces the amount of noise, that means smaller logs, less pressure on fail2ban, lower cpu usage, fewer disk iops
2 Likes
I would also suggest hardening the fail2ban rules and even implementing new ones.
There is a pull request pending to be incorporated. It implements a fail2ban whitelist to IPs that successfully connected to the mail server. With that activated you may safely harden the fail2ban rules and the recidive rule to ban very fast those login attempts safely.
1 Like
Thanks both! Your advice definitely sounds like what I want to do. Thanks for providing the steps above @eris. That was super easy to configure. I did not know this feature was built into HestiaCP. Love it!
Btw, just something I noticed. I tried to create a list back with under_scores and it errored out. I then changed to hyphens and it worked. Is there any reason why the use of underscores are blocked? Just thought I would ask it, in case this was unintentional and missed in the development of the control panel.
See attached screenshot:
@jlguerrero - thanks for your input as well. I definitely want to do anything that can reduce noise on the server. I had Sentora control panel before VestaCP with no fail2ban and it was a painful experience.
I actually had scripts running every 15 minutes to check if the MySQL service was down or up and it would restart it, because the load on the server from the attacks was killing the server. Those were the early days when I didn’t know much more than just how to do the basic install of a LAMP server on Ubuntun.
Once that pull request is in, it would be great if you could share how to configure fail2ban with those additional rules. I’m loving HestiaCP and this community. I think the next step would be to have some really good knowledge base documents for these additional configuration tasks. Similar to what the DigitalOCean community has done, but have them written with HestiaCP’s configuration in mind. Things like 1.) how to harden security with fail2ban, IPsec, 2.) configure spamassassin, etc.
Thanks all!
One last question, while I have all these skilled and helpful people on this thread. And since it’s related to the security of email.
I noticed in the email server settings of HestiaCP, that there is a SSL option for the mail. I of course have all my websites configured with SSL (Let’s Encrypt certificates), but I never bothered with the SSL for the email. In fact, I just noticed it was a thing.
What is the recommendation for this? Should this be enabled, is it just matter of clicking a button (similar to let’s encrypt for the domains), or do I need to do something else with my email configuration and how my email accounts are configured in gmail, etc.
Thanks!
And this is actually the last outstanding task on my list to fully configure this server. Not bad, after a week of playing around with it. I hope this is one thing I can just enjoy not touching for another year or two, or until I need to upgrade PHP or something. 
Yes always SSL
Thanks @eris !
I attempted to do this, but I’m getting an error. Any idea why?
And this error shows in red text: “Error: Let’s Encrypt validation status 400. Details: Unable to update challenge :: authorization must be pending”
I have added the webmail cname to my Cloudflare DNS settings for this domain. Also I have put Cloudflare in “developer” mode just to see if that has any effect. And I still get this error.
Any ideas?
Btw, I saw that it mentions to make sure to have DNS records for mail and webmail. So what is this SSL option actually doing? Is it just adding SSL cert for the webmail interface, or is it adding SSL onto all email communications? I’m just curious what this feature does, as I haven’t used it before and wondering if it’s just related to webmail interface or something else. Thanks!
Does both mail and webmail exists?
Correct, both exists. I have an A record for mail pointing to my server IP address and I just added the webmail as a cname record. These are both on cloudflare.
I also checked what HestiaCP put in the local DNS, even though I don’t use them (I have my domain pointing to Cloudflare’s DNS servers).
So not sure, what’s going on.
Disable force ssl / disable proxy should work fine