Configuring PERMIT_DOCKER=network allows use as open relay with IPv6 enabled on host but disabled in Docker
#1405
Comments
|
Your problem is probably that you are losing the real external IP somewhere. From your logs:
The connection is from In other words you need to check your networking setup to ensure that the real external IP addresses for clients are preserved. |
|
@erik-wramner Thanks. That's strange. I tried to verify what you say On the host that should run the mail server: Then, I connect from And this is the result from inside the Container: Where So I assume the IP address is properly submitted into the Container. Is there another factor to consider? EDIT: Netcat (
|
|
There is no need to assume, the logs clearly show that you are connecting from 172.25.0.1. You need to fix the configuration so that the real remote addresses are present in the logs, otherwise things won't work very well. Try to find out where the remote addresses are lost. What is your network topology? Is the host running the mail server (in docker) connected to the Internet with a public IP, or is there something else in front? Do you use a proxy (HAProxy, Nginx) or do you connect directly? |
Yes.
There shouldn't be, except the Host Europe's Router; the contract says, 1 public IPv4 and ifconfig listed that IP.
We use those on Port 80 and 443 but not on any other port, as you can see from the
Since I noticed that, I had multiple |
|
Now I see something like: in the Logs when Google's Mail Exchanger connects but also So Postfix gets the Docker Proxy's Gateway IP on Port 25 and Dovecot the correct remote IP on port 143. |
|
Aha. Compose created an IPv4 network, since IPv6 is not enabled for Docker on that host. When another host connects to the host running the container using IPv6, the Docker Proxy translates IPv6 to IPv4 and inserts itself/its Gateway as Source IP Address, essentially doing NAT. I think that scenario isn't uncommon @erik-wramner - since by default many servers you can rent have IPv6 enabled initially but Docker disabled that by default. Additionally, I am in favor of a big warning on that. Easy to miss (while setting up and testing) and ugly impact. (And surely not the container's author's fault.) |
Rillke
changed the title
PERMIT_DOCKER=network allows use as open relayPERMIT_DOCKER=network allows use as open relay with IPv6 enabled on host but disabled in Docker
|
Sadly, I can't find any documentation about the Docker IPv6 to IPv4 NAT behavior. Thinking about solutions, we might block the gateways using iptables when |
|
As an interim solution I bound port 25 to the public IPv4 interface instead of any interface. If my host wants to send email, it has to authenticate now, but that's okay. ports:
- - "25:25"
+ - "the_IP_v4:25:25" |
|
Sorry for not answering, I've been busy. I don't want to firewall anything in the container, not least because I don't want the container to have that access right. I know it is needed for fail2ban, but people not using fail2ban can skip granting it and be safer for it. I'm all for a loud and clear warning in the README and Wiki and by all means if you want to log it during startup. Not sure how you would detect it without false alarms though? |
|
Should this warning also be made clear in the wiki example? It demonstrates enabling the The main README links to wikipedia about open relays, which does have a section on closing them:
How that should be done has not been communicated though?
Is this also going to be an issue then with reverse proxies? I don't think nginx-proxy supports these ports, but I think others like Traefik do?(which can be containerized or not)
So that I'm understanding this correctly... that's the IPv4 IP for the host server that's exposed to the internet? Is it only important for port 25? The IP needs to be a specific one(public IP to server that the domain name points to?), I guess that there is rarely any reason for having a proxy layer via a container like Traefik for these ports(not done any multi-server distributed container deployments with things like kubernetes, so not sure if that could be a case). Is there a benefit to this vs the default localhost?(containers I may be misunderstanding something as I'm new to setting up a mail server. I imagine a common use-case is to setup one for another container service to be able to send out e-mails, the docs aren't entirely clear on this,
Big warning would be useful, but more clarity on what the user should do to avoid the vulnerability would be good too. Besides locking the port to the host external IP, does enabling IPv6 in docker also prevent open relay issue? |
|
Another mention for |
Most likely. You can verify that by connecting via IPv6 at the same time watching the logs. |
|
This should be taken seriously. Has anything happened in the meantime here? I will make sure the README explains this, and we'll need to log this. |
|
|
docker-mailserver/target/postfix/main.cf Line 14 in 9577ab5 docker-mailserver/target/scripts/startup/setup.d/networking.sh Lines 51 to 74 in 9577ab5 They all seem to only support IPv4 subnets. As you can see the default is Ideally you'd instead have that container / service use ports 587 or 465 to submit mail with credentials to authorize, rather than require As for the open relay from IPv6 on the host. This is presumably because you have an AAAA DNS record that resolves to the mail server, the only time that is unintentional AFAIK is when you are using a bare domain instead of say Alternatively:
|
|
Hi @polarathene, is there an easy way to test if the configuration deployed has this security issue? Does not having AAAA DNS records mean that there is no exposure to this issue? |
https://stackoverflow.com/questions/60648/how-can-i-tell-if-i-have-an-open-relay/98264#98264
If both attempts fail, you should be ok. The default
Probably not, but it should reduce the risk? A spammer probably isn't concerned about resolving DNS records, but I think it may be a lot more difficult for them to hit your IPv6 address randomly than an IPv4 address 🤷♂️ Main issue with IPv6 is as explained above. If the Docker host can be reached via IPv6, the networking defaults for Docker tries to be helpful but is actively harmful if you're trusting a subnet for authorization. Our current Regarding the feature, it needs some rework such as the CIDR masks assigned look a tad wonky (inaccurate): #3478 |
Configuring
PERMIT_DOCKER=networkallows use as open relayWhat was the behaviour observed?
Configuring
PERMIT_DOCKER=networkallowed the an external IP to send E-Mail to an external address.What was the expected behaviour?
Only E-Mail from valid (SPF checks passing) external hosts are accepted.
Steps to reproduce:
Start the container based on it with
docker-compose up.Run telnet on an arbitrary host (not even in your host's network) that allows outgoing connections on port 25:
Container logs:
Compose configuration:
The text was updated successfully, but these errors were encountered: