How To Install DenyHosts on Fedora 42

SSH brute-force attacks pose a constant threat to Linux servers exposed to the internet. Attackers use automated tools to bombard SSH services with thousands of login attempts, trying common usernames and passwords until they gain unauthorized access. DenyHosts offers a straightforward solution to this problem by automatically blocking malicious IP addresses after a specified number of failed authentication attempts. This comprehensive guide walks you through installing, configuring, and optimizing DenyHosts on Fedora 42 to protect your server from these persistent attacks.

DenyHosts is a Python-based log parsing application that monitors SSH authentication logs and adds offending IP addresses to the /etc/hosts.deny file using TCP Wrappers. Unlike firewall-based solutions, DenyHosts works at the application level, making it lightweight and easy to implement. While newer alternatives like Fail2ban have gained popularity, DenyHosts remains effective for dedicated SSH protection and requires minimal system resources.

This tutorial provides detailed, step-by-step instructions for setting up DenyHosts on Fedora 42. You’ll learn installation methods, configuration best practices, troubleshooting techniques, and security hardening strategies to create a robust defense against SSH attacks.

Understanding DenyHosts

What is DenyHosts?

DenyHosts is an open-source intrusion prevention tool specifically designed to protect SSH servers from brute-force attacks. Written entirely in Python, it functions as a daemon that continuously monitors authentication log files for suspicious activity. When DenyHosts detects repeated failed login attempts from a single IP address, it automatically adds that address to the system’s hosts.deny file, effectively blocking all future connection attempts.

The application integrates seamlessly with TCP Wrappers, a host-based networking access control system built into most Linux distributions. This integration allows DenyHosts to leverage existing security infrastructure without requiring kernel modifications or complex firewall rules. The tool maintains its own database of blocked addresses and can optionally synchronize with a global network of DenyHosts installations to share information about known attackers.

How DenyHosts Works

DenyHosts operates through a continuous monitoring cycle. The daemon reads your system’s secure log file, typically located at /var/log/secure on Fedora systems, searching for specific patterns that indicate failed authentication attempts. It distinguishes between different types of failures, including invalid usernames, valid usernames with incorrect passwords, and root login attempts.

When DenyHosts identifies suspicious activity, it increments a counter for the offending IP address. Once this counter reaches a predetermined threshold, DenyHosts appends the IP address to /etc/hosts.deny with a rule that blocks SSH connections. The application maintains several tracking files in its working directory to store information about blocked hosts, failed attempts, and timestamps. This data enables features like automatic expiration of bans after a specified period and whitelisting of trusted addresses.

DenyHosts vs. Fail2ban

Understanding the differences between DenyHosts and Fail2ban helps you make an informed choice for your security needs. DenyHosts uses hosts.deny for blocking, which works through TCP Wrappers at the application level. Fail2ban, conversely, creates firewall rules using iptables or firewalld, blocking traffic at the network layer.

DenyHosts focuses exclusively on SSH protection, making it simpler to configure but less versatile. Fail2ban monitors multiple services including web servers, email servers, and FTP services, providing comprehensive protection across your entire server infrastructure. DenyHosts also lacks IPv6 support, a significant limitation in modern networking environments.

Choose DenyHosts when you need straightforward SSH-only protection with minimal configuration overhead. Its simplicity makes it ideal for administrators managing multiple servers who want consistent, predictable behavior. However, consider Fail2ban if you require multi-service protection, IPv6 support, or more active development and community support.

Prerequisites

Before installing DenyHosts on your Fedora 42 system, ensure you meet these essential requirements. You need a functioning Fedora 42 server or workstation installation with network connectivity. Root privileges or sudo access are mandatory for installing packages and modifying system configuration files.

Your system must have OpenSSH server installed and running, as DenyHosts protects SSH by monitoring its authentication logs. Verify SSH functionality before proceeding with DenyHosts installation to avoid troubleshooting multiple issues simultaneously. Basic command-line proficiency will significantly enhance your ability to follow this guide and troubleshoot potential problems.

An active internet connection enables package downloads from repositories. If you plan to whitelist specific IP addresses, having a static IP for administrative access prevents accidentally locking yourself out of the server. Finally, allocate at least 50MB of free disk space for DenyHosts and its dependencies, though actual requirements typically remain much smaller.

Prepare Your Fedora 42 System

Update System Packages

Begin by updating all installed packages to their latest versions. Open a terminal and execute the following command:

sudo dnf update -y

This command refreshes package repository metadata and upgrades all outdated packages. The -y flag automatically confirms all prompts, streamlining the update process. Maintaining current packages prevents compatibility issues and ensures you benefit from the latest security patches. Wait for the update process to complete before proceeding to the next step.

Verify SSH Service Status

Confirm that OpenSSH server is installed and operational on your Fedora 42 system. Check the service status with:

sudo systemctl status sshd

If the output shows “active (running)” in green text, SSH is functioning correctly. Should the service be inactive or not installed, enable and start it using:

sudo systemctl enable --now sshd

This command simultaneously enables SSH to start at boot and launches it immediately.

Configure your firewall to permit SSH connections. Fedora 42 uses firewalld by default. Execute:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

These commands permanently add SSH to the allowed services list and reload the firewall configuration.

Configure EPEL Repository

DenyHosts may be available through the Extra Packages for Enterprise Linux (EPEL) repository. Check if EPEL is already configured:

dnf repolist | grep epel

If no results appear, install EPEL with:

sudo dnf install epel-release -y

This adds the EPEL repository to your system, expanding available software beyond Fedora’s default repositories. Note that DenyHosts availability varies by Fedora version, and you may need to install from source if no package exists.

Install DenyHosts on Fedora 42

Method 1: Installation via DNF

Attempt installation through the package manager first, as this method offers the simplest setup and automatic dependency resolution. Try installing DenyHosts directly:

sudo dnf install denyhosts -y

If the package exists in your repositories, DNF downloads and installs it along with all required dependencies. Alternatively, explicitly specify the EPEL repository:

sudo dnf --enablerepo=epel install denyhosts -y

Verify successful installation by querying the package database:

rpm -qa | grep denyhosts

This command displays the installed DenyHosts package and version number. If installation fails with “No match for argument: denyhosts,” proceed to the source installation method described below.

Method 2: Installation from Source

When repository packages are unavailable, installing from source ensures you can still deploy DenyHosts. Begin by installing Python 3 and necessary development tools:

sudo dnf install python3 python3-pip python3-setuptools -y

These packages provide the Python runtime and package management tools required by DenyHosts. Install the ipaddr Python module:

sudo pip3 install ipaddr

Download the latest DenyHosts source code from GitHub:

wget https://github.com/denyhosts/denyhosts/archive/master.zip

Extract the downloaded archive:

unzip master.zip
cd denyhosts-master

Run the installation script:

sudo python3 setup.py install

This command compiles and installs DenyHosts to your system. Copy the configuration file to the standard location:

sudo cp denyhosts.conf /etc/

Copy the daemon control script:

sudo cp daemon-control-dist /usr/bin/denyhosts
sudo chmod 755 /usr/bin/denyhosts

These commands install the control script and make it executable.

Verify Installation

Confirm DenyHosts installed correctly by checking its version:

denyhosts --version

Verify the configuration file exists:

ls -l /etc/denyhosts.conf

If both commands return appropriate information, installation succeeded.

Configure DenyHosts

Essential Configuration Settings

DenyHosts configuration resides in /etc/denyhosts.conf, a text file containing all operational parameters. Open this file with your preferred text editor:

sudo nano /etc/denyhosts.conf

Or use vim if you prefer:

sudo vim /etc/denyhosts.conf

The configuration file contains numerous options with detailed comments explaining each parameter.

Critical Configuration Parameters

SECURE_LOG Location

Specify the path to your system’s authentication log file. For Fedora and other Red Hat-based distributions, set:

SECURE_LOG = /var/log/secure

This tells DenyHosts where to find SSH authentication records. Debian-based systems use /var/log/auth.log instead, but Fedora uses /var/log/secure.

HOSTS_DENY File

Configure the location where DenyHosts writes blocked IP addresses:

HOSTS_DENY = /etc/hosts.deny

This standard location ensures compatibility with TCP Wrappers.

BLOCK_SERVICE

Specify which service DenyHosts should protect:

BLOCK_SERVICE = sshd

You can also use “ALL” to block all services, though this is generally not recommended.

DENY_THRESHOLD Settings

These parameters control how many failed attempts trigger a ban. Configure different thresholds for various scenarios:

DENY_THRESHOLD_INVALID = 5
DENY_THRESHOLD_VALID = 10
DENY_THRESHOLD_ROOT = 1
DENY_THRESHOLD_RESTRICTED = 1

DENY_THRESHOLD_INVALID applies to login attempts using non-existent usernames. DENY_THRESHOLD_VALID governs attempts with valid usernames but incorrect passwords. DENY_THRESHOLD_ROOT specifically protects root account access, typically set to 1 for maximum security. DENY_THRESHOLD_RESTRICTED handles attempts on restricted user accounts.

AGE_RESET Parameters

These settings determine how long DenyHosts remembers failed attempts before resetting counters:

AGE_RESET_VALID = 5d
AGE_RESET_ROOT = 25d
AGE_RESET_INVALID = 10d

The “d” suffix indicates days; you can also use “h” for hours, “m” for minutes, or “s” for seconds. Setting these values balances security with usability, preventing permanent bans for occasional mistakes.

Working Directory

Specify where DenyHosts stores its tracking files:

WORK_DIR = /var/lib/denyhosts

This directory contains databases of blocked hosts, timestamps, and other operational data.

Lock File

Configure the PID file location:

LOCK_FILE = /var/run/denyhosts.pid

DenyHosts uses this file to prevent multiple instances from running simultaneously.

Email Notifications

Enable email alerts for blocked hosts by configuring SMTP settings:

ADMIN_EMAIL = your_email@domain.com
SMTP_HOST = localhost
SMTP_PORT = 25
SMTP_FROM = DenyHosts <denyhosts@yourdomain.com>

Replace “your_email@domain.com” with your actual email address. Email notifications keep you informed about attack patterns and blocking activity.

Daemon Mode Settings

Configure DenyHosts daemon behavior:

DAEMON_LOG = /var/log/denyhosts
DAEMON_SLEEP = 30s
DAEMON_PURGE = 1h

DAEMON_LOG specifies the DenyHosts log file location. DAEMON_SLEEP determines how frequently DenyHosts checks the authentication log; 30 seconds provides reasonable responsiveness without excessive resource consumption. DAEMON_PURGE controls how often expired entries are removed from the database.

Save the configuration file after making all necessary changes. Press Ctrl+O then Enter in nano, or :wq in vim.

Configure Whitelist

Why Whitelist is Critical

Whitelisting prevents DenyHosts from blocking trusted IP addresses, including your own administrative connections. Without proper whitelisting, you risk locking yourself out of your server if you mistype your password multiple times. Always configure whitelisting before starting DenyHosts.

Configure /etc/hosts.allow

The hosts.allow file takes precedence over hosts.deny, ensuring whitelisted addresses never get blocked. Open this file:

sudo nano /etc/hosts.allow

Add your trusted IP addresses in the following format:

sshd: 192.168.1.100
sshd: 203.0.113.50
sshd: 198.51.100.0/24

Each line permits SSH connections from the specified IP address or subnet. The third example demonstrates CIDR notation for whitelisting an entire network range. Add as many entries as needed, one per line.

Configure DenyHosts Allowed-Hosts

DenyHosts maintains its own whitelist file for additional protection. Create or edit this file:

sudo nano /var/lib/denyhosts/allowed-hosts

Add trusted IP addresses and hostnames, one per line:

192.168.1.100
203.0.113.50
youroffice.example.com

This ensures DenyHosts never adds these addresses to its internal tracking databases.

Verify TCP Wrappers Configuration

Test your configuration for syntax errors using TCP Wrappers diagnostics:

sudo tcpdchk -v

This command validates hosts.allow and hosts.deny files, reporting any configuration problems. Address any errors before proceeding.

Configure Blacklist (Optional)

Configure /etc/hosts.deny

While DenyHosts automatically populates hosts.deny, you can manually add known malicious IP addresses. Open the file:

sudo nano /etc/hosts.deny

Add entries in the format:

sshd: 198.51.100.50
sshd: 203.0.113.75

Remember that hosts.allow takes precedence over hosts.deny. If an IP appears in both files, the allow rule wins. You can also block all addresses by default:

sshd: ALL

However, this configuration requires explicit whitelisting in hosts.allow for any permitted connections.

Start and Enable DenyHosts Service

Create Systemd Service File

If you installed from source, create a systemd service file for automated management. Create the file:

sudo nano /etc/systemd/system/denyhosts.service

Add the following content:

[Unit]
Description=DenyHosts Service
After=network.target

[Service]
Type=forking
ExecStart=/usr/bin/denyhosts --daemon
PIDFile=/var/run/denyhosts.pid

[Install]
WantedBy=multi-user.target

Save the file and reload systemd to recognize the new service:

sudo systemctl daemon-reload

This command refreshes systemd’s service catalog.

Start DenyHosts Service

Launch the DenyHosts daemon:

sudo systemctl start denyhosts

For systems without systemd integration, use the init script:

sudo /etc/init.d/denyhosts start

Either command initiates DenyHosts monitoring.

Enable DenyHosts at Boot

Configure DenyHosts to start automatically when the system boots:

sudo systemctl enable denyhosts

This creates the necessary symbolic links in systemd’s startup configuration.

Verify DenyHosts is Running

Check the service status:

sudo systemctl status denyhosts

Look for “active (running)” in green, indicating successful operation. Verify the process is running:

ps aux | grep denyhosts

This displays the DenyHosts daemon process. Confirm the PID file exists:

ls -l /var/run/denyhosts.pid

The presence of this file confirms DenyHosts launched successfully.

Monitor and Test DenyHosts

View DenyHosts Logs

Monitoring logs helps you understand DenyHosts activity and verify proper operation. View the DenyHosts log file:

sudo tail -f /var/log/denyhosts

The -f flag provides real-time updates as new entries are written. Monitor the system authentication log simultaneously:

sudo tail -f /var/log/secure

This displays actual SSH authentication attempts as they occur.

Check Blocked IP Addresses

Review currently blocked addresses by examining hosts.deny:

sudo cat /etc/hosts.deny

This file contains all blocked IP addresses, each prefaced with “sshd:”. List DenyHosts working directory contents:

sudo ls -l /var/lib/denyhosts/

This directory contains several tracking files.

Test DenyHosts Functionality

Verify DenyHosts blocks attackers by simulating failed login attempts from a test machine. From another computer, attempt SSH login with an incorrect password:

ssh testuser@your-fedora-ip

Deliberately enter wrong passwords multiple times, exceeding your configured threshold. Monitor the DenyHosts and secure logs on your Fedora server to observe the blocking process. After reaching the threshold, verify the test machine’s IP appears in /etc/hosts.deny:

sudo grep "test-machine-ip" /etc/hosts.deny

Attempt another connection from the blocked IP to confirm it’s rejected.

Understanding DenyHosts Data Files

DenyHosts maintains several files in its working directory, each serving a specific purpose. The “hosts” file contains all currently blocked IP addresses. The “hosts-restricted” file tracks restricted host access attempts. The “hosts-root” file logs failed root login attempts. The “hosts-valid” file records failed attempts for valid usernames. The “users-hosts” file maintains user-specific blocking data. Understanding these files aids troubleshooting and provides insights into attack patterns.

Unblock IP Addresses

Manual IP Unblocking Process

Occasionally you may need to unblock legitimate IP addresses that triggered DenyHosts. Follow this systematic process to ensure complete removal. First, stop the DenyHosts service:

sudo systemctl stop denyhosts

Stopping the daemon prevents it from re-adding the address while you work. Edit hosts.deny to remove the blocked IP:

sudo nano /etc/hosts.deny

Locate and delete the line containing the IP address. Remove the IP from all DenyHosts tracking files:

sudo sed -i '/IP_ADDRESS/d' /var/lib/denyhosts/hosts
sudo sed -i '/IP_ADDRESS/d' /var/lib/denyhosts/hosts-root
sudo sed -i '/IP_ADDRESS/d' /var/lib/denyhosts/hosts-valid
sudo sed -i '/IP_ADDRESS/d' /var/lib/denyhosts/hosts-restricted
sudo sed -i '/IP_ADDRESS/d' /var/lib/denyhosts/users-hosts

Replace “IP_ADDRESS” with the actual IP you’re unblocking. Add the IP to your whitelist:

sudo nano /etc/hosts.allow

Add a line permitting the address. Restart DenyHosts:

sudo systemctl start denyhosts

This completes the unblocking process.

Automated Unblocking Script

Create a shell script to streamline unblocking operations. Save this as unblock-ip.sh:

#!/bin/bash
IP=$1
sudo systemctl stop denyhosts
sudo sed -i "/$IP/d" /etc/hosts.deny
sudo sed -i "/$IP/d" /var/lib/denyhosts/hosts*
echo "sshd: $IP" | sudo tee -a /etc/hosts.allow
sudo systemctl start denyhosts
echo "IP $IP unblocked and whitelisted"

Make the script executable:

chmod +x unblock-ip.sh

Use it by specifying the IP address as an argument.

Prevent Future Blocking

To avoid repeatedly unblocking the same addresses, add them to your whitelist proactively. If legitimate users trigger blocks frequently, review and adjust your DENY_THRESHOLD settings to be more permissive.

Troubleshooting Common Issues

DenyHosts Not Starting

If DenyHosts fails to start, examine recent log entries for error messages:

sudo journalctl -u denyhosts -n 50

This displays the last 50 log entries for the DenyHosts service. Common startup failures include configuration syntax errors; carefully review denyhosts.conf for typos. Missing Python dependencies also prevent startup; reinstall required modules. Incorrect file permissions on the working directory cause failures; ensure /var/lib/denyhosts is accessible.

IP Keeps Getting Re-Added to Blacklist

When an unblocked IP immediately reappears in hosts.deny, authentication log entries continue triggering DenyHosts. The secure log retains old failed attempts that DenyHosts reads during its monitoring cycle. Clear these entries by rotating logs:

sudo logrotate -f /etc/logrotate.conf

Verify the IP appears in the allowed-hosts file:

sudo grep "IP_ADDRESS" /var/lib/denyhosts/allowed-hosts

Ensure no conflicting entries exist in your configuration. Confirm hosts.allow includes the IP with correct syntax.

DenyHosts Not Blocking Attackers

When DenyHosts fails to block obvious attacks, verify the SECURE_LOG path matches your actual log file location. Check if SSH logs authentication attempts:

sudo grep "Failed password" /var/log/secure

If no entries appear, SSH logging may be disabled or misconfigured. Ensure your threshold settings aren’t too permissive; attackers may stay below your configured limits. Verify TCP Wrappers is functioning:

sudo ldd /usr/sbin/sshd | grep wrap

This confirms SSH was compiled with TCP Wrappers support.

Email Notifications Not Working

Email notification failures typically stem from SMTP configuration issues. Test your mail server:

sudo systemctl status postfix

Ensure the mail service runs correctly. Verify ADMIN_EMAIL contains a valid address. Check SMTP_HOST, SMTP_PORT, and SMTP_FROM settings in denyhosts.conf. Test email delivery manually:

echo "Test email" | mail -s "DenyHosts Test" your_email@domain.com

DenyHosts Stopped Working After Update

System updates occasionally break DenyHosts functionality. Reinstall DenyHosts to resolve compatibility issues. Check for SELinux denials on Fedora:

sudo ausearch -m avc -ts recent

SELinux may block DenyHosts from modifying system files. Verify the systemd service file remains valid after updates. Review DenyHosts logs immediately following the update to identify specific errors.

Advanced Configuration

Customize Blocking Thresholds

Tailor thresholds to match your specific security requirements and user behavior patterns. High-security environments benefit from aggressive settings:

DENY_THRESHOLD_INVALID = 3
DENY_THRESHOLD_VALID = 5
DENY_THRESHOLD_ROOT = 1

Environments with less sophisticated threats can use more permissive values:

DENY_THRESHOLD_INVALID = 10
DENY_THRESHOLD_VALID = 15
DENY_THRESHOLD_ROOT = 3

Configure different thresholds for specific user types to balance security and usability.

Integrate with Email Alerts

Enhance monitoring capabilities through detailed email notifications. Configure comprehensive SMTP settings:

ADMIN_EMAIL = security@yourdomain.com
SMTP_HOST = mail.yourdomain.com
SMTP_PORT = 587
SMTP_USERNAME = denyhosts@yourdomain.com
SMTP_PASSWORD = your_password
SMTP_FROM = DenyHosts Security <denyhosts@yourdomain.com>
SMTP_SUBJECT = [DenyHosts] Security Alert

Set email frequency to avoid inbox flooding:

DAEMON_LOG_MESSAGE_FORMAT = %(asctime)s - %(name)s - %(message)s

Customize message templates to include relevant details about blocked hosts.

Synchronize Blocked Hosts Across Multiple Servers

DenyHosts can participate in a synchronized network where servers share information about attackers. Enable synchronization:

SYNC_SERVER = http://xmlrpc.denyhosts.net:9911
SYNC_INTERVAL = 1h
SYNC_UPLOAD = yes
SYNC_DOWNLOAD = yes
SYNC_DOWNLOAD_THRESHOLD = 3

This configuration connects to the public DenyHosts sync server, uploading your blocked hosts and downloading others’ data. The SYNC_DOWNLOAD_THRESHOLD determines how many servers must report an IP before you block it. Synchronization creates a collective defense mechanism, providing protection against emerging threats.

Configure Automatic Purging

Automatically remove old blocks to prevent hosts.deny from growing indefinitely. Enable purging:

PURGE_DENY = 4w
PURGE_THRESHOLD = 0

These settings automatically remove blocks after four weeks. PURGE_THRESHOLD controls additional purging criteria; zero means age-based purging only. Balance security requirements against the possibility of persistent attackers returning after purge periods.

SELinux Configuration for Fedora 42

Fedora’s SELinux security framework may restrict DenyHosts operations. Check SELinux status:

sudo sestatus

If SELinux is enforcing, configure appropriate policies. Allow DenyHosts to modify hosts.deny:

sudo semanage fcontext -a -t etc_t "/etc/hosts.deny"
sudo restorecon -v /etc/hosts.deny

Grant DenyHosts necessary permissions:

sudo setsebool -P allow_ypbind 1

Monitor for SELinux denials and create custom policies as needed.

Security Best Practices

Layer DenyHosts with Other Security Measures

DenyHosts provides valuable protection but should never constitute your sole security measure. Implement defense in depth by combining multiple security layers. Strong password policies force users to create complex, difficult-to-guess passwords. Password complexity requirements, minimum length standards, and regular rotation schedules significantly enhance security.

Enable SSH Key-Based Authentication

SSH keys provide dramatically stronger authentication than passwords. Generate an SSH key pair on your client machine:

ssh-keygen -t ed25519 -C "your_email@domain.com"

Copy the public key to your Fedora server:

ssh-copy-id yourusername@your-fedora-ip

Test key-based login before disabling passwords. Once verified, disable password authentication in /etc/ssh/sshd_config:

PasswordAuthentication no

Restart SSH for changes to take effect.

Change Default SSH Port

Changing SSH from the default port 22 dramatically reduces automated attack traffic. Edit /etc/ssh/sshd_config:

Port 2222

Update firewall rules to permit the new port:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Configure SELinux to permit SSH on the custom port:

sudo semanage port -a -t ssh_port_t -p tcp 2222

Restart SSH to apply changes.

Disable Root Login via SSH

Preventing direct root login via SSH eliminates a primary attack target. Configure sshd_config:

PermitRootLogin no

Use sudo for administrative tasks instead. This forces attackers to compromise two factors: a valid username and its password, then separate credentials for privilege escalation.

Implement Additional SSH Hardening

Further restrict SSH access using allowlists. Configure specific user access in sshd_config:

AllowUsers admin1 admin2

Only listed users can authenticate via SSH. Disable old protocol versions:

Protocol 2

Configure idle session timeouts:

ClientAliveInterval 300
ClientAliveCountMax 2

These settings disconnect idle sessions after 10 minutes. Enable two-factor authentication for maximum security.

Regular Monitoring and Maintenance

Establish routine monitoring practices to maintain effective security. Review blocked IP lists weekly:

sudo wc -l /etc/hosts.deny

Analyze DenyHosts logs for attack patterns and trends. Schedule monthly configuration reviews to ensure settings remain appropriate for current threat levels. Keep your system and security software updated through regular maintenance windows. Update whitelists as your infrastructure changes to prevent service disruptions.

Congratulations! You have successfully installed DenyHosts. Thanks for using this tutorial for installing DenyHosts on the Fedora 42 Linux system. For additional help or useful information, we recommend you check the official DenyHosts website.