Chapter 7 — Linux server baseline
Lesson map
Lesson 07 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Applying"]
N2["7.2 Testing"]
N3["7.3 Checking"]
N4["7.4 Exceptions"]
N5["Benchmark items in practice"]
N6["Updates, drift lessons and reporting"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Applying"]
N2["7.2 Testing"]
N3["7.3 Checking"]
N4["7.4 Exceptions"]
N5["Benchmark items in practice"]
N6["Updates, drift lessons and reporting"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[Learning outcomes]
|
v
[7.1 Applying]
|
v
[7.2 Testing]
|
v
[7.3 Checking]
|
v
[7.4 Exceptions]
|
v
[Benchmark items in practice]
|
v
[Updates, drift lessons and reporting]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) apply the CIS Benchmark to Linux servers; (2) automate checks; (3) handle exceptions.
7.1 Applying
The infrastructure team applies the Linux appendix of the standard using its configuration management tool, so settings are defined in code and applied consistently. Defining settings in code means every Linux server receives the same configuration, and changes can be reviewed before they are applied. It also makes the standard easier to show to auditors, since the code can be compared directly with the appendix. When the standard changes, the infrastructure team updates the code and records the change. Settings that cannot be applied on a server because of the warehouse system become documented exceptions rather than quiet omissions.
7.2 Testing
Changes go first to a test copy of the route planning server, then to production in a maintenance window. The route planning server is chosen because it is business-critical: if a setting breaks it, deliveries cannot be planned. Testing on a copy shows whether the application still works with the new settings before production is touched. The infrastructure team runs the planners' usual tasks on the test copy and records any problems. Production changes happen in an agreed maintenance window with a rollback plan. Each change is logged with the date and result, so problems can be traced to a specific change.
7.3 Checking
The tool reports drift daily. Seun's monthly figure comes from these reports. Daily drift reports show when a server no longer matches the standard, whether because someone changed a setting by hand or an update reset it. The infrastructure team investigates each drift: a legitimate need becomes a change request, while an unexplained change is corrected and noted. Seun's monthly figure uses the share of servers fully compliant on the last day of the month, defined the same way each time. The reports also go into the evidence pack, so auditors can see compliance held between monthly figures.
7.4 Exceptions
The warehouse system's vendor requires an older library on two servers; these are exceptions with isolation and review dates. The vendor confirms in writing that its software needs the older library, and gives a target date for a version that does not. The two servers sit on a restricted network segment that allows only the connections the warehouse system needs. Each exception has a named owner, a review date and a link to the vendor's letter in the register. They account for the remaining gap in the Linux compliance figure, which is reported with that explanation.
Benchmark items in practice
The Linux appendix includes items such as disabling unused filesystems, setting permissions on sensitive files, configuring time synchronisation, enabling the audit daemon, restricting SSH settings and setting password rules for local accounts. Each comes from the CIS Benchmark for the distribution, with three tailored items for the route planning software.
The team rolls items out in batches of ten, so that any problem can be traced to a small set of changes.
Each batch is recorded with its date and the compliance figure before and after.
Updates, drift lessons and reporting
The Linux baseline requires security updates through the package manager within the patch targets, with kernel updates followed by a scheduled reboot; live patching is considered but not adopted this year, since monthly reboots fit the maintenance window. Daily drift reports show that most drift comes from emergency fixes made directly on servers, so the team agrees to back-port such fixes into the configuration code within one working day. The Linux figure in Seun's monthly table comes straight from the tool's compliance report, with exceptions listed beneath it, so the number and its caveats always travel together.
Worked example
Linux compliance rises from 50 to 89 percent; the two exceptions account for the remainder.
Synthetic case. Figures are synthetic.
Errors and limits
Manual changes outside the tool are overwritten, so everyone must use it.
Exercises
- EX031 — Code benefits. Why define settings in configuration code? Rubric: 3 = consistent, repeatable, reviewable;; 2 = consistent;; 1 = vague;; 0 = none.
- EX032 — Test copy. Why test on a copy first? Rubric: 3 = avoid outages;; 2 = safety;; 1 = vague;; 0 = none.
- EX033 — Result. State the Linux compliance change. Rubric: 3 = 50 to 89;; 2 = one;; 1 = vague;; 0 = none.
- EX034 — Vendor exception. How is the vendor library exception handled? Rubric: 3 = isolation, review date;; 2 = recorded;; 1 = vague;; 0 = none.
- EX035 — Manual changes. What happens to manual changes? Rubric: 3 = overwritten;; 2 = lost;; 1 = vague;; 0 = none.
Synthesis
Defining baselines in code keeps servers consistent and measurable.
Continue studying — chapter 07 of 12
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →