Npm

Here’s a step-by-step guide to set up Fail2ban to protect your Docker applications behind Nginx Proxy Manager (NPM), which is acting as a reverse proxy. The logs for NPM are located at /dockge/npm/data/logs/, and I’ll assume this directory is accessible on the host system where Fail2ban will run. This setup will focus on protecting against common attacks, such as failed authentication attempts and excessive 404 errors, by monitoring NPM’s logs.

Prerequisites

Fail2ban Installed: Ensure Fail2ban is installed on the host system, as it needs to manage firewall rules (e.g., iptables) to block malicious IPs. Install it with:

bash
```
sudo apt update && sudo apt install fail2ban  # For Debian/Ubuntu-based systems
sudo yum install fail2ban                    # For CentOS/RHEL-based systems
```
NPM Logs Accessible: The logs at /dockge/npm/data/logs/ should be available on the host. If NPM runs in a Docker container, this directory is likely a mounted volume from the host (e.g., via a -v /dockge/npm/data/logs:/path/in/container in your Docker configuration). Verify this path exists and contains log files like error.log or access.log.
Log Files Identified: NPM, being based on Nginx, typically generates access.log (all requests) and error.log (errors, including failed authentication attempts). Check /dockge/npm/data/logs/ to confirm the exact file names.

Step 1: Understand the Setup

NPM acts as a reverse proxy, handling incoming requests to your Docker applications. Fail2ban will monitor NPM’s logs to detect malicious activity (e.g., brute-force login attempts or probing for vulnerabilities) and ban offending IP addresses by updating the host’s firewall rules. Since the logs are in /dockge/npm/data/logs/, Fail2ban will read them from this location on the host.

Step 2: Configure Fail2ban Jails

Fail2ban uses "jails" to define what logs to monitor, what patterns to look for (via filters), and what actions to take (e.g., banning IPs). We’ll set up two jails:

Authentication Protection: Monitor the error log for failed basic authentication attempts (common if NPM enforces basic auth).
Bot Protection: Monitor the access log for excessive 404 errors (indicating potential vulnerability scanning).

Jail Configuration File

Create a new configuration file for NPM in Fail2ban’s jail directory:

bash

sudo nano /etc/fail2ban/jail.d/npm.conf

Add the following content:

ini

[npm-http-auth]
enabled  = true
port     = http,https
filter   = nginx-http-auth
logpath  = /dockge/npm/data/logs/*_error.log
maxretry = 5
findtime = 3600
bantime  = 86400

[npm-botsearch]
enabled  = true
port     = http,https
filter   = nginx-botsearch
logpath  = /dockge/npm/data/logs/*_access.log
maxretry = 10
findtime = 3600
bantime  = 86400

Explanation:

[npm-http-auth]:
- enabled = true: Activates this jail.
- port = http,https: Protects traffic on ports 80 and 443 (adjust if NPM uses different ports).
- filter = nginx-http-auth: Uses Fail2ban’s built-in filter to detect failed basic auth attempts in error logs (e.g., "user not found" or "password mismatch").
- logpath = /dockge/npm/data/logs/*_error.log: Monitors all error logs (using a wildcard to catch files like error.log, app1_error.log, etc.).
- maxretry = 5: Bans an IP after 5 failed attempts.
- findtime = 3600: Looks for those 5 attempts within 1 hour (3600 seconds).
- bantime = 86400: Bans the IP for 1 day (86400 seconds).
[npm-botsearch]:
- Similar to above, but uses the nginx-botsearch filter to detect excessive 404 errors in access logs.
- logpath = /dockge/npm/data/logs/*_access.log: Monitors all access logs.
- maxretry = 10: Allows more retries (10) since 404s might occur legitimately.

Adjust maxretry, findtime, and bantime based on your security needs (e.g., stricter settings for sensitive applications).

Step 3: Verify Log Files and Filters

Check Log Files: List the contents of /dockge/npm/data/logs/:

bash
```
ls -l /dockge/npm/data/logs/
```
Confirm that files like error.log or access.log (or similar, e.g., proxy_error.log) exist. If names differ, update logpath in the jail config accordingly.
Filter Compatibility: Fail2ban’s default filters (nginx-http-auth and nginx-botsearch) expect standard Nginx log formats:
- Error Log Example (for nginx-http-auth):
```
2023/10/10 13:55:36 [error] 2846#0: *1 user "user" was not found in "/etc/nginx/htpasswd", client: 192.168.1.1
```
- Access Log Example (for nginx-botsearch):
```
192.168.1.1 - - [10/Oct/2023:13:55:36 +0000] "GET /nonexistent HTTP/1.1" 404 612
```
If NPM’s logs differ, create custom filters in /etc/fail2ban/filter.d/ (e.g., npm-http-auth.conf) by copying and modifying the defaults:

bash

sudo cp /etc/fail2ban/filter.d/nginx-http-auth.conf /etc/fail2ban/filter.d/npm-http-auth.conf

Edit the failregex to match your log patterns, then update the jail to use filter = npm-http-auth.

Step 4: Apply and Test the Configuration

Restart Fail2ban:

bash
```
sudo systemctl restart fail2ban
```
Check Status:

bash
```
sudo fail2ban-client status
```
List active jails (e.g., npm-http-auth, npm-botsearch).

Verify Specific Jails:

bash

sudo fail2ban-client status npm-http-auth
sudo fail2ban-client status npm-botsearch

This shows monitored logs and banned IPs (if any).

Review Logs: Check /var/log/fail2ban.log for errors:

bash
```
sudo tail -f /var/log/fail2ban.log
```

Step 5: Additional Considerations

Permissions: Ensure Fail2ban can read the logs:

bash

sudo ls -l /dockge/npm/data/logs/
sudo chmod -R o+r /dockge/npm/data/logs/  # If needed

Docker Networking: Since NPM and your applications run in Docker, banning IPs at the host level (via iptables) should block traffic before it reaches NPM, assuming standard bridge networking and host-exposed ports (e.g., 80, 443).
Multiple Applications: The wildcard logpath monitors all logs in /dockge/npm/data/logs/. If NPM separates logs per application, this protects all of them. For granular control, create separate jails per log file.

Final Notes

This setup protects your Docker applications by leveraging NPM’s logs to detect and block malicious IPs. If NPM doesn’t handle authentication (and backends do), you may need to monitor backend logs instead, but since the query specifies NPM’s logs, this configuration assumes NPM’s role includes logging relevant security events.

Test the setup by simulating failed logins or 404 requests (e.g., with curl) and verify that IPs get banned. Adjust filters or parameters as needed based on your specific log formats and security requirements.

Wordpress