Week 2 Day 4 — NETW-0014 Advanced Operating Systems

0:00–0:10
Recap

0:10–0:35
Lecture

0:35–1:50
Lab 2D

1:50–2:00
Debrief

0:00 – 0:10Recap · 10 min

Time is reliable — now what's written to the log files?

Quick check: timedatectl timesync-status on S2 — should show S1 as source, stratum 3. Fix any drift before today's lab; incorrect timestamps undermine the exercise.
Scenario: "An attacker roots S2 and runs echo '' > /var/log/auth.log. What evidence is destroyed?" — everything local. Today's centralised-logging half of the lab is the fix.

0:10 – 0:35Lecture · 25 min

The syslog standard, rsyslog architecture, the custom template, and centralised logging

Facility and severity (8 min): every syslog message carries a facility (auth/authpriv, kern, daemon, cron, local0–7 — what generated it) and a severity, 0 (emerg) through 7 (debug). In a rule, facility.severity means that level and above — *.debug means everything.
rsyslog architecture (6 min): /etc/rsyslog.conf holds daemon properties and templates; /etc/rsyslog.d/50-default.conf holds routing rules (facility.severity /path). A leading dash means async (faster, risk of losing the last lines on crash).
The custom template (6 min): the default log line omits facility/severity. Adding $template myDefault,"%timegenerated% %HOSTNAME% %syslogfacility-text%.%syslogseverity-text% %syslogtag% %msg%\n" plus $ActionFileDefaultTemplate myDefault in rsyslog.conf makes every line self-describing — essential once logs are centralised from multiple sources.
Centralised logging (5 min): enabling imudp reception on S1 and adding a @loghost forwarding line to S2's 50-default.conf (keeping the local rule too) means a copy of S2's auth events lands on S1 in real time — surviving even if S2's local log is wiped.

Instructor note: the custom template is the step students forget most often — without it, logging still works, but without the facility/severity context that makes analysis efficient. Call it out explicitly before the lab starts.

0:35 – 1:50Lab 2D · 75 min

Lab 2D — Template and redirection on S1, then centralised logging from S2, plus rotation

Part 1 — Custom template and local redirection (30 min)

Snapshot S1 first — a misconfigured rsyslog can silently stop all logging. Back up rsyslog.conf and 50-default.conf.
Add the two template lines to rsyslog.conf, restart rsyslog, trigger an SSH login, confirm /var/log/auth.log now shows facility.severity in each line.
Comment out the existing auth,authpriv.* /var/log/auth.log rule (with a dated comment explaining why) and add auth,authpriv.* -/var/log/logrecord.log. Restart, trigger login events, and confirm the new file exists and is receiving entries.

Part 2 — Centralised logging from S2, then rotation (45 min)

On S1, uncomment the imudp module and input lines in rsyslog.conf, binding to S1's LAN1 IP specifically (address="192.168.50.1") rather than 0.0.0.0 — discuss why binding to a specific interface matters. Verify with sudo ss -ulnp | grep 514.
On S2, add a loghost entry to /etc/hosts, then add auth,authpriv.* @loghost to 50-default.conf alongside the existing local rule (don't remove it). Restart rsyslog on S2, trigger logins, and confirm the events appear on S1's live-tailed syslog within seconds.
Verify with tcpdump (-A udp port 514) that syslog is plaintext in transit — note the security implication.
Write a logrotate rule for /var/log/syslog: daily, missingok, rotate 5, compress, delaycompress, notifempty, sharedscripts, and a postrotate block that reloads rsyslog. Test with logrotate --debug (dry run), then add a crontab entry to run it at 2am daily.
Restore from the Lab 2D snapshot (or the config backups) before finishing — leave NTP in place.

Snapshot reminder: a misconfigured rsyslog.conf can silently stop logging entirely. Take the snapshot before touching anything, and don't skip it under time pressure.

Optional take-home extension (on the handout): the second-facility redirect exercise (kern.* → NewLog.log), the full six-log-file research table (auth.log, syslog, kern.log, dpkg.log, dmesg, wtmp), and the omusrmsg live-terminal bonus that prints auth events directly to a watching session. All were part of the original two-day version.

1:50 – 2:00Debrief · 10 min

Ask: "What's the security difference between a dash and no dash before the log path in a routing rule?" — async (fast, can lose the last lines on crash) vs. sync (safer for security-critical logs).
Preview Friday's assessment: practice reading auth.log tonight — grep "Failed password" and grep "Accepted" — the practical uses a pre-seeded log file.
Preview Week 3: DHCP and DNS — the services that let machines find each other by name. The DNS zones built there are referenced in every remaining week.

Learning outcomes — by end of Day 4, students can…

Name the eight syslog severity levelsList 0–7 with names and keywords

Add a custom log template and redirect a facilityInsert myDefault and route a facility to a new file

Configure centralised loggingEnable UDP reception bound to a specific interface and forward a client's logs with @loghost

Write a logrotate rule and schedule itUse daily/rotate/compress/sharedscripts/postrotate, driven by a crontab entry

What you need ready before class

Lab 2D handout printed Mini-Assessment 2 printed for tomorrow Snapshot capability confirmed in Hyper-V

←← Week 2 Overview ← Day 3 Lab 2D Handout Day 5 →