Mailcow-dockerized: Mailcow Docker Instance got hacked?

[Knot3n]

Describe the bug
Hello,

seems like my docker instance or mailcow instance got hacked, i did a reinstall and restored the backuped .. so it seems like it is somewhere in the backup because as you can seen on the screenshots it is there again.

Could someone help me please?

Logs
If you need some, please tell me which one.

System

• OS: centOS7

[andryyy]

It was probably an open relay and was not hacked...
Or a weak password.

It is very, very important to check for correct IPv6 configuration and IPv4 NAT, if used.

A misconfigured IPv6 NAT makes remote connectors seem to come from private IP addresses.

[Knot3n]

Should be Mailcow not be configured as a not open relay ?
Because relay is not activated on my server.

Weak Password for ? The Admin User ? User?

Just to be sure, this is not about over SSH, its the Docker instance, because SSH is unlikely because we are using a key.

"It is very, very important to check for correct IPv6 configuration and IPv4 NAT, if used."

Wehere to i need to look?
Mailcow.conf ?

*Thanks for your quick reply

[andryyy]

It is not an open relay by default, no.

It is when the network is not correctly configured. And it happens mostly when IPv6 NAT is broken or you are using a misconfigured IPv4 NAT setup. Do you use IPv4 NAT?

@mkuron can help with IPv6 NAT stuff. :-)

[Knot3n]

So would it help for the first aid that i disable ipv6 ?

[andryyy]

Still don't know if you use IPv4 NAT, that is more important.

[Knot3n]

I'm a bit confused, we're talking about IPv4 NAT (SNAT)?
So that I also post the right line from the config ..

[andryyy]

That's nothing in your config. It is your server network. Does it use IPv4 NAT?

[mkuron]

If your server is an open relay, that can either happen because there is a masquerading NAT in front of it or because Docker's iptables rules are not getting applied. To identify the former, please check whether docker-compose logs postfix-mailcow shows any private IPs. To identify the latter, please show us iptables --list and ip6tables --list.

[Knot3n]

Hello @mkuron

can i send these logfiles to you over email?

@andryyy im useing a openVPN instance too on that server, maybe this is the problem.

[Knot3n]

Seems like disableing the VPN Firewall Rules resolved this issue.

This line seems legit to the Mailcow Process:

root 21419 0.0 0.0 85256 3708 ? S 09:59 0:00 smtpd -t pass -u -o stress= -o

smtpd_helo_restrictions=permit_mynetworks,reject_non_fqdn_helo

[andryyy]

This process is just a listening smtpd. It does not indicate a hack. :)

[Knot3n]

Hello,

again thanks for the fast reply and help.

just to be sure for myself can you if you have time check the process list if anything is noticeable - for me everything is now alright after the firewall misconfiguration.

https://nopaste.xyz/?5337a6ac8fae1654#iFsb0jFR7Dfj1fK4GPUuXdFpCPetZ8yaMbuIedHjoBk=

EDIT

Okay, seems like that the firewalld rule about VPN was not the problem because after a restart (docker / container) the problem is again there..

Attachted you can find the ipv4 / ipv6 firewall rules.

fw6.txt
firewall.txt

[Knot3n]

I have cleared the firewall rules of the VPN + deleted VPN service.
Unfortunately, I dont get it that the server stops sending spam.

I'm a little helpless

[Knot3n]

i installed all freshly it seems like the IP is attacked by spam servers ... postscreen is handeling this but seems like there are over 1000 x ips which try to "connect and send over the server".
But the server does not send any. What is good.

[andryyy]

Is it always the same IP that is blocked by Postscreen? Can you post the IP?

[Knot3n]

No,

they are different.

19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [91.204.139.66]:54950: 550 5.7.1 Service unavailable; client [91.204.139.66] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
-- | -- | --
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [102.176.197.253]:49334: 550 5.7.1 Service unavailable; client [102.176.197.253] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [91.204.139.66]:54950: 550 5.7.1 Service unavailable; client [91.204.139.66] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [114.69.240.162]:59559: 550 5.7.1 Service unavailable; client [114.69.240.162] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [154.58.223.182]:54501: 550 5.7.1 Service unavailable; client [154.58.223.182] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [89.108.137.51]:37190: 550 5.7.1 Service unavailable; client [89.108.137.51] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=<7bx.ru>
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [185.162.60.86]:58654: 550 5.7.1 Service unavailable; client [185.162.60.86] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [109.238.208.231]:55248: 550 5.7.1 Service unavailable; client [109.238.208.231] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [91.204.139.66]:54950: 550 5.7.1 Service unavailable; client [91.204.139.66] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [91.204.139.66]:54950: 550 5.7.1 Service unavailable; client [91.204.139.66] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [103.224.185.20]:43403: 550 5.7.1 Service unavailable; client [103.224.185.20] blocked using zen.spamhaus.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [154.58.223.182]:54501: 550 5.7.1 Service unavailable; client [154.58.223.182] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [110.235.196.85]:35550: 550 5.7.1 Service unavailable; client [110.235.196.85] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [190.119.199.18]:53183: 550 5.7.1 Service unavailable; client [190.119.199.18] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [91.204.139.66]:54950: 550 5.7.1 Service unavailable; client [91.204.139.66] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [43.252.18.231]:45466: 550 5.7.1 Service unavailable; client [43.252.18.231] blocked using zen.spamhaus.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [170.0.125.212]:55104: 550 5.7.1 Service unavailable; client [170.0.125.212] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [187.32.75.173]:57457: 550 5.7.1 Service unavailable; client [187.32.75.173] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [138.186.23.146]:37702: 550 5.7.1 Service unavailable; client [138.186.23.146] blocked using zen.spamhaus.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [89.108.137.51]:37190: 550 5.7.1 Service unavailable; client [89.108.137.51] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=<7bx.ru>
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [91.204.139.66]:54950: 550 5.7.1 Service unavailable; client [91.204.139.66] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [185.162.60.86]:58654: 550 5.7.1 Service unavailable; client [185.162.60.86] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [109.197.159.190]:40724: 550 5.7.1 Service unavailable; client [109.197.159.190] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [119.18.154.194]:38813: 550 5.7.1 Service unavailable; client [119.18.154.194] blocked using zen.spamhaus.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [154.58.223.182]:54501: 550 5.7.1 Service unavailable; client [154.58.223.182] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [91.204.139.66]:54950: 550 5.7.1 Service unavailable; client [91.204.139.66] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [103.245.34.46]:43931: 550 5.7.1 Service unavailable; client [103.245.34.46] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [196.207.29.66]:56977: 550 5.7.1 Service unavailable; client [196.207.29.66] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [103.95.97.185]:40506: 550 5.7.1 Service unavailable; client [103.95.97.185] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=
19.11.2018, 13:04:14 | info | NOQUEUE: reject: RCPT from [91.204.139.66]:54950: 550 5.7.1 Service unavailable; client [91.204.139.66] blocked using b.barracudacentral.org; from=[e-mail], to=[e-mail], proto=SMTP, helo=

*This is just a small amount of them.

[andryyy]

Oh, you could have blocked them then via netfilter.

But as long as your server is responsive, you can wait for it to stop.

[mkuron]

Your VPN probably had a masquerade firewall rule. If that is applied to all interfaces and not just the VPN, that probably caused your problem.

Also, please stop looking at process lists. They only tell you roughly how much load there is on your Postfix. To actually check whether you have an open relay, look at the Postfix log.

[Knot3n]

@andryyy
Netfilter / Fail2ban is configured like:

Bantime: 36000
Max Retrys: 3
Retry Time: 600

I manually added some of them to stop it a b it.

@mkuron

Yes it had, i disabled the masquerade on the firewall to prevent that.
Anyway its a bad idea to have VPN / Mail on the same server.

I checked it in the Webinterface, there is no "relay" configured.
So i didnt changed any standard configuration from mailcow for "open relay".

[mkuron]

I checked it in the Webinterface, there is no "relay" configured.
So i didnt changed any standard configuration from mailcow for "open relay".

Open relaying is nothing that anyone would want to have on purpose, so there is obviously no switch for that in the configuration interface. If your server is misconfigured (like yours with the masquerading), it acts as an open relay.

Netfilter / Fail2ban

That doesn't help. That only bans IP addresses after a certain number of authentication failures. The traffic you are seeing is servers asking for relaying without authentication, which is why Postfix (now that your server is configured correctly) replies with NOQUEUE.

In a few hours/days, that traffic should decrease. It seems like there are lists online of open relays that spammers discover and share with each other. Now that your server is no longer an open relay, the spammers should notice that and eventually take you off their lists.

[usimmjt1000]

I am having the same issue with someone hacking (using) my postfix to send spam. I have read the above threads. I do not have an open relay but I am using IPV4NAT. I have rebuilt the mailcow server and the problem continues. I have read the comments about the importance of correctly configured IPV4NAT but I do not understand why it is a problem or how to configure it the correct way. Any assistance would be greatly appreciated.

[andryyy]

If you hide the connectors IP, you will always turn into an open relay. All connections will be coming from your firewalls internal IP, which is a trusted source for relaying.

Don't Hide-NAT.

[usimmjt1000]

Thank you for your reply but I do not understand what "Don't Hide-NAT" means. Does this mean I can't use NAT at all ? Is these some documentation you can point me to that shows me an example of the correct configuration ?

[andryyy]

I can only help you with mailcow. It is essentially for mailcow to see the connectors real IP. You CAN use NAT, but not like this. I cannot help you configuring your firewall. :/

[Adorfer]

Note: Can somebody please modify the subject of this issue to a less clickbaity one?

[usimmjt1000]

Thank you again. I do understand you cannot help with configuring my firewall. I am running mailcow-dockerized. I believe my firewall is preserving the outside connectors real IP at least to the docker host. Is there something specific to the mailcow config with regard to docker I should investigate ?