How to Disable POP/IMAP to avoid Bruteforce Attacks?

@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. :wink:

Yes always SSL

Thanks @eris !

I attempted to do this, but I’m getting an error. Any idea why?

Screen Shot 2021-04-20 at 1.30.25 PM

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

as @eris pointed out both subdomains mail. and webmail. need to point to your server ip, so you can get an SSL cert for it. the benefit of this obviously that you can a) can access your webmail. domain in your browser properly via https and b) if you connect via IMAP and use mail. your domain together with tls you won’t receive any certificate warnings in the mail client anymore…

I have changed the webmail record from cname to A in case that makes a difference. So both mail and webmail are configured on cloudflare and pointing to my IP address of the server, but same result.

I can’t get this to add. Any idea? @eris - you mentioned something about disabling force SSL / disable proxy. Where do I do that? I don’t see an option on that page anywhere.

Also, in case it helps. I am seeing this in the error log at (/var/log/hestia/error.log

2021-04-20 14:30:13 v-list-dns-records ‘myuser’ ‘mail.mywebsite.com’ [Error 3]
2021-04-20 14:30:13 v-add-letsencrypt-domain ‘myuser’ ‘mywebsite.com’ ’ ’ ‘yes’ [Error 15]

Okay, so this is somewhat hell. hah. I have no idea what’s going on.

So here is what I did. As I mentioned, I had Cloudflare set to “development” mode. Nothing was working, so I figured I would try to completely disable cloudflare. On the overview page of cloudflare for this specific domain, on the bottom right corner, I checked the option “Pause Cloudflair on Site”.

Then I attempted to enable SSL / Let’s Encrypt on this domain on HestiaCP again.

And then it finally took. It took about 20 seconds or so, and then when I went back to the main page of the mail setting, I can see that SSL is not enabled. So no idea what was causing the issue. And also, I’m wondering if I re-enable cloudflare is it going to break something. Also, how will it renew the license later, or will that fail? Is there some setting on Cloudflare that I should be editing?

However, the pain continues. So now I’m trying to do the same thing on another domain I have on this server. I did the same steps as above (added the webmail DNS record in Cloudflare). However, this time, I’m getting an error saying: Error: DNS record for webmail.mydomain.com doesn’t exist.

However, webmail DNS record exists. So no idea why it can’t seem to find it. Any way I can troubleshoot this. This seems like a check that’s being done by HestiaCP, so how does it check it? I guess I need to fix this one now.

[Update]: One more thing to share. I noticed while logged into the server via terminal, for some reason when I attempt to ping webmail.mydomain.com it comes back with:

ping: connect: Network is unreachable

All other subdomains work fine and respond with the cloudflare IP addresses. So it seems for some reason the local server cannot resolve the webmail address.

cloudflare is a pita and usually over the top anyway. you wanna use it? you deal with it! expect no mercy on that one :stuck_out_tongue:

apart from that: adding/changing DNS records simply might need some time to propagate. if your server cannot resolve it (yet) probably letsencrypt also can’t.

and keep in mind that letsencrypt might rate limit you on your tries, so impatiently trying over and over might make you wait even longer.
ideally check from an external server first, if you properly can resolve both subdomains to the correct IP, just like LE would do.

1 Like

Cloudflare as a PITA…under statement. :wink:

Well, I guess I just like hell, as I decided to implement Cloudflare at the same time of migrating everything from VestaCP to HestiaCP. Like I said, I’m having a quick moment of free time finally, so trying to get this all sorted out.

So, I’m unfortunately, also new to Cloudflare, so it seems like I might have made some stupid/simply mistakes. I kept trying to figure out what Eris comment meant. :wink: He’s like yoda, just short tip/direction, and Luke skywalker gotta figure out the rest.

Anyway, I figured since pausing cloudflare was the thing that got things working, I figured there must be an issue there. So I’m updating this thread to help anyone else in my situation (new to Hestia and new to Cloudflare). This tip will save you a good few hours (I wish I had my time saved).

I believe the issue was because I had the cname and A records for mail and webmail behind the Cloudflair proxy. I guess most people have their production web site server separate from their email, so the guides don’t always clearly mention this. Anyway, I disabled the proxy option on the DNS records for mail and webmail on all my domains configured through Cloudflare.

And that worked. What was strange during my testing, was that even with the proxy on, I could still successfully save the SSL Let’s encrypt option on the 1st domain I was troubleshooting. IDK, perhaps it’s because the SSL cert was already loaded, so it did not reach out to Let’s Encrypt servers, and that’s why it appeared to work, but it wouldn’t have. So I think I said myself a headache down the road when the server goes to renew these certificates, as now Cloudflare is properly configured.

So the key take away: ENSURE THAT PROXY is disabled on the INDIVIDUAL CLOUDFLARE DNS entries for webmail and mail. Basically, anything related to mail should have proxy disabled.

For anyone that’s interested, here are the two articles I found related to this:

And also the second domain issue has been resolved. No idea why the hell the DNS took so long to propogate, but perhaps as falzo mentioned, maybe it was just blocking my requests as I had attempted so many times. I’ve been dealing with trying to figure out why the hell gmail is throwing some of my emails into archive (skipping inbox) for no reason (still haven’t figured it out), but that gave me enough time to take a break from this, that by the time I came back and attempted again, the server seemed to have finally figured out where webmail.mydomain.com was.

So all mail servers are now configured with SSL certs. Thanks guys!!!

1 Like

Just finished re-reading this thread. Such great advice in here. Thank you all again!

@eris @falzo - Thank you for your great work and the release of 1.4. Now that 1.4 has been pushed to production, is there documentation for the SMTP function that has been added? The one which allows to send email passed through SES versus being sent directly by the server.

I’m wondering if that function will resolve the issues I am seeing in my Exim mainlog regarding gmail rate limiting email sent from my server. I don’t recall seeing this prior to moving to Hestia, but perhaps I just did not notice it, or perhaps it’s because I’m on a new server IP and google/gmail still thinks I’m spammy. Mail still gets passed through, but sometimes the delay causes issues (e.g. thinking the email is not being processed by the 3rd party or something).

Is what you describe above the solution for this? So that gmail knows my server is acting as a mail server simply passing email through to my gmail account? Thanks in advance!

2021-05-31 11:12:04 1lnmON-001tyN-DK == [email protected] <[[email protected]](mailto:[email protected])> R=dnslookup T=remote_smtp defer (-46) H=alt4.gmail-smtp-in.l.google.com [172.217.197.26]: SMTP error from remote mail server after end of data: 421-4.7.28 [xxx.xxx.xxx.xxx 15] Our system has detected an unusual rate of\n421-4.7.28 unsolicited mail originating from your IP address. To protect our\n421-4.7.28 users from spam, mail sent from your IP address has been temporarily\n421-4.7.28 rate limited. Please visit\n421-4.7.28 https://support.google.com/mail/?p=UnsolicitedRateLimitError to\n421 4.7.28 review our Bulk Email Senders Guidelines. p14si10350218qtq.268 - gsmtp

Forwarders should not be used to other servers then your own. Gmail has an special function to pull emails from a 3rd location via pop3 / imap

2 Likes

Read carefully:

This is the most important advice. Don’t forward emails. Instead configure Gmail to connect via IMAP to fetch the emails and show them to your users.

If you just forward (redirect) you will also redirect your spam.

Thanks for the replies guy. Yes, I’m aware that spam will be forwarded along as well, which is why I have quite strict spamassassin rules and I discard most of the junk. Anything over a score of 8 gets deleted, so that I’m not forwarding along to gmail.

I’ve had this setup for more than 10 years now and never really had a problem with rate limiting until this new server. I’ve always simply set up my web server email as an alias to forward all emails to gmail. I only have two users on my web server and each domain is setup with emails which are simply aliases which forward to our two gmail accounts. I’ve not had a problem with this setup and I believe its quite common and many others have the same setup.

I’m just curious why you are saying it should not be done. I understand the obvious reasons about the forwarding spam, which is why I’m trying to combat that with Spamassassin. I thought that was the recommended way to deal with it, not to remove forwarding and setup direct pulls from the server via IMAP/POP. I’m trying to avoid the additional resource demand on the server. Based on what you guys are saying, this approach appears to be wrong. I’m just trying to figure out why so many articles are written on this topic. If I can’t get it under control with spamassassin or some other configuration, then I guess I could switch it up using the pull from gmail, it would just be a PITA (pain in the ass).

This is not enough.

You will be receiving spam from N sources, and all of the surviving spam will be redirected from only 1 source: your server via your account.

That configuration works until it doesn’t work anymore.

Google sets its own policies and doesn’t like spam. Why Google behaves one way or another doesn’t really matter since we will have to do as Google says or our emails will not be delivered.

You mean one small request per minute in an email server with two accounts is not much. Your server can handle a lot more for sure.

How about you set a catch-all address or redirect all email traffic to 1 address that you own and then, pull only the emails from that address to gmail.

[email protected] > Forwards > [email protected]
[email protected] > Forwards > [email protected]
[email protected] > Forwards > [email protected]
[email protected] > Forwards > [email protected]

[email protected] < Pulls < [email protected]

EDIT: You may read a bit on Google’s point of view here. Best practices for forwarding email to Gmail - Gmail Help . Google says that it is fine to do what you say but then… Why does it keep banning your server?

2 Likes

Thanks @jlguerrero, I appreciate your detailed response and advice. I think I will go that route if I start to have issues. At this point in time, I’m not really sure what the impact is. I just see these errors/warnings in the log files that mail has been rate limited, however I’m not seeing the impact on the frontend of things. For example, none of the emails I’m receiving from reputable sources appear to be rate limited.

For example: when I request a pin/code from one of my many online user accounts, I receive the email immediately. I also immediately receive any email I send from another account to myself as well as any email sent from friends, etc (from outside my mail server). So the notices in the email logs don’t really appear to impact me. So I’m not sure what is actually being rate limited or how often/how much time they are limiting. Perhaps it’s just that junk/spam mail that is being forwarded is getting rate limited, which in that case, I could care less, as it’s just being routed to the spam box on gmail anyway.

So the server is definitely not getting blocked (I think the spam assassin settings I have is helping to keep it somewhat under control - I had to strengthen the default settings that shipped with the HestiaCP installer, but it appears to be working fine).

This post was more exploratory and trying to understand if there is a way to reduce the error messages or whether or not there is a configuration that could clear it completely. For now, I think I will leave it as is, but in the future, if Gmail starts delaying my legitimate email from arriving to my gmail account, I will definitely take your approach outlined above. THANK YOU for the suggestions and advice.

1 Like

Very good.
The brute force attack has slowed down a lot.
Thanks.