Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running mailu without docker's iptables creates an open relay #332

Closed
pgeorgi opened this issue Nov 25, 2017 · 4 comments
Closed

Running mailu without docker's iptables creates an open relay #332

pgeorgi opened this issue Nov 25, 2017 · 4 comments

Comments

@pgeorgi
Copy link

@pgeorgi pgeorgi commented Nov 25, 2017

When disabling iptables in docker, its forwarding proxy process takes over. This creates the situation that every incoming connection on port 25 seems to come from the local network (docker's 172.17.x.x) and is accepted.

IMHO there should be some mechanism to check for that situation and refuse service in such cases, but right now I'm at loss what that could look like.

@kaiyou
Copy link
Member

@kaiyou kaiyou commented Nov 25, 2017

This is actually quite a worrying security issue. Probably we should not even include anything by default in the trusted networks, as authentication already does most of the job.

@domnoble
Copy link

@domnoble domnoble commented Dec 18, 2017

yea this is a worrying security issue, for the past month or so ive had a bunch of IPs trying to brute force access to the mailserver via port 25, there was a whole block of about 20 IPs in ukraine at 91.200.12.x, one of them had a hostname walkerj.ex.com, which i followed the domain (ex.com) back to another IP in canada which seemed to be a command and control for ransomware also seems to be a massive hoard of domains some good ones too, i run everything behind a separate firewall so i can see what is going on

yesterday morning at about 05:00 i got so many port scans my internet literally started to lag, with them originating from israel, germany and china, i was able to block all the IPs which appeared to be port scanning but then today going over the logs i can now see the docker internal IP now doing some weird port scanning, i assume its down to this, sure enough if i shut down all the containers for mailu, the port scanning from the docker IP stops

im assuming the only sollution to this would be to try and install iptables on the host, start again with the containers and delete all the volumes

@kaiyou
Copy link
Member

@kaiyou kaiyou commented Dec 18, 2017

Well, I think you misunderstood the issue. Portscans and authentication bruteforce is common and actually pretty normal on the internet (at least for portscans). It's my opinion only, but I don't think you should spend too much energy trying to track them down (I personally get hundreds bruteforce attempts per day).

That being said, the current issue is in your configuration: you should not have the Docker proxy enabled except in a testing setup. It is not a supported Docker setup and not one that will play well with many images, including Mailu. The recommended solution is to enable the Docker iptables configuration in your daemon.json.

This issue will be resolved when the default config does not pose a risk for people still running a Docker proxy, or when the documentation states clearly enough that there is a risk of open relay.

@DarioFra
Copy link

@DarioFra DarioFra commented Apr 5, 2021

Hi I moved my mailu server from a docker linux host to a docker-desktop v3.2.2 (using WSL2 / ubuntu windows) host and the server turned in to an open relay. (did not care to check due to lack of imagination I guess)

Seems the windows system does source NAT and the mailu_smtp_1 container gets source addresses from the docker network, as opposed to real external ones when running on a linux docker installation using iptables. (same with the mailu_front nginx container)

A workaround (for now) is to add a line to this file
overrides/postfix.cf (the doc incorrectly specifies it should be under /overrides/postfix/postfix.cf)
mynetworks = 127.0.0.1/32

I dont think this is sustainable since I suspect its hard for mailu to in turn check black-lists without the real IP available for incoming mails.

Understand that this might not be a mailu problem to deal with but I think it would be good to mention the complexity in the install docs since its a pain and not that fun to run an open relay...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants