Further Locking Down Email
-
Hello All!
I was curious if anyone else has implemented any other solutions to further lock down their Cloudron Email servers?Currently, we're consistently seeing at least 200+ attempts to send emails from non-existent email addresses (Connection denied. No such address) and have seen upwards of 1000+ attempts a day.
We do have a few blacklists enabled which does seem to catch some items.
Thank you!
-
J JLX89 marked this topic as a question on
-
I think there is no need to worry because of those reasons:
- Cloudron mail is already limitting the requests per second
- You dont' want to deny anyone to deliver email as long as you don't know to whom it will request to deliver to
- If the requests are comming from the same server you may consider to block this server in the Network Configuration of Cloudron (or external Firewall)
However, I experience the same attempts to send spam to my Cloudron, and in the beginning I was concerned, too. But it seems that this is todays internet and there is not much you can do. I think the rate limit (already in Cloudron) is helping a lot already.
-
@Kubernetes Thank you for your reply!
@Kubernetes said in Further Locking Down Email:
But it seems that this is todays internet and there is not much you can do. I think the rate limit (already in Cloudron) is helping a lot already.
Yes, I agree with this. Incoming spam thankfully isn't too bad yet, but attempts to generate outgoing spam using the domains setup in Cloudron was what I was referring to. At a minimum, I do see that the configured blacklists we are using are catching quite a bit of the incoming spam.
-
@girish I assume the "attempts to create outgoing spam" refer to attempts to log in to the SMTP server which show up in the logs as authentication failed.
Generally I find that the rate limit and the DSBL-checking eliminate 99.5% of incoming spam before it even reaches a mailbox. IP range blocking in the network setings is good for persistant abusers. It would be nice, however, to have the option to completely delete spam based on rules defined in the blocklist, rather than have them moved to the SPAM folder. there are some mails that are 100% SPAM and could be removed instantly. Once the mail has been defined as SPAM, it doesn't seem possible for a user to set up a filter to aitomatically delete such mails.
Concerning outbound SPAM, unless a user has a very weak and guessable password, it is highly unlikely that a spammer will be able to log in to the SMTP server to send mail. Most spammers are just scanning for open relays or insecure accounts.
-
@Kubernetes said in Further Locking Down Email:
@JLX89 is referring to "(Connection denied. No such address) ". This is incoming spam, and not tries to brute force an mailbox account.
That is correct
-
@JLX89 You would only see successful outbound spam attempts in the event log and that is when you might want to be concerned. If your accounts are secure that should never happen though. Unsuccessful authentication attempts only show up in the mail logs.
In general I would say that Cloudron's mailserver implementation does a very good job at blocking unwanted connections. A mailserver by its nature has to be able to receive unauthenticated connections from other servers, which is why good filters and blocking are important. The thousands of attempts to deliever spam are just something we have to live with.
-
G girish has marked this topic as solved on
-
Has anyone else been getting hit a lot recently with spam connections?
What I find peculiar is the consistency in type of random connection attempts. What do you think one is trying to achieve by trying random aliases/accounts in this fashion? It's not even remotely close to real world accounts, just random strings of letters and numbers of similar length.
These are coming from IP addresses in all sorts of countries - Hong Kong, Bangladesh, Russia, United States, Netherlands, South Korea, etc. Makes me think it's from some type of botnet.
-
I've seen this a couple of times this year. If you look in the logs you will see that the same IP attempts to send mails to 100 non-existent addresses on each connection. The sending addresses are almost always from .ru domains but the actual relaying computers (i.e. the computers compromised by the botnet) are mostly also in India, Brazil, Pakistan and Vietnam. There is nothing you can do about this. The mailserver is correctly rejecting the attempted delivery and the annoyance will probably just stop after 7 - 10 days.
-
Another thing that's interesting is it's hitting all my domains activated for email. Despite some of them basically never ever being used or given out. It's like a bot has harvested all the domains associated to my Cloudron instance somehow. Could this be something akin to the domain TLS cert info harvesting method (think solved now)? Some method to centrally obtain all in-use domains operating on the server
-
@xarp note that all newly registered domains and new cert issuances are basically available online. For example, https://crt.sh/ and https://certstream.calidog.io/ . https://dnpedia.com/tlds/daily.php shows newly registered domains... It's easy to get lists from those sites and feed them into some bot code.
-
@girish said in Further Locking Down Email:
@xarp note that all newly registered domains and new cert issuances are basically available online. For example, https://crt.sh/ and https://certstream.calidog.io/ . https://dnpedia.com/tlds/daily.php shows newly registered domains... It's easy to get lists from those sites and feed them into some bot code.
That's it, that'll do it. Thanks for the reminder.
-
N necrevistonnezr referenced this topic on
-
A general question. Is it ok to maintain the file "/home/yellowtent/platformdata/firewall/blocklist.txt" manually via a terminal as well? Since I unfortunately now maintain a larger list and the UI throws an error when saving. Also, I would like to automate that this is distributed over multiple instances. And this would help with that.
-
