Replies: 1 comment 1 reply
-
Probably won't make a difference but that should all be in
How often is the IP changing here in the logs? If it's not changing, you could block it. Otherwise there might be some additional config to identify the behaviour and block with Fail2Ban, or more strict restrictions on Postfix for what connections are permitted, not sure if that'd help here with that kind of activity though.
This is all I have to go by, but are you actually on DMS v11.1 still? Upgrading might help, we're at v13 now. Many fixes + updates since.
I am curious if enabling Postfix docs (I've slightly modified it in the quote):
This was suggested recently for this discussion, but their issue was related to a proxy routing their ingress from the client to DMS which lost the source IP address, and the proxy IP that replaced it was considered trusted. The feature was temporarily enabled as an improvement to block spam, but some users found it was a bit too aggressive for them so we've required it to be opt-in.
#!/bin/bash
echo 'Enabling "reject_unknown_reverse_client_hostname" to "dms_smtpd_sender_restrictions"'
sedfile -i -E \
's|^(dms_smtpd_sender_restrictions = .*)|\1, reject_unknown_reverse_client_hostname|' \
/etc/postfix/main.cf |
Beta Was this translation helpful? Give feedback.
-
I added docker-mailserver to my unraid server some time back and everything was fine for a while, but lately some hacking attempts on port 25 have been leading to smptd processes becoming stuck in an uninterruptible state. When this happens the unraid server eventually reaches a high load and other docker containers begin to fail to respond. Attempting to stop the mailserver docker fails and the unraid array cannot be stopped cleanly leading to a lenghtly parity check on restart. Once its back up again its usually only a day or two before another round of the same type of hacking attempt is made which leads to the same outcome for the server. Without mailserver running the unraid server is stable and does not suffer from these periodic 'hangs'.
Here is the pattern seen in the logs that leads to the smtpd processes becoming hung:
These are the last lines before the docker becomes unresponsive.
As I am not seeing people talking about this kind of problem, I am pretty sure there is something in how I configured the docker that may be leaving it open to this vulnerability.
Here is the docker run command used:
Any help/suggestions as to how to fix or diagnose the issue would be greatly appreciated.
Beta Was this translation helpful? Give feedback.
All reactions