Login Failure Detection (LFD) for Linux: Configuration Guide

What Is Login Failure Detection (LFD)?

Login Failure Detection — commonly known as LFD — is a daemon process that continuously monitors authentication logs on a Linux server and takes automated action when suspicious patterns are detected. When an IP address exceeds a configured number of failed login attempts within a given time window, LFD blocks that IP at the firewall level, preventing further access to any service on the server.

LFD is one of the most critical components of server security. Without it, attackers can make unlimited login attempts against SSH, FTP, email, and web services. Brute-force attacks against these services are relentless — a typical internet-facing server receives thousands of unauthorized login attempts per day, the majority automated by botnets scanning every reachable IP address.

VistoShield’s Server Edition includes a full-featured LFD daemon that monitors all major server services simultaneously and integrates with the iptables/nftables firewall for instant, kernel-level blocking. This guide covers the complete configuration of LFD on a Linux server using VistoShield.

How LFD Works: The Technical Process

Understanding how LFD operates helps you configure it effectively. The process follows these steps:

1. Log monitoring: The LFD daemon watches authentication log files in real time using inotify (or polling as a fallback). On most distributions, the relevant files are /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS/Alma/Rocky).
2. Pattern matching: Each new log line is evaluated against a set of regular expressions that identify failed authentication attempts for each monitored service. Different services log failures in different formats.
3. Tracking: When a failed attempt is detected, LFD records the source IP, the service, and the timestamp in an in-memory tracking table.
4. Threshold evaluation: The daemon checks whether the accumulated failures for that IP (across one or all services) have exceeded the configured threshold within the time window.
5. Blocking: If the threshold is exceeded, LFD executes an iptables/nftables rule to DROP all packets from the offending IP address. The block is recorded in a persistent block list.
6. Notification: Optionally, an email alert is sent to the administrator with details about the block including the IP, the service, the number of failures, and a whois lookup.

Services Monitored by VistoShield LFD

VistoShield LFD monitors a comprehensive set of Linux server services. Each service has its own failure threshold, allowing you to fine-tune sensitivity based on the expected usage patterns of each service.

Installing VistoShield LFD

LFD is included as part of the VistoShield Server Edition. If you have already installed it, LFD is running by default. If not:

# Install VistoShield Server Edition
curl -sSL https://vistoshield.com/install.sh | bash

# Verify LFD is running
systemctl status vistoshield-lfd

# Check current block count
vistoshield --lfd-status

For detailed installation instructions and system requirements, visit the Getting Started documentation.

Configuration File Structure

LFD settings are stored in the main VistoShield configuration file at /etc/vistoshield/vistoshield.conf. The configuration uses a simple KEY = VALUE format. All LFD-related settings are prefixed with LF_ for easy identification.

# Main LFD enable/disable
LF_DAEMON = 1

# Global trigger (failures across ALL services)
LF_TRIGGER = 0

# Per-service triggers
LF_SSHD = 5
LF_FTPD = 10
LF_SMTPAUTH = 5
LF_POP3D = 10
LF_IMAPD = 10
LF_HTACCESS = 5
LF_MODSEC = 5
LF_WORDPRESS = 5

# Trigger time interval (seconds)
LF_INTERVAL = 3600

# Block type
LF_TEMP_BAN = 1
LF_TEMP_BAN_TIME = 3600
LF_TEMP_BAN_LIMIT = 5
LF_PERMBLOCK = 1
LF_PERMBLOCK_INTERVAL = 86400
LF_PERMBLOCK_COUNT = 5

# Notifications
LF_EMAIL_ALERT = 1
LF_ALERT_TO = admin@yourdomain.com
LF_ALERT_FROM = lfd@yourdomain.com

After making changes, reload the configuration:

vistoshield --restart-lfd
# or
systemctl restart vistoshield-lfd

Configuring Thresholds: Finding the Right Balance

Setting thresholds is a balancing act between security and usability. Thresholds that are too low cause false positives (blocking legitimate users who mistype passwords); thresholds that are too high allow attackers more attempts before being blocked.

Recommended Thresholds by Service

SSH (LF_SSHD = 5)

SSH is the highest-value target on any Linux server. Root access via SSH provides complete control over the system. A threshold of 5 is appropriate because:

• Legitimate SSH users typically use key-based authentication (zero password failures)
• Even password-based SSH users rarely exceed 2–3 failures
• SSH brute-force bots typically test hundreds of credentials at high speed

Best practice: Disable password authentication for SSH entirely and use key-based authentication. Even with key-based auth, keep LFD monitoring SSH because it catches bots that probe for password-based access and wastes their resources.

FTP (LF_FTPD = 10)

FTP clients sometimes retry failed connections automatically, and users may have outdated credentials saved in FTP clients. A slightly higher threshold of 10 accommodates this while still blocking brute-force attacks quickly.

Best practice: Consider migrating from FTP to SFTP (which runs over SSH) to eliminate one attack surface entirely.

Email Services (LF_POP3D = 10, LF_IMAPD = 10)

Email clients are particularly prone to generating false positives because they check for new mail at regular intervals. If a user changes their password but forgets to update their email client, the client will generate a failed login attempt every few minutes. A threshold of 10 allows time for the user to realize the issue.

WordPress (LF_WORDPRESS = 5)

WordPress login attacks are extremely common and highly automated. A threshold of 5 is aggressive enough to stop brute-force bots while allowing legitimate users a reasonable number of retries. This works in conjunction with the Login Guard plugin which adds rate limiting and 2FA at the application level.

Temporary vs Permanent Blocking Strategy

VistoShield LFD supports a graduated blocking strategy that handles both one-time offenders and persistent attackers appropriately.

Temporary Blocks

When LF_TEMP_BAN = 1, first-time offenders are blocked for a limited duration specified by LF_TEMP_BAN_TIME (in seconds). After the timeout, the block is automatically removed and the IP can access the server again. This is suitable for:

• Legitimate users who trigger the threshold accidentally
• Shared IP addresses (NAT) where one user’s failures should not permanently block others
• Dynamic IPs that may be reassigned to different users over time

Escalation to Permanent Blocks

When LF_PERMBLOCK = 1, IPs that accumulate LF_PERMBLOCK_COUNT temporary blocks within LF_PERMBLOCK_INTERVAL seconds are permanently blocked. This catches persistent attackers who rotate their attacks to stay just under the temporary block duration.

# Example: Permanent block after 5 temporary blocks within 24 hours
LF_PERMBLOCK = 1
LF_PERMBLOCK_INTERVAL = 86400
LF_PERMBLOCK_COUNT = 5

The Allow List: Preventing Self-Lockout

One of the most common concerns with LFD is accidentally blocking yourself or critical services. VistoShield uses an allow list file at /etc/vistoshield/csf.allow to prevent this.

# Always allow your office IP
203.0.113.50  # Main office
203.0.113.51  # Backup office

# Always allow monitoring services
198.51.100.0/24  # UptimeRobot range

# Always allow the server's own IPs
# (Added automatically during installation)

IPs in the allow list are never blocked by LFD, regardless of how many failures they generate. This does not mean failures are ignored — they are still logged and reported — but no blocking action is taken.

Critical rule: Always add your own IP to the allow list before enabling LFD. If you are locked out, you will need console access or an out-of-band connection to recover.

Advanced LFD Features

Process Tracking

Beyond login failures, VistoShield LFD can detect suspicious processes running on the server:

• PT_USERMEM: Alert when a user’s processes exceed a memory threshold (catches cryptominers)
• PT_USERTIME: Alert on excessive CPU usage per user
• PT_LIMIT: Maximum number of processes per user before alerting
• PT_DELETED: Detect processes running from deleted executables (common malware behavior)

Connection Tracking

LFD monitors active connections and alerts on suspicious patterns:

• CT_LIMIT: Maximum number of connections from a single IP
• CT_INTERVAL: Time window for connection counting
• CT_PORTS: Restrict connection tracking to specific ports

Directory Watching

LFD can monitor specified directories for new or modified files, alerting on potential web shell uploads or unauthorized file changes:

# Watch the /tmp directory for suspicious scripts
LF_DIRWATCH = 1
LF_DIRWATCH_FILE = /tmp;/var/tmp;/dev/shm

Integrity Checking

VistoShield LFD performs periodic integrity checks on critical system files, alerting if they are modified unexpectedly. This detects rootkits and unauthorized system modifications.

Monitoring LFD Activity

Effective security requires monitoring. VistoShield provides several tools for tracking LFD activity.

Command-Line Tools

# View current blocked IPs
vistoshield --deny-list

# View recent LFD blocks
vistoshield --lfd-log | tail -50

# Check how many IPs are blocked
vistoshield --deny-count

# Unblock an IP
vistoshield --unblock 192.168.1.100

# View block details for a specific IP
vistoshield --lookup 192.168.1.100

Control Panel Integration

If you are using a hosting control panel, the VistoShield module provides a graphical view of all LFD activity. Available for cPanel, DirectAdmin, and Webmin, the panel module shows blocked IPs, block reasons, and allows one-click unblocking.

Email Alerts

When configured, LFD sends detailed email alerts for each block including:

• The blocked IP address and its whois information
• The service that was attacked (SSH, FTP, etc.)
• The number of failures that triggered the block
• Whether the block is temporary or permanent
• The log lines that triggered the block

LFD and WordPress: Bridging Server and Application

One of VistoShield’s unique capabilities is bridging server-level LFD with WordPress login protection. When a WordPress login failure occurs, the Login Guard plugin writes the failure to a log file that the server-level LFD daemon monitors. If the threshold is exceeded, the IP is blocked at the iptables level — not just at the WordPress PHP level.

This means WordPress brute-force attacks are handled by the kernel firewall, consuming virtually zero server resources regardless of attack volume. This is a significant advantage over WordPress-only security plugins that must process every attack request through the full PHP stack. For more on this architecture, see our article on WordPress login protection.

Troubleshooting Common LFD Issues

Legitimate Users Being Blocked

If legitimate users report being blocked, check the LFD log to identify the cause:

vistoshield --lfd-log | grep "192.168.1.100"

Common causes include outdated email client passwords, FTP clients with saved wrong credentials, and automated scripts using expired API keys. Solutions include adding the user’s IP to the allow list or increasing the relevant service threshold.

LFD Not Detecting Failures

If attacks are not being blocked, verify that LFD can read the correct log files. Different distributions use different log paths. Check the VistoShield configuration for the correct log paths:

# Verify log file paths in the configuration
grep "HTACCESS_LOG\|SSHD_LOG\|FTPD_LOG" /etc/vistoshield/vistoshield.conf

High Memory Usage

On servers with very high traffic, the in-memory tracking table can consume significant memory. Reduce the LF_INTERVAL value to shorten the tracking window, or increase the LF_TRIGGER values to reduce the number of tracked entries.

LFD Best Practices Summary

After years of operating LFD across thousands of servers, the following best practices have proven most effective:

• Enable LFD on every internet-facing server. There is no legitimate reason to expose authentication services to unlimited brute-force attempts. The performance overhead of LFD is negligible compared to the resource consumption of unblocked attacks.
• Use key-based SSH authentication and keep LFD monitoring SSH as a detection mechanism. Even with key-based auth, LFD catches bots probing for password-based access.
• Set conservative thresholds for high-value services (SSH: 5, SMTP: 5, WordPress: 5) and slightly higher thresholds for services prone to legitimate failures (POP3: 10, IMAP: 10, FTP: 10).
• Always populate the allow list first. Before enabling LFD, add your own IP addresses, monitoring services, and any business-critical IP ranges. This prevents self-lockout and ensures critical services are never interrupted.
• Enable graduated blocking. Temporary blocks handle accidental lockouts gracefully, while permanent block escalation ensures persistent attackers are dealt with decisively.
• Review logs regularly. LFD logs provide valuable intelligence about who is attacking your server, which services they target, and where they come from. Use this data to inform additional security measures like country blocking or targeted port restrictions.
• Integrate with WordPress. If your server hosts WordPress sites, the Login Guard plugin bridges WordPress authentication failures to the server-level LFD, providing iptables-level blocking for WordPress brute-force attacks.

Key Takeaways

• LFD is essential for any internet-facing Linux server. Without it, brute-force attacks proceed unchecked against all authentication services.
• Configure per-service thresholds to balance security and usability. Different services have different legitimate failure patterns.
• Use graduated blocking (temporary then permanent) to handle both accidental lockouts and persistent attackers.
• Always maintain an allow list with your own IPs, monitoring services, and critical infrastructure IPs.
• VistoShield bridges server and WordPress security, enabling iptables-level blocking for WordPress login attacks — a capability unique to its dual-layer architecture.
• Refer to the LFD documentation for the complete configuration reference and the Commands reference for all available CLI tools.