NetSec Intrusion Detection Systems
An Intrusion Detection System (IDS) monitors network traffic or system activity and raises alerts when it detects suspicious behavior that may indicate an attack. An IDS watches and reports — it does not block traffic. Think of it as a security camera system: it records and alerts, but it does not physically stop an intruder.
IDS vs IPS
IDS (Intrusion Detection System): Network → [IDS monitors copy of traffic] → Alert sent to security team Network traffic continues unaffected, IDS just observes IPS (Intrusion Prevention System): Network → [IPS sits inline] → blocks threats in real time → clean traffic passes Traffic can be dropped before reaching the destination
Two Deployment Types
Network-Based IDS (NIDS)
A NIDS monitors all traffic flowing across a network segment. It typically connects to a network switch via a SPAN (mirror) port, which sends a copy of all traffic to the NIDS without interrupting the actual traffic flow. NIDS provides visibility into everything crossing the network.
NIDS ARCHITECTURE:
[ Internet ] → [ Firewall ] → [ Core Switch ]
│
SPAN/Mirror port
│
[ NIDS Sensor ] → Alerts → [ Security Console ]
The NIDS receives a copy of all traffic — it cannot block anything directly,
but it sees everything and alerts on suspicious patterns.
Host-Based IDS (HIDS)
A HIDS runs as software on an individual device. It monitors system calls, file integrity, log files, and running processes on that specific machine. HIDS detects attacks that have already reached the device — including insider threats and malware executing on the system.
HIDS monitors on each endpoint: ┌─────────────────────────────────────────────┐ │ Server running HIDS agent │ │ │ │ Monitors: │ │ • System files (are config files changed?) │ │ • Running processes (is malware running?) │ │ • User logins (unusual time or location?) │ │ • Privilege escalations (sudo/runas usage) │ │ • Network connections (unexpected outbound)│ └─────────────────────────────────────────────┘ Alert → Security console if anything suspicious detected
Detection Methods
Signature-Based Detection
The IDS compares traffic against a database of known attack signatures — like a virus database for network attacks. A signature might be: "any packet containing the string '/etc/passwd' in an HTTP request" or "a TCP SYN packet to 1,000 different ports within one second." When traffic matches a signature, the IDS fires an alert.
Signature Example: SQL Injection signature: Input contains ' OR '1'='1 or UNION SELECT IDS sees POST request with ' OR '1'='1 in parameter → Match found → Alert: "SQL Injection Attempt Detected" → Logged with source IP, timestamp, request details → Security analyst notified Advantage: Very low false positives for known attacks Weakness: Cannot detect new (zero-day) attacks with no signature yet
Anomaly-Based Detection
The IDS establishes a baseline of normal behavior over time, then alerts when behavior deviates significantly from that baseline. Anomaly detection catches novel attacks that have no signature but exhibit unusual patterns.
Anomaly Detection Example: Baseline (normal): User alice logs in: 8am–6pm weekdays Downloads: ~50 files/day Data volume out: ~10 MB/day Anomaly detected (Sunday 3am): alice logs in (unusual time) Downloads 4,000 files in 20 minutes Sends 8 GB of data to external IP → ALERT: Data exfiltration pattern detected Advantage: Can detect new and unknown attack patterns Weakness: Higher false positive rate; requires careful tuning
Behavioral Analysis
A refinement of anomaly detection that focuses on sequences of events rather than single events. Normal user behavior is not just about quantity — it follows patterns. An attacker who compromises an account might perform the right individual actions but in an unusual sequence.
Alert Types: True Positive, False Positive, False Negative
Alert Type | Definition | Impact
-----------------|-----------------------------------|----------------------
True Positive | Real attack correctly detected | Good — respond to it
False Positive | Legitimate traffic flagged as bad | Analyst fatigue, wasted time
False Negative | Real attack NOT detected | Bad — attack goes unnoticed
True Negative | Normal traffic correctly ignored | Good — no alert needed
Goal: Maximize True Positives and True Negatives
Minimize False Positives (alert fatigue) and False Negatives (missed attacks)
IDS Placement Strategies
Placement | What It Detects -------------------------------|----------------------------------------------- Outside the firewall | All external attack attempts (noisy) Inside the firewall | Attacks that bypass or pass through firewall In the DMZ | Attacks on public-facing servers On internal network | Lateral movement, insider threats On critical servers (HIDS) | Attacks that have reached the server itself Between VLANs | Cross-VLAN attacks, policy violations
IDS Limitations
Limitation | Implication -------------------------------|---------------------------------------------- Cannot block traffic | Alert must be acted on by a human or IPS Encrypted traffic | Cannot inspect payload inside TLS without SSL inspection High false positive rate | Analysts get overwhelmed and start ignoring alerts Evasion techniques | Fragmented packets, protocol anomalies bypass signatures Requires constant tuning | Outdated rules = missed attacks Needs signature updates | New attacks are invisible until signature added
An IDS delivers value only when its alerts are reviewed and acted upon promptly. An IDS generating 10,000 alerts per day that nobody reviews provides false confidence — the organization believes it is monitored when it is not. Successful IDS deployments invest as much in the response process and analyst training as in the technology itself.