IDS vs IPS

Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) are security technologies that monitor network traffic for malicious activity. The fundamental difference is that an IDS is a passive monitoring system, while an IPS is an active inline system. An IDS only generates alerts when it detects suspicious activity; it does not take action to block or prevent the traffic. An IPS, on the other hand, sits directly in the traffic path and can automatically block or drop malicious packets in real time.

Both systems analyze network packets and compare them against signatures of known attacks or behavioral baselines. They are critical for detecting and preventing threats such as malware, exploits, and policy violations. On the SY0-701 exam, you must know the specific characteristics, advantages, and disadvantages of each, as well as the detection methods they use.

IDS Operation: - An IDS receives a copy of network traffic from a network tap or SPAN port. It does not sit inline, so traffic flows through the network without passing through the IDS. - The IDS processes packets, reassembles streams, and applies detection rules (signatures, anomaly baselines, or stateful protocol analysis). - When a match occurs, the IDS generates an alert and logs the event. It may also send notifications via email, syslog, or to a SIEM. - The IDS cannot drop or modify the malicious traffic; it only reports. Response depends on human intervention or external systems.

IPS Operation: - An IPS is deployed inline, meaning all traffic must pass through the IPS device. It acts as a bump in the wire. - The IPS inspects packets in real time and can take immediate action: drop the packet, reject the connection, reset the TCP session, or block the source IP. - IPS actions are automatic and occur within milliseconds, preventing the attack from reaching the target. - Because it is inline, a failure of the IPS can cause a network outage (unless configured in fail-open mode).

Detection Methods: - Signature-based: Compares traffic against known attack patterns (e.g., Snort rules). Effective for known threats but cannot detect zero-day attacks. - Anomaly-based: Establishes a baseline of normal traffic and flags deviations. Can detect novel attacks but has high false positive rates. - Behavioral-based: Monitors for specific behaviors (e.g., multiple failed logins, port scans) rather than packet content. - Stateful Protocol Analysis: Understands protocol states (e.g., TCP handshake) and detects violations (e.g., invalid flags).

Deployment Modes: - Network-based (NIDS/NIPS): Monitors traffic at network boundaries. Examines headers and payloads. - Host-based (HIDS/HIPS): Runs on individual endpoints, monitoring system logs, file integrity, and process activity. Examples: OSSEC (HIDS), Windows Defender Firewall with Advanced Security (HIPS). - Wireless (WIDS/WIPS): Monitors wireless traffic for rogue APs, deauthentication attacks, etc.

Response Actions (IPS): - Drop packet - Reject connection (sends TCP RST or ICMP unreachable) - Block source IP for a duration - Reset TCP session - Shun (block) traffic from a source

Standards and Tools: - Snort (open-source NIDS/NIPS) - Suricata (open-source, multi-threaded, supports file extraction) - Zeek (formerly Bro, focuses on network analysis) - Cisco Firepower (commercial NGFW with IPS) - McAfee Network Security Platform - RFC 2827 (ingress filtering) relates to IPS placement

Evasion Techniques: - Fragmentation: Split attack payload across multiple packets to evade signature matching. IDS/IPS must reassemble fragments correctly. - Encryption: Attackers use TLS/SSL to hide payload. IDS/IPS needs decryption capabilities (e.g., SSL inspection). - Obfuscation: Encoding payload (e.g., Unicode, base64) to bypass signature detection. - TTL manipulation: Send packets with short TTL so they expire before reaching the IPS but arrive at the target. - Polymorphic code: Attack payload changes each time, evading signature-based detection.

Defender Deployment: - Place NIDS/NIPS at network perimeter (behind firewall) and internal segments. - Use HIDS/HIPS on critical servers and endpoints. - Configure signatures for known CVEs (e.g., CVE-2014-0160 for Heartbleed). - Tune thresholds to reduce false positives. - Integrate with SIEM for centralized alerting.

Snort IDS rule example:

alert tcp any any -> $HOME_NET 80 (msg:"HTTP SQL Injection Attempt"; content:"union select"; nocase; sid:1000001; rev:1;)

This rule alerts on TCP traffic to port 80 containing the string "union select" (SQL injection attempt).

Suricata IPS mode (inline):

drop tcp any any -> $HOME_NET 445 (msg:"EternalBlue Exploit"; content:"|00 00 00 31 ff 53 4d 42|"; sid:2000002; rev:1;)

This rule drops packets to SMB port 445 containing the EternalBlue exploit pattern.

Checking Snort alerts:

tail -f /var/log/snort/alert

Zeek (Bro) script for HTTP detection:

event http_request(c: connection, method: string, uri: string) {
    if (uri == "/admin") {
        NOTICE([$note=Admin_Access, $conn=c, $msg="Admin page accessed"]);
    }
}

Scenario 1: Retail Company PCI DSS Compliance A retail company must comply with PCI DSS requirement 11.4, which mandates intrusion detection/prevention systems. They deploy a network IPS (Cisco Firepower) inline at the internet perimeter. The IPS is configured with signatures for known payment card malware and SQL injection. One day, the IPS detects an attempted SQL injection on the e-commerce website's login page. Because it is inline, the IPS drops the malicious packets immediately, preventing data breach. The SOC analyst receives an alert and confirms the attack was blocked. The company logs this as a security event for compliance. A common mistake: organizations deploy an IDS instead of an IPS, failing PCI requirement for active prevention. The analyst must ensure the system is inline and not just monitoring.

Scenario 2: University Campus Network A university uses a Snort-based IDS on a SPAN port to monitor student dormitory traffic. The IDS alerts on peer-to-peer file sharing and potential malware downloads. The network team receives alerts but cannot block traffic automatically because the IDS is passive. They manually investigate and block offending IPs on the border router. During a large-scale malware outbreak (e.g., WannaCry), the IDS generates thousands of alerts, overwhelming the team. The response is delayed, and several student computers are encrypted. The mistake: using only an IDS without an IPS for automatic blocking in a high-volume environment. The solution: deploy an IPS inline at the campus internet gateway to automatically drop malicious traffic.

Scenario 3: Healthcare Hospital HIDS A hospital deploys host-based IDS (OSSEC) on critical servers (EHR, PACS). The HIDS monitors file integrity, registry changes, and login attempts. An attacker gains access to a workstation and tries to escalate privileges on the domain controller. The HIDS on the domain controller detects multiple failed logins followed by a successful admin login from an unusual IP. It generates an alert, but because it's a HIDS, it cannot block the login. The security team receives the alert after 30 minutes, by which time the attacker has exfiltrated patient data. The mistake: relying solely on HIDS without an HIPS or network IPS to block the attack in real time. The hospital later implements Windows Defender Firewall with IPS capabilities to block suspicious inbound connections.