## Snort: The Grandfather of IDS

**Snort** (created by Sourcefire, now owned by Cisco) is the de-facto standard for NIDS. Even if you use other tools, you will likely use "Snort Rules" because the syntax is universal.

### Snort Architecture
1.  **Packet Decoder**: Prepares packets for inspection.
2.  **Preprocessors**: Normalizes traffic (e.g., reassembling fragmented TCP packets so attackers can't hide payload by splitting it up).
3.  **Detection Engine**: The core. Matches packets against rules.
4.  **Logging/Alerting**: Outputs to a file, Syslog, or Database.

### Snort Rule Syntax (Memorize This!)
A Snort rule has two parts: The **Header** (Action/Protocol/IPs) and the **Options** (What to look for).

`alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"Possible SQL Injection"; content:"UNION SELECT"; nocase; sid:1000001; rev:1;)`

*   `alert`: The Action. (Could be `drop`, `log`, `pass`).
*   `tcp`: The Protocol (udp, icmp, ip).
*   `$EXTERNAL_NET any`: Source IP and Port.
*   `->`: Direction (One way).
*   `$HTTP_SERVERS 80`: Destination IP and Port.
*   `( ... )`: The Options.
    *   `msg`: What shows up in the alert log.
    *   `content`: The specific string to search for in the packet payload ("UNION SELECT").
    *   `nocase`: Ignore Case (Select vs sELecT).
    *   `sid`: Signature ID (Unique number).
    *   `rev`: Revision number.

### Writing a Custom Rule
Scenario: You want to detect anyone downloading a file named `confidential_salary.xlsx` via HTTP.
`alert tcp any any -> any any (msg:"Sensitive File Access"; content:"confidential_salary.xlsx"; http_uri; sid:1000002;)`
(Note: `http_uri` tells Snort to look only in the URI part of the packet, making it faster).

### Pros and Cons
*   **Pros**: Universal, massive community rule sets (Emerging Threats - ET Open).
*   **Cons**: Single-threaded (historically). On 10Gbps networks, Snort execution can bottleneck one CPU core while others sit idle. (Snort 3.0 fixes this, but adoption is slow).