Am I Getting Attacked

Am I Getting Attacked?

Introduction

The moment every system administrator dreads: you’re reviewing logs and discover a flood of blocked connection attempts. Your firewall shows hundreds of banned IP addresses, predominantly from foreign networks. Meanwhile, your web-facing services become intermittently unavailable. Sound familiar?

This scenario reflects a universal truth in modern internet operations: every public IPv4 address is under constant scanning and attack attempts. As highlighted in a recent Reddit discussion, users of self-hosted services like OPNsense firewalls and TrueNAS/NextCloud installations frequently observe these patterns:

“I noticed a bunch of bans on my OPNsense router CrowdSec logs - just a flood of blocked port scans originating from Brazil. Every time this happens, my TrueNAS/Nextcloud (web-facing) service goes down.”

For DevOps engineers and homelab enthusiasts, understanding these events is critical. This guide examines:

1. Why public-facing infrastructure constantly attracts malicious traffic
2. How to distinguish between normal background noise and targeted attacks
3. Advanced mitigation strategies beyond basic geo-blocking
4. Architectural patterns for maintaining service availability during scans

We’ll analyze real-world attack patterns, dissect why simple WAF rules sometimes fail, and implement enterprise-grade protections in homelab environments.

Understanding Internet Background Radiation

The Constant Scanning Reality

Every public IPv4 address receives:

• 10-50 unauthorized connection attempts per minute
• Scanning from botnets covering 100+ countries
• Exploit attempts for known vulnerabilities (Log4j, ProxyShell, etc.)

According to Cloudflare’s network analysis, over 45% of internet traffic exhibits malicious characteristics.

Why Services Fail During Scans

Three primary failure mechanisms occur during scanning events:

1. Resource Exhaustion:
   • State table overload in firewalls
   • Web server worker saturation
   • Bandwidth consumption
2. False Positives:
   • Overly aggressive blocking rules
   • GeoIP database inaccuracies
3. Collateral Damage:
   • Legitimate traffic blocked alongside malicious
   • DNS/DHCP services impacted by firewall load

Geo-Blocking Limitations

The original poster attempted:

# Basic OPNsense geo-blocking rule
pass in quick on $WAN proto { tcp udp } from { US } to { $SERVER } port { 80,443 }

Why this fails:

1. Attackers use cloud proxies in allowed regions
2. IPv6 traffic bypasses IPv4 geo-filters
3. Scans originate from compromised US systems

Prerequisites for Effective Protection

Infrastructure Requirements

Component	Minimum Specs	Recommended
Firewall/Router	2-core CPU, 2GB RAM	4-core CPU, 4GB RAM
Web Server	4GB RAM	8GB RAM + SSD
Network Bandwidth	100Mbps	1Gbps with QoS

Critical Software Components

1. Firewall: OPNsense 23.7+ or pfSense CE 2.7+
2. Intrusion Prevention: CrowdSec 1.5.x or Suricata 6.0.12+
3. Web Application Firewall: ModSecurity 3.0.8 with OWASP CRS 3.3.4

Security Foundations

Before implementing advanced protections:

1. Confirm all services are patched to latest versions
2. Verify SSH/RDP exposed only via VPN or tailscale
3. Implement certificate-based authentication
4. Establish complete offline backups

Installation & Configuration Walkthrough

OPNsense CrowdSec Deployment

1. Install CrowdSec plugin:

   opnsense-code tools ports
   cd /usr/ports/security/crowdsec && make install clean
   

2. Configure acquisition for firewall logs:

   # /usr/local/etc/crowdsec/acquis.yaml
   filenames:
     - /var/log/filter.log
   labels:
     type: opnsense
   

3. Enable bouncers for automatic blocking:

   pkg install crowdsec-firewall-bouncer
   sysrc crowdsec_firewall_enable="YES"
   service crowdsec_firewall start
   

Advanced Geo-Blocking Implementation

Overcome basic geo-filter limitations with:

# /usr/local/etc/OPNsense.xml excerpt
<rule>
  <description>Strict GeoIP Filter</description>
  <source>
    <address>!US</address>
    <address>::/0</address> <!-- Block all IPv6 -->
  </source>
  <destination>
    <network>wanip</network>
  </destination>
  <target>block</target>
  <protocol>any</protocol>
</rule>

Key improvements:

1. Explicit IPv6 blocking (scanners increasingly use IPv6)
2. Inverted logic: block all non-US instead of allowing US
3. Applies to all destination ports

TrueNAS SCALE Hardening

Mitigate NextCloud outages during attacks:

1. Configure resource limits:

   # /etc/systemd/system/nextcloud.service.d/limits.conf
   [Service]
   LimitNOFILE=65535
   LimitNPROC=4096
   

2. Implement adaptive rate limiting:

   # /usr/local/etc/nginx/nginx.conf
   http {
     limit_req_zone $binary_remote_addr zone=nextcloud:10m rate=30r/m;
     server {
    location / {
      limit_req zone=nextcloud burst=50 nodelay;
    }
     }
   }
   

Operational Optimization

Performance Tuning for High Scan Volumes

Adjust OPNsense kernel parameters:

# /boot/loader.conf
kern.ipc.maxsockets=2000000
net.inet.ip.portrange.first=1024
net.inet.tcp.msl=5000

Optimize CrowdSec decision making:

# /usr/local/etc/crowdsec/profiles.yaml
name: opnsense_throttle
filters:
 - 'Alert.Remediation == true && Alert.GetScope() == "Ip"'
decisions:
 - type: ban
   duration: 4h
   scope: Ip
on_success: break

Multi-Layered Defense Architecture

1. Edge Protection (OPNsense):
   • GeoIP blocking
   • Port knocking for admin interfaces
   • Protocol anomaly detection
2. Service Layer (TrueNAS/NextCloud):
   • Application-layer rate limiting
   • CAPTCHA for failed logins
   • File integrity monitoring
3. Host Protection:
   • Fail2ban for SSH/SMB
   • Kernel hardening (sysctl.conf)
   • Mandatory access control (AppArmor)

Troubleshooting Service Disruptions

Diagnostic Checklist

When services fail during scanning:

1. Check State Table Utilization:

   pfctl -si | grep states
   # Look for high "current" relative to "limit"
   

2. Analyze Web Server Workers:

   nginx -T | grep worker_connections
   systemctl status nextcloud | grep Active
   

3. Verify Block Effectiveness:

   crowdsec metrics -b crowdsec-firewall-bouncer
   # Confirm increasing blocked_ip count
   

Common Issues and Solutions

Problem: Geo-blocking rules bypassed Solution:

# Verify IPv6 blocking
pfctl -s rules | grep inet6
# Add explicit IPv6 deny if missing

Problem: NextCloud crashes under load Solution:

# Increase PHP memory limits
sed -i 's/memory_limit = .*/memory_limit = 512M/' /usr/local/etc/php.ini

Problem: False positives blocking legitimate users Solution:

# /usr/local/etc/crowdsec/parsers/s02-enrich/whitelist.yaml
name: corporate_whitelist
whitelist:
  reason: 'Corporate IP Range'
  expression:
   - 192.168.0.0/24

Conclusion

The question “Am I getting attacked?” has a definitive answer: Yes, constantly. All public-facing infrastructure exists in a perpetual state of siege. However, through layered defenses and proper architecture, service disruptions become preventable.

Key takeaways:

1. Basic geo-blocking is insufficient against modern scanners
2. Service outages during scans indicate architectural gaps
3. Defense-in-depth beats any single solution

Where to learn more:

1. OPNsense CrowdSec Documentation
2. Cloudflare Attack Analysis Reports
3. OWASP Web Application Firewall Guide

Security isn’t about building impenetrable walls - it’s about creating resilient systems that withstand the internet’s constant background radiation while maintaining service availability. By implementing these patterns, you transform from passive victim to hardened operator.