Dockerized Mailcow, Rspamd, and Blocking CIDRs

aaronsmith

You may have noticed that docker configures iptables in such a way that adding firewall rules (e.g. via ufw) has no effect. If you’re running dockerized-mailcow and have been using ufw/iptables incorrectly to add rules intended to help filter traffic from bad sources, they won’t work:
https://docs.docker.com/network/iptables/

If you’re running Docker on a host that is exposed to the Internet, you will probably want to have iptables policies in place that prevent unauthorized access to containers or other services running on your host.

First off, make use of pflogsumm to see what’s been happening within your mail server. In my example below, we’ll see some rejected messages:
https://docs.mailcow.email/manual-guides/Postfix/u_e-postfix-pflogsumm/

Special note: You can remove the “–since 24h” if you want to enumerate the statistics for the entire time period available from the postfix-mailcow container.

message reject detail

RCPT
blocked using b.barracudacentral.org (total: 1)
1 45.134.23.234
blocked using hostkarma.junkemailfilter.com (total: 1)
1 31.210.22.179
blocked using zen.spamhaus.org (total: 3)
2 31.210.22.179
1 185.216.71.7

Notice from the above, an IP attempted to deliver multiple messages (31.210.22.179 tried 2 times.) Repeated offenders should be higher priority for you to block.

These rejects were done by Rspamd’s RBLs. There are several RBLs enabled by default, and some additional ones added by Mailcow:
https://community.mailcow.email/d/1921-rspamd-rbls-configure-for-mailcow-differ-from-rspamd-defaults

But the offender was still allowed to connect to your machine. Also these statistics will show warnings that could include deliberate attempts to execute HTTP command via SMTP, which should also be blocked:

Warnings

1 non-SMTP command from unknown[205.210.31.46]: GET / HTTP/1.1
1 non-SMTP command from unknown[138.68.91.83]: GET /c/version.js …
1 non-SMTP command from unknown[69.57.160.94]: GET /remote/fgt_la…

Going back to the docker documentation I linked above…

By default, all external source IPs are allowed to connect to the Docker host.

Docker installs two custom iptables chains named DOCKER-USER and DOCKER, and it ensures that incoming packets are always checked by these two chains first.

If you need to add rules which load before Docker’s rules, add them to the DOCKER-USER chain.

So if you want to start blocking offending IPs to prevent them from attempting anything against mailcow (which can have vulnerabilities), use the following command:

iptables -I DOCKER-USER -s <IP ADDRESS> -j DROP

This will block a single IP address by adding it to the DOCKER-USER iptables chain. You could use ‘whois <IP ADDRESS>’ to obtain the associated CIDR block of IPs associated with the offender, but that may be overkill and increases the risk of rejecting valid emails.

After you add an entry, you can verify it via the following command:

iptables -L DOCKER-USER

If you wish to log the activity from DOCKER-USER chain (to verify drops in the future)

iptables -A DOCKER-USER -j LOG

Keep in mind that doing this means you’ll never see connection attempts from that IP again. If the IP gets itself removed from RBLs, then you’ll be disconnected from this change. As such, I recommend only blocking repeat offenders, and periodically checking the RBLs to see if they’ve been removed, suggesting the owner fixed their problems.

Hope this is helpful!

uniquegch

Hello Aaronsmith,
I am new with mailcow dockerized and want to restrict the web GUI access to the admin and Sogo (which I actually would not really need). The reason to restrict those access is as follows:

I am the only user of that Server
I want only to access from on external IP@ and one internal IP @ range.

I have seen a post using the NGINX config for Stream - Server in allowing - denying IPs. Which one would be better, especially keeping the config when updating the docker containers.
Thanks

esackbauer

I don’t see any benefit in this. If you have it on external IP (and you are already letting the whole internet penetrate your ports 25, 587, 993 etc), and you are using safe credentials (long enough password) then its fine, because brute force is detected an banned via fail2ban/netfilter.
Its a reason why that has been implemented so you must not deal with blocking single IPs…
SOGo can be deactivated in mailcow.conf, but its actually one of the main selling points for mailcow.
SKIP_SOGO=y
But then you also don’t have CardDAV/CalDAV anymore…

aaronsmith

I’ve seen fail2ban is not catching these attempts because they are only being attempted once per hour or half-hour, but it was always systematically on that time interval.

So while I agree fail2ban is a good automated response, I opt for manual management on top of that with iptables to prevent any attempts when I isolate malicious CIDRs.

Arguably (perhaps pedantically or academically, take your pick 🙂) this helps reduce the potential for future vulnerabilities from being exploited from those same point-of-origins.

But this method is also tedious and cat/mouse.

[unknown] I would lean towards NGINX since there is documentation for mailcow on how to integrate the reverse proxy for it.

But you could also just only permit it to your home IP by adding an allow rule for your /32 IP and then a deny rule for anything else to 443. Of course you’d have to update the rule anytime your IP changes, but seems a minor inconvenience.

HTTPS/443 is only used for the web admin/client interfaces, email clients will use the other ports/protocols.

[unknown] I would lean towards NGINX since there is documentation for mailcow on how to integrate the reverse proxy for it.

HTTPS/443 is only used for the web admin/client interfaces, email clients will use the other ports/protocols.

esackbauer

I’ve seen fail2ban is not catching these attempts because they are only being attempted once per hour or half-hour, but it was always systematically on that time interval.

It they are attempted once per halfhour and you have secure passwords, any breach would take millions of years.
2FA makes brute force even impossible.

HTTPS/443 is only used for the web admin/client interfaces, email clients will use the other ports/protocols.

As I wrote if you block this you don’t have CalDAV anymore.
But then you should rethink your whole setup, if you don’t use SOGo, use a different mail stack (e.g. docker-mailserver/docker-mailserver), that comes with less components and therefore less attack surface.

Or you could use a Web Application Firewall in front of mailcow, as I do (Sophos Firewall is free for private use).

aaronsmith

esackbauer Oh I didn’t realize that about CalDAV, thanks for sharing! I think this comes down to what you’re comfortable with. Personally, I don’t want to even see the failed login attempts in the logs from locations that I can tell are malicious.

uniquegch

ok well call me paranoid, but if can restrict it I will. Also I want to disable pop3 and pops. do not see a reason in that. Now I am posting here my settings for failban and the current IP networks I am banning. and that is ridicilous. So for me it would be much easier to allow 1 IP address range and one public IP address. Furthermore yes Sogo looks nice but I only really need the mailboxes I have for several domains.

furthermore it seems that dovecot (intervals by -10 till to 0) and postfix (intervals by -2 till to 0) are falling ill (based on watchdog).

Those are the IP networks, which got “trapped” by failtoban and I checked manually (ip geolocations (always thread level = high and sometimes crawlers = yes) , whois and subnet calculator) and block them.
68.140.0.0/15
94.128.0.0/9
106.0.0.0/8
147.78.103.0/24
2.57.0.0/16
174.64.0.0/12
110.0.0.0/8
172.105.144.0/23
36.32.0.0/14
45.0.0.0/8
76.128.0.0/11
141.0.0.0/8
61.0.0.0/8
34.64.0.0/10
5.0.0.0/8
211.0.0.0/8
202.0.0.0/8
154.0.0.0/8
81.176.0.0/15
192.3.0.0/16
60.0.0.0/8
196.191.0.0/16
188.162.0.0/16
76.96.0.0/11
185.0.0.0/8
187.0.0.0/8
173.73.0.0/16
172.105.0.0/17
62.97.32.0/19
190.200.0.0/13
103.0.0.0/8
62.16.96.0/19
112.0.0.0/5
87.120.84.0/24
178.176.0.0/14
80.16.0.0/13
1.0.0.0/8
64.62.128.0/17
120.0.0.0/5
176.32.0.0/11
41.0.0.0/8
38.0.0.0/8
89.154.0.0/16
208.0.0.0/8
39.32.0.0/11
102.37.0.0/16
192.72.0.0/19
2.55.0.0/16
14.0.0.0/8
167.94.138.0/24
91.72.0.0/14
172.104.0.0/16
221.0.0.0/8
2.64.0.0/13
39.128.0.0/10
92.36.0.0/16
220.0.0.0/8
193.187.82.0/23
182.0.0.0/8
85.31.45.0/24
68.128.0.0/13
222.0.0.0/8
201.0.0.0/8
190.119.0.0/16
109.48.0.0/15
172.105.146.0/24
68.136.0.0/14
189.8.124.0/22
149.72.0.0/16
46.0.0.0/8
139.0.0.0/8
219.0.0.0/8
191.36.0.0/16
218.0.0.0/8
85.15.128.0/18
171.208.0.0/12
186.0.0.0/8
111.0.0.0/8
81.161.229.0/24
198.23.128.0/17
144.48.0.0/16
58.0.0.0/8
59.0.0.0/8
81.86.0.0/16
136.255.0.0/16
50.128.0.0/9
223.0.0.0/8
192.237.0.0/16
172.105.128.0/20

[unknown]
The IP address range is indeed a 10.x.x.x and I have one static IP that seems never changing, which actually would not be an issue because I would prefer going through the 10.x.x.x network. The mailserver I have is on a VPS by a provider.
I would add those nginx config setting in the nginx.conf? I am not so familiar with webserver configs.

[unknown] The IP address range is indeed a 10.x.x.x and I have one static IP that seems never changing, which actually would not be an issue because I would prefer going through the 10.x.x.x network. The mailserver I have is on a VPS by a provider.
I would add those nginx config setting in the nginx.conf? I am not so familiar with webserver configs.

The IP address range is indeed a 10.x.x.x and I have one static IP that seems never changing, which actually would not be an issue because I would prefer going through the 10.x.x.x network. The mailserver I have is on a VPS by a provider.
I would add those nginx config setting in the nginx.conf? I am not so familiar with webserver configs.

esackbauer

aaronsmith

I don’t want to even see the failed login attempts in the logs from locations that I can tell are malicious.

It is happening now, 7×24 and on all ports you have opened. Its a competition you as single person can never win.
I gave up on this long time ago. And it also makes no sense to suppress 5 login attempts from a single IP, when you have safe passwords.

uniquegch

ok something went really wrong with my last post (meaning vom unknown being posted too many times, because of an error I received trying to post).
Anyway right now I am facing the issue that when using a mailclient that I can neither get my e-mails nor send any, because the message is connection refused. I will go ahead and comment out the IPv6 settings in the nginx configs. that caused my neither being able to get to the admin page nor using Sogo, but it kept the server calm and steady. I have no idea why that change is having a (positive) impact of keeping the server stable.
I will also look into docker-mailserver.

… and something else is not adding up.
When I look into the sites.active (…/mailcow-dockerized/data/config/nginx I see those two lines

include /etc/nginx/conf.d/server_name.active;
include /etc/nginx/conf.d/includes/site-defaults.conf;

but the path is correct. I have the files but not under /etc/… I assume that is a docker thing?