Defense-in-Depth for Validators:

- Firewall rules
- DDoS protection
- Port restrictions

- OS hardening
- Service minimization
- File integrity monitoring

- rippled configuration
- Access controls
- Secure key management

- Intrusion detection
- Log monitoring
- Incident response

- Backups
- Disaster recovery
- Business continuity

Each layer provides protection if others fail

Common Attack Vectors:

- SSH brute force (mitigated in Lesson 3)
- Exploitation of vulnerable services
- DDoS against validator port
- Application-layer attacks

- Unauthorized server access
- Key theft
- Social engineering

- Compromised dependencies
- Malicious updates
- Infrastructure provider breach

- Most likely attacks first
- Highest impact attacks
- Your specific risk profile

---

AIDE (Advanced Intrusion Detection Environment) monitors file integrity:

# Install AIDE
sudo apt install aide -y

# Initialize the database (takes time)
sudo aideinit

# Move initialized database
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Manual check
sudo aide --check

Configure AIDE for Validator:

Add validator-specific monitoring:

# Monitor rippled configuration
/opt/ripple/etc CONTENT_EX
/opt/ripple/etc/rippled.cfg CONTENT_EX

# Monitor rippled binary
/opt/ripple/bin CONTENT_EX

# Monitor validator keys location (if present)
/home/validator/.ripple CONTENT_EX

# System critical files
/etc/ssh CONTENT_EX
/etc/passwd CONTENT_EX
/etc/shadow CONTENT_EX

Schedule regular checks:

# Add to crontab
sudo crontab -e

# Daily integrity check at 3 AM
0 3 * * * /usr/bin/aide --check | mail -s "AIDE Report $(hostname)" [email protected]

For network-level intrusion detection:

# Install Suricata
sudo apt install suricata -y

# Update rules
sudo suricata-update

# Configure for your interface
sudo nano /etc/suricata/suricata.yaml

Basic configuration:

# /etc/suricata/suricata.yaml
vars:
  address-groups:
    HOME_NET: "[YOUR_SERVER_IP/32]"
    EXTERNAL_NET: "!$HOME_NET"

af-packet:
  - interface: eth0  # Your network interface
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes

Start Suricata:

# Start service
sudo systemctl enable suricata
sudo systemctl start suricata

# Monitor alerts
sudo tail -f /var/log/suricata/fast.log

Monitor system calls and process activity:

# Install auditd
sudo apt install auditd -y

# Add validator-specific rules
sudo nano /etc/audit/rules.d/validator.rules

Audit rules for validators:

# Monitor rippled configuration changes
-w /opt/ripple/etc/rippled.cfg -p wa -k rippled_config

# Monitor rippled binary
-w /opt/ripple/bin/rippled -p x -k rippled_exec

# Monitor SSH configuration
-w /etc/ssh/sshd_config -p wa -k ssh_config

# Monitor user/group changes
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes

# Monitor sudo usage
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# Monitor cron changes
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron

# Load rules
sudo augenrules --load

# View audit logs
sudo ausearch -k rippled_config

Build on basic firewall from Lesson 3:

# Review current rules
sudo ufw status verbose

# Rate limiting for SSH (if not already)
sudo ufw limit ssh

# Rate limiting for peer port (prevent connection floods)
sudo ufw limit 51235/tcp

# Log denied connections
sudo ufw logging high

For more granular control:

Advanced ruleset:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Allow established connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow loopback
-A INPUT -i lo -j ACCEPT

# SSH with rate limiting and connection tracking
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
-A INPUT -p tcp --dport 22 -j ACCEPT

# rippled peer port with connection limiting
-A INPUT -p tcp --dport 51235 -m connlimit --connlimit-above 50 --connlimit-mask 32 -j DROP
-A INPUT -p tcp --dport 51235 -m state --state NEW -m recent --set --name PEERS
-A INPUT -p tcp --dport 51235 -m state --state NEW -m recent --update --seconds 1 --hitcount 10 --name PEERS -j DROP
-A INPUT -p tcp --dport 51235 -j ACCEPT

# Drop invalid packets
-A INPUT -m state --state INVALID -j DROP

# Log dropped packets (limited)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables-dropped: "

# Drop everything else
-A INPUT -j DROP

COMMIT

# Enable SYN cookies
echo "net.ipv4.tcp_syncookies = 1" | sudo tee -a /etc/sysctl.conf

Increase SYN backlog

echo "net.ipv4.tcp_max_syn_backlog = 4096" | sudo tee -a /etc/sysctl.conf

Reduce SYN-ACK retries

echo "net.ipv4.tcp_synack_retries = 2" | sudo tee -a /etc/sysctl.conf

Apply settings

sudo sysctl -p
```

# Install logwatch
sudo apt install logwatch -y

Configure daily reports

sudo nano /etc/logwatch/conf/logwatch.conf
```

#!/bin/bash
#===============================================================================
# Security Monitoring Script
# Run periodically to detect suspicious activity
#===============================================================================

ALERT_EMAIL="[email protected]"
HOSTNAME=$(hostname)

Function to send alert

send_alert() {
local subject="$1"
local message="$2"
echo "$message" | mail -s "[$HOSTNAME] Security Alert: $subject" "$ALERT_EMAIL"
logger -t security-monitor "Alert sent: $subject"
}

Check for failed SSH attempts (last hour)

FAILED_SSH=$(grep "Failed password" /var/log/auth.log | grep "$(date -d '1 hour ago' '+%b %d %H')" | wc -l)
if [ "$FAILED_SSH" -gt 10 ]; then
send_alert "High SSH Failures" "Detected $FAILED_SSH failed SSH attempts in the last hour"
fi

Check for new listening ports

CURRENT_PORTS=$(ss -tlnp | grep LISTEN | sort)
if [ -f /var/run/baseline_ports ]; then
BASELINE_PORTS=$(cat /var/run/baseline_ports)
if [ "$CURRENT_PORTS" != "$BASELINE_PORTS" ]; then
send_alert "Port Change Detected" "Listening ports have changed:\n\nCurrent:\n$CURRENT_PORTS\n\nBaseline:\n$BASELINE_PORTS"
fi
else
echo "$CURRENT_PORTS" > /var/run/baseline_ports
fi

Check rippled process

if ! pgrep -x "rippled" > /dev/null; then
send_alert "rippled Not Running" "rippled process is not running!"
fi

Check for unauthorized sudo

SUDO_USAGE=$(grep "sudo:" /var/log/auth.log | grep "$(date '+%b %d')" | grep -v "session opened|session closed")
if [ -n "$SUDO_USAGE" ]; then
SUDO_COUNT=$(echo "$SUDO_USAGE" | wc -l)
if [ "$SUDO_COUNT" -gt 20 ]; then
send_alert "High sudo Activity" "Detected $SUDO_COUNT sudo events today"
fi
fi

Check disk usage

DISK_USAGE=$(df /var/lib/rippled/db | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$DISK_USAGE" -gt 85 ]; then
send_alert "High Disk Usage" "Disk usage at ${DISK_USAGE}%"
fi

Check for configuration file changes

if [ -f /var/run/rippled_cfg_hash ]; then
CURRENT_HASH=$(md5sum /opt/ripple/etc/rippled.cfg | awk '{print $1}')
BASELINE_HASH=$(cat /var/run/rippled_cfg_hash)
if [ "$CURRENT_HASH" != "$BASELINE_HASH" ]; then
send_alert "Config Change Detected" "rippled.cfg has been modified"
fi
else
md5sum /opt/ripple/etc/rippled.cfg | awk '{print $1}' > /var/run/rippled_cfg_hash
fi

echo "Security check completed at $(date)"
```

# Make executable and schedule
sudo chmod +x /opt/ripple/bin/security-monitor.sh

Run hourly

echo "0 * * * * /opt/ripple/bin/security-monitor.sh >> /var/log/security-monitor.log 2>&1" | sudo crontab -
```

DDoS Attack Types:

- Flood bandwidth
- SYN floods
- UDP floods
- Goal: Overwhelm network capacity

- Exploit protocol weaknesses
- Connection exhaustion
- Malformed packets
- Goal: Exhaust server resources

- Target rippled specifically
- Malicious peer connections
- Invalid validation requests
- Goal: Disrupt validation

Cloud Provider DDoS Protection:

- AWS Shield Standard (free)
- AWS Shield Advanced (paid)
- CloudFront for additional protection

- Automatic DDoS protection included
- Configurable via Robot

- Cloud Firewalls
- Limited built-in DDoS protection

- Anti-DDoS protection included
- VAC (Vacuum) system

- Proxy for non-HTTP traffic
- Enterprise feature

# SYN flood protection
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2

Connection tracking

net.netfilter.nf_conntrack_max = 200000
net.netfilter.nf_conntrack_tcp_timeout_established = 600

ICMP protection

net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

Source validation

net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

Disable source routing

net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

Disable redirects

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
```

Extend fail2ban to protect rippled:

Incident Severity Levels:

- Validator compromise confirmed
- Key theft suspected
- Active exploitation
- Immediate response required

- Unsuccessful attack detected
- Service disruption
- Configuration tampering
- Urgent response (hours)

- Suspicious activity
- Reconnaissance detected
- Performance anomaly
- Same-day response

- Failed login attempts (normal levels)
- Port scans
- Minor anomalies
- Routine review

Response Framework:

1. IDENTIFY

1. CONTAIN

1. ERADICATE

1. RECOVER

1. LESSONS LEARNED

# Validator Incident Response Runbook

Auth logs

sudo grep -i "fail|invalid|denied" /var/log/auth.log | tail -100

System logs

sudo journalctl --since "1 hour ago" | grep -i "error|fail"
```

Network connections

ss -tlnp
netstat -plant

Open files

lsof -i
```

AIDE check

sudo aide --check
```

#!/bin/bash
#===============================================================================
# Monthly Security Audit Script
#===============================================================================

echo "=============================================="
echo "Security Audit - $(date)"
echo "=============================================="

echo ""
echo "=== 1. System Updates ==="
apt list --upgradable 2>/dev/null | head -20

echo ""
echo "=== 2. User Accounts ==="
echo "Users with login shells:"
grep -E "bash|sh$" /etc/passwd

echo ""
echo "=== 3. SSH Configuration ==="
grep -E "^PermitRootLogin|^PasswordAuthentication|^PubkeyAuthentication" /etc/ssh/sshd_config

echo ""
echo "=== 4. Listening Ports ==="
ss -tlnp | grep LISTEN

echo ""
echo "=== 5. Firewall Status ==="
sudo ufw status numbered

echo ""
echo "=== 6. Failed Login Attempts (Last 7 Days) ==="
sudo grep "Failed password" /var/log/auth.log | wc -l

echo ""
echo "=== 7. rippled Configuration Permissions ==="
ls -la /opt/ripple/etc/rippled.cfg

echo ""
echo "=== 8. Key File Check ==="
if [ -f ~/.ripple/validator-keys.json ]; then
echo "WARNING: Master key file found on server!"
ls -la ~/.ripple/validator-keys.json
else
echo "OK: No master key file on server"
fi

echo ""
echo "=== 9. Crontab Review ==="
echo "Root crontab:"
sudo crontab -l 2>/dev/null || echo "No root crontab"
echo ""
echo "User crontabs:"
for user in $(cut -f1 -d: /etc/passwd); do
crontab -u $user -l 2>/dev/null && echo "--- Above for user: $user"
done

echo ""
echo "=== 10. AIDE Status ==="
if command -v aide &> /dev/null; then
echo "AIDE installed, last check:"
ls -la /var/lib/aide/aide.db 2>/dev/null || echo "Database not found"
else
echo "AIDE not installed"
fi

echo ""
echo "=============================================="
echo "Audit Complete"
echo "=============================================="
```

Complete Security Checklist:

Network Security:
□ Firewall enabled (UFW)
□ Only required ports open (SSH, 51235)
□ Rate limiting on SSH
□ Rate limiting on peer port
□ SYN flood protection enabled
□ DDoS mitigation configured

Access Control:
□ SSH key-only authentication
□ Root login disabled
□ fail2ban active
□ Strong user passwords
□ sudo logging enabled
□ No shared accounts

Host Security:
□ OS updates automatic
□ Unnecessary services disabled
□ File permissions appropriate
□ AIDE configured
□ auditd running
□ Security monitoring active

rippled Security:
□ Admin ports localhost only
□ Configuration file permissions (600)
□ No master keys on server
□ Validator token secured
□ Log rotation configured

Monitoring:
□ Health checks scheduled
□ Security monitoring script running
□ Log analysis configured
□ Alerting functional

Documentation:
□ Incident response plan documented
□ Key recovery procedures documented
□ Security audit schedule established
□ Contact information current

✅ Defense-in-depth provides resilience - Multiple security layers mean single failures don't result in compromise

✅ Intrusion detection catches many attacks - File integrity monitoring and process auditing detect unauthorized changes

✅ Rate limiting prevents many attacks - Simple connection limits stop unsophisticated attacks

✅ Documentation enables consistent response - Written procedures prevent mistakes during high-stress incidents

⚠️ Optimal security vs. complexity tradeoff - More security tools mean more maintenance; balance with your resources

⚠️ Effectiveness against sophisticated attackers - Advanced persistent threats may bypass standard detection

⚠️ Alert threshold tuning - Too sensitive causes alert fatigue; too insensitive misses attacks

📌 Security theater over substance - Installing tools without monitoring or maintenance provides false confidence

📌 Complexity introducing vulnerabilities - More software means more potential vulnerabilities; keep systems simple

📌 Incident response untested - Plans not practiced often fail when needed; test your procedures

📌 Security as one-time setup - Security requires ongoing attention; systems degrade without maintenance

The security measures in this lesson are appropriate for validators, but they require ongoing attention. Installing intrusion detection without reviewing alerts is worse than useless—it creates false confidence.

Start with fundamentals (Lesson 3), add layers appropriate to your threat model and resources, and maintain what you deploy. A simple security system that's actually monitored beats a complex system that's ignored.

Assignment: Implement advanced security measures and document your security posture.

Requirements:

• Install and configure AIDE

• Run initial database creation

• Document what's being monitored

• Schedule automated checks

• Implement rate limiting on peer port

• Configure SYN flood protection

• Enable logging of dropped connections

• Document all firewall rules

• Configure security monitoring script

• Set up email alerting (or document alternative)

• Run and document initial baseline

• Schedule automated execution

• Complete incident response runbook

• Document severity classifications

• List contacts and procedures

• Create recovery checklist

• PDF or Markdown document

• Configuration file excerpts

• Script outputs

• Completed runbook

• Working intrusion detection (25%)

• Enhanced firewall configuration (25%)

• Operational security monitoring (25%)

• Complete incident response documentation (25%)

Time investment: 4-6 hours
Value: Production-grade security posture for your validator

1. Defense-in-Depth (Tests Security Philosophy):

What is the primary benefit of a defense-in-depth security strategy?

A) It makes attacks impossible
B) If one security layer fails, others continue to provide protection
C) It reduces the number of security tools needed
D) It eliminates the need for monitoring

Correct Answer: B
Explanation: Defense-in-depth accepts that no single security measure is perfect. By implementing multiple layers—network, host, application, detection, and recovery—failure of one layer doesn't mean complete compromise. An attacker must bypass multiple protections, and detection becomes more likely.

2. Intrusion Detection (Tests Technical Knowledge):

What does AIDE (Advanced Intrusion Detection Environment) primarily monitor?

A) Network traffic for suspicious patterns
B) File system integrity—detecting unauthorized changes to files
C) User login attempts
D) CPU and memory usage

Correct Answer: B
Explanation: AIDE is a host-based intrusion detection system that monitors file integrity. It creates a database of file checksums and properties, then alerts when files are modified, added, or deleted unexpectedly. This detects many types of compromise where attackers modify system files, configuration, or binaries.

3. DDoS Mitigation (Tests Operational Knowledge):

Which kernel setting helps protect against SYN flood attacks?

A) net.ipv4.ip_forward
B) net.ipv4.tcp_syncookies
C) net.ipv4.icmp_echo_ignore_all
D) vm.swappiness

Correct Answer: B
Explanation: tcp_syncookies enables SYN cookies, which allow the server to handle SYN flood attacks without exhausting connection tracking resources. When enabled, the server doesn't allocate resources for half-open connections until the three-way handshake completes, making SYN floods much less effective.

4. Incident Response (Tests Process Understanding):

What should be your FIRST action upon detecting a confirmed validator compromise?

A) Begin detailed forensic analysis
B) Notify the community and UNL operators
C) Stop rippled and contain the incident to prevent further damage
D) Rotate the validator token

Correct Answer: C
Explanation: The first priority is containment—stop ongoing damage. Stop rippled to prevent the compromised validator from affecting the network or continuing to be exploited. Forensic analysis and notification come after containment. Token rotation is part of recovery, not initial response.

5. Security Monitoring (Tests Practical Application):

Your security monitoring script alerts on a sudden increase in failed SSH login attempts (from 5/hour to 200/hour). What's the appropriate response?

A) Ignore it—fail2ban will handle it
B) Investigate the source, verify fail2ban is blocking attempts, and consider additional IP blocking if persistent
C) Immediately shut down the server
D) Change the SSH port

Correct Answer: B
Explanation: Elevated SSH failures indicate an active attack, but if fail2ban is working, immediate danger is limited. Investigate the source IPs, verify fail2ban is successfully blocking them, and consider whether additional action (like permanent IP blocks or reporting) is warranted. Shutting down is excessive; changing ports mid-attack doesn't help.

For Next Lesson:
With security hardened, Lesson 11 will cover amendment voting and fee/reserve settings—the governance responsibilities of validators. We'll explore how validators influence XRPL protocol evolution through amendment votes.

End of Lesson 10

Total words: ~5,600
Estimated completion time: 65 minutes reading + 4-6 hours implementation