Chapter 11 — Operating systems | Bachelor's Security operations and blue team

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 11 — Operating systems

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 What operating systems record"]
  N2["11.2 Windows and Linux"]
  N3["11.3 Users and privileges"]
  N4["11.4 Research servers"]
  N5["11.5 SSH"]
  N6["11.6 Configuration matters"]
  N7["11.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 What operating systems record"]
  N2["11.2 Windows and Linux"]
  N3["11.3 Users and privileges"]
  N4["11.4 Research servers"]
  N5["11.5 SSH"]
  N6["11.6 Configuration matters"]
  N7["11.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 What operating systems record]
    |
    v
[11.2 Windows and Linux]
    |
    v
[11.3 Users and privileges]
    |
    v
[11.4 Research servers]
    |
    v
[11.5 SSH]
    |
    v
[11.6 Configuration matters]
    |
    v
[11.7 Case]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) explain processes, users, permissions and logging in Windows and Linux; (2) locate security-relevant events on servers; (3) relate OS configuration to what a SOC can see; (4) recognise privilege changes as signals.

11.1 What operating systems record

Operating systems control processes, files and users, and can log logons, process creation, privilege changes and service installation. Logging is configurable: unconfigured systems record little.

On Riverton's managed laptops, logging of logons and process creation is enabled by policy; on research servers, settings depend on whoever installed them. That difference matters later in the case, because a server set up with default settings recorded far less than the SOC needed. Knowing what is logged comes before writing any detection that depends on it.

11.2 Windows and Linux

University staff laptops run Windows; research servers mostly run Linux. Windows records events in event logs; Linux uses system logs and, where configured, the audit subsystem. Both can forward logs to the SOC.

For the SOC, the two need different parsing. A Windows event has a numeric identifier and structured fields, while a Linux authentication log line is text that must be split carefully. Lucas's tool handles both by converting each record into the same small set of fields, such as time, host, user and action, before analysis.

11.3 Users and privileges

Administrators can install software and change settings. Adding a user to an administrators group or to Linux's sudo group is a privilege change worth alerting on.

Such changes are rare and powerful, so they make good alerts: on Riverton's servers, administrator groups change only a few times a year. Each change should match a ticket or a known administrator's action. A change with no matching request, especially at night, suggests that someone has gained access and is securing their foothold.

11.4 Research servers

Research groups often run their own servers with local accounts. The research GPU server in the physics department was set up by a postdoc and forwarded no logs to the SOC until this year.

The GPU server held datasets and expensive computing time, which made it attractive to attackers who mine cryptocurrency. Because it forwarded no logs until recently, the SOC had little history to compare against when the alert arrived. The postdoc who set it up had since moved to another group, so nobody owned it day to day.

11.5 SSH

Linux servers accept remote logins over SSH. Authentication logs show successes and failures with source addresses. Key-based login without passwords reduces guessing risk.

On the physics server, password login was still enabled for some accounts, and the authentication log showed thousands of failed attempts from internet addresses every day. Most were automated guessing. The SOC's concern was the rare success from an unknown address, which, combined with the sudo alert, became the starting point of the week-five investigation of the GPU server.

11.6 Configuration matters

A rule for "new administrator added" works only if the server logs group changes and forwards them.

Forwarding to the SOC had been enabled on the physics server only a few weeks before the alert. Had it been left at its old setting, the sudo change would have stayed in a local file nobody read. Lucas's lesson was that each detection rule needs a check that its source is still logging and forwarding. The SOC now alerts when a server stops sending logs for a day.

11.7 Case

In week five, an alert reports a new sudo user on the physics GPU server.

The alert arrived at 23:40 on a weeknight, with no matching change request. Lucas checked the authentication log first, to see who had signed in shortly before the change and from where. That question, rather than the sudo change itself, determines whether the event is an administrator's late-night fix or an intruder's. He also checked who normally administers the server, so he knew whom to ask before taking any action that might disrupt running research jobs.

Worked example

Lucas checks the server's authentication log: the new user was created by the server's administrator account at 14:02 from a university IP address belonging to the physics building. He contacts the research group, who confirm a new PhD student was added. He closes the alert as authorised and suggests the group record such changes in a ticket first.

Synthetic case. Servers and events are invented.

Errors and limits

Local accounts on research servers may not match central identity records, complicating investigation.

Exercises

EX031 — Privilege signal. Why is adding a user to sudo or administrators a useful signal? Rubric: 3 = grants admin rights attackers seek; 2 = partial; 1 = noise; 0 = none.
EX032 — Rule dependency. When does a "new administrator" rule work? Rubric: 3 = server logs group changes and forwards them; 2 = partial; 1 = always; 0 = none.
EX033 — GPU alert outcome. How was the sudo alert resolved? Rubric: 3 = created by admin from physics building; confirmed new PhD student; closed authorised; ticket suggested; 2 = partial; 1 = ignored; 0 = none.

Synthesis

Operating systems produce useful security events only when configured and forwarded; privilege changes deserve attention.

Continue studying — chapter 11 of 40

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →