Firedog – Advanced Firewall & Threat Detection irreplaceable

Product Description

Firedog is an advanced host-based firewall system for Linux that redefines perimeter protection through the union of restrictive policies, multi-layer anti-attack protections and intelligent analysis of blocked traffic. Unlike traditional firewalls that just allow/block, Firedog implements a "defense-in-depth" approach with machine learning-based threat scoring that identifies attack patterns in real time.

Built on iptables/nftables with default DROP policy, Firedog automatically protects against the most common threats: SYN flood, port scanning, SSH brute force, ICMP flood, packet spoofing and application-level attacks. Each blocked package is logged into PCAP format for post-incident forensic analysis, while the threat intelligence engine assigns a 0-100 risk score to each source IP to identify persistent attackers.

Management through CLI Python user-friendly hides the complexity of iptables, also allowing non-expert sysadmin to configure enterprise-grade firewalls in minutes. With native integration MicroSIEM and Sentinel Core (via Integration Pack), Firedog becomes the arm of a coordinated and automated defense strategy. You can also use the web-interface written in reaction and install on remote target machines and manage the features for all debian machines in production. You can contribute or download firedog and firedog web-consul on github at this address.

Main features

🛡️ Multi-Layer Firewall with Restrictive Policy

Default's DROP Policy:

The "deny-all, allow-by-exception" philosophy ensures maximum safety:

bash

# Default policy (all chains)
iptables -P INPUT DROP      # Block all incoming traffic
iptables -P OUTPUT DROP     # Block all outgoing traffic  
iptables -P FORWARD DROP    # Block all forwarded traffic

# Solo traffico esplicitamente permesso passa

Why DROP instead of REJECT:

  • DROP: Silently discarded package (attacker doesn't know if host exists)
  • REJECT: Responds with ICMP "port unreachable" (information disclosure)

Best practice security: DROP is preferable for exposed Internet systems.

Connection Tracking:

bash

# Allow established connections (responses to outgoing requests)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow loopback (localhost communication)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
```

**Connection states:**
- **NEW**: Primo pacchetto di nuova connessione
- **ESTABLISHED**: Connessione già stabilita
- **RELATED**: Connessione correlata (e.g. FTP data channel dopo control channel)
- **INVALID**: Pacchetto malformato o non tracciabile

**Chain Structure:**
```
INPUT chain (traffico in ingresso):
├─ Loopback accept (lo interface)
├─ Established/Related accept
├─ Anti-attack rules (rate limiting, flood protection)
├─ Whitelist rules (permitted IPs/ports)
├─ Logging (NFLOG per dropped packets)
└─ Default policy: DROP

OUTPUT chain (traffico in uscita):
├─ Loopback accept
├─ Established/Related accept
├─ Application rules (allow specific outbound)
├─ Logging (dropped outbound = suspicious)
└─ Default policy: DROP

FORWARD chain (routing/NAT):
├─ Connection tracking
├─ NAT rules (if gateway)
└─ Default policy: DROP

Dual Stack Support (IPv4 + IPv6):

Firedog protects both Stacks:

  • iptables for IPv4
  • ip6tables for IPv6 (parallel rules)

Critical: Many organizations forget IPv6, leaving backdoors. Firedog hardens both by default.

🚨 Integrated anti-attack protections

1. SYN Flood Protection:

Attack vector: Attacker sends thousands of SYN packets, runs out of server connection table.

Firedog mitigation:

bash

# Limit new TCP connections to 10/second per IP
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 10 -j DROP

# Alternative: Limit using recent module
iptables -A INPUT -p tcp --syn -m recent --name syn_flood --set
iptables -A INPUT -p tcp --syn -m recent --name syn_flood --update --seconds 1 --hitcount 10 -j LOG --log-prefix "SYN_FLOOD: "
iptables -A INPUT -p tcp --syn -m recent --name syn_flood --update --seconds 1 --hitcount 10 -j DROP
```

**Threshold**: Max 10 nuove connessioni/secondo per IP. Se superato → DROP per 60 secondi.

**Log example**:
```
SYN_FLOOD: IN=eth0 SRC=203.0.113.50 DST=192.168.1.10 PROTO=TCP SPT=45123 DPT=80 SYN

2. Port Scan Detection:

Attack vector: Attacker scans ports to find vulnerable services (nmap, masscan).

Firedog mitigation:

bash

# Detect port scanning: >15 different ports in 1 minute
iptables -A INPUT -m recent --name portscan --rcheck --seconds 60 --hitcount 15 -j LOG --log-prefix "PORT_SCAN: "
iptables -A INPUT -m recent --name portscan --rcheck --seconds 60 --hitcount 15 -j DROP

# Track port access attempts
iptables -A INPUT -m recent --name portscan --set -j ACCEPT

Detection logic:

  • IP track touching different ports
  • If >15 ports in 60 seconds → identified as scan
  • 1 hour IP Ban

Advanced: Pattern recognition identifies scan types:

  • Horizontal scan: Same multiple IP port (worm)
  • Vertical scan: Multiple ports on same IP (reconnaissance)
  • Stealth scan: abnormal TCP flags (Xmas, NULL, FIN scan)

3. SSH Brute Force Protection:

Attack vector: Automated login attributes with dictionary/credential stuffing.

Firedog mitigation:

bash

# Allow max 4 SSH connection attempts per minute
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name ssh --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name ssh --update --seconds 60 --hitcount 4 -j LOG --log-prefix "SSH_BRUTE: "
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name ssh --update --seconds 60 --hitcount 4 -j DROP

Enhanced protection (fail2ban-like integration):

  • After 4 failed attempts → ban 1 hour
  • After 3 ban → permanent ban (whitelist manual unban)
  • Logging IP + timestamp → forensic analysis

Best practice combination:

  • Firedog rate limiting
  • SSH key-only authentication (disable password)
  • Non-standard SSH port (e.g. 2222 instead of 222)
  • VPN required for SSH access

4. ICMP Flood Protection:

Attack vector: Overwhelm network with ICMP echo requests.

Firedog mitigation:

bash

# Allow max 5 ping per second
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/s --limit-burst 10 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j LOG --log-prefix "ICMP_FLOOD: "
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

# Allow ICMP echo-reply, destination-unreachable, time-exceeded (necessary for network functions)
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT

Rational: Ping utility for troubleshooting, but flood is attack. Limit rate keeps utility, blocks abuse.

5. Invalid Packet Filtering:

Attack vectors: Malformed packets for firewall bypass or exploit kernel vulnerabilities.

Firedog protection:

bash

# Drop INVALID packets (malformed, corrupted)
iptables -A INPUT -m conntrack --ctstate INVALID -j LOG --log-prefix "INVALID_PKT: "
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# Drop NULL packets (no flags set - reconnaissance)
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j LOG --log-prefix "NULL_PKT: "
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# Drop XMAS packets (all flags set - Nmap Xmas scan)
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j LOG --log-prefix "XMAS_PKT: "
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

# Drop FIN packets without ACK (invalid TCP handshake)
iptables -A INPUT -p tcp --tcp-flags FIN,ACK FIN -j LOG --log-prefix "FIN_SCAN: "
iptables -A INPUT -p tcp --tcp-flags FIN,ACK FIN -j DROP

# Drop packets with SYN and FIN set (invalid combination)
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG --log-prefix "SYN_FIN: "
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

Protection rational: Legitimate packages never have these combinations. Detection = attack or misconfiguration.

6. Anti-Spoofing (Martian Packets):

Attack vector: IP source address spoofing (false source IP to evade detection or DDoS reflection).

Firedog mitigation:

bash

# Drop packets with private IP as source from Internet
iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j LOG --log-prefix "SPOOFED_10: "
iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP

iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j LOG --log-prefix "SPOOFED_172: "
iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP

iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j LOG --log-prefix "SPOOFED_192: "
iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP

# Drop packets with localhost IP from external interface
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j LOG --log-prefix "SPOOFED_LOCALHOST: "
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP

# Drop packets with multicast source
iptables -A INPUT -s 224.0.0.0/4 -j LOG --log-prefix "SPOOFED_MULTICAST: "
iptables -A INPUT -s 224.0.0.0/4 -j DROP

# Enable reverse path filtering (kernel-level anti-spoofing)
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

Martian packets: Packets with impossible IP (e.g. 192.168.x.x coming from Internet). Name comes from "Martians" (aliens) because they should not exist.

7. Fragment Attack Protection:

Attack vector: IP fragmentation to circumvent IDS/firewall or exploit reassemble bugs.

Firedog mitigation:

bash

# Drop fragmented packets
iptables -A INPUT -f -j LOG --log-prefix "FRAGMENT: "
iptables -A INPUT -f -j DROP

# Kernel-level protection
echo 1 > /proc/sys/net/ipv4/ip_always_defrag  # Force defragmentation before firewall

Rational: Legitimate Fragmentation is rare with modern MTU discovery. Lock fragments = maximum safety with minimum legitimate impact.

📝 Logging and Forensics PCAP

ULOGD2 Integration:

Firedog uses ulogd2 (Userspace Logging Daemon) for advanced logging instead of traditional syslog.

Advantages ulogd2:

  • ✅ Native PCAP output (Wireshark/tcpdump compatible)
  • ✅ Separate INPUT/OUTPUT (granular analysis)
  • ✅ Higher performance (kernel-space → efficient userspace)
  • ✅ Plugin architecture (PCAP, MySQL, PostgreSQL, JSON, etc.)

Ulogd2 Configuration:

ini

# /etc/ulogd.conf

# Stack for INPUT dropped packets
stack=log_input:NFLOG,base1:BASE,pcap1:PCAP

[log_input]
group=1
bind=0.0.0.0

[pcap1]
file="/var/log/ulogd/input_dropped.pcap"
sync=1  # Sync after each packet (prevents data loss on crash)

# Stack for OUTPUT dropped packets  
stack=log_output:NFLOG,base2:BASE,pcap2:PCAP

[log_output]
group=2
bind=0.0.0.0

[pcap2]
file="/var/log/ulogd/output_dropped.pcap"
sync=1

Iptables logging rules:

bash

# Log dropped INPUT packets to NFLOG group 1
iptables -A INPUT -j NFLOG --nflog-group 1 --nflog-prefix "INPUT_DROP" --nflog-threshold 50

# Log dropped OUTPUT packets to NFLOG group 2
iptables -A OUTPUT -j NFLOG --nflog-group 2 --nflog-prefix "OUTPUT_DROP" --nflog-threshold 50

NFLOG vs LOG:

  • LOG: Logging a syslog/dmesg (text-based, limited info)
  • NFLOG: Logging a userspace daemon (binary, full packet capture)

Threshold parameter: Batch 50 packets before flush (performance optimization).

Log Rotation with Logrotate:

Problem: PCAP files grow rapidly (GB/day on busy servers).

Solution: Automatic rotation with compression.

bash

# /etc/logrotate.d/firedog-pcap

/var/log/ulogd/*.pcap {
    daily                    # Rotate ogni giorno
    rotate 30                # Keep 30 giorni di log
    maxsize 1G               # Force rotate se file >1GB
    compress                 # Gzip compression (riduce ~80%)
    delaycompress            # Compress file precedente, non corrente
    notifempty               # Don't rotate se file vuoto
    create 0640 root adm     # Nuovo file permissions
    sharedscripts
    postrotate
        systemctl reload ulogd2 > /dev/null 2>&1 || true
    endscript
}

Retention policy configurable:

  • Default: 30 days or 1GB (whatever comes first)
  • Compliance-heavy: 90-365 days (healthcare, finance)
  • High-traffic: 7 days with Cold Storage Offload (S3 Glacier)

Forensic Analysis:

Manual analysis with tcpdump:

bash

# View PCAP in real-time
tcpdump -r /var/log/ulogd/input_dropped.pcap

# Filter by IP
tcpdump -r input_dropped.pcap src host 203.0.113.50

# Filter by port
tcpdump -r input_dropped.pcap dst port 22

# Extract specific timestamp
tcpdump -r input_dropped.pcap 'greater 2024-01-15 10:00:00 and less 2024-01-15 11:00:00'

# Count packets per IP
tcpdump -r input_dropped.pcap -n | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn

Analysis with Wireshark (GUI):

  • Open PCAP file
  • Filter syntax: ip.src == 203.0.113.50 && tcp.flags.syn == 1
  • Statistics → Conversations (see top talkers)
  • Statistics → Protocol Hierarchy (see attack types)

Export for SIEM:

bash

# Convert PCAP to JSON for SIEM ingestion
tshark -r input_dropped.pcap -T json > dropped_packets.json

# Upload to Elasticsearch
curl -X POST "localhost:9200/firedog-logs/_bulk" -H 'Content-Type: application/json' --data-binary @dropped_packets.json

🧠 Threat Intelligence & Analysis

Traffic Analyzer with ML-like Scoring:

Firedog includes traffic-analyzer.py which scans PCAP files and assigns threat score 0-100 to each source IP.

Scoring Algorithm:

python

threat_score = (
    packet_volume_score +      # Volume anomalo
    port_diversity_score +     # Scansione porte multiple
    protocol_diversity_score + # Protocolli multipli (recon)
    critical_port_targeting +  # RDP, Telnet, MSSQL (honeypot signals)
    syn_flood_pattern +        # TCP SYN senza ACK
    known_malicious_ip         # Blacklist match
)

# Normalized 0-100

Detailed factors:

1. Packet Volume Score (0-25 points):

python

packets_per_minute = total_packets / time_window_minutes

if packets_per_minute > 1000: score = 25      # Flood attack
elif packets_per_minute > 500: score = 20
elif packets_per_minute > 100: score = 15
elif packets_per_minute > 50: score = 10
else: score = 5

2. Port Diversity Score (0-30 points):

python

unique_ports_targeted = len(set(destination_ports))

if unique_ports > 50: score = 30     # Comprehensive scan
elif unique_ports > 20: score = 25   # Port scan
elif unique_ports > 10: score = 18
elif unique_ports > 5: score = 10
else: score = 0  # Targeting specific service (legit possibile)

3. Critical Port Targeting (0-20 points):

python

critical_ports = [23, 3389, 1433, 3306, 5432, 445, 139]  # Telnet, RDP, SQL, SMB
score = 0

for port in destination_ports:
    if port in critical_ports:
        score += 5  # Cap at 20

Rational: Critical ports are rarely legit targets, often honeypot indicators.

4. SYN Flood Pattern (0-15 points):

python

syn_packets = count_packets_with_flag('SYN')
ack_packets = count_packets_with_flag('ACK')

syn_ack_ratio = syn_packets / (ack_packets + 1)  # +1 avoid division by zero

if syn_ack_ratio > 10: score = 15   # Quasi solo SYN = flood
elif syn_ack_ratio > 5: score = 10
elif syn_ack_ratio > 2: score = 5

5. Protocol Diversity (0-10 points):

python

unique_protocols = set([pkt.protocol for pkt in packets])

if len(unique_protocols) > 5: score = 10  # TCP + UDP + ICMP + ... = recon
elif len(unique_protocols) > 3: score = 7
elif len(unique_protocols) > 1: score = 3
```

---

**Threat Classification:**

| Score Range | Level | Indicatori | Azione Raccomandata |
|-------------|-------|------------|---------------------|
| **90-100** | 🔴 **CRITICAL** | Flood attack confermato, scan massivo, exploit tentativi multipli | **Immediate ban** IP, investigate compromissione, check logs altri sistemi |
| **70-89** | 🟠 **HIGH** | Port scan aggressivo, targeting porte critiche, volume elevato | **Temporary ban** (1-24h), monitoraggio stretto, correlazione con IDS |
| **50-69** | 🟡 **MEDIUM** | Attività sospetta ma non definitiva, possibile recon fase iniziale | **Log & alert**, no ban automatico, review manuale |
| **30-49** | 🟢 **LOW** | Anomalia leggera, potrebbe essere legit (e.g. vulnerability scanner autorizzato) | **Monitoring only**, verifica se IP è interno o partner |
| **0-29** | ⚪ **MINIMAL** | Traffico normale bloccato per policy restrittive (e.g. servizio non permesso) | **No action**, log per troubleshooting |

---

**Attack Pattern Recognition:**

**Port Scan Patterns:**
```
Sequential scan: 80, 81, 82, 83, ... (tools: nmap -sS)
Random scan: 8080, 443, 22, 3389, ... (tools: masscan)
Specific scan: 22, 2222, 22222 (SSH variants hunting)
```

**SYN Flood Pattern:**
```
Characteristics:
- High volume SYN packets (>500/sec)
- Low ACK response
- Source port randomization
- Often spoofed source IP
```

**Service Attack Pattern:**
```
Targeting specific vulnerability:
- Repeated requests to same port (e.g. 445 SMB - EternalBlue)
- Payload signatures (exploit code patterns)
- Timing patterns (exploit retry logic)
```

---

**Reporting & Recommendations:**

**Analyzer Output:**
```
=== Threat Analysis Report ===
Period: 2024-01-15 10:00 - 11:00 (1 hour)
Total IPs analyzed: 247

🔴 CRITICAL Threats (3):
├─ 203.0.113.50 [Score: 95/100]
│  ├─ Packets: 15,234 (flood)
│  ├─ Ports scanned: 127
│  ├─ Critical ports targeted: RDP, Telnet, MSSQL
│  ├─ Pattern: Horizontal + Vertical scan
│  └─ ⚠️ RECOMMENDATION: Permanent ban, report to ISP abuse@

├─ 198.51.100.20 [Score: 92/100]
│  ├─ Packets: 8,912
│  ├─ SYN flood detected (SYN/ACK ratio: 15:1)
│  └─ ⚠️ RECOMMENDATION: Immediate ban + check for DDoS botnet

🟠 HIGH Threats (12):
├─ 192.0.2.100 [Score: 78/100]
│  ├─ SSH brute force (480 attempts/hour)
│  └─ ⚠️ RECOMMENDATION: Implement fail2ban, consider VPN-only SSH

[... truncated for brevity ...]

💡 Strategic Recommendations:
1. Top attacked port: 22 (SSH) - Consider non-standard port or VPN requirement
2. Geographic anomaly: 80% attacks from CN/RU - Consider geo-blocking
3. Attack time: Peak 03:00-05:00 UTC - Schedule maintenance outside this window

🎛️ User-Friendly CLI Management

Firewall Manager (firewall-manager.py):

Python CLI tool that hides iptables complexity with intuitive interface.

Main commands:

1. Listing Rules:

bash

# List all rules
firewall-manager --list

# List specific chain
firewall-manager --list INPUT
firewall-manager --list OUTPUT

# Output example:
INPUT Chain Rules:
[1] ACCEPT tcp dpt:22 src:192.168.1.0/24  # SSH da LAN
[2] ACCEPT tcp dpt:80                     # HTTP
[3] ACCEPT tcp dpt:443                    # HTTPS
[4] DROP   tcp dpt:23                     # Telnet blocked

2. Adding Rules:

bash

# Open porta TCP (INPUT)
sudo firewall-manager --add-input 8080

# Open porta UDP
sudo firewall-manager --add-input 53 --protocol udp

# Open porta con source IP restriction
sudo firewall-manager --add-input 22 --source 192.168.1.10 --comment "SSH admin only"

# Open porta con subnet
sudo firewall-manager --add-input 3306 --source 10.0.0.0/8 --comment "MySQL internal network"

# OUTPUT rules (allow outgoing)
sudo firewall-manager --add-output 587 --comment "SMTP submission"
sudo firewall-manager --add-output 443 --dest 203.0.113.50 --comment "API server"

Validation:

  • Port range check (1-65535)
  • IP address validation (CIDR notation supported)
  • Protocol validation (tcp/udp/icmp)
  • Duplicate detection (prevent duplicate rules)

3. Removing Rules:

bash

# List rules with numbers
firewall-manager --list INPUT

# Remove by rule number
sudo firewall-manager --remove INPUT 5

# Confirmation prompt:
Remove rule: ACCEPT tcp dpt:8080
Are you sure? (y/n): y
✓ Rule removed successfully

4. Statistics & Analysis:

bash

# Show firewall statistics
firewall-manager --stats

# Output:
Firewall Statistics:
├─ Rules active: 23 (INPUT), 15 (OUTPUT)
├─ Packets processed (24h): 1,234,567
├─ Packets dropped (24h): 45,123 (3.7%)
├─ Top dropped source IPs:
│  ├─ 203.0.113.50: 12,345 packets
│  ├─ 198.51.100.20: 8,912 packets
│  └─ 192.0.2.100: 3,456 packets
└─ Most attacked ports: 22 (SSH), 3389 (RDP), 23 (Telnet)

5. Threat Analysis:

bash

# Analyze traffic ultima ora
sudo firewall-manager --analyze

# Analyze specific time range (hours)
sudo firewall-manager --analyze 24  # Last 24 hours

# Show only high-severity threats (score >= 70)
sudo firewall-manager --threats 70

# Output:
🔴 CRITICAL Threats (score >= 80):
├─ 203.0.113.50 [Score: 95]
│  └─ Port scan + SYN flood detected
└─ Recommendation: Permanent ban

🟠 HIGH Threats (score 70-79):
├─ 198.51.100.20 [Score: 78]
│  └─ SSH brute force (480 attempts)

6. Backup & Restore:

bash

# Save current rules
sudo firewall-manager --save
# Saved to: /etc/firewall/iptables.rules

# Backup with timestamp
sudo firewall-manager --backup
# Saved to: /etc/firewall/backups/iptables-20240115-103045.rules

# Restore from backup
sudo firewall-manager --restore /etc/firewall/backups/iptables-20240115-103045.rules

# List available backups
firewall-manager --list-backups

7. Testing & Dry-Run:

bash

# Test rule without applying (dry-run)
firewall-manager --add-input 8080 --dry-run

# Output:
[DRY-RUN] Would execute:
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

# Validate current ruleset (syntax check)
firewall-manager --validate

🔐 OWASP/NIST Security Compliance

Defense in Depth:

Firedog implements multiple layers of protection:

  1. Network layer: Packet filtering (iptables)
  2. Transport layer: Connection tracking, rate limiting
  3. Application layer: Pattern recognition (exploit signatures)
  4. Logging layer: PCAP for forensics
  5. Intelligence layer: Threat scoring, abnormally detection

If attacker bypasses a layer, other layers still protect.

Fail Secure:

Policy DROP default ensures that in case of:

  • Bad rule
  • Crash firewall daemon
  • Misconfiguration

→ System default lock all (fail-safe) instead of allow everything (fail-open insecure).

Last Privilege:

Only traffic explicitly necessary is allowed:

  • No "allow all" rules
  • Every open door must have justification
  • OUTPUT filtering (unusual but important): prevents data exfiltration, C2 communication

& Logging Audit:

PCAP logging complete allows:

  • Incident reconstruction
  • Compliance audit (PCI-DSS Req 10: logging)
  • Forensic analysis post-beach
  • Threat intelligence generation

Retention: Configurable for compliance (e.g. PCI-DSS requires 1 year log retention).

Rate Limiting:

Protection against resource exhaustion:

  • Connection rate limiting (anti-flood)
  • Packet rate limiting (anti-DDoS)
  • Per-IP limits (prevent single source overwhelming)

Input Validation:

Firedog valid for every package:

  • TCP flags validation
  • IP address validation (anti-spoofing)
  • Fragmentation validation (anti-evasion)
  • Protocol compliance (RFC-compliant packets only)

Cases of Use

Case 1: WordPress E-commerce – Exposed Site Protection

Scenario:
Online WordPress shop on VPS, 5000 visitors/day. 3-4 attacks/week: brute force wp-admin, vulnerability scan, DDoS attempts.

Before Firedog:

  • Cloud provider firewall only (basic)
  • Apache saturated attacks (downtime)
  • Unusable log access.log (too much noise)
  • WordPress security plugin ineffective against network attacks

Firedog implementation:

Day 1 – Deployment:

bash

# Install Firedog
curl -sSL https://firedog.dognet.tech/install.sh | sudo bash

# Apply web-server template
sudo firewall-init.sh --template web-server

# Rules applicate:
├─ Allow 80, 443 (HTTP/HTTPS)
├─ Allow 22 from admin IP only (SSH)
├─ Block 3389, 23, 445 (RDP, Telnet, SMB - not needed)
├─ Rate limiting: max 100 req/sec per IP
├─ SYN flood protection active
└─ Port scan detection active

Week 1 – Tuning:

  • Alert Slack when threat score >70
  • Whitelist Cloudflare IPs (if they use CDN)
  • Automatic IP ban with score >90

Results after 1 month:

  • Attack success rate: 100% → 0% (zero downtime from attacks)
  • Apache load: -40% (malevolent traffic blocked before reaching Apache)
  • Bandwidth saving: ~20GB/month (attack traffic dropped)
  • Incident response time: 2 hours → 10 minutes (alert immediate + PCAP analysis)
  • Positive False: <1% (legit users blocked – quick whitelist)

Specific attack blocked:

  • XMLrpc.php DDoS: 50k blocked requests (WordPress vulnerability common)
  • wp-login.php brute force: 1200+ attempts from botnet (SSH protection analog)
  • Vulnerability scanner: Nessus/Acunetix scan from competitor (port scan detection)

Case 2: SaaS Startup – Multi-Tenant API Protection

Scenario:
SaaS B2B startup with REST API. 50 corporate customers. API keys leak on GitHub → credential stuffing attack. 100k unauthorized API calls in 2 hours.

Problem:

  • Application-level rate limiting exists but late (requests already processed)
  • Overwhelmed database (query for each auth check)
  • Legit customers impacted (general slowdown)

Firedog implementation:

Emergency Response:

bash

# Block attacking IPs (identified from application logs)
for ip in $(cat /tmp/attacking_ips.txt); do
    sudo firewall-manager --add-input --source $ip --action DROP
done

# Rate limit API port aggressively
sudo iptables -A INPUT -p tcp --dport 8080 -m limit --limit 50/sec --limit-burst 100 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 8080 -j DROP

Attack mitigated in 5 minutes.

Long-term Solution:

  • Geo-blocking: API clients are only US/EU → block CN/RU/IN (where leak deployed)
bash
# Using ipset for efficient geo-blocking
sudo ipset create geoblock_cn hash:net
sudo ipset add geoblock_cn 1.0.0.0/8  # China CIDR blocks
# ... (add all China IP ranges)
sudo iptables -A INPUT -p tcp --dport 8080 -m set --match-set geoblock_cn src -j DROP
```

- **API key rotation enforcement**: Email clienti per rotate leaked keys
- **Firedog monitoring**: Alert se spike request da IP sconosciuto

**Risultati:**
- **Attack stopped**: 5 minuti (vs 2 ore senza Firedog)
- **Database load**: Reduced 80% (malicious requests never reach app)
- **Customer impact**: Minimized (only 5 min slowdown)
- **Reputation saved**: No public disclosure needed (handled internally)

Case 3: Healthcare – Segmentation HIPAA Network

**Scenario:**
Clinic with EHR system. HIPAA compliance requires network segmentation: DMZ, EHR network, Administrative network. Firedog on gateway server for enforcement.

**Network Topology:**
“`
Internet
│
[Firedog Gateway]
├─ DMZ (Web server, public-facing)
├─ EHR Network (Database, application servers – PHI date)
└─ Admin Network (Staff workstations)

Firedog Rules:

DMZ → EHR Network:

bash

# Allow ONLY web server to database (specific IP + port)
sudo firewall-manager --add-forward --source 10.0.1.10 --dest 10.0.2.5 --port 5432 --comment "Web to DB"

# Block everything else from DMZ to EHR
sudo iptables -A FORWARD -s 10.0.1.0/24 -d 10.0.2.0/24 -j DROP

Admin Network → EHR Network:

bash

# Allow admin workstations to EHR application (HTTPS only)
sudo firewall-manager --add-forward --source 10.0.3.0/24 --dest 10.0.2.10 --port 443

# Allow database admin access (restricted IP)
sudo firewall-manager --add-forward --source 10.0.3.50 --dest 10.0.2.5 --port 5432 --comment "DBA access"

Internet → DMZ:

bash

# Allow HTTPS only
sudo firewall-manager --add-input 443

# Block everything else (including SSH - use VPN)

Logging for HIPAA Audit:

  • Every FORWARD rule logs (audit trail)
  • PCAP retention 2 years (HIPAA requirement)
  • Monthly review report generated automatically

Compliance Result:

  • HIPAA Security Rule §164.312(a)(1): Network segmentation enforced ✅
  • §164.312(b): Full Audit logs ✅
  • Penetration test: Attended lateral movement from DMZ → EHR blocked ✅

Case 4: Manufacturing – SCADA/ICS protection

Scenario:
Manufacturing company with SCADA (Industrial Control System) system for production line. SCADA network must be air-gapped but has enterprise network connection for remote monitoring.

Risk:

  • SCADA protocols (Modbus, OPC) have no native security
  • Ransomware on corporate networks can propagate to SCADA
  • SCADA devices not patchable (vendor EOL, critical uptime 99.9%)

Firedog implementation:

Firewall SCADA Gateway:

bash

# Whitelist ONLY: Engineering workstation → SCADA devices
sudo firewall-manager --add-forward --source 192.168.100.50 --dest 10.10.0.0/24 --comment "Engineer to SCADA"

# Whitelist: SCADA historian (monitoring) → Corporate DB (report)
sudo firewall-manager --add-forward --source 10.10.0.10 --dest 192.168.1.100 --port 1433

# DENY everything else (default policy)
# Especially: Block corporate workstations → SCADA (prevent ransomware spread)

Monitoring Alerts:

bash

# Alert if ANY non-whitelisted traffic attempts SCADA access
sudo firewall-manager --alert-on-drop --dest 10.10.0.0/24 --notify slack

Virtual Patching (SCADA Vulnerability):

  • SCADA PLC has critical vulnerability (CVE-2023-XXX), no patch available (EOL device)
  • Firedog blocks exploit pattern:

bash

# Block specific exploit traffic pattern (identified by ICS-CERT advisory)
sudo iptables -A FORWARD -d 10.10.0.5 -m string --algo bm --hex-string '|504c4320...|' -j LOG --log-prefix "SCADA_EXPLOIT_ATTEMPT: "
sudo iptables -A FORWARD -d 10.10.0.5 -m string --algo bm --hex-string '|504c4320...|' -j DROP

Incident Response:

  • Corporate network infected with ransomware (WannaCry variant)
  • Ransomware attributes propagated via SMB
  • Firedog blocks: SMB (445) corporate traffic → SCADA
  • Result: SCADA network untouched, production continues
  • Downtime avoided: €500k/hour production loss

Compliance:

  • IEC 62443 (Industrial security standard): Network segmentation required ✅
  • NIS2 Directive (EU critical infrastructure): Protective measurements documented ✅

Case 5: Hosting Provider – Multi-Tenant Security

Scenario:
Hosting provider with 500 VPS customers on the same infrastructure. Need isolation between tenant, protection shared resources.

Challenge:

  • Some customers are high-profile targets
  • DDoS on customer A must not impact customer B
  • Prevent lateral movement if client compromised

Firedog implementation (on each VPS):

Automated Deployment:

bash

# Ansible playbook per deploy Firedog su 500 VPS
---
- hosts: all_vps
  tasks:
    - name: Install Firedog
      shell: curl -sSL https://firedog.dognet.tech/install.sh | bash
    
    - name: Apply base template
      command: firewall-init.sh --template vps-hosting
    
    - name: Configure tenant-specific rules
      template:
        src: firewall-rules.j2
        dest: /etc/firewall/custom_rules.conf
      vars:
        allowed_ports: "{{ tenant_allowed_ports }}"
        admin_ip: "{{ tenant_admin_ip }}"

Tenant Isolation:

bash

# Each VPS can ONLY communicate with:
# - Internet (outbound)
# - Hosting provider management network (inbound admin)
# - NO inter-VPS communication

# Block RFC1918 destinations (prevent lateral movement)
sudo iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
sudo iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
sudo iptables -A OUTPUT -d 192.168.0.0/16 -j DROP

# Exception: Allow DNS to hosting resolver
sudo iptables -I OUTPUT -d 10.0.0.53 -p udp --dport 53 -j ACCEPT

DDoS Protection for Tenant:

  • Firedog rate limiting for VPS
  • If VPS receives >10k pkt/sec → automatic upstream notification (BGP blackhole route)
  • PCAP captured for forensics

Centralized Monitoring:

  • Hosting dashboard provider: Real-time threat score all VPS
  • Alert if VPS compromise (unusual outbound traffic pattern)
  • Automatic forty: Comromised VPS isolated network

Results:

  • Tenant satisfaction: +15% (improved security posture)
  • DDoS incident: -70% (early detection + mitigation)
  • Support tickets: -30% (less "my VPS slow" – better noisey neighbor prevention)
  • Compliance: SOC 2 Type II audit passed (isolation controls documented)

FAQ – Firedog

General

Q: Firedog replaces hardware firewall (Fortinet, Palo Alto)?
A: No, Firedog is host-based firewall (turns on the server itself), not perimeter firewall. They Additional:

  • Perimeter firewall: First line defense, filters incoming/outgoing network traffic
  • Firedog: Second line defense, protects single host even if attacker bypass perimeter

Defense-in-depth: Both layers are important.

Q: Does it only work on Linux?
A: Currently yes (iptables/nftables are Linux-specific).
Roadmap: Windows Firewall version (Q2 2026), macOS pf version (Q4 2026).

Q: Need advanced Linux expertise?
A: No, CLI Python (firewall-manager) hides iptables complexity. Intuitive commands:

bash

# Instead of:
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

# You write:
firewall-manager --add-input 8080

Learning Curve: 30 minutes for basic operations, 2-3 hours for advanced tuning.

Q: How much is it?
A: Licensing: For servers, not for traffic/rules/features.

Deployment & Configuration

Q: How much time do you need for deployment?
A: Basic setup: 15-30 minutes

bash

# 3 comandi:
curl -sSL https://firedog.dognet.tech/install.sh | sudo bash  # 5 min
sudo firewall-init.sh --template web-server                    # 2 min
sudo systemctl enable --now firedog                             # 1 min

Production-ready (with tuning): 2-4 hours (testing, whitelist, alert config).

Q: Can I test without impacting production?
A: Yes, dry-run mode:

bash

# Apply rules in LOG-only mode (no DROP)
sudo firewall-init.sh --template web-server --mode log-only

# Monitor logs for false positives (24-48h)
tail -f /var/log/firedog/blocked.log

# If looks good, activate blocking
sudo firewall-init.sh --template web-server --mode enforce

Q: What happens if the wrong rule lock me out (SSH)?
A: Safety mechanisms:

  1. Auto-rollback: If unreachable server after 5 min → automatic rollback
  2. Console accessed: Physical access/ IMPS bypass firewall
  3. Rescue mode: Boot in rescue, disabled firewall, fix rules

Best practice: ALWAYS test on staging first, keep console access ready.

Q: Does it support pre-configured templates?
A: Yes, template for use common cases:

  • web-server: Apache/Nginx (80, 443, 22)
  • database-server: MySQL/PostgreSQL (3306, 5432, 22)
  • mail-server: SMTP/IMAP/POP3 (25, 587, 143, 993, 110, 995)
  • vpn-gateway: OpenVPN/WireGuard (1194, 51820)
  • dns-server: BIND (53 UDP/TCP)
  • minimal: SSH only (22) – ultra-restrictive
  • custom: Build your own

Usage:

bash

sudo firewall-init.sh --template web-server

Q: Can I use Firedog with cloud provider firewall (AWS Security Groups, Azure NSG)?
A: Yes, layered approach (recommended):

  • Cloud firewall: First layer, coarse rules (e.g. allow 80/443 from 0.0.0.0/0)
  • Firedog: According to layer, fine rules (e.g. rate limiting, anti-brute-force)

Benefit: If attacker bypasses cloud firewall (misconfiguration), Firedog still protects.

Protection & Threat Detection

Q: SYN flood protection is effective against DDoS?
A: Partially:

  • ✅ Effective: Small/medium DDoS (<10Gbps), single-source attacks
  • ⚠️ Limited: Large DDoS (>10Gbps), distributed attacks (100k+ sources)

For massive DDoS you need:

  • Upstream mitigation (ISP, Cloudflare, AWS Shield)
  • Anycast network
  • Scrubbing centers

Firedog protects: Application-layer after DDoS mitigation (L7 attacks passing CDN).

Q: How many false positives does port scan detection generate?
A: Threshold configurable:

  • Aggressive (>10 ports/min): ~5-10% false positive (vulnerability scanner legit)
  • Balanced (>15 doors/min): ~1-2% false positive (default)
  • Conservative (>30 doors/min): <1% false positive but miss some scan

Tuning: After 1 week monitoring, adjust threshold for your environment.

Q: SSH brute force protection is better than fail2ban?
A: Similar but Integrated:

FeatureFiredogfail2ban
Limiting rate✅ Kernel-level (iptables)✅ Userspace (log parse)
PerformanceFaster (no log parsing)Slower (regex log)
IntegrationNative FiredogSeparate daemon
FlexibilityLimited (SSH, HTTP)High (any service)
RecommendedFiredog + fail2ban combofail2ban if only tool

Best practice: Use both – Firedog for immediate protection, fail2ban for custom services.

Q: Is Threat Score Accurate? How many false positives?
A: Accuracy ~85-90% After tuning:

Common false positives:

  • Vulnerability scanner authorized (Nessus scan) → score 70+ (looks like attack)
    • Mitigation: Whitelist IP Scanner
  • Load balancer health checks → high volume packs
    • Mitigation: Whitelist LB IP
  • Backup software → port scanning (looking for services to backup)
    • Mitigation: Whitelist backup server

Tuning: After 2 weeks, false positive rates <5%.

Q: PCAP logging impact performance?
A: Overhead ~2-5%:

  • CPU: +3-5% (ulogd2 processing)
  • I/O Disk: Depends on traffic volume (high traffic = high I/O)
  • RAM: +50-100MB (ulogd2 buffering)

Mitigation for high-traffic:

  • Use SSD (write-intensive PCAP)
  • Dedicated core CPU for ulogd2 (taskset)
  • Reduce logging verbosity (log only DROP, not all traffic)
  • Shorter retention (7 days instead 30)

High Traffic Servers (>100Mbps supported): Consider dedicated logging server (remote ulogd2).

Integration with Sentinel Suite

Q: Does Firedog communicate with MicroSIEM and Sentinel Core?
A: Yes, with Integration Pack:

Firedog → MicroSIEM:

  • Threat alerts forwarded to MicroSIEM dashboard
  • PCAP files accessible from MicroSIEM (for correlation)
  • Unified alerting (Slack notification with context from both tools)

Sentinel Core → Firedog:

  • Critical vulnerability discovered → Firedog auto-block affected port
  • Exploit confirmed (by Intellidog) → Firedog create virtual patch rule

Firedog ↔ MicroSIEM Intellidog:

  • Intellidog analysis Firedog PCAP for exploit detection
  • Virtual patching orchestrated through Firedog API

Q: Is Integration Pack mandatory?
A: NoFiredog works standalone. Integration Pack is optional for automation cross-tool.

Q: Can I use Firedog without other suite tools?
A: Absolutely.. Firedog is fully functional independently. Integration is bonus, not requirement.

Compliance & Reporting

Q: Does Firedog help with PCI-DSS compliance?
A: Yes, specifically.:

  • Requirements 1.2.1: Restriction inbound/outbound traffic ✅ (DROP policy)
  • Requirements 1.3: Prohibit direct public access between Internet and cardholder data ✅ (network segmentation)
  • Requirements 10.2: Implementation automated audit trails ✅ (PCAP logging)

Gap: PCI-DSS also requires physical firewall. Firedog is complementary, not substitute.

Q: PCAP logs are audit-ready?
A: Yes:

  • Timestamp NTP-synced (accurate timing)
  • Immutable (append-only, can’t modify past events)
  • Standard format (PCAP – universally readable)
  • Configurable retention (e.g. 1 year for PCI-DSS)

Auditor can:

  • Open PCAP in Wireshark
  • Verify timestamp authenticity
  • Replay attack sequences

Q: Does Firedog generate compliance reports?
A: Roadmap v2.0 (Q3 2025): Automated compliance report generation.

Currently: Manual report via:

bash

# Generate summary
sudo traffic-analyzer --report --format pdf --output compliance-report.pdf

# Include:
# - Blocked attacks summary
# - Top threat sources
# - Protection efficacy metrics

Troubleshooting & Support

Q: How to debug if legitimate service is blocked?
A: Troubleshooting steps:

Step 1: Check logs

bash

# View recent drops
sudo tail -100 /var/log/ulogd/input_dropped.log | grep <service_port>

Step 2: Temporary allow

bash

# Allow temporarily (1 hour)
sudo firewall-manager --add-input <port> --temporary 3600

Step 3: If works, make permanent

bash

sudo firewall-manager --add-input <port> --comment "Service X"

Q: Firedog blocks everything after system update, how fix?
A: Common Causes: Kernel upgrade broke iptables modules.

Fix:

bash

# Reload modules
sudo modprobe ip_tables
sudo modprobe iptable_filter
sudo modprobe nf_conntrack

# Restart Firedog
sudo systemctl restart firedog

Q: PCAP files grow too fast, how to manage?
A: Options:

1. Reduce retention:

bash

# /etc/logrotate.d/firedog-pcap
rotate 7  # Instead of 30

2. Compressed aggressively:

bash

compress
compresscmd /usr/bin/xz  # Better compression than gzip

3. Offload to cold storage:

bash

# Cron job: Upload to S3 Glacier dopo 7 giorni, delete local
0 2 * * * aws s3 cp /var/log/ulogd/*.pcap.7.gz s3://mybucket/firedog-logs/ && rm -f /var/log/ulogd/*.pcap.7.gz

4. Log only critical:

bash

# Don't log INFO-level drops, only HIGH/CRITICAL
# (requires custom ulogd2 config)

Q: Support includes incident response?
A: Support tiers:

Standard (including):

  • Email support for configuration issues
  • Troubleshooting legitimate blocks
  • False positive tuning advice

Premium (+€2000/year):

  • 24/7 phone support
  • Incident response guidance (not hands-on, but advisory)
  • Custom rule development

Professional Services (€150/hour):

  • Hands-on incident response
  • PCAP forensic analysis
  • Post-incident remediation

Technical Deep Dive

Q: Difference between iptables and nftables?
A: nftables is a modern successor to iptables:

FeatureiptablesnftablesPerformanceGoodBetter (20-30% faster)SyntaxComplexSimpler, more consistentIPv4/IPv6Separate toolsUnifiedScriptingLimitedBetter (transaction-based)

Firedog support:

  • v1. x: iptables (maximum compatibility)
  • v2.0 (roadmap 2025): nftables support

Q: Can I use Firedog with Docker containers?
A: Yes, with caveat:

Scenario 1: Firedog on host, protect Docker:

bash

# Firedog rules si applicano PRIMA di Docker iptables manipulation
# Works, but Docker potrebbe bypass alcune rules

Scenario 2: Firedog in container (not recommended):

bash

# Container non ha accesso privilegiato a iptables host
# Needs --privileged flag (security risk)

Best practice: Firedog on host, + container-specific firewall (e.g. network policy in Kubernetes).

Q: Firedog scale for >1Gbps traffic?
A: Limitations:

  • iptables/nftables are firewall software (CPU-bound)
  • Typical performance: ~5-10Gbps on high-end server (16 core, 3GHz+)
  • Bottleneck: Connection tracking table (default 65536 entries)

Optimization for high traffic:

bash

# Increase connection tracking table
echo 262144 > /proc/sys/net/netfilter/nf_conntrack_max

# Reduce connection tracking timeout (free entries faster)
echo 60 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established

# Dedicate CPU cores to network interrupts (IRQ affinity)

For >10Gbps: Hardware firewall (FPGA-based) or XDP (eXpress Data Path) – roadmap Firedog v3.0.

Q: Does it support IPv6?
A: Yes, full dual-stack:

bash

# All Firedog rules applied to both IPv4 and IPv6
firewall-manager --add-input 80  # Applies to both iptables and ip6tables

IPv6-specific considerations:

  • ICMPv6 must be partially allowed (Neighbor Discovery Protocol)
  • IPv6 address notation (::1, fe80::/10, etc.)

Q: API available for automation?
A: Roadmap v2.0 (Q2 2025): REST API for:

  • Add/remove rules programmatically
  • Query threat score
  • Retrieve PCAP via API (for SIEM integration)

Currently: CLI scripting:

bash

# Ansible example
- name: Open port 8080
  command: firewall-manager --add-input 8080

CONTACT US

Contact Sales Team

Contact us

Dognet Technologies SRL

Via XXV April 47, 24055
Colony to the Serius (Bg)

Tel: 351.5568240 | 352.0321176

Mail: info@dognet.tech

PI and CF: 04867480164
BG N.R.E.A. 495176

Italy

Pages

Proudly powered by WordPress

EnglishenEnglishEnglish
ItalianitItalianItalianoEnglishenEnglishEnglish