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

Tip to get good timezone in logs (and to make fail2ban work on host) #1849

Closed
fred727-temp opened this issue Mar 13, 2021 · 9 comments
Closed
Labels
area/security kind/improvement Improve an existing feature, configuration file or the documentation priority/medium service/security/fail2ban

Comments

@fred727-temp
Copy link

fred727-temp commented Mar 13, 2021

It is a good practice to install fail2ban on every server hosted on the internet...

So it was a good idea to include it in this projet, but if it is already installed on host, it is easier to active it and configure it on host (we just have to configure the good path so that fail2ban could find logs).

The problem is that timezone in the container is Etc/UTC and perhaps this is not the same on your host. In this case, fail2ban will have problem and no IP will be banned.

The solution is to add link to your /etc/timezone and /etc/localtime in the docker-compose.yml

    volumes:
      - /etc/timezone:/etc/timezone
      - /etc/localtime:/etc/localtime

This way, timezone in container is the same as on your host. (I think this could be in the default docker-compose file...)

Simple and efficient ! (Hope this help)

@fred727-temp fred727-temp added kind/question Someone asked a question - feel free to answer meta/help wanted The OP requests help from others - chime in! :D meta/needs triage This issue / PR needs checks and verification from maintainers priority/low labels Mar 13, 2021
@casperklein
Copy link
Member

if it is already installed on host, it is easier to active it and configure it on host (we just have to configure the good path so that fail2ban could find logs).

Have you tested this setup, does it really block connections to the container? I did a quick test on the host: iptables -I INPUT 1 -p tcp --dport 995 -j DROP
This does not prevent accessing tcp/995 in the container.

I think, that's part of dockers iptables prerouting "magic".

I have iptables on the host, with the default INPUT policy set to DROP any not allowed connections. When using containers, I don't have to allow any ports explicitly on the host, when using docker run -p HOST_PORT:CONTAINER_PORT

@casperklein
Copy link
Member

    volumes:
      - /etc/timezone:/etc/timezone
      - /etc/localtime:/etc/localtime

I am using the localtime mount myself for a long time. However not the timezone. AFAIK it's not necessary. Do you know, if that adds any value to DMS?

@fred727-temp
Copy link
Author

fred727-temp commented Mar 13, 2021

Have you tested this setup, does it really block connections to the container?

Yes I have enabled the postfix-aggressive jail on host and it work perfectly.

[DEFAULT]
protocol = all

[postfix-aggressive]
enabled  = true
chain    = DOCKER-USER
port     = smtp,ssmtp
logpath  = /your/path/to/mail.log
filter   = postfix[mode=aggressive]

I have IP banned every minutes. All banned IP does not appear in mail log anymore after they are banned.

I am using the localtime mount myself for a long time. However not the timezone. AFAIK it's not necessary

Yes perhaps it is not necessary... I added it in case...

@casperklein
Copy link
Member

casperklein commented Mar 13, 2021

I see you use the DOCKER-USER chain. Using this chain, I was able to block the access. I didn't know that 😄

@wernerfred
Copy link
Member

Ou nice approach. This might help me with #1761 as the logs should show the real ip received from the proxy protocol. For now i was using DROP on FORWARD as INPUT had no effect ("docker iptables magic" 😅)

We are currently migrating the wiki to docs hosted in this repo (see #1826) I would ping you here again when this PR is merged and ask you for providing a small write up for this scenario.

@georglauterbach georglauterbach added area/enhancement kind/improvement Improve an existing feature, configuration file or the documentation priority/medium service/security/fail2ban area/security and removed kind/question Someone asked a question - feel free to answer meta/help wanted The OP requests help from others - chime in! :D meta/needs triage This issue / PR needs checks and verification from maintainers priority/low labels Mar 14, 2021
@georglauterbach
Copy link
Member

So, I don't know what I'm doing wrong, but my host is still not banning IPs properly.

I would therefore reall love to see a working host F2B setup:)

@fred727-temp
Copy link
Author

fred727-temp commented Mar 25, 2021

@aendeavor, you can read this page which explain an other solution.
Perhaps it will work for you

Here is the explanation of the DOCKER-USER chain :
https://docs.docker.com/network/iptables/

@georglauterbach
Copy link
Member

georglauterbach commented Mar 25, 2021

@fred727-temp Thanks! I will read it, but we've found a solution in #1821 already :)

@wernerfred
Copy link
Member

We are currently migrating the wiki to docs hosted in this repo (see #1826) I would ping you here again when this PR is merged and ask you for providing a small write up for this scenario.

@fred727-temp the documentation pr is now merged (find it here: https://docker-mailserver.github.io/docker-mailserver/edge/) If you want to contribute your tip there feel free to open a PR with changes to the according file - or click the "edit" (pencil) button within the documentation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/security kind/improvement Improve an existing feature, configuration file or the documentation priority/medium service/security/fail2ban
Projects
None yet
Development

No branches or pull requests

4 participants