EXAM – `systemd` SERVICES AND PROCESS MANAGEMENT ON UBUNTU 24.04

Student Name: _____________________________________
Group: ____________

PART 1 – INVESTIGATION OF AN ALREADY ACTIVE `systemd` SERVICE (PORT 3000)

1. PREREQUISITES

Before starting this section, ensure the following conditions are met:

A Wiki.js server configured to run on port 3000.
An active NGINX server.

Preparation commands:

sudo apt update
sudo apt install nginx
sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl status nginx

2. SCENARIO CONTEXT

Mr. Eric, a system administrator, is attempting to deploy the Wiki.js application. The installation seems correct, but the application is not responding as expected on port 3000. You need to conduct a detailed investigation to identify and permanently resolve this issue.

3. INVESTIGATION STEPS

Step 1 – Checking the used port

Initial check of port 3000:

lsof -i :3000

Result:

COMMAND   PID   USER     FD   TYPE DEVICE SIZE/OFF NODE NAME
node     9744   wikijs   22u  IPv4  59242      0t0  TCP *:3000 (LISTEN)

Question 1:

What is the purpose of the lsof command? Compare it to the fuser command: do they have the same uses? How do they differ in managing open files or ports on Linux?

Answer 1:

...............................................................................................................................

Step 2 – Attempting manual stop

Attempt to stop the process:

kill -15 9744
kill -9 9744

Question 2:

Does the process automatically restart after being manually stopped? Explain why, based on systemd mechanisms:

Answer 2:

............................................................................................................................... ............................................................................................................................... ...............................................................................................................................

Question 3:

What is the difference between a classic daemon (or background process) and a systemd service? Provide a concrete example to illustrate each case.

Answer 3:

Step 3 – Identifying the responsible service

Identification of the systemd service:

systemctl list-units --type=service --state=running | grep -i wiki
ps aux | grep node
ls -l /etc/systemd/system/ | grep wiki

Identified service:

wikijs.service

Question 4:

You identified the wikijs.service using the following commands:
systemctl list-units --type=service --state=running | grep -i wiki
ps aux | grep node
ls -l /etc/systemd/system/ | grep wiki
Explain how these commands confirm the existence of an active systemd service. Justify why these three approaches are complementary.

Answer 4:

Step 4 – Verifying the link between service and port

Final confirmation of the link:

sudo lsof -i -P -n | grep 3000
ps -p <PID> -o pid,cmd

Question 5:

Explain how the above commands establish a direct link between a given PID, port 3000, and the previously identified systemd service. Why is this step indispensable before stopping or disabling a service?

Answer 5:

Step 5 – Definitive service deactivation

Final commands:

sudo systemctl stop wikijs.service
sudo systemctl disable wikijs.service

Verification of port release:

lsof -i :3000

Question 6:

Explain the difference between the systemctl stop and systemctl disable commands. Why is it necessary to execute both to ensure the service does not restart, even after a machine reboot? Why is the kill -9 command insufficient in this case?

Answer 6:

Question 7:

7.1. Why did the process linked to port 3000 automatically restart after a kill -9?

Answer: ...............................................................................................................................

7.2. Which command quickly identifies active systemd services containing a keyword?

Answer: ...............................................................................................................................

7.3. Which method allowed you to confirm the link between the port and the wikijs.service file?

Answer: ...............................................................................................................................

7.4. Explain why it is recommended to use systemctl stop and disable rather than kill -9.

Answer: ............................................................................................................................... ...............................................................................................................................

7.5. Propose a simple script to automate this search:

# Script:
...............................................................................................................................
...............................................................................................................................

Question 8 (Bonus):

To go further, test and explain these tools:

systemd-cgls
ss -lptn
fuser -k 3000/tcp
journalctl -u wikijs.service

PART 2 – DETECTION AND NEUTRALIZATION OF A MALICIOUS `systemd` SERVICE

1. IMPORTANT GENERAL INSTRUCTIONS

Conducted on Ubuntu 24.04.
The malicious service logservice.service is active from startup.
Submit a precise final report.
No system reboot or complete shutdown allowed.

2. TECHNICAL CONTEXT

A malicious service continuously generates log files in /var/log/malicious, risking system saturation. This service automatically restarts if stopped (Restart=always).

Suspicious file:

/etc/systemd/system/logservice.service

3. OBJECTIVE

Identify an abnormal service.
Stop and permanently disable a systemd service.
Clean up generated files.
Provide a precise technical report.

3.1. Create the malicious script

sudo mkdir -p /opt/malicious
sudo nano /opt/malicious/logwriter.sh

Script content:

#!/bin/bash

mkdir -p /var/log/malicious

while true; do
  echo "$(date) - LOG ENTRY" >> /var/log/malicious/attack.log
  sleep 0.1
done

3.2. Make the script executable

sudo chmod +x /opt/malicious/logwriter.sh

3.3. Create the malicious `systemd` service

sudo nano /etc/systemd/system/logservice.service

logservice.service file content:

[Unit]
Description=Malicious Service – Log Generator
After=network.target

[Service]
ExecStart=/opt/malicious/logwriter.sh
Restart=always
RestartSec=1

[Install]
WantedBy=multi-user.target

3.4. Enable and start the service

sudo systemctl daemon-reload
sudo systemctl enable logservice
sudo systemctl start logservice

3.5. Verify behavior

sudo systemctl status logservice
ls -lh /var/log/malicious/

You will see the file grow very quickly.
This service simulates a malicious "log flooding" behavior, typical of a binary installed discreetly and persistent at startup. It prompts you to:
- Identify a file that is dangerously growing (du, lsof, etc.)
- Correlate PID ↔ systemd service
- Attempt to stop with kill -9 (failure)
- Understand Restart=always
- Apply the correct sequence:
  - systemctl stop
  - systemctl disable
  - rm
  - daemon-reload
  - Cleanup

4. STEPS TO PERFORM

Step 1 – Problem identification

Commands to use:

du -sh /var/log/*
ps aux | grep logservice
lsof | grep malicious
systemctl status logservice

Question 9:

Explain what each of these commands does and how it helps identify abnormal behavior related to the logservice. Your answer should mention observable technical elements (size, process, open files, status, etc.).

Answer:

Step 2 – Stop attempts

Command 1 (brutal process stop):

sudo kill -9 <PID>

Command 2 (stop via systemd):

sudo systemctl stop logservice

Question 10:

The two commands above aim to interrupt the execution of the malicious service.

Which one is truly effective for permanently stopping the service?

Why is the kill -9 command often insufficient for a service managed by systemd?

Justify your answer in relation to the .service file parameters.

Expected answer:

Step 3 – Complete service deactivation

Disable the service at startup:

sudo systemctl disable logservice

Remove the definition file:

sudo rm /etc/systemd/system/logservice.service

Reload systemd configuration:

sudo systemctl daemon-reload

Remove generated files:

sudo rm -rf /var/log/malicious

Question 11:

Explain precisely the role of each of the above commands.

Why must the first three commands be executed in this order to fully disable a systemd service?

Why is the daemon-reload command indispensable in this process?

And finally, what is the risk if the deletion of the /var/log/malicious directory is forgotten?

Answer:

Step 4 – Final validation

Verification of service stop:

sudo systemctl status logservice

Verification of directory deletion:

ls -la /var/log/malicious

Question 12:

Explain what these two commands verify.

What should you observe in their respective outputs if the service has been successfully neutralized and if the malicious files have been successfully deleted?

Expected answer:

Question 13:

13.1. Identification

Which command detected the problematic directory?

Answer: ...............................................................................................................................

What was the exact name of the malicious process?

Answer: ...............................................................................................................................

Which command provided its PID?

Answer: ...............................................................................................................................

13.2. Process stop

Command used for a brutal stop?

Answer: ...............................................................................................................................

Did the process automatically return?

Answer: ...............................................................................................................................

Effective command to permanently stop the service?

Answer: ...............................................................................................................................

13.3. Deactivation and cleanup

Command used to permanently remove the service?

Answer: ...............................................................................................................................

Command used to remove the generated files?

Answer: ...............................................................................................................................

13.4. Understanding questions

Why is kill -9 insufficient against certain services?

Answer: ...............................................................................................................................

What does Restart=always mean in a .service file?

Answer: ...............................................................................................................................

Command to reload systemd service configuration?

Answer: ...............................................................................................................................

BONUS (OPTIONAL)

Create a hello.service writing the current date every 5 seconds to /tmp/bonjour.log:

Script: /opt/bonjour.sh
Service: /etc/systemd/system/hello.service

Insert your solution in the final report if completed.

FINAL DELIVERABLE EXPECTED

Required content:

All commands used in the appendix
Detailed observations
Complete answers to questions
Bonus solution if completed

Exam created on: December 2024

PART 1 – INVESTIGATION OF AN ALREADY ACTIVE systemd SERVICE (PORT 3000)​

1. PREREQUISITES​

2. SCENARIO CONTEXT​

3. INVESTIGATION STEPS​

Step 1 – Checking the used port​

Step 2 – Attempting manual stop​

Step 3 – Identifying the responsible service​

Step 4 – Verifying the link between service and port​

Step 5 – Definitive service deactivation​

PART 2 – DETECTION AND NEUTRALIZATION OF A MALICIOUS systemd SERVICE​

1. IMPORTANT GENERAL INSTRUCTIONS​

2. TECHNICAL CONTEXT​

3. OBJECTIVE​

3.1. Create the malicious script​

3.2. Make the script executable​

3.3. Create the malicious systemd service​

3.4. Enable and start the service​

3.5. Verify behavior​

4. STEPS TO PERFORM​

Step 1 – Problem identification​

Step 2 – Stop attempts​

Step 3 – Complete service deactivation​

Step 4 – Final validation​

13.1. Identification​

13.2. Process stop​

13.3. Deactivation and cleanup​

13.4. Understanding questions​

BONUS (OPTIONAL)​

FINAL DELIVERABLE EXPECTED​

PART 1 – INVESTIGATION OF AN ALREADY ACTIVE `systemd` SERVICE (PORT 3000)

1. PREREQUISITES

2. SCENARIO CONTEXT

3. INVESTIGATION STEPS

Step 1 – Checking the used port

Step 2 – Attempting manual stop

Step 3 – Identifying the responsible service

Step 4 – Verifying the link between service and port

Step 5 – Definitive service deactivation

PART 2 – DETECTION AND NEUTRALIZATION OF A MALICIOUS `systemd` SERVICE

1. IMPORTANT GENERAL INSTRUCTIONS

2. TECHNICAL CONTEXT

3. OBJECTIVE

3.1. Create the malicious script

3.2. Make the script executable

3.3. Create the malicious `systemd` service

3.4. Enable and start the service

3.5. Verify behavior

4. STEPS TO PERFORM

Step 1 – Problem identification

Step 2 – Stop attempts

Step 3 – Complete service deactivation

Step 4 – Final validation

13.1. Identification

13.2. Process stop

13.3. Deactivation and cleanup

13.4. Understanding questions

BONUS (OPTIONAL)

FINAL DELIVERABLE EXPECTED