Server Hardening: Security Best Practices from Log Analysis

Setting Up Log-Based Intrusion Detection

A proper log-based intrusion detection system (IDS) goes beyond ad-hoc grep commands. It requires structured collection, pattern matching, and alerting. Here is how to build one from the ground up.

Step 1: Centralize Your Logs

The first requirement is getting all logs into a single location where they can be correlated. Attackers often touch multiple services -- an SSH brute force may precede a web application exploit, which may precede privilege escalation.

# /etc/rsyslog.d/50-remote.conf
# Forward all logs to a central syslog server
*.* @@logserver.internal:514

# Or use journald to forward to a central location
# /etc/systemd/journal-upload.conf
[Upload]
URL=https://logserver.internal:19532
ServerKeyFile=/etc/ssl/private/journal-upload.pem
ServerCertificateFile=/etc/ssl/certs/journal-upload.pem
TrustedCertificateFile=/etc/ssl/ca/ca.pem

Step 2: Define Detection Rules

Create a structured rule set that maps log patterns to security events. Here is a Python-based detection engine that processes multiple log sources:

#!/usr/bin/env python3
"""Simple log-based intrusion detection system."""
import re
import sys
from collections import defaultdict
from datetime import datetime, timedelta

# Detection rules: (name, log_pattern, threshold, window_seconds, severity)
RULES = [
    {
        'name': 'SSH Brute Force',
        'pattern': re.compile(r'Failed password.*from (\d+\.\d+\.\d+\.\d+)'),
        'threshold': 10,
        'window': 300,
        'severity': 'CRITICAL',
        'group_by': 'ip',  # group by captured IP
    },
    {
        'name': 'HTTP Login Brute Force',
        'pattern': re.compile(r'(\d+\.\d+\.\d+\.\d+).*POST.*/(?:login|signin|wp-login).*(?:401|403)'),
        'threshold': 20,
        'window': 60,
        'severity': 'CRITICAL',
        'group_by': 'ip',
    },
    {
        'name': 'SQL Injection Attempt',
        'pattern': re.compile(r'(\d+\.\d+\.\d+\.\d+).*(?:union.*select|or\+1=1|drop\+table|sleep\(\d)', re.I),
        'threshold': 3,
        'window': 600,
        'severity': 'HIGH',
        'group_by': 'ip',
    },
    {
        'name': 'Path Traversal',
        'pattern': re.compile(r'(\d+\.\d+\.\d+\.\d+).*\.\.(?:/|%2f|%252f)', re.I),
        'threshold': 5,
        'window': 300,
        'severity': 'HIGH',
        'group_by': 'ip',
    },
    {
        'name': 'Vulnerability Scanner',
        'pattern': re.compile(r'(\d+\.\d+\.\d+\.\d+).*(?:\.env|wp-admin|phpmyadmin|actuator|\.git/config)', re.I),
        'threshold': 5,
        'window': 600,
        'severity': 'HIGH',
        'group_by': 'ip',
    },
    {
        'name': 'Privilege Escalation',
        'pattern': re.compile(r'sudo:.*COMMAND=.*(chmod\+s|chown.*root|passwd|useradd|visudo)'),
        'threshold': 1,
        'window': 60,
        'severity': 'CRITICAL',
        'group_by': 'all',
    },
]

class LogIDS:
    def __init__(self):
        self.events = defaultdict(list)  # rule_name -> [(timestamp, group_key)]
        self.alerts = []

    def process_line(self, line, timestamp=None):
        if timestamp is None:
            timestamp = datetime.now()
        for rule in RULES:
            match = rule['pattern'].search(line)
            if match:
                group_key = match.group(1) if rule['group_by'] == 'ip' else 'global'
                event_key = f"{rule['name']}:{group_key}"

                # Add event and prune old entries
                cutoff = timestamp - timedelta(seconds=rule['window'])
                self.events[event_key] = [
                    t for t in self.events[event_key] if t > cutoff
                ]
                self.events[event_key].append(timestamp)

                # Check threshold
                if len(self.events[event_key]) >= rule['threshold']:
                    alert = {
                        'rule': rule['name'],
                        'severity': rule['severity'],
                        'source': group_key,
                        'count': len(self.events[event_key]),
                        'window': rule['window'],
                        'timestamp': timestamp,
                    }
                    self.alerts.append(alert)
                    self.events[event_key] = []  # reset after alert
                    print(f"[{rule['severity']}] {rule['name']}: "
                          f"{group_key} - {alert['count']} events in "
                          f"{rule['window']}s", file=sys.stderr)

    def report(self):
        print(f"\n=== INTRUSION DETECTION REPORT ===")
        print(f"Total alerts: {len(self.alerts)}\n")
        for alert in sorted(self.alerts, key=lambda a: a['timestamp']):
            print(f"  [{alert['severity']}] {alert['rule']}")
            print(f"    Source: {alert['source']}")
            print(f"    Events: {alert['count']} in {alert['window']}s window")
            print(f"    Time: {alert['timestamp']}")
            print()

if __name__ == "__main__":
    ids = LogIDS()
    for log_file in sys.argv[1:]:
        with open(log_file) as f:
            for line in f:
                ids.process_line(line.strip())
    ids.report()

Step 3: Establish Baselines

Detection rules need context. A server that normally sees 5 failed SSH logins per day should alert at 20. A server that handles 500 legitimate failures per day (large user base) might need a threshold of 2,000. Baseline your normal activity before setting thresholds:

# Baseline SSH failures per day over the last 30 days
for i in $(seq 0 29); do
    date_str=$(date -d "$i days ago" +%b\ %e)
    count=$(grep "$date_str" /var/log/auth.log | grep -c "Failed password")
    echo "$(date -d "$i days ago" +%Y-%m-%d): $count failures"
done

# Baseline HTTP error rates per hour
awk '{print substr($4, 2, 14)}' /var/log/nginx/access.log | \
  sort | uniq -c | awk '{print $2, $1}' > /tmp/hourly_baseline.txt

# Calculate mean and standard deviation for anomaly detection
awk '{sum+=$2; sumsq+=$2*$2; n++}
     END {mean=sum/n; sd=sqrt(sumsq/n - mean*mean);
          print "Mean:", mean, "StdDev:", sd, "Alert threshold (3-sigma):", mean+3*sd}' \
  /tmp/hourly_baseline.txt

Identifying Vulnerability Scanners and Their Signatures

Vulnerability scanners are among the noisiest attackers in your logs. Automated tools like Nikto, Nmap, Nessus, OpenVAS, and custom scripts systematically probe your server for known weaknesses. Detecting them early tells you someone is mapping your attack surface -- an intrusion may follow.

Scanner Fingerprints in Access Logs

Each scanner leaves characteristic patterns. Here are the most common signatures:

# Detect known vulnerability scanners
grep -iE "(nikto|nmap|sqlmap|wpscan|acunetix|nessus|openvas|ZAP)" \
  /var/log/nginx/access.log | awk '{print $1}' | sort -u

# Detect scanner behavior: IPs with high 404 rates on admin paths
awk '$9 == 404 && $7 ~ /(\.env|wp-admin|phpmyadmin|\.git|actuator|config|backup|admin)/ {
    print $1
}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Comprehensive scanner detection: IPs requesting many non-existent paths
awk '$9 == 404 {ips[$1]++} END {for(ip in ips) if(ips[ip]>50) print ips[ip], ip}' \
  /var/log/nginx/access.log | sort -rn

Building a Scanner Detection Script

#!/usr/bin/env python3
"""Detect vulnerability scanner activity from access logs."""
import re
import sys
from collections import defaultdict

# Paths that scanners commonly probe
SCANNER_PATHS = {
    '/.env', '/.git/config', '/.git/HEAD', '/.svn/entries',
    '/wp-admin/', '/wp-login.php', '/xmlrpc.php', '/wp-config.php',
    '/phpmyadmin/', '/pma/', '/myadmin/', '/mysql/',
    '/admin/', '/administrator/', '/manager/', '/console/',
    '/actuator/', '/actuator/health', '/actuator/env',
    '/solr/', '/jenkins/', '/jmx-console/',
    '/server-status', '/server-info', '/.htaccess', '/.htpasswd',
    '/backup.sql', '/dump.sql', '/database.sql', '/db.sql',
    '/config.php', '/configuration.php', '/settings.php',
    '/phpinfo.php', '/info.php', '/test.php',
    '/api/v1/admin', '/graphql', '/api/swagger',
    '/cgi-bin/', '/shell', '/cmd', '/command',
}

LOG_RE = re.compile(r'(\S+) \S+ \S+ \[.+?\] "(\S+) (\S+) \S+" (\d+)')

def detect_scanners(log_file):
    ip_scanner_hits = defaultdict(int)
    ip_total = defaultdict(int)
    ip_paths = defaultdict(set)
    ip_errors = defaultdict(int)

    with open(log_file) as f:
        for line in f:
            m = LOG_RE.search(line)
            if not m:
                continue
            ip, method, path, status = m.groups()
            ip_total[ip] += 1
            if int(status) >= 400:
                ip_errors[ip] += 1
            # Check against scanner paths
            path_lower = path.lower().split('?')[0]
            for sp in SCANNER_PATHS:
                if path_lower.startswith(sp) or path_lower == sp:
                    ip_scanner_hits[ip] += 1
                    ip_paths[ip].add(sp)
                    break

    print(f"{'IP':<20} {'Scanner Hits':>12} {'Total Reqs':>10} {'Errors':>8} {'Unique Paths':>12} {'Verdict'}")
    print("-" * 85)
    for ip in sorted(ip_scanner_hits, key=ip_scanner_hits.get, reverse=True)[:30]:
        hits = ip_scanner_hits[ip]
        total = ip_total[ip]
        errors = ip_errors[ip]
        unique = len(ip_paths[ip])
        verdict = "SCANNER" if hits >= 10 or unique >= 5 else "SUSPECT" if hits >= 3 else "MONITOR"
        print(f"{ip:<20} {hits:>12} {total:>10} {errors:>8} {unique:>12} {verdict}")

if __name__ == "__main__":
    detect_scanners(sys.argv[1])

SSH and Authentication Log Analysis

SSH remains the primary administrative access method for Linux servers, making it the number one target for automated attacks. Your authentication logs (/var/log/auth.log on Debian/Ubuntu, /var/log/secure on RHEL/CentOS) contain a wealth of security intelligence.

Key Events to Monitor

• Failed password attempts: The most obvious brute force indicator
• Invalid user attempts: Attackers trying common usernames (root, admin, test, guest, oracle, postgres)
• Accepted logins from unusual IPs: Legitimate-looking access from unexpected locations
• Key authentication failures: Could indicate compromised key distribution
• Session opened/closed patterns: Short sessions may indicate automated access
• sudo usage: Privilege escalation attempts after initial access

# Failed password analysis - who is being targeted?
grep "Failed password" /var/log/auth.log | \
  awk '{for(i=1;i<=NF;i++) if($i=="for") print $(i+1)}' | \
  sort | uniq -c | sort -rn | head -20

# Invalid user attempts (non-existent accounts)
grep "Invalid user" /var/log/auth.log | \
  awk '{print $8}' | sort | uniq -c | sort -rn | head -20

# Sample output:
#  847 admin
#  623 root
#  412 test
#  298 user
#  187 oracle
#  145 postgres
#  134 ftpuser
#   98 ubuntu

# Successful logins - verify each one is legitimate
grep "Accepted" /var/log/auth.log | \
  awk '{print $1, $2, $3, $9, $11}' | tail -20

# Detect successful login after many failures (possible compromise!)
awk '/Failed password/ {fails[$NF]++}
     /Accepted/ {if(fails[$NF]>10) print "ALERT: Login success after", fails[$NF], "failures from", $NF}' \
  /var/log/auth.log

Hardening SSH Based on Log Intelligence

Use the patterns you find in your logs to tighten your SSH configuration:

# /etc/ssh/sshd_config - Hardened configuration based on log analysis

# Disable password authentication entirely (use keys only)
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

# Restrict to specific users
AllowUsers deploy monitoring admin

# Disable root login
PermitRootLogin no

# Limit authentication attempts per connection
MaxAuthTries 3

# Set idle timeout
ClientAliveInterval 300
ClientAliveCountMax 2

# Use only strong key exchange algorithms
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com

# Log verbosely for security monitoring
LogLevel VERBOSE

# Change default port (reduces noise, not security)
Port 2222

# Fail2ban jail for SSH - configure based on your baseline
# /etc/fail2ban/jail.d/ssh.conf
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 300
bantime = 3600
action = iptables-multiport[name=sshd, port="2222"]
         sendmail-whois[name=sshd, dest=security@example.com]

Web Application Firewall (WAF) Log Correlation

A Web Application Firewall generates its own logs when it blocks or flags requests. Correlating WAF logs with web server access logs and application logs reveals the complete attack picture -- what was attempted, what was blocked, and critically, what may have slipped through.

ModSecurity Audit Log Analysis

ModSecurity is the most widely deployed open-source WAF. Its audit log contains detailed information about every intercepted request:

# Parse ModSecurity audit log for blocked attacks
# Audit log format: section A (headers), B (request body), F (response headers), H (audit info)

# Count blocked requests by rule ID
grep -oP 'id "\K\d+' /var/log/modsec_audit.log | sort | uniq -c | sort -rn | head -20

# Common ModSecurity rule IDs and what they detect:
# 942100 - SQL Injection attack detected
# 941100 - XSS attack detected
# 930100 - Path traversal attack
# 913100 - Scanner detection
# 920350 - IP not allowed by geo-restriction
# 949110 - Inbound anomaly score exceeded

# Extract source IPs from blocked requests
grep -B5 'Action: Intercepted' /var/log/modsec_audit.log | \
  grep -oP '\d+\.\d+\.\d+\.\d+' | sort | uniq -c | sort -rn | head -20

# Find requests that scored high but were NOT blocked (detection-only mode)
grep 'Anomaly Score Exceeded' /var/log/modsec_audit.log | \
  grep -v 'Action: Intercepted'

Cross-Correlating WAF and Access Logs

The real power of WAF logs comes from correlating them with your access logs. This reveals gaps in WAF coverage:

#!/usr/bin/env python3
"""Correlate WAF blocks with access log entries to find gaps."""
import re
import sys
from collections import defaultdict

def load_waf_blocked_ips(waf_log):
    """Extract IPs that the WAF has blocked."""
    blocked = set()
    with open(waf_log) as f:
        for line in f:
            match = re.search(r'(\d+\.\d+\.\d+\.\d+)', line)
            if match and 'Intercepted' in line:
                blocked.add(match.group(1))
    return blocked

def find_unblocked_attacks(access_log, blocked_ips):
    """Find attack signatures in access log from IPs NOT blocked by WAF."""
    attack_patterns = [
        (re.compile(r'(?:union.*select|or\+1=1|sleep\(\d)', re.I), 'SQLi'),
        (re.compile(r'(?: {path} [{status}]")

if __name__ == "__main__":
    blocked = load_waf_blocked_ips(sys.argv[1])
    find_unblocked_attacks(sys.argv[2], blocked)

Detecting Data Exfiltration Through Log Anomalies

Data exfiltration -- the unauthorized transfer of data out of your environment -- is often the final stage of a breach. Attackers who have gained access to sensitive data need to get it out, and this process leaves detectable traces in your logs.

Network-Level Exfiltration Indicators

• Unusual outbound data volume: A server that normally sends 50MB/day suddenly transferring 5GB
• Connections to new external IPs: Outbound connections to IP addresses never seen before
• DNS tunneling: Abnormally long or high-volume DNS queries (data encoded in DNS requests)
• Off-hours transfers: Large data transfers at 3 AM when no administrators are working
• Encrypted outbound channels: New SSH or HTTPS connections to unknown endpoints

# Monitor outbound connection volume from iptables/netfilter logs
# Enable outbound connection logging first:
iptables -A OUTPUT -m state --state NEW -j LOG --log-prefix "OUTBOUND: "

# Analyze outbound connection log entries
grep "OUTBOUND:" /var/log/kern.log | \
  awk '{for(i=1;i<=NF;i++) if($i ~ /DST=/) print $i}' | \
  sort | uniq -c | sort -rn | head -20

# Detect DNS tunneling via query length analysis
# Normal DNS queries are short; tunneled data produces long queries
tcpdump -r /var/log/dns_capture.pcap -nn 'port 53' 2>/dev/null | \
  awk '{print length($NF), $NF}' | sort -rn | head -20

# Monitor for unusual data transfer sizes in access logs
# (large responses could indicate database dumps being served)
awk '{if($10 > 10000000) print $1, $7, $10, $4}' /var/log/nginx/access.log | \
  sort -t' ' -k3 -rn | head -20

Application-Level Exfiltration Detection

#!/usr/bin/env python3
"""Detect potential data exfiltration from access log anomalies."""
import re
import sys
from collections import defaultdict

LOG_RE = re.compile(
    r'(\S+) \S+ \S+ \[(.+?)\] "(\S+) (\S+) \S+" (\d+) (\d+)'
)

def analyze_exfiltration(log_file):
    ip_bytes = defaultdict(int)
    ip_requests = defaultdict(int)
    ip_large_responses = defaultdict(list)
    hourly_bytes = defaultdict(int)

    with open(log_file) as f:
        for line in f:
            m = LOG_RE.search(line)
            if not m:
                continue
            ip, timestamp, method, path, status, size = m.groups()
            size = int(size) if size != '-' else 0
            hour = timestamp[:14]

            ip_bytes[ip] += size
            ip_requests[ip] += 1
            hourly_bytes[hour] += size

            if size > 5_000_000:  # Flag responses > 5MB
                ip_large_responses[ip].append((path, size, timestamp))

    # Calculate average bytes per hour for anomaly detection
    avg_hourly = sum(hourly_bytes.values()) / max(len(hourly_bytes), 1)

    print("=== POTENTIAL DATA EXFILTRATION ===\n")

    # Report IPs with abnormally high data transfer
    print("--- High-Volume Data Recipients ---")
    for ip, total_bytes in sorted(ip_bytes.items(), key=lambda x: -x[1])[:20]:
        mb = total_bytes / 1_000_000
        avg_per_req = total_bytes / max(ip_requests[ip], 1)
        if mb > 100:  # Flag IPs receiving > 100MB
            print(f"  {ip}: {mb:.1f} MB total, {ip_requests[ip]} requests, "
                  f"{avg_per_req/1000:.1f} KB avg/request")

    # Report large single responses
    print("\n--- Unusually Large Single Responses ---")
    for ip, responses in ip_large_responses.items():
        for path, size, ts in responses:
            print(f"  {ip}: {size/1_000_000:.1f} MB -> {path} at {ts}")

    # Report hourly anomalies
    print(f"\n--- Hourly Transfer Anomalies (avg: {avg_hourly/1_000_000:.1f} MB) ---")
    for hour, total in sorted(hourly_bytes.items(), key=lambda x: -x[1])[:10]:
        if total > avg_hourly * 3:
            print(f"  {hour}: {total/1_000_000:.1f} MB ({total/max(avg_hourly,1):.1f}x average)")

if __name__ == "__main__":
    analyze_exfiltration(sys.argv[1])

Automated Alerting for Security Events

Detection without alerting is surveillance without action. You need automated pipelines that route security events to the right people at the right time, with enough context for immediate triage.

Alert Priority Framework

Building an Alert Pipeline

#!/bin/bash
# security_alerter.sh - Process log events and send alerts
# Run via cron every minute: * * * * * /opt/scripts/security_alerter.sh

LOG="/var/log/auth.log"
ACCESS_LOG="/var/log/nginx/access.log"
STATE_FILE="/var/run/security_alerter.state"
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
ALERT_EMAIL="security@example.com"

# Track last-processed position
LAST_POS=$(cat "$STATE_FILE" 2>/dev/null || echo 0)
CURRENT_SIZE=$(stat -c%s "$LOG")

# P1: Successful login after brute force
SUCCESS_AFTER_BRUTE=$(tail -c +$LAST_POS "$LOG" | \
  awk '/Accepted password/ {
    ip=$NF;
    cmd="grep -c \"Failed password.*" ip "\" /var/log/auth.log";
    cmd | getline fails; close(cmd);
    if(fails > 50) print "CRITICAL: Login success from " ip " after " fails " failures"
  }')

if [ -n "$SUCCESS_AFTER_BRUTE" ]; then
    # P1 Alert: immediate notification
    curl -s -X POST "$SLACK_WEBHOOK" \
      -H "Content-Type: application/json" \
      -d "{\"text\":\"🚨 *P1 SECURITY ALERT*\n$SUCCESS_AFTER_BRUTE\"}"
    echo "$SUCCESS_AFTER_BRUTE" | mail -s "[P1] Security Alert - Possible Breach" "$ALERT_EMAIL"
fi

# P2: High-volume login failures in last minute
BRUTE_FORCE=$(tail -c +$LAST_POS "$LOG" | \
  grep "Failed password" | awk '{print $NF}' | \
  sort | uniq -c | awk '$1 > 20 {print $2 ": " $1 " failures"}')

if [ -n "$BRUTE_FORCE" ]; then
    curl -s -X POST "$SLACK_WEBHOOK" \
      -H "Content-Type: application/json" \
      -d "{\"text\":\"⚠️ *P2 Alert: Brute Force Detected*\n\`\`\`$BRUTE_FORCE\`\`\`\"}"
fi

# P3: Vulnerability scanning detected
SCANNERS=$(tail -100 "$ACCESS_LOG" | \
  grep -iE '(\.env|\.git/config|wp-admin|phpmyadmin|actuator)' | \
  awk '{print $1}' | sort -u)

if [ -n "$SCANNERS" ]; then
    echo "Scanners detected: $SCANNERS" >> /var/log/security/daily_digest.log
fi

# Update state file
echo "$CURRENT_SIZE" > "$STATE_FILE"

Compliance and Audit Logging Requirements

Security logging is not just a best practice -- for many organizations, it is a legal and regulatory requirement. Compliance frameworks mandate specific logging, retention, and monitoring capabilities. Failure to comply can result in fines, legal liability, and loss of business.

GDPR (General Data Protection Regulation)

GDPR applies to any organization that processes data of EU residents. Relevant logging requirements include:

• Access logging: Record who accessed personal data, when, and why (Article 30 - Records of processing)
• Breach detection: Ability to detect breaches within 72 hours for mandatory notification (Article 33)
• Data minimization in logs: Logs themselves may contain personal data (IP addresses, usernames) and must be handled accordingly
• Right to erasure: Consider whether logs containing personal data need to be purged upon request
• Retention limits: Do not retain logs containing personal data longer than necessary

PCI-DSS (Payment Card Industry Data Security Standard)

PCI-DSS has the most explicit logging requirements of any major framework:

SOC 2 (Service Organization Control 2)

SOC 2 Trust Services Criteria relevant to logging:

• CC6.1: Logical access security -- log all authentication events
• CC6.8: Prevent unauthorized changes -- log all system configuration changes
• CC7.2: Monitor system components for anomalies -- implement continuous log monitoring
• CC7.3: Evaluate security events -- process for analyzing and responding to log alerts
• CC7.4: Respond to identified security incidents -- documented incident response leveraging log data

Implementing Compliant Logging

# Ensure comprehensive audit logging is enabled

# Linux auditd configuration for PCI-DSS compliance
# /etc/audit/rules.d/pci-dss.rules

# Log all authentication events (PCI 10.2.4, 10.2.5)
-w /etc/pam.d/ -p wa -k pam_changes
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /var/log/faillog -p wa -k login_failures
-w /var/log/lastlog -p wa -k login_events

# Log privilege escalation (PCI 10.2.2)
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/sudoers.d/ -p wa -k sudoers_changes
-a always,exit -F arch=b64 -S setuid -S setgid -k privilege_escalation

# Log file access to sensitive directories (PCI 10.2.1)
-w /var/lib/mysql/ -p r -k database_access
-w /data/cardholder/ -p rwa -k cardholder_data

# Log system administration actions (PCI 10.2.2, 10.2.7)
-a always,exit -F arch=b64 -S unlink -S rmdir -S rename -k file_deletion
-a always,exit -F arch=b64 -S creat -S open -S openat -F exit=-EACCES -k access_denied
-a always,exit -F arch=b64 -S creat -S open -S openat -F exit=-EPERM -k access_denied

# Log audit log tampering attempts (PCI 10.2.3, 10.2.6)
-w /var/log/audit/ -p wa -k audit_log_access
-w /etc/audit/ -p wa -k audit_config
-w /sbin/auditctl -p x -k audit_tools
-w /sbin/auditd -p x -k audit_tools

# Make rules immutable (requires reboot to change)
-e 2

# Log rotation with compliance retention
# /etc/logrotate.d/compliance
/var/log/audit/audit.log {
    daily
    rotate 365          # Keep 1 year of daily logs (PCI-DSS)
    compress
    delaycompress
    missingok
    notifempty
    create 0600 root root
    postrotate
        /sbin/service auditd restart 2>/dev/null || true
    endscript
}

/var/log/nginx/access.log {
    daily
    rotate 365
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
    endscript
}

Using LogBeast for Real-Time Security Monitoring

The techniques covered in this guide -- pattern matching, behavioral analysis, cross-log correlation, anomaly detection -- are powerful but require significant manual effort to implement and maintain. LogBeast automates the entire security monitoring pipeline, turning raw logs into actionable threat intelligence.

Security Features Overview

Getting Started with LogBeast Security Monitoring

Setting up LogBeast for security monitoring takes minutes, not days:

1. Point LogBeast at your log files: Access logs, auth logs, error logs, WAF logs -- it parses all common formats automatically
2. Review the security dashboard: Immediate visibility into attack patterns, suspicious IPs, and anomalous behavior
3. Configure alert thresholds: Adjust detection sensitivity based on your server's baseline traffic
4. Set up notifications: Route critical alerts to your preferred channels
5. Export blocklists: Generate IP blocklists for integration with fail2ban, iptables, or your WAF

# Example: Feed LogBeast security findings into fail2ban
# LogBeast exports suspicious IPs to a blocklist file

# /etc/fail2ban/filter.d/logbeast.conf
[Definition]
failregex = ^<HOST> is flagged by LogBeast
ignoreregex =

# /etc/fail2ban/jail.d/logbeast.conf
[logbeast]
enabled = true
port = http,https
filter = logbeast
logpath = /var/log/logbeast/threats.log
maxretry = 1
bantime = 86400
action = iptables-multiport[name=logbeast, port="http,https"]

Security Monitoring Checklist

Use this checklist to evaluate your server's security monitoring posture:

• Log collection: Are all critical log sources (web, auth, system, application, WAF) being collected?
• Centralization: Are logs forwarded to a central location for correlation?
• Retention: Do retention periods meet compliance requirements (1 year for PCI-DSS)?
• Integrity: Are logs protected against tampering (write-only access, separate log server)?
• Real-time monitoring: Are critical events detected within minutes, not days?
• Alerting: Do alerts reach the right people through the right channels?
• Baseline: Do you know what "normal" looks like for your environment?
• Response: Is there a documented process for investigating and responding to alerts?
• Review: Are logs reviewed regularly, even when no alerts fire?
• Testing: Do you periodically test your detection capabilities with simulated attacks?

Conclusion

Server hardening is not a one-time task -- it is an ongoing discipline. Attackers constantly evolve their techniques, and your defenses must evolve with them. The constant in this arms race is that every attack leaves traces in your logs, and systematic analysis of those traces is the most reliable way to detect, investigate, and prevent security incidents.

The key takeaways from this guide:

1. Logs are evidence, not noise. Every failed login, every 404 error, every unusual outbound connection tells a story. Read it
2. Know your attack patterns. Brute force, SQLi, path traversal, XSS, and scanner activity all produce distinct log signatures. Learn to recognize them
3. Build automated detection. Manual log review does not scale. Implement rule-based detection with automatic alerting for critical events
4. Correlate across sources. The full attack story spans multiple log files. Cross-reference web, auth, system, and WAF logs to see the complete picture
5. Meet compliance requirements. GDPR, PCI-DSS, and SOC 2 mandate specific logging, monitoring, and retention capabilities. Build them into your infrastructure from day one
6. Use the right tools. Tools like LogBeast automate the entire pipeline from raw logs to actionable security intelligence, saving hundreds of hours of manual analysis

Start with your logs today. Run the detection commands in this guide, review the output, and ask yourself: do you know what is happening on your servers right now? If the answer is anything other than a confident "yes," it is time to invest in log-based security monitoring.