Installs, configures, and tunes Snort 3 intrusion detection system to monitor network traffic for malicious activity using custom and community rulesets, preprocessors, and alert output plugins on authorized network segments.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Installs, configures, and tunes Snort 3 intrusion detection system to monitor network traffic for malicious activity using custom and community rulesets, preprocessors, and alert output plugins on authorized network segments.
Deploying a network-based intrusion detection system to monitor traffic at key network boundaries
Writing custom Snort rules to detect organization-specific threats, attack patterns, or policy violations
Tuning existing rulesets to reduce false positives while maintaining detection coverage
Integrating Snort alerts with SIEM platforms for centralized security monitoring
Validating network security controls by generating test traffic and confirming detection
Do not use as a replacement for endpoint detection, for monitoring encrypted traffic without TLS inspection, or as the sole security control without complementary defenses.
Common Misconfigurations & Verification
HOME_NET wrong or too narrow: if HOME_NET doesn't cover your real subnets (or is left at a sample like 10.10.0.0/16 when you're 192.168.x), every $HOME_NET/$EXTERNAL_NET rule misfires and east-west traffic is unscored. Verify with snort -c snort.lua -T and grep the resolved value; test a rule that should fire on internal traffic.
NIC offloading left on: GRO/LRO/TSO hand Snort reassembled super-frames with bad checksums, so content matches silently miss. Run ethtool -k eth1 | grep -E 'gro|lro|tso|gso' — all must be off; re-disable on every boot via the snort-iface.service.
Not in promiscuous mode / no SPAN or tap: Snort only sees broadcast/its-own traffic. Confirm ip link show eth1 shows PROMISC and that the switch SPAN session actually mirrors the monitored VLAN.
Rules loaded = 0 or config silently degraded: always validate with snort -c .../snort.lua -T 2>&1 | grep -i "rules loaded" and confirm a nonzero count after every PulledPork run.
Detection never proven: replay a known-bad pcap — snort -c snort.lua -r malicious.pcap -A fast — or tcpreplay it to the interface and confirm the expected SID appears in alert_fast.txt. No alert means the rule, port var, or flow direction is wrong.
Over-suppression / over-thresholding: broad suppress by subnet can mute real detections. Audit suppress.rules and confirm suppressed SIDs are genuinely noisy via .
# Disable offloading features that interfere with packet inspectionsudo ethtool -K eth1 gro off lro off tso off gso off rx off tx off
# Enable promiscuous modesudo ip linkset eth1 promisc on
# Create systemd service for persistent interface configurationsudotee /etc/systemd/system/snort-iface.service << 'EOF'
[Unit]
Description=Configure Snort capture interface
Before=snort.service
[Service]
Type=oneshot
ExecStart=/sbin/ethtool -K eth1 gro off lro off tso off gso off rx off tx off
ExecStart=/sbin/ip linkset eth1 promisc on
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl enable snort-iface.service
IDS passively monitors traffic and generates alerts; IPS sits inline and can actively block or drop malicious packets in real time
Snort Rule
Detection signature with header (action, protocol, src/dst, ports) and options (content matches, flow direction, metadata) that triggers on matching traffic
Preprocessor
Snort component that normalizes and reassembles protocol-specific traffic before rule inspection, handling fragmentation, stream reassembly, and protocol anomalies
DAQ (Data Acquisition)
Abstraction layer in Snort 3 that interfaces with packet capture mechanisms (AF_PACKET, PCAP, NFQ) for receiving network data
Oink Code
Personal registration code from snort.org required to download Snort Subscriber or Registered rulesets
Threshold/Suppression
Tuning mechanisms that control alert frequency (threshold) or completely silence alerts from specific sources/destinations (suppress)
Tools & Systems
Snort 3: Open-source network intrusion detection and prevention system with Lua-based configuration and multithreaded architecture
PulledPork 3: Automated Snort rule management tool that downloads, processes, and deploys rulesets with policy-based filtering
Barnyard2: Dedicated spooler that reads Snort's unified2 binary output and writes to databases (MySQL, PostgreSQL) for SIEM integration
tcpreplay: Tool for replaying PCAP files through Snort to validate rules and test detection capabilities
Common Scenarios
Scenario: Deploying Snort IDS at a Network Perimeter for Compliance
Context: A healthcare organization needs to deploy network IDS to meet HIPAA technical safeguard requirements. The IDS must monitor traffic between the DMZ and internal network, detect common attack patterns, and forward alerts to the existing Splunk SIEM. The network carries approximately 500 Mbps of traffic during peak hours.
Approach:
Install Snort 3 on a dedicated sensor with dual NICs -- one for monitoring (span port from core switch) and one for management
Configure AF_PACKET DAQ with a 512 MB ring buffer to handle peak throughput without drops
Deploy Snort Community rules plus Emerging Threats Open ruleset as baseline detection
Write custom rules for organization-specific threats: detection of PHI data patterns (SSN, MRN formats) leaving the network, unauthorized access to DICOM/HL7 ports, and connections to known bad IP lists
Configure JSON alert output and forward to Splunk via syslog using rsyslog
Run Snort against 24 hours of captured baseline traffic to identify false positives, then create suppression rules for legitimate traffic patterns
Enable Snort as a systemd service with automatic restart and log rotation
Pitfalls:
Deploying all available rules without tuning, overwhelming the sensor and SOC with thousands of daily false positives
Forgetting to disable NIC offloading, causing Snort to miss packets due to checksum errors or jumbo frames
Not sizing the sensor hardware for peak traffic, leading to packet drops during high-volume periods
Relying solely on community rules without custom rules for organization-specific threats and compliance requirements
Output Format
## Snort IDS Deployment Report
**Sensor**: snort-sensor-01 (10.10.1.250)
**Interface**: eth1 (span port from Core-SW1 gi0/24)
**Configuration**: /usr/local/etc/snort/snort.lua
**Ruleset**: Snort Community 3.0 + Local Rules (1,247 active rules)
**HOME_NET**: 10.10.0.0/16
### Detection Summary (24-hour baseline)
| Category | Alert Count | Top Rule SID |
|----------|-------------|--------------|
| Attempted Recon | 342 | 1:2100498 (ICMP ping) |
| Trojan Activity | 12 | 1:1000001 (Reverse shell) |
| Policy Violation | 87 | 1:1000004 (FTP cleartext) |
| Web Application Attack | 23 | 1:2100654 (SQL injection) |
### Tuning Actions Taken
- Suppressed SID 2100498 for 10.10.1.100 (monitoring server legitimate ICMP)
- Thresholded SID 1000004 to 5 alerts per source per hour
- Added 3 custom rules for PHI exfiltration detection
