[SOLVED] Blacklisting IP address blocks in Postfix

gattu_marrudu · 2025-09-03 16:25:37

Hi there,
I am setting up a public mail server. Shortly after starting Postfix and hitting it with some external MX lookup tools, I noticed repeated login attempts from a /24 IP block.

Sep 03 16:11:36 eolo postfix/smtpd[6758]: connect from unknown[81.30.107.145]
Sep 03 16:11:36 eolo postfix/smtpd[6757]: disconnect from unknown[81.30.107.185] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Sep 03 16:11:37 eolo postfix/smtpd[6753]: warning: SASL authentication failure: Could not open /etc/sasldb2: gdbm_errno=3
Sep 03 16:11:37 eolo postfix/smtpd[6753]: warning: unknown[81.30.107.189]: SASL LOGIN authentication failed: generic failure, sasl_username=nws
Sep 03 16:11:38 eolo postfix/smtpd[6753]: disconnect from unknown[81.30.107.189] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Sep 03 16:11:40 eolo postfix/smtpd[6758]: warning: SASL authentication failure: Could not open /etc/sasldb2: gdbm_errno=3
Sep 03 16:11:40 eolo postfix/smtpd[6758]: warning: unknown[81.30.107.145]: SASL LOGIN authentication failed: generic failure, sasl_username=plc
Sep 03 16:11:40 eolo postfix/smtpd[6758]: disconnect from unknown[81.30.107.145] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Sep 03 16:11:47 eolo postfix/smtpd[6757]: connect from unknown[81.30.107.160]
Sep 03 16:11:48 eolo postfix/smtpd[6753]: connect from unknown[81.30.107.149]
Sep 03 16:11:51 eolo postfix/smtpd[6758]: connect from unknown[81.30.107.159]
Sep 03 16:11:52 eolo postfix/smtpd[6757]: warning: SASL authentication failure: Could not open /etc/sasldb2: gdbm_errno=3
Sep 03 16:11:52 eolo postfix/smtpd[6757]: warning: unknown[81.30.107.160]: SASL LOGIN authentication failed: generic failure, sasl_username=success

So I implemented the changes suggested in https://wiki.archlinux.org/title/Postfi … ing_emails and added a blacklist to my Postfix config. However, that didn't seem to have any effect. The spammers keep hammering away.

My relevant postfix config section (from postconf output):

smtpd_recipient_restrictions = check_client_access lmdb:/etc/postfix/blacklist permit_mynetworks permit_sasl_authenticated reject_rbl_client zen.spamhaus.org reject_rhsbl_reverse_client dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org

My blacklist file (I hashed it):

$ cat /etc/postfix/blacklist
81.30.107.0/24		REJECT buzz off

I have a few questions:

1. Is it OK to blacklist a whole /24 block?

2. The Arch Wiki uses "check_sender_access" while other sites use "check_client_access". The Postfix manual mentions "check_client_access" for "smtpd_recipient_restrictions" and "check_sender_access" for "smtpd_sender_restrictions". I went with the former. Is the Wiki correct?

3. What are the "Could not open /etc/sasldb2" messages? Are they related to the filter not working? I am using Dovecot SASL.

Thanks.
gm

Last edited by gattu_marrudu (2025-09-03 21:56:15)

-thc · 2025-09-03 16:47:20

Are you aware what kind of protection a public SMTP server needs? You'll need to craft a watertight postfix configuration.
A single line recipient restriction is IMHO not enough.

The error means your postfix SASL setup is broken.

The continuing errors mean your blacklist configuration change doesn't do anything - because postfix restrictions follow the SMTP protocol "stages" (from top to bottom):

smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictions

and - presumably - the postfix default for the "earlier" restrictions try the SASL auth way before "smtpd_recipient_restrictions".

"check_sender_access" and "check_client_access" are checks for some of the five restriction sets above. The fromer checks the "MAIL FROM:" field - the latter the IP address of the connecting SMTP client.

Last edited by -thc (2025-09-03 16:58:28)

cryptearth · 2025-09-03 16:56:49

you don't want to handle the application the blocking - but that's what firewalls are for
as for /24 blocks? I have far bigger blocks in my firewall because for convenience they were assigned continious

gattu_marrudu · 2025-09-03 18:52:33

Thanks for clarifying the difference between "check_sender_address" and "check_client_access". It looks like I was trying to secure the opposite end (incoming emails vs. SMTP login attempts).

I agree with @cryptearth about using a firewall for blocking traffic, I'll move my IP filters there.

Re. setup: I'm moving this SMTP & IMAP server from a similar one I have had on a cloud server for some years, where I have set up DNS records for SPF and DKIM, elliptic curve SASL, Postgrey filtering, etc. It hasn't given me much trouble so far, but surely it's not airtight, and I look forward to improving it as I go.

mpan · 2025-09-03 18:53:55

If by “public mail server” you mean one available for other people, I can’t offer much. My experience is limited mostly to the single-user case.

But one thing I can suggest is separating mail transfer and mail submission/retrieval. This way you divide concerns, including protection measures that are very different for each of these services.

In the default configuration Postfix doesn’t allow authentication attempts and only relays mails from a single trusted client (usually localhost, but that can be changed). This takes the entire pile of trouble from your shoulders. All the reverse bruteforce and credential stuffing attacks turn into nothing but log noise.

Then the other service, for example Dovecot, can handle IMAP, POP3, and SMTP-submission. They will run on a different port,⁽¹⁾⁽²⁾ which gives you an opportunity to set separate firewall rules. There, now not worried about affecting legitimate incoming mail traffic, you can be much more strict with security policies. You also have two distinct log streams to look at.

On a separate note, manually whack-a-moling this kind of offenders is IMO futile and, if done lazily, harmful. There are a some repetitive offenders (like 198.55.98.0/24), but most addresses are from botnets: quickly used and equally quickly discarded. This is mostly a fight against noise in logs.⁽³⁾ From security standpoint it’s at best slowing down the attack, but only by the rate at which new addresses join the botnet.

____
⁽¹⁾ Including SMTP-submission, which can run on 587 and 465, instead of 25.
⁽²⁾ Since you’re dealing with your own users only, you can even choose an arbitrary custom port to further reduce log noise.
⁽³⁾ Which is not without value! But we should not have unrealistic expectations.

gattu_marrudu · 2025-09-03 20:16:27

mpan wrote:

If by “public mail server” you mean one available for other people, I can’t offer much. My experience is limited mostly to the single-user case.

I have a single-user server with multiple aliases. I might add a handful of other accounts in the future, either for myself or for trusted friends, but still controlled by a few local accounts.

mpan wrote:

But one thing I can suggest is separating mail transfer and mail submission/retrieval. This way you divide concerns, including protection measures that are very different for each of these services.
In the default configuration Postfix doesn’t allow authentication attempts and only relays mails from a single trusted client (usually localhost, but that can be changed). This takes the entire pile of trouble from your shoulders. All the reverse bruteforce and credential stuffing attacks turn into nothing but log noise.
Then the other service, for example Dovecot, can handle IMAP, POP3, and SMTP-submission. They will run on a different port,⁽¹⁾⁽²⁾ which gives you an opportunity to set separate firewall rules. There, now not worried about affecting legitimate incoming mail traffic, you can be much more strict with security policies. You also have two distinct log streams to look at.

What you are suggesting is using Postfix for relay and Dovecot for both sending and receiving, correct? I currently use postfix for relay and submission, and Dovecot for receiving mail. From what I read in their documentation, SMTP support in Dovecot seems very basic and comes with some big warnings, so I might have to look for a third service to run and configure. Would there still be advantages with that setup vs. using Postfix for SMTP?

mpan · 2025-09-03 21:41:26

The big warnings in Dovecot’s documentation refer to SMTP support being limited to receiving mails for submission, without offering the full STMP service functionality like e.g. Postfix does. That is: it can’t act as a full mail relay. It doesn’t mean there are shortcomings to SMTP implementation in Dovecot, where receiving messages from clients is concerned.

In this case Postfix would act as the relay, but relaying mails to the outside only passed to it from Dovecot.

So yes, the same advantages apply.

Of course this doesn’t have to be Dovecot. It was just an example, since I use it myself and it also handles POP3 and IMAP.

But if it’s only for you and a few trusted people, then the problem of malicious authentication attempts becomes less relevant. If everybody agrees to use strong passphrases, which can be much easier achieved in such a small group, then reverse bruteforce attacks are no risk at all and credentials stuffing has a much smaller impact too.

Arch Linux

#1 2025-09-03 16:25:37

[SOLVED] Blacklisting IP address blocks in Postfix

#2 2025-09-03 16:47:20

Re: [SOLVED] Blacklisting IP address blocks in Postfix

#3 2025-09-03 16:56:49

Re: [SOLVED] Blacklisting IP address blocks in Postfix

#4 2025-09-03 18:52:33

Re: [SOLVED] Blacklisting IP address blocks in Postfix

#5 2025-09-03 18:53:55

Re: [SOLVED] Blacklisting IP address blocks in Postfix

#6 2025-09-03 20:16:27

Re: [SOLVED] Blacklisting IP address blocks in Postfix

#7 2025-09-03 21:41:26

Re: [SOLVED] Blacklisting IP address blocks in Postfix

Board footer