Building a basic intrusion detection system with Snort

An intrusion detection system watches a network for activity that may indicate misuse, compromise or reconnaissance. Snort is a compact packet analyser and rule engine that examines captured traffic, matches it against signatures and raises alerts with source, destination and contextual details. Used passively, it observes copies of packets without blocking them, making it a practical first layer for a small business, school or home laboratory.

The idea is simple, but a useful Snort setup needs disciplined boundaries. A signature can identify a suspicious protocol exchange or packet pattern; it cannot prove that a user is malicious, and encrypted sessions may hide the payload a rule hopes to inspect. Strong projects combine Snort with operating-system patching, access controls, firewall policy and human review. An alert is evidence to investigate, not a verdict.

A basic deployment needs three pieces: a network position that can see relevant traffic, a stable host for packet capture and a dependable path for reviewing alerts. A mirror port on a managed switch is usually enough for a modest office network, while a small business with several sites may use a network tap or router capture feature. Running Snort on the firewall or gateway is possible, but mixes observation with the device responsible for forwarding traffic.

Australian networks add ordinary but important local context. An office in Sydney or Melbourne may combine fixed-line services from Telstra or Optus with broadband from a provider such as iiNet, while a branch in Brisbane, Adelaide or Perth may use a different access technology. The sensor should therefore begin with a written scope, expected traffic profile and retention policy rather than an assumption that every unusual packet deserves action.

Why packet-level detection is useful

Traffic filtering and intrusion detection solve different problems. A firewall enforces which connections may proceed, while an intrusion detection system studies traffic that has already been permitted. Snort can reveal scans, unusual protocol use and matches to known attack signatures in either direction. This visibility matters after a workstation has been authorised to reach the internet, because malicious traffic can travel inward through an allowed session as easily as outward.

Snort’s signature engine is the centre of the system, but supporting components determine how useful it becomes. Rules can match addresses, ports, header options and packet contents, while preprocessors reassemble streams and decode common protocols. This allows a rule to inspect more than isolated packets. It also consumes CPU and memory, so an office sensor should begin with a small trusted ruleset, enable only the decoders needed for observed services and record which rule caused every alert.

Australian broadband and corporate links produce traffic patterns that may look unusual to a generic rule set. A compressed software update, peer-to-peer transfer or regular connection to an overseas server can resemble scanning or an attack. Latency on long-distance links may also cause time-based thresholds to behave differently from those seen in local test environments. These are reasons to tune rules against real traffic, not reasons to disable detection and accept blind spots.

Preparing the monitoring host

Choose a dedicated machine or an isolated virtual appliance with a stable network interface, sufficient memory and reliable storage. FreeBSD and Linux were common choices for Snort 2.x sensors, and either can run on modest hardware when the monitored traffic volume is limited. Place the interface on a switch mirror configured with the VLANs of interest. A physical tap offers cleaner capture but costs more and may reduce the available bandwidth for the monitoring port.

Install Snort and its packet-capture dependencies, then create a restricted account that owns the capture interface and log directory. Promiscuous mode allows the interface to receive packets addressed to other machines, so enable it with ifconfig eth0 promisc on a classic Linux configuration and confirm the setting with ifconfig. A short tcpdump test should reveal traffic from the monitored segment before starting Snort with a command such as snort -c /etc/snort/snort.conf -i eth0 -l /var/log/snort.

Following a repeatable sensor methodology helps maintain consistency when the host is rebuilt or moved. Record the hardware, interface, capture point, enabled rules and every configuration change. Secure the host itself with a minimal installation, automatic security updates and restricted administrative access. Store timestamps in coordinated universal time and convert them to Australian Eastern Standard Time or Australian Central Standard Time when reporting, remembering that daylight-saving changes affect the displayed local hour.

Creating and validating rules

A local rule needs a clear action, protocol, source, destination and unique identifier. A simple Snort 2.x example is alert tcp any any -> any 445 (msg:"SMB access attempt"; sid:1000001; rev:1;). This rule deliberately produces many alerts and is useful for understanding the rule language, not for identifying every malicious SMB exchange. A production rule should narrow the addresses and ports, describe the behaviour accurately and include a revision number that changes whenever its meaning changes.

Build small families of rules around the network’s actual services. A port-scan rule can identify repeated connection attempts, HTTP rules can examine unusual requests and DNS rules can reveal excessive lookups or suspicious destinations. Snort’s stream and protocol decoders help with multi-packet behaviour, while thresholds can combine many related events into one alert. Give every local signature a unique sid above 1,000,000 and maintain a separate description so the alert text remains understandable when an incident is reviewed months later.

Test each rule with controlled traffic before allowing it into the active ruleset. Generate a harmless scan, connect to a test web server and reproduce ordinary DNS activity, then compare the results with background traffic. Excessive false positives train staff to ignore alerts, while narrow or incorrect rules create false negatives. Keep the experimental ruleset and production ruleset separate, and use a controlled address range for initial tests so that alerts cannot be confused with real intrusions.

Deploying and operating the sensor

Start in observe-only mode and keep the original traffic path unchanged. A mirror port beside the internet gateway provides a broad external view, while a second sensor at a server switch can reveal internal movement that never crosses the perimeter. Compare both views during the pilot: a compromised workstation may generate obvious outbound alerts but appear ordinary from the internet sensor. Only move the sensor after confirming that its capture point, packet loss rate and CPU load are acceptable.

Every alert needs an owner and a documented review path. A useful record includes the rule, timestamp, addresses, ports, sensor identity and the reason for the disposition. If an incident may involve multiple organisations, significant data loss or coordinated criminal activity, CERT Australia can provide national coordination guidance and advice about reporting. Local escalation should still identify who may contact affected customers, preserve evidence and avoid sending packet contents through ordinary email.

Operational maintenance is as important as the initial configuration. Check dropped packets, sensor load, disk space and rule-loading errors daily, and review new alerts for changes in false-positive rates. Schedule regular rule updates and test them against saved traffic before deployment. Rotate or archive logs according to the retention policy, and keep the host’s clock synchronised with a reliable time source. That matters in Australia, where daylight-saving transitions can otherwise make two otherwise identical alerts appear separated by an unexpected hour.

Governance should be settled before live capture begins. The Privacy Act 1988 may apply when packet contents include personal information, even if the primary purpose is security monitoring. A customs broker handling declarations for the Australian Customs Service illustrates why credentials and sensitive records must not be copied indiscriminately into alert files. Restrict access, document the traffic being observed, avoid retaining unnecessary payloads and ensure that monitoring activity complies with employment contracts, customer agreements and applicable law.

Comparing common detection approaches

No single monitoring method provides a complete view. Network sensors see traffic across a segment, host-based systems reveal actions within a machine, firewall records show which connections policy permitted or rejected, and inline devices can stop traffic when a match is reliable. The right combination depends on available staff, network design, privacy requirements and whether the objective is detection, investigation or prevention.

Approach	Best visibility	Main strengths	Common blind spots	Typical placement
Network IDS with Snort	Traffic crossing a monitored segment	Detailed signatures, scans and protocol behaviour	Encrypted payloads and traffic outside the capture point	Switch mirror or network tap
Host-based IDS	Activity on one machine	Process, file and login context	Cannot reveal activity on other systems	Server or protected workstation
Firewall logs	Allowed and denied connections	Easy correlation with existing policy	Limited payload detail	Internet gateway
Inline IPS	Traffic passing through a filter	Can block matched activity	Greater configuration and latency risk	Gateway appliance
Honeypot	Deliberately attractive decoy	Reveals intent with little normal noise	Does not protect genuine systems	Isolated internal segment

For a small Australian network, a Snort sensor on a switch mirror can provide substantial visibility without changing the traffic path. Host records, firewall logs and disciplined system administration then supply the context Snort cannot obtain from packets alone. This combination creates a realistic and defensible foundation for detecting suspicious activity while preserving the availability and performance that business networks require.