Skip to content

Services, Wiki-Artikel, Blog-Beiträge und Glossar-Einträge durchsuchen

↑↓NavigierenEnterÖffnenESCSchließen
Netzwerksicherheit Glossary

Intrusion Prevention System (IPS) - Aktive Angriffserkennung und -abwehr

An Intrusion Prevention System (IPS) analyzes network traffic in real time and actively blocks detected attacks, unlike an Intrusion Detection System (IDS), which only detects and alerts. IPS modes: inline (packet filtering in the network path), passive (out-of-band) with TCP reset. Detection methods: signature-based (Snort rules), anomaly-based (baseline comparison), behavior-based (UEBA). Integration into NGFW platforms (Palo Alto, Fortinet).

Intrusion Prevention System (IPS) is the active extension of the IDS concept: Instead of merely detecting and reporting attacks, an IPS blocks attack traffic in real time. Modern NGFWs (Next-Generation Firewalls) integrate IPS functionality directly into the firewall architecture, thereby combining perimeter protection with attack blocking.

IDS vs. IPS: Fundamental Difference

IDS vs. IPS Comparison:

IDS (Intrusion Detection System):
  → Passive: analyzes traffic as a copy (SPAN port)
  → Detects and reports: no interference with traffic
  → No latency (traffic is not slowed down)
  → False positives: no damage (only false alerts)
  → Deployment: Out-of-Band (separate from the network)

IPS (Intrusion Prevention System):
  → Active: located in the network path (inline)
  → Detects AND blocks: traffic is filtered
  → Minimal latency (packet inspection takes time)
  → False positives: legitimate traffic blocked! → serious
  → Deployment: In-line (between firewall and network)

  ┌──────────────────────────────────────────┐
  │                                          │
  │  Internet → Firewall → [IPS] → Network  │  IPS inline
  │                        ↓                 │
  │                    Drop/Block            │
  │                                          │
  │  Internet → Firewall → Switch → Network │  IDS out-of-band
  │                            ↓             │
  │                         [IDS]            │
  │                     Alert/Log only       │
  └──────────────────────────────────────────┘

Hybrid approach (recommended):
  → Critical segments: Inline IPS (immediate blocking)
  → Monitoring segments: Out-of-band IDS (no risk of false positives)
  → Modern NGFWs: both in a single device

IPS Detection Methods

Detection engines:

1. Signature-based detection:
   → Known attack patterns in database
   → Snort rules, Suricata rules (open source)
   → Commercial threat intelligence feeds

   Snort rule example:
   alert tcp any any -> $HOME_NET 22 (
     msg:"Possible SSH brute force";
     threshold: type threshold, track by_src, count 10, seconds 60;
     sid:10001; rev:1;
   )

   Advantages: low false positive rate for known attacks
   Disadvantages: blind to zero-days and new attack methods

2. Anomaly-based detection:
   → Baseline: normal behavior (volumes, protocols, connections)
   → Alert: if deviation from baseline (e.g., +300% DNS traffic)
   → Advantages: detects new/unknown attacks
   → Disadvantages: high false positive rate, time-consuming baseline maintenance

3. Behavior-based detection:
   → Detects attack patterns over time (not just individual packets)
   → Example: Port-scan pattern across 100 hosts → Alert
   → Stateful Inspection: tracks the state of connections

4. Protocol anomaly detection:
   → Deviations from RFC (e.g., malformed HTTP headers)
   → Detects HTTP smuggling
   → Malformed packets (could be an exploit attempt)

5. Reputation-based detection:
   → Block known malicious IPs/domains
   → Threat Intelligence Feeds: MISP, VirusTotal, Shodan
   → Geoblocking: Block traffic from specific countries

Next-Generation IPS in NGFW

NGFW with integrated IPS (Palo Alto Networks):

Palo Alto IPS configuration:
  # Security Policy with Threat Profile:
  set rulebase security rules "Allow-Web" profile-setting profiles {
    virus: default-av-profile
    spyware: strict
    vulnerability: strict    # IPS profile!
    url-filtering: default
    file-blocking: basic-file-blocking
    wildfire-analysis: default
  }

  # Vulnerability Protection Profile (IPS):
  # Critical CVEs: Block + Alert
  # High Severity: Alert + PCAP
  # Medium: Alert
  # Low: Alert

  # Threat Prevention → IPS Signatures:
  # → Snort-compatible rules can be imported
  # → Custom rules for internal applications

Fortinet FortiGate IPS:
  config ips sensor
    edit "high-security-ips"
      set comment "IPS for DMZ"
      config entries
        edit 1
          set severity high critical
          set action block
        next
        edit 2
          set severity medium
          set action default  # From signature configuration
        next
      end
    next
  end

  # Apply IPS in Security Policy:
  config firewall policy
    edit 1
      set ips-sensor "high-security-ips"
    next
  end

IPS bypass techniques (pentest perspective):
  → Encryption: HTTPS → IPS cannot inspect (without SSL inspection)
  → Fragmentation: split large packets into small ones → IPS patterns not detected
  → Encoding: URL encoding, Unicode → Bypass pattern matching
  → Slow attacks: very slow requests → No rate-based rules
  → Protocol-level tricks: Exploit RFC compliance
  → Evasion: Snort evasion techniques (known since the 2000s!)

IPS Tuning and Operation

False Positive Management - Most Critical Task:

Problem: Too many false positives → IPS is disabled (worst solution!)

Tuning Process:
  1. Set IPS to "Alert Mode" first (no blocking!)
  2. 2–4 weeks: Analyze all alerts
  3. Identify FP patterns: Which rules are triggering legitimate traffic?
  4. Create exceptions (only for verified FPs!)
  5. Enable blocking for critical rules
  6. Iteratively switch additional rules to blocking

Exceptions:
  # Suricata - Disable rule:
  # /etc/suricata/disable.conf:
  # 2010937  # Example SID generating the FPs

  # Disable only for specific IP ranges (better!):
  # /etc/suricata/threshold.conf:
  suppress gen_id 1, sig_id 2010937, track by_src, ip 10.0.0.0/8

IPS Performance:
  → Throughput depends on enabled rules
  → Rule set size: more rules = more CPU
  → SSL inspection: very CPU-intensive (30–70% throughput reduction!)
  → Hardware sizing: always include a buffer for peaks

IPS Monitoring:
  □ Alert volume: daily, weekly, monthly (trends!)
  □ Top 10 rules: which rules have the most hits?
  □ Blocked traffic: what is being blocked?
  □ Evasion attempts: encoded attacks, fragmented packets
  □ IPS health: are signature updates current? (daily!)

Syslog → SIEM Integration:
  → IPS Alerts → SIEM (all blocking events)
  → Correlation: IPS alert + EDR alert for same IP → high confidence
  → Threat Intelligence: Check blocked IPs against OSINT