Hi Hestia Community!
Long time user of VestaCP (and Sentora prior to that). Just moved to HestiaCP yesterday and I now have all sites online and working. Thank you for your hard work on creating this beautiful control panel.
I’m hoping someone can tell me what is the best approach to simply disable IMAP and POP.
The reason:
I am the only user of this web server and I have a few websites on it. I have several domains and emails registered through it. However, ALL emails are forwarded to gmail, no copy is ever saved on the server, it just gets forwarded to a central gmail account.
I know that fail2ban is there to deal with bruteforce attacks, but I figure since I will never use IMAP and POP (at least for the foreseeable future), I assume it would be best to just disable these services and the ports, so that annoying bots and hackers don’t even bother with my server in that regard.
I use gmail to send outbound emails using the SMTP server on this server, but I assume it does not have anything to do with POP and IMAP, so I can safely disable these?
Does my logic make sense, and if so, can someone please point me in the direction of how to disable and block this stuff so I have one less annoying thing to deal with. I hate bots.
Is it as simple as just changing the firewall rule in HestiaCP to block for POP and IMAP? Is there any benefit to disable or shutdown these services to free up server memory and avoid CPU usage?
Thanks!
Do I need to anything in hestia.conf for POP? Or only IMAP system is required?
Also, thanks for providing the steps, but can you also share if this is the best method? Or to make things easier in the future to use POP or IMAP, would it be better to just block traffic to POP and IMAP with the HestiaCP firewall settings?
Usually I try to stick to the defaults as much as possible, in order to avoid future surprises. For this reason and also because I wouldn’t know if I might need these services in the future, I would prefer to just block traffic to POP / IMAP ports. But this is just me.
Thanks for confirming my thoughts and assumptions. I think best to just block the ports in firewall for now. I was just wondering how much different performance would be, but I assume since nobody is accessing, it should be minimal. And it makes it easier to enable in the future, as you say. I’ll go with that method then. Thanks!
A quick follow up question on this one. I disabled POP and IMAP as suggested. However, I was looking at the log files today. I still have these annoying people trying to hack into my email server. I see this in the exim log file: /var/log/exim4/mainlog
2021-04-18 13:38:00 dovecot_login authenticator failed for (User) [77.247.110.204]: 535 Incorrect authentication data ([email protected])
2021-04-18 13:38:06 dovecot_login authenticator failed for (User) [77.247.110.204]: 535 Incorrect authentication data ([email protected])
2021-04-18 13:38:16 dovecot_login authenticator failed for (User) [77.247.110.204]: 535 Incorrect authentication data ([email protected])
2021-04-18 13:38:33 dovecot_login authenticator failed for (User) [77.247.110.204]: 535 Incorrect authentication data
I replaced my real domain name with “mydomain.com” in the above example from the log file.
It seems these annoying people are still able to try to log into dovecot. I’m constantly being hit with this stuff, that’s why I was trying to simply block it so that my server doesn’t need to deal with these as I assume it’s taking away memory and CPU from other useful tasks.
Is there a way to prevent this? As I mentioned, I don’t use POP or IMAP, so I don’t know why I need to even have the server respond to dovecot authentication. Looking for advice. Thanks!
I think you are misinterpreting here. the message you see there has nothing to do with people trying to access imap/pop. it is in the scope of exim so this are attempts to login to smtp.
exim4 might use the dovecot_login as authenticator, which makes sense if you think about it for a minute - you do not want or need to manage user credentials differently for the mail services, but instead it’s easier to use a common auth module after all.
unless you close the smtp ports too, you simply should get used to regular noise in the public internet. no way to avoid that people are blindly throwing dictionary attacks against your services - only way is not running services at all.
rather make sure to not use/allow easy password and such. also fail2ban should be able to catch these attempts and ban the offenders quickly.
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.
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?
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
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.
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
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
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.
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.
