TSSR module 4: security, consolidation and a mock start of course

Day 43 · 15/12 — Security: the CIA triad, common threats, phishing

Goal: classify a threat by what it attacks, and recognise a phishing message.

Theory 1/2: the CIA triad

Information security protects three properties, the "CIA triad":

• Confidentiality: only authorised people read the information (encryption, access rights).
• Integrity: the information is not changed without it being known (hashes, signatures, logs).
• Availability: the information is reachable when needed (redundancy, backups, monitoring).

Common threats: phishing, ransomware (which encrypts data and demands a ransom), credential theft, unpatched software being exploited, denial of service, human error.

Theory 2/2: spotting phishing

A phishing message wants you to click, open or pay. Its signals: urgency or a threat ("account suspended in 24 h"), a sender whose domain does not match the organisation, a link whose real address (on hover) differs from its text, an unexpected attachment (especially an archive, a document with macros, an executable), a request for credentials or payment, mistakes or a sloppy layout, an impersonal greeting, an offer too good to be true, a change of bank details, a request for secrecy. In France, the public service Cybermalveillance.gouv.fr explains how to react and report.

Practice (30 min)

1. List ten scam signals in the notebook, each with an invented example.
2. Open your junk folder (without clicking anything): find at least three of these signals in real messages.
3. In one message, show the source or full headers: find the real sender and the result of the SPF, DKIM or DMARC checks if they are shown.

Recap (10 min)

Recite the triad with one protection per property, and five phishing signals.

Day 44 · 16/12 — Authentication: passwords, MFA, least privilege

Goal: know what makes authentication strong, and turn on MFA for two accounts.

Theory (20 min)

• Factors: something I know (password), something I have (phone, security key), something I am (fingerprint). MFA (multi-factor authentication) combines at least two of different kinds: a stolen password is no longer enough.
• Passwords: length matters more than complexity; one unique password per service, kept in a password manager. France's ANSSI and CNIL publish recommendations on their strength.
• Second factors are not equal: SMS is the weakest (line hijacking), an app that generates short-lived codes (TOTP) is better, security keys and passkeys (FIDO2) resist phishing.
• Least privilege: everyone gets the rights their task needs, no more. An administrator has two accounts: one for daily work, one for administration.

Practice (30 min)

1. Pick two of your important accounts (e-mail, main online account) and turn on MFA in their security settings, with an authenticator app or a security key rather than SMS when offered.
2. Store the recovery codes where you can find them without the phone.
3. In the Debian VM, apply least privilege: check who is in the sudo group (getent group sudo) and remove whoever has no business there (sudo deluser bruno sudo if needed).

Recap (10 min)

Three lines: the three factors, why SMS is the weakest, what least privilege is.

Day 45 · 17/12 — Firewall: concepts, ports, iptables and nftables

Goal: read the Debian VM's firewall rules and write a simple policy.

Theory 1/2: filtering

A firewall lets traffic through or blocks it according to rules: source and destination address, protocol, port. A stateful firewall remembers open connections: it lets back in the replies to what you asked for. The right policy: deny everything by default on the way in, then allow only what is needed. Ports to know: 22 SSH, 25 SMTP, 53 DNS, 67-68 DHCP, 80 HTTP, 443 HTTPS, 445 SMB, 3389 remote desktop (RDP).

Theory 2/2: on Linux

Filtering happens in the kernel, in the netfilter subsystem. iptables was the historical tool; nftables replaces it, and Debian has used it by default since Debian 10 (2019), with the iptables command becoming a compatibility layer. A Debian install sets no rules: everything passes. Tools such as ufw make rules easier to write.

Practice (30 min)

1. Take a snapshot of the Debian VM: a badly written rule can cut you off from SSH.
2. sudo nft list ruleset: probably empty. Look at the open ports too: ss -tlnp.
3. Write /etc/nftables.conf:

   #!/usr/sbin/nft -f
   flush ruleset
   table inet filter {
     chain input {
       type filter hook input priority 0; policy drop;
       iif lo accept
       ct state established,related accept
       tcp dport { 22, 80 } accept
       icmp type echo-request accept
       icmpv6 type { echo-request, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
     }
   }

4. Apply it from the VM's console (not over SSH): sudo nft -f /etc/nftables.conf, then sudo systemctl enable nftables so it applies at boot.
5. Check from Windows: the web page and SSH answer; the SMB share (445) no longer does. Add 445 to the list if you want, reload, check again.

Recap (10 min)

Three lines: default policy, the role of ct state established, why test from the console. Recite eight ports.

Day 46 · 18/12 — VPN: site-to-site and remote access

Goal: tell the two uses of a VPN apart and draw remote access.

Theory (20 min)

A VPN (virtual private network) builds an encrypted tunnel across the Internet, as if both ends sat on the same private network.

• Site-to-site: two routers or firewalls permanently join two networks, for example headquarters and a branch. Users install nothing.
• Remote access: a client on the employee's computer opens the tunnel to the company firewall, then reaches internal resources after authentication, ideally with MFA.

Common protocols: IPsec (an IETF standard, very common site-to-site), OpenVPN (built on TLS), WireGuard (modern, simple, in the Linux kernel since version 5.6 in 2020). Two choices to explain: split tunnelling (only traffic to the company goes through the tunnel) or a full tunnel (all traffic goes through it, and the company can filter it).

Practice (30 min)

1. Draw remote VPN access: the employee's laptop at home, their router, the Internet, the company firewall with its public address (use 203.0.113.10), the internal network with a file server and a domain controller.
2. Show: where the tunnel starts and ends, which address the laptop gets inside the tunnel, where authentication (and MFA) happens, what the firewall filters after the tunnel.
3. Add a branch joined site-to-site on the same diagram.

Recap (10 min)

Three lines: site-to-site versus remote access, three protocols, split tunnelling.

Day 47 · 19/12 — Antivirus, EDR, updates, digital hygiene

Goal: know what each tool protects, and quickly audit your own machine.

Theory (20 min)

• Classic antivirus recognises known malware (signatures) and suspicious behaviour. Windows includes Microsoft Defender.
• EDR (Endpoint Detection and Response) records workstation activity (processes, connections, changes), detects attack behaviour, and lets you isolate a machine and investigate. It is driven from a central console, often with a monitoring team (SOC).
• Updates: most successful attacks exploit flaws that are already fixed. Apply them quickly, system and software, after a test on a few machines in a company.
• Digital hygiene: accounts kept current (leavers' accounts removed), least privilege, tested backups, MFA, encrypted laptops, an inventory of the fleet. France's ANSSI publishes a 42-measure IT hygiene guide for organisations.

Practice (30 min): auditing your machine

1. Windows: Windows Security → virus protection, firewall, account protection; Windows Update: any updates pending?
2. Accounts: net user (Windows) or the account list: who is an administrator? Any unused account?
3. Encryption: is BitLocker (Windows) or LUKS (Linux) on for your laptop?
4. Debian VM: sudo apt update && apt list --upgradable, then apply.
5. Backup: when did you last restore a file?
6. Write a ten-line audit report: finding, risk, action, priority.

Recap (10 min)

Three lines: antivirus versus EDR, why updates first, three hygiene measures.

Day 48 · 20/12 — GDPR: the essentials for a technician

Goal: know the principles that change the way a technician works.

Theory (20 min)

The General Data Protection Regulation (GDPR, EU regulation 2016/679, RGPD in French) has applied since 25 May 2018. It protects personal data: any information that identifies a person, directly (name) or indirectly (IP address, identifier, photo). In France the supervisory authority is the CNIL. The principles of Article 5:

• lawfulness, fairness and transparency;
• purpose limitation: collect for a specific purpose;
• data minimisation: only what is necessary;
• accuracy;
• storage limitation: a set duration, then deletion;
• integrity and confidentiality: appropriate security;
• and accountability: being able to demonstrate it.

For a technician, in practice: look at personal data only for the task at hand, do not copy it to a personal stick, report a leak or loss at once (the organisation has 72 hours to notify the authority of a breach that carries a risk), respect the retention periods of logs and backups.

Practice (30 min)

1. Read the CNIL's page presenting the GDPR's principles and its page on securing personal data (both have English versions).
2. Write your five-line "must know" sheet: what personal data is, the key principles, your reflexes during an intervention, the notification deadline, whom to tell in the organisation (the data protection officer, DPO).
3. Go back to the day 36 backup plan: what retention period would you set, and why?

Recap (10 min)

Recite your sheet from memory.

Day 49 · 21/12 — Maths review: conversions and powers of 2

Goal: twenty timed calculations, no calculator, and measure your progress since day 3.

Theory (20 min): the tables to know

Reread your notebook for days 3, 10 and 17 to 19: the weights of a byte, the powers of 2 up to 2¹⁶, the /25 to /30 table, the block-size method. Then run through the generators below: the goal is speed.

Practice (30 min)

Twenty calculations on paper, stopwatch running: five decimal → binary, five binary → decimal, three hexadecimal ↔ decimal, three host counts, two network addresses, two broadcast addresses. Goal: under 30 seconds per conversion. Note your total time and compare it with day 3.

Recap (10 min)

Note the two slowest kinds of calculation: you will redo them on day 55.

Day 50 · 22/12 — Technical English: two official documentation pages

Goal: read two pages of official documentation and summarise each in three sentences.

Theory (20 min): reading documentation

Official documentation often has the same structure: Overview, Prerequisites, Installation or Getting started, Configuration, Examples, Troubleshooting, Reference. Read the headings first, then the examples, then the text. Frequent words: deprecated (obsolete, no longer to be used), default, required / optional, supported, warning, note, see also.

Practice (30 min)

1. Read the nft manual page (introduction), or the "Getting started" page of the nginx or Docker documentation.
2. Read a Microsoft Learn page on a topic you have covered: local accounts, GPOs or Get-Service.
3. Summarise each in three sentences: what it is, how to use it, one pitfall or limit.
4. Add the new words to your day 11 cards.

Recap (10 min)

Read your two summaries aloud.

Day 51 · 23/12 — The job: ticketing, SLAs, ITIL, customer relations

Goal: write clear tickets and understand how a support team is organised.

Theory 1/2: ITIL and tickets

ITIL is a body of IT service management practice, born in the United Kingdom in the late 1980s (the current version is ITIL 4). Two notions not to mix up:

• an incident: an interruption or degradation of a service ("the second-floor printer no longer prints");
• a service request: a normal request ("create an account for a new starter").

A problem is the cause of one or more incidents, which you try to remove. Every request becomes a ticket in a tool (GLPI is a free tool widely used in France), with a priority worked out from the impact (how many people) and the urgency.

Theory 2/2: SLAs and customer relations

The SLA (service level agreement) sets the commitments: time to pick up, time to resolve by priority, hours covered, promised availability. Support levels: level 1 (reception, diagnosis, simple fixes), level 2 (specialist technician), level 3 (expert or vendor). With the user: listen, rephrase, ask closed questions to diagnose, announce a time and keep it, explain without jargon, confirm the fix before closing.

Practice (30 min)

Write two complete fictitious tickets:

1. An incident: requester, date, category, impact, urgency, priority, factual description (what happens, since when, exact error message), diagnosis, actions taken in order, resolution, user's confirmation, time spent.
2. A request: a new employee joining accounts (account, group, access to day 34's share, e-mail, workstation), with the task list and who approves.

Recap (10 min)

Three lines: incident, request, problem; what an SLA commits to; the three support levels.

Day 52 · 24/12 — Redo the full network lab in one session

Goal: redo on your own, in one go, VLANs, routing, DHCP, DNS and NAT in Packet Tracer.

Theory (20 min): the plan before the cabling

Before placing a device, write the addressing plan: each network, its prefix, its gateway, the DHCP range, the fixed addresses. Then cable, configure layer by layer, and test at each step instead of testing everything at the end.

Practice (30 min, timed)

1. A switch with both VLANs; a "router-on-a-stick": subinterfaces gi0/0.10 and gi0/0.20 with encapsulation dot1Q 10 (and 20), the switch port as a trunk.
2. One DHCP pool per VLAN on the router, excluding the gateways.
3. A Packet Tracer server on the server network, DNS service on with an A record intranet.sme.example, given as DNS in the pools.
4. A second router for the "Internet", the /30 link, NAT overload on the first.
5. Tests: a PC in each VLAN gets an address, reaches the other VLAN, resolves intranet.sme.example, reaches the "Internet" router.

Recap (10 min)

Compare with day 28: time spent, commands forgotten, faults met. Note what is still shaky.

Day 53 · 25/12 — Redo the full Linux lab

Goal: redo permissions, services and a script on your own, on a clean VM.

Theory (20 min): the checklist

Reread your notebook for days 7 to 9, 32, 37 to 39 and 45, then write the list of what you are going to do, without the commands: that is your plan. The commands will come from memory.

Practice (30 min, timed)

1. Restore the Debian VM's clean snapshot.
2. Users and groups: two accounts, a group, a shared directory at 770, tested with both accounts.
3. Services: nginx installed, page in place, enabled at boot; checked with curl and from Windows.
4. Firewall: the day 45 policy, applied and persistent.
5. Script: the day 39 backup script, scheduled by cron, with a tested restore.
6. Logs: find nginx's start and an SSH login in journalctl.

Recap (10 min)

Compare with day 14: time, hesitations, commands to review.

Day 54 · 26/12 — A CCNA 1 style mock exam

Goal: sit a mock exam under real conditions and pin down your gaps precisely.

Theory (20 min): preparing the exam

The Cisco Networking Academy course "CCNA: Introduction to Networks" (the first of the three CCNA courses) ends with module exams and a final exam; if you have access, sit the practice final. Otherwise build your own 50-question multiple-choice test from your day 14 and 28 quizzes and the exercises on this site. Rules: one hour, no notes, no calculator, one attempt.

Practice (30 min)

1. Sit the test (run into the recap time if needed: the exam matters more than the timing today).
2. Note your score.
3. For each mistake: the topic, the right answer, and why you got it wrong (forgot, mixed up, miscalculated, read too fast).

Recap (10 min)

Group your gaps by topic: that is tomorrow's programme.

Day 55 · 27/12 — Filling the gaps

Goal: go back over yesterday's missed topics and redo their exercises.

Theory (20 min)

For each of the three most-missed topics, reread the matching session of this path and redo its recap from memory. The generators below cover the calculations, the most frequent source of mistakes.

Practice (30 min)

1. Redo the missed mock-exam questions, then exercises of the same kind from the sessions concerned.
2. For each confusion (for example SMTP and IMAP, or incremental and differential), write one sentence that tells them apart.

Recap (10 min)

Retake the missed mock-exam questions: how many do you get right now?

Day 56 · 28/12 — Final project 1/2: the virtual SME

Goal: build the model of a small business: directory, DHCP, DNS, file sharing, printing.

Theory (20 min): the specification

The SME from your day 33: twenty people, two departments (Accounts, Workshop). It needs a directory for its accounts, addresses handed out automatically, names resolved internally, one shared folder per department, a shared printer. Two routes, depending on your hardware:

• All in Packet Tracer: the simulated servers provide DHCP, DNS and a file service; the directory stays a diagram.
• With VMs: a Windows Server evaluation VM (domain controller, DNS, DHCP, shares, printing) and your Windows 11 VM joined to the domain; the Debian VM can provide the Samba share and the PDF printer.

Practice (30 min)

1. Write the addressing plan and the list of servers with their role.
2. Cable the model (Packet Tracer) or create the VMs on a VirtualBox internal network.
3. Set up, in order: directory (or its diagram), DNS, DHCP, per-department shares with group rights, shared printer.
4. Test from one workstation per department: address received, name resolved, access to its share and refusal on the other, printing.

Recap (10 min)

List what works, what does not, and what is left for tomorrow.

Day 57 · 29/12 — Final project 2/2: secure and document

Goal: harden the model and write its technical documentation.

Theory (20 min): a project's documentation

The technical file expected on a course often follows this outline: context and need, architecture (network diagram, addressing plan), installation and configuration of each service, security applied, tests run with their results, operating procedures (backup, adding a user), limits and possible improvements. A readable diagram is worth a page of text.

Practice (30 min)

1. Secure: firewall (only the useful ports), group rights checked, named accounts, separate administration accounts, strong passwords, updates applied, a scheduled backup.
2. Retest everything that worked yesterday: hardening that breaks a service is an outage.
3. Write the documentation along the outline above, with the diagram.

Recap (10 min)

Have someone read the documentation, or reread it the next morning: every question it raises is a gap.

Day 58 · 30/12 — Oral presentation of the project

Goal: present the project in five minutes, aloud, as in front of a trainer.

Theory (20 min): building the five minutes

1. Context and need (30 s).
2. The architecture, on the diagram (1 min).
3. The services set up and one justified choice (1 min 30).
4. Security (1 min).
5. A demonstration or test evidence, and one difficulty overcome (45 s).
6. Limits and next steps (15 s).

Prepare three questions you might be asked, with your answer. Justifying a choice ("why a /25?", "why this firewall?") counts more than listing it.

Practice (30 min)

1. Give the presentation standing, aloud, timed, recording yourself.
2. Listen back: time, verbal tics, unclear passages.
3. Do it once more, correcting.

Recap (10 min)

Note three improvements for the next presentation.

Day 59 · 31/12 — Final review

Goal: a two-page summary sheet: what I can do, what needs review.

Theory (20 min): reread the notebook

Reread your whole notebook, days 1 to 58. Note along the way the topics where your recaps were hesitant.

Practice (30 min)

1. Page 1, "what I can do": for each module, the skills acquired, each with its evidence (an exercise passed, a lab redone, a document).
2. Page 2, "to review": the shaky topics, ranked by priority, with the session to go back to.
3. Tick the start-of-course checklist on the path page, honestly.

Recap (10 min)

Three lines in the notebook: what you are proudest of, what cost you the most, what you will do in the first week of the course.