Mastering Imunify360: How to Configure PAM_ABUSE to Stop SMTP & IMAP Brute-Force Attacks

Brute‑force attacks on SMTP and IMAP services are a persistent headache for system administrators, especially on shared‑hosting platforms where a single compromised credential can jeopardize the entire server. Imunify360—the AI‑powered security suite from CloudLinux—includes a robust pam_abuse module that automatically detects and blocks repeated authentication failures, throttling malicious login attempts before they cause damage.

Why pam_abuse Is Essential for Mail Services

Traditional firewalls and intrusion‑prevention systems excel at filtering network‑level threats, but they rarely provide per‑user visibility into authentication failures. When attackers target SMTP (ports 25/587) or IMAP (ports 143/993) with rapid password‑guessing scripts, they can:

• Consume server resources, degrading performance for legitimate users.
• Trigger account lockouts, generating support tickets and user frustration.
• Gain unauthorized access, enabling spam relaying or data exfiltration.

The pam_abuse module plugs directly into the Pluggable Authentication Modules (PAM) stack, giving Imunify360 visibility into every login attempt. Once a configurable threshold of failures is reached, the module automatically bans the offending IP address for a defined period, stopping the attack in its tracks.

Prerequisites: Preparing for Configuration

1. Imunify360 installed and active – Verify the daemon is running with imunify360-agent status.
2. Root or sudo access – All changes require administrative privileges.
3. Mail services using PAM – Most modern Dovecot (IMAP/POP3) and Postfix (SMTP) installations rely on PAM. Confirm by checking /etc/pam.d/dovecot and /etc/pam.d/postfix.
4. Backup configuration files – A quick cp /etc/pam.d/dovecot /etc/pam.d/dovecot.bak (and the same for Postfix) prevents accidental lock‑outs.

Step‑by‑Step: Enabling and Tuning pam_abuse

1. Verify the pam_abuse Module Is Available

Imunify360 ships the pam_imunify360.so library, which contains the abuse‑prevention functionality. Confirm its presence:

ls -l /usr/lib64/security/pam_imunify360.so
# or on 32‑bit systems
ls -l /usr/lib/security/pam_imunify360.so

If the file is missing, reinstall Imunify360:

# RHEL/CentOS
yum reinstall imunify360-agent

# Debian/Ubuntu
apt-get install --reinstall imunify360-agent

2. Add the Module to the PAM Stack for Mail Services

Edit the PAM configuration for Dovecot and Postfix. Insert the pam_imunify360.so line before the sections that perform password verification.

# /etc/pam.d/dovecot
auth    required    pam_imunify360.so   abuse=mail
account required    pam_imunify360.so   abuse=mail

# /etc/pam.d/postfix
auth    required    pam_imunify360.so   abuse=mail
account required    pam_imunify360.so   abuse=mail

The abuse=mail argument tells Imunify360 to treat the service as a mail‑related entry point, applying the appropriate default thresholds.

3. Configure Global pam_abuse Settings

Thresholds are stored in /etc/imunify360/pam_abuse.conf. Open the file with your preferred editor:

nano /etc/imunify360/pam_abuse.conf

Key parameters to adjust:

• max_attempts – Number of failed logins before a ban (default = 5).
• ban_time – Length of the ban in seconds (default = 3600 = 1 hour).
• whitelist_ip – Comma‑separated list of trusted IPs that should never be blocked (e.g., monitoring servers).
• log_level – info or debug for more verbose logging during rollout.

Example of a stricter configuration:

{
    "mail": {
        "max_attempts": 3,
        "ban_time": 7200,
        "whitelist_ip": ["203.0.113.10"],
        "log_level": "info"
    }
}

After saving, reload the Imunify360 daemon so the new settings take effect:

systemctl restart imunify360

4. Test the Protection

From a remote host, deliberately trigger a few failed logins:

openssl s_client -connect mail.example.com:587 -starttls smtp
# Then attempt AUTH LOGIN with an incorrect password three times.

Check the Imunify360 log to confirm the ban:

grep pam_abuse /var/log/imunify360/imunify360.log

You should see an entry similar to:

2026-10-09 12:34:56 INFO pam_abuse: IP 198.51.100.23 banned for 7200 seconds after 3 failed mail authentication attempts.

Attempt another connection from the same IP; the server should refuse it immediately.

Fine‑Tuning and Best Practices

Adjust Thresholds to Match Traffic Patterns

High‑volume environments (large corporate mail servers) often generate legitimate failures—password changes, mobile device sync issues, etc. Consider raising max_attempts to 7 or 10 and shortening ban_time to a few minutes. Conversely, a low‑traffic shared host benefits from tighter limits.

Pair with Fail2Ban for Redundancy

While pam_abuse handles most scenarios, integrating Fail2Ban adds an extra safety net. Configure Fail2Ban to monitor the same Imunify360 log and apply a secondary ban if needed.

Regularly Review Banned IPs

Periodically audit the ban list to ensure no legitimate IPs are caught in the crossfire. Use the Imunify360 CLI:

imunify360-agent banlist

To lift a false positive:

imunify360-agent unban --ip 198.51.100.23

Keep Imunify360 Updated

Security signatures and detection algorithms improve with each release. Schedule regular updates:

# RHEL/CentOS
yum update imunify360-agent

# Debian/Ubuntu
apt-get update && apt-get upgrade imunify360-agent

New releases may introduce additional pam_abuse parameters (e.g., per‑user thresholds) that further refine protection.

Conclusion

Configuring Imunify360’s pam_abuse module for SMTP and IMAP services provides a lightweight yet highly effective shield against brute‑force attacks. By integrating directly with the PAM stack, it can instantly block malicious IPs after a configurable number of failed attempts, preserving server performance and protecting user credentials. Follow the step‑by‑step guide above, fine‑tune thresholds to suit your traffic profile, and monitor the ban list regularly. With Imunify360 handling the heavy lifting, you can focus on delivering reliable email services instead of constantly firefighting authentication attacks.