Docker Mailserver
Is there a way to block 'unknown user' from Dovecot logins? #4554
-
|
I am seeing a LOT of these attempts in my logs recently ...
... is there a way to block 'unknown user' or do something with fail2ban? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
This just means someone tried to login to Dovecot with a username that doesn't exist. If this isn't from legitimate users making mistakes or running into some other related issue, then it's most likely automated attempts to login (but not likely targeting you specifically, just low-hanging fruit with common usernames / passwords). Fail2Ban should be able to monitor for such and ban the IP, but that isn't my area of expertise in the project 😅 Just be mindful of legitimate failures also being possible depending on your users, and that automated attempts will just keep coming in via different IPs anyway. For the most part though, provided you have strong passwords (a decent amount of entropy is all that matters really), these attempts won't compromise any actual accounts it'd just be noise in the logs that you can filter out. This sort of activity is quite common for publicly exposed services regardless, like a VPS getting hammered with SSH login attempts. I've had some instances secured with a 5 random word password (all lowercase letters, no special chars), and that doesn't get compromised since the entropy is decent enough (different story if someone were to target that server specifically, but there's often more affordable attacks instead in that case). One option that could probably work better is using mTLS, which would require connecting clients to provide their own client certificate for establishing trust before proceeding. I'm pretty sure Dovecot supports this, but DMS has no official support to assist with that, and again it might add friction to your users to configure at their clients, you're effectively giving them a VIP card or stamp like at an event, so anyone that presents that is allowed to pass on through. A similar feature is IP white/allow lists when that is acceptable to restrict on. Some do this with VPNs, which would be fine for the Dovecot ports to interact with mail, but you'd still need Postfix port 25 public to receive mail from public MTAs. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @polarathene , Firstly, thank you for such a comprehensive answer. Secondly, I could go down the Fail2Ban route (always happy to learn) but your mention of a VPN made me think - it would be trivial for me to use my exiting Tailscale network and block all traffic on port 993 except for my laptop's Tailscale IP. There are only work emails on my server and I only do work from my laptop. That would fix it right and provide an extra layer of security? |
Beta Was this translation helpful? Give feedback.
-
|
UPDATE I have just logged in to briefly look at Fail2Ban and found that it is actually doing something with those attempts from my OP ... ... is this correct behaviour? It seems to be doing it on the second failed attempt? |
Beta Was this translation helpful? Give feedback.
-
Yeah, if it's not publicly accessible then the logs would only represent failed attempts from authorized clients (on your TS network). Just ensure port 25 is reachable publicly if you want other mail servers to be able to reach you. I think you will want to publish DMS container ports to the different networks, so port 25 might be If instead Docker isn't using a single network interface within the container, it can be a little tricky. I think there might be another caveat known about outbound connections if the host has more than one suitable interface, I vaguely recall our docs examples tab/section has a community guide about this for binding interfaces if that becomes necessary.
Again, I don't have much expertise on the F2B support, but I think out integration for F2B is fairly light/simple. At a glance I see this config which enables Dovecot and mentions that IPs are monitored for failures up to 6 times within the span of a week before a 1 week ban is applied. If it's occurring reliably at only 2 attempts, perhaps there's 3 triggers per attempt (Postfix + Dovecot logs monitored and perhaps something else or more than one log line?). You can see the logs We recently disabled/removed a separate F2B rule for |
Beta Was this translation helpful? Give feedback.
-
|
Again, thank you for such a detailed reply. It looks like I can 'safely' ignore these attempts while the server IMAP is publicly accessible, and also it looks like Fail2Ban is doing something at least! I will look in to the flipping it over to the Tailscale IP for completeness. Cheers, Paully |
Beta Was this translation helpful? Give feedback.
Yeah, if it's not publicly accessible then the logs would only represent failed attempts from authorized clients (on your TS network).
Just ensure port 25 is reachable publicly if you want other mail servers to be able to reach you.
I think you will want to publish DMS container ports to the different networks, so port 25 might be
0.0.0.0:25:25, and other ports could be to your TS IP instead of0.0.0.0. Presumably that should go smoothly 😅If instead Docker isn't using a single network interface within the container, it can be a little tricky. I think there might be another caveat known about outbound connections if the hos…