Miscellaneous first checks
Affected Component(s)
fail2ban
What happened and when does this occur?
As mentioned in #1810, DMS in its default configuration keeps being constantly hammered by zombie servers, script kiddies and other bad actors. These actions make up for the bulk of DMS request-response cycles on my server. Having postscreen in play and not using it for anything else than DNSBL is a security vulnerability, IMO. These kinds of attacks should clearly be stopped, as all necessary components are in place (postscreen/fail2ban).
Log samples with a few attack types:
Mar 14 21:58:05 mail postfix/postscreen[12729]: CONNECT from [141.98.11.52]:60710 to [redacted]:25
Mar 14 21:58:05 mail postfix/postscreen[12729]: PASS OLD [141.98.11.52]:60710
...
Mar 14 21:58:05 mail postfix/smtpd[12730]: connect from unknown[141.98.11.52]
Mar 14 21:58:06 mail dovecot: auth: passwd-file(info,141.98.11.52): unknown user (SHA1 of given password: 34dec8)
Mar 14 21:58:08 mail postfix/smtpd[12730]: warning: unknown[141.98.11.52]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
...
Mar 14 21:40:06 mail postfix/postscreen[7478]: PREGREET 11 after 0.02 from [79.110.62.240]:54115: EHLO User\r\n
Mar 14 20:50:32 mail postfix/postscreen[32395]: PREGREET 11 after 0.02 from [79.110.62.240]:57517: EHLO User\r\n
Mar 14 20:22:16 mail postfix/postscreen[27498]: PREGREET 1 after 0 from [43.158.217.180]:53256: \002
Mar 14 20:22:16 mail postfix/postscreen[27498]: PREGREET 611 after 0 from [43.158.217.180]:53112: o\372\300\276\270\300\244\311\211\242\302\217\203\257\221\227\276\315\271\317\254\233\260\253\240\26
Mar 14 20:22:15 mail postfix/postscreen[27498]: PREGREET 1023 after 0 from [43.158.217.180]:52998: \377\242\377\000\377=\377\255\377\000\377\321\377\330\361\255\377\276H\373_5\377\255\361\rl\345\372p
Failures also often include broken/malformed TLS communication attempts which also could be considered a security problem:
Mar 14 21:58:55 mail postfix/smtps/smtpd[13069]: warning: TLS library problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331: |
Mar 14 21:58:55 mail postfix/smtps/smtpd[13069]: SSL_accept error from unknown[194.165.16.78]: -1 |
These attacks can use arbitrary intervals, therefore checks which take only 10-minute sample window into consideration are completely useless (a small excerpt from today):
Which is clearly not caught by F2B (using default configuration):
root@mail:/etc/fail2ban# fail2ban-client status dovecot
Status for the jail: dovecot
|- Filter
| |- Currently failed: 33
| |- Total failed: 1233
| `- File list: /var/log/mail.log
`- Actions
|- Currently banned: 0
|- Total banned: 1
`- Banned IP list:
root@mail:/etc/fail2ban# fail2ban-client status postfix
Status for the jail: postfix
|- Filter
| |- Currently failed: 3
| |- Total failed: 3
| `- File list: /var/log/mail.log
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:
root@mail:/etc/fail2ban# fail2ban-client status postfix-sasl
Status for the jail: postfix-sasl
|- Filter
| |- Currently failed: 33
| |- Total failed: 1233
| `- File list: /var/log/mail.log
`- Actions
|- Currently banned: 0
|- Total banned: 1
`- Banned IP list:
root@mail:/etc/fail2ban# fail2ban-client status custom
Status for the jail: custom
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list:
`- Actions
|- Currently banned: 8
|- Total banned: 8
`- Banned IP list: 107.170.243.25 159.203.224.10 162.142.125.213 167.94.138.62 180.214.239.18 193.42.33.76 93.174.95.106 163.123.143.10
While I understand fail2ban is a software package from another maintainer, so is every other part of DMS. We should do what we can to minimize attack vectors. This is a low hanging fruit, as the author of linked issue already provided a solution for this security vulnerability here: #1810 (comment).
What did you expect to happen?
The following should be expected:
- postscreen should get a proper jail config which would catch these "usual suspects"
- the sampling window of F2B to be of a meaningful value (not 10 minutes)
- typical low-hanging fruit attack vectors to be banned
- especially dangerous attack vectors like user/password brute-forcing (repeated failed auth attempts) to be banned either for for some meaningful unit of time, not an hour, or using incremental ban times
How do we replicate the issue?
- Use DMS in its default config and wait for a few hours. You'll get plenty of samples.
DMS version
v11.3.1
What operating system is DMS running on?
Linux
Which operating system version?
4.4.180+ SMP Tue Jan 31 23:19:16 CST 2023 x86_64 GNU/Linux synology_apollolake_918+
What instruction set architecture is DMS running on?
AMD64 / x86_64
What container orchestration tool are you using?
Docker Compose
docker-compose.yml
services:
mailserver:
image: docker.io/mailserver/docker-mailserver:11.3.1
container_name: mailserver
env_file: mailserver.env
volumes:
- ./data/mail-data/:/var/mail/
- ./data/mail-state/:/var/mail-state/
- ./data/mail-logs/:/var/log/mail/
- ./data/config/:/tmp/docker-mailserver/
- /etc/localtime:/etc/localtime:ro
- /...redacted.../traefik/config/acme.json:/etc/letsencrypt/acme.json:ro
restart: unless-stopped
stop_grace_period: 1m
cap_add:
- NET_ADMIN
healthcheck:
test: "ss --listening --tcp | grep -P 'LISTEN.+:smtp' || exit 1"
timeout: 3s
retries: 0
network_mode: hostRelevant log output
No response
Other relevant information
No response
What level of experience do you have with Docker and mail servers?
Code of conduct
Improvements to this form?
No response
Miscellaneous first checks
Affected Component(s)
fail2ban
What happened and when does this occur?
As mentioned in #1810, DMS in its default configuration keeps being constantly hammered by zombie servers, script kiddies and other bad actors. These actions make up for the bulk of DMS request-response cycles on my server. Having postscreen in play and not using it for anything else than DNSBL is a security vulnerability, IMO. These kinds of attacks should clearly be stopped, as all necessary components are in place (postscreen/fail2ban).
Log samples with a few attack types:
Failures also often include broken/malformed TLS communication attempts which also could be considered a security problem:
These attacks can use arbitrary intervals, therefore checks which take only 10-minute sample window into consideration are completely useless (a small excerpt from today):
Which is clearly not caught by F2B (using default configuration):
While I understand fail2ban is a software package from another maintainer, so is every other part of DMS. We should do what we can to minimize attack vectors. This is a low hanging fruit, as the author of linked issue already provided a solution for this security vulnerability here: #1810 (comment).
What did you expect to happen?
The following should be expected:
How do we replicate the issue?
DMS version
v11.3.1
What operating system is DMS running on?
Linux
Which operating system version?
4.4.180+ SMP Tue Jan 31 23:19:16 CST 2023 x86_64 GNU/Linux synology_apollolake_918+
What instruction set architecture is DMS running on?
AMD64 / x86_64
What container orchestration tool are you using?
Docker Compose
docker-compose.yml
Relevant log output
No response
Other relevant information
No response
What level of experience do you have with Docker and mail servers?
Code of conduct
Improvements to this form?
No response