Log sources and log analysis: Windows, Linux, firewall and web logs

What to monitor first

You cannot collect everything, so start with logs that show the steps attackers almost always take: signing in, running programs, changing permissions and moving data. Collecting the right ten sources well beats collecting a hundred badly.

Windows event logs

Windows records security events in the Security log. A few event IDs are worth learning by heart:

Many organisations also install Sysmon, a free Microsoft tool that records richer process, network and file events.

Linux, firewall and web logs

• Linux: authentication events go to /var/log/auth.log (Debian, Ubuntu) or /var/log/secure (Red Hat family). On systemd systems, journalctl reads the journal. Look for failed SSH logins, sudo use and new users.
• Firewall logs: source and destination IP, ports, protocol, rule matched and action (allow or deny). Denied outbound traffic from an internal server is often more interesting than denied inbound noise.
• Web server logs: client IP, time, method, requested path, status code, size and user agent. Bursts of 404 errors suggest scanning; long, strange query strings can suggest injection attempts.

journalctl -u ssh --since "1 hour ago"
grep "Failed password" /var/log/auth.log
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 50

A method for log analysis

1. Normalise time: convert every source to one time zone, ideally UTC.
2. Start from the alert: note the host, user and time.
3. Widen the window: look 30 minutes before and after for related events.
4. Pivot: search other sources for the same user, IP or file hash.
5. Build a timeline: list events in order with their source, then decide what happened.

Watch out for common traps. A missing log does not prove nothing happened; it may mean logging was off or the attacker cleared it. Shared accounts make the "who" impossible to answer, so avoid them. Network address translation and proxies can hide the real source address, so check the device that saw the original connection. Finally, write down every query you run and what it returned, so another analyst can repeat your steps and reach the same conclusion.

Tip: protect logs from tampering by forwarding them quickly to a central store that ordinary administrators cannot edit, and keep them long enough to investigate slow attacks.

Real-world example: a small shop's web server

The owner of a fictional online craft shop notices the site is slow. The IT contractor checks the web server logs and sees thousands of requests from a handful of IP addresses for login pages that do not exist, all with 404 status codes, followed by repeated POST requests to the real admin login. The auth logs show no successful admin sign-ins from those addresses. The contractor blocks the addresses, adds rate limiting to the login page, turns on MFA for the admin account and sets up an alert for more than 20 failed logins in five minutes.