Intrusion detection on a settlement network is mostly a person reading the right records on a routine: who logged in and from where, which services are listening, which system files have changed, which devices are on the network, and what the firewall dropped. Record what normal looks like first, because an alarm is only a difference from normal, and keep the baseline and the logs on a second machine so that someone who breaks into the first cannot rewrite them. A tool that raises alerts nobody reads protects nothing.
Part of Networking
Noticing unauthorised access to a small network: the baseline, the records worth reading, how to capture traffic, and what to do when something is wrong.
Detection Is A Comparison Against A Known Baseline
The carrier Internet Infrastructure already contains the two basic habits: log dropped packets for security monitoring, and review what is running with netstat -tlnp, shutting down anything unexpected. Shared Resources adds that logging all access to sensitive resources creates an audit trail, that regular review or automated alerts on odd patterns detect unauthorised access, and that comprehensive logs also deter misconduct because people know their access is recorded. Network Security ranks insiders, physical access and mistakes above remote attack for a settlement, and detection has to be able to see those: an account in use at a strange hour, a device nobody registered, a file that changed.
A traffic-capturing tool needs the right vantage point. Network Interface explains that on a switched network a capture machine sees only its own traffic and broadcasts unless the switch is set to copy ports to it (a mirror port) or a tap is inserted. Capture is for investigation after a signal from the records below, not for watching all day.
What You Need
- A second machine for logs and baselines
- The address plan with every registered machine (Network Addressing)
- A hashing tool (File Transfer names SHA-256)
- A weekly appointment with a named person
Method: A Weekly Routine
Step 1: Record the baseline once, while the system is known good The listening ports (Core Protocols), the accounts and their groups (Access Control), the registered devices, and a hash of each system program and configuration file. Checksums explains why a plain checksum is not enough here: it guards against accidental damage, and a cryptographic hash such as SHA-256 is needed when data may have been deliberately altered. Keep the list of hashes on the second machine and a printed copy.
Step 2: Each week, compare Recompute the hashes and compare; list listening ports and compare; list accounts and compare.
Step 3: Read the login records Look for failed logins in runs, logins at hours nobody works, and logins to accounts of people who have left.
Step 4: Read what the firewall dropped The log rule in Firewalls records it. A burst of drops from one inside address is a machine behaving oddly.
Step 5: Count devices against the plan The DHCP lease list (DHCP) should hold only registered hardware addresses plus known visitors.
Step 6: If something is wrong, contain first, then investigate Pull the network cable of the suspect machine rather than switching it off, so its memory and records survive (general practice, not from the other articles); copy its logs elsewhere; restore from the offline backup (Server Deployment); change credentials that machine knew; write down what happened.
Step 7: Ship logs off the machine An intruder with administrator rights can edit local logs. Send copies to the second machine as they are written.
Worked Example: A Baseline Catches Two Changes
The plan registers 190 permanent machines (invented for the example). The lease list this week shows 193 distinct hardware addresses. The difference, 193 - 190 = 3, is three devices to account for: visitors with a clinic laptop, a new machine nobody registered, or someone’s unauthorised device. Each is found by walking to the port it appears on (Star Topology: switch port statistics point to the link).
A SHA-256 hash is 256 bits, which is 256 / 4 = 64 hexadecimal characters. The stored line for a program might be 64 characters followed by the file name. If this week’s hash of the login program differs at all from the stored one, the file is not the same file, whether through damage or tampering, and that machine goes to the contain-and-investigate step. A changed hash after an update you made yourself is expected, which is why every deliberate change updates the baseline the same day.
Common Mistakes
- No baseline — you cannot tell what changed
- Keeping the hash list on the machine it checks — an intruder rewrites both
- Alerts without a reader — assign a name and a day
- Switching the machine off at once — it destroys the evidence in memory; disconnect it instead
- Ignoring physical signs — a disconnected cable or a new device in the equipment room is detection too
What’s Next
- Learn next: Network Security — how this fits with prevention
- Combine with: Firewalls — the log source with the clearest signal