PROVA – SERVIÇOS `systemd` E GERENCIAMENTO DE PROCESSOS NO UBUNTU 24.04

Nome do estudante: _____________________________________
Turma: ____________

PARTE 1 – INVESTIGAÇÃO DE UM SERVIÇO `systemd` JÁ ATIVO (PORTA 3000)

1. PRÉ-REQUISITOS

Antes de iniciar esta seção, certifique-se de que as seguintes condições estão atendidas:

Um servidor Wiki.js configurado para rodar na porta 3000.
Um servidor NGINX ativo.

Comandos de preparação:

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

2. CONTEXTO DO CENÁRIO

O Sr. Éric, administrador de sistemas, está tentando fazer o deploy da aplicação Wiki.js. A instalação parece correta, mas o aplicativo não responde como esperado na porta 3000. Você deve realizar uma investigação detalhada para identificar e resolver definitivamente esse problema.

3. ETAPAS DA INVESTIGAÇÃO

Etapa 1 – Verificação da porta utilizada

Verificação inicial da porta 3000:

lsof -i :3000

Resultado:

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

Pergunta 1:

Para que serve o comando lsof? Compare com o comando fuser: eles têm os mesmos usos? Em que diferem no gerenciamento de arquivos ou portas abertas no Linux?

Resposta 1:

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

Etapa 2 – Tentativa de parada manual

Tentativa de parar o processo:

kill -15 9744
kill -9 9744

Pergunta 2:

O processo reinicia automaticamente após ser parado manualmente? Explique por quê, com base nos mecanismos do systemd:

Resposta 2:

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

Pergunta 3:

Qual a diferença entre um daemon (ou processo em segundo plano) clássico e um serviço systemd? Dê um exemplo concreto para ilustrar cada caso.

Resposta 3:

Etapa 3 – Identificação do serviço responsável

Identificação do serviço systemd:

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

Serviço identificado:

wikijs.service

Pergunta 4:

Você identificou o serviço wikijs.service usando os seguintes comandos:
systemctl list-units --type=service --state=running | grep -i wiki
ps aux | grep node
ls -l /etc/systemd/system/ | grep wiki
Explique como esses comandos permitem confirmar a existência de um serviço systemd ativo. Justifique por que essas três abordagens são complementares.

Resposta 4:

Etapa 4 – Verificação do vínculo entre serviço e porta

Confirmação final do vínculo:

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

Pergunta 5:

Explique como os comandos acima permitem estabelecer um vínculo direto entre um PID específico, a porta 3000 e o serviço systemd identificado anteriormente. Por que essa é uma etapa indispensável antes de parar ou desabilitar um serviço?

Resposta 5:

Etapa 5 – Desativação definitiva do serviço

Comandos finais:

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

Verificação da liberação da porta:

lsof -i :3000

Pergunta 6:

Explique a diferença entre os comandos systemctl stop e systemctl disable. Por que é necessário executar ambos para garantir que o serviço não será reiniciado, mesmo após um reboot da máquina? Por que o comando kill -9 é insuficiente neste caso?

Resposta 6:

Pergunta 7:

7.1. Por que o processo ligado à porta 3000 reiniciava automaticamente após um kill -9?

Resposta: ...............................................................................................................................

7.2. Qual comando permite identificar rapidamente os serviços systemd ativos contendo uma palavra-chave?

Resposta: ...............................................................................................................................

7.3. Qual método permitiu confirmar o vínculo entre a porta e o arquivo wikijs.service?

Resposta: ...............................................................................................................................

7.4. Explique por que é recomendado usar systemctl stop e disable em vez de kill -9.

Resposta: ............................................................................................................................... ...............................................................................................................................

7.5. Proponha um script simples para automatizar essa busca:

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

Pergunta 8 (Bônus):

Para aprofundar, teste e explique essas ferramentas:

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

PARTE 2 – DETECÇÃO E NEUTRALIZAÇÃO DE UM SERVIÇO MALICIOSO (`systemd`)

1. INSTRUÇÕES GERAIS IMPORTANTES

Execução no Ubuntu 24.04.
O serviço malicioso logservice.service está ativo desde a inicialização.
Entregar um relatório final preciso.
Não é permitido reiniciar ou desligar completamente o sistema.

2. CONTEXTO TÉCNICO

Um serviço malicioso gera continuamente arquivos de log em /var/log/malicious, podendo saturar o sistema. Esse serviço reinicia automaticamente em caso de parada (Restart=always).

Arquivo suspeito:

/etc/systemd/system/logservice.service

3. OBJETIVO

Identificar um serviço anômalo.
Parar e desabilitar definitivamente um serviço systemd.
Limpar os arquivos gerados.
Fornecer um relatório técnico preciso.

3.1. Criar o script malicioso

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

Conteúdo do script:

#!/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. Tornar o script executável

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

3.3. Criar o serviço `systemd` malicioso

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

Conteúdo do arquivo logservice.service:

[Unit]
Description=Serviço Malicioso – Gerador de Logs
After=network.target

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

[Install]
WantedBy=multi-user.target

3.4. Ativar e iniciar o serviço

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

3.5. Verificar o comportamento

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

Você verá o arquivo crescer rapidamente.
Este serviço simula um comportamento malicioso do tipo "log flooding", típico de um binário instalado discretamente e persistente na inicialização. Isso leva você a:
- Identificar um arquivo que cresce perigosamente (du, lsof, etc.)
- Correlacionar PID ↔ serviço systemd
- Tentar parar com kill -9 (falha)
- Entender Restart=always
- Aplicar a sequência correta:
  - systemctl stop
  - systemctl disable
  - rm
  - daemon-reload
  - Limpeza

4. ETAPAS A REALIZAR

Etapa 1 – Identificação do problema

Comandos a utilizar:

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

Pergunta 9:

Explique o que faz cada um desses comandos e como eles permitem identificar um comportamento anômalo relacionado ao serviço logservice. Sua resposta deve mencionar os elementos técnicos observáveis (tamanho, processo, arquivos abertos, status, etc.).

Resposta:

Etapa 2 – Tentativas de parada

Comando 1 (parada forçada do processo):

sudo kill -9 <PID>

Comando 2 (parada via systemd):

sudo systemctl stop logservice

Pergunta 10:

Os dois comandos acima visam interromper a execução do serviço malicioso.

Qual deles é realmente eficaz para parar o serviço de forma duradoura?

Por que o comando kill -9 é frequentemente insuficiente no caso de um serviço gerenciado pelo systemd?

Justifique sua resposta em relação aos parâmetros do arquivo .service.

Resposta esperada:

Etapa 3 – Desativação completa do serviço

Desativação do serviço na inicialização:

sudo systemctl disable logservice

Remoção do arquivo de definição:

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

Recarregamento da configuração do systemd:

sudo systemctl daemon-reload

Remoção dos arquivos gerados:

sudo rm -rf /var/log/malicious

Pergunta 11:

Explique precisamente o papel de cada um dos comandos acima.

Por que é necessário executar os três primeiros comandos nesta ordem para desabilitar totalmente um serviço systemd?

Por que o comando daemon-reload é indispensável nesse processo?

E, por fim, qual o risco se a exclusão da pasta /var/log/malicious for esquecida?

Resposta:

Etapa 4 – Validação final

Verificação da parada do serviço:

sudo systemctl status logservice

Verificação da exclusão do diretório:

ls -la /var/log/malicious

Pergunta 12:

Explique o que essas duas comandos permitem verificar.

O que você deve observar em suas respectivas saídas se o serviço foi realmente neutralizado e se os arquivos maliciosos foram realmente excluídos?

Resposta esperada:

Pergunta 13:

13.1. Identificação

Qual comando detectou o diretório problemático?

Resposta: ...............................................................................................................................

Qual era o nome exato do processo malicioso?

Resposta: ...............................................................................................................................

Qual comando permitiu obter seu PID?

Resposta: ...............................................................................................................................

13.2. Parada do processo

Comando utilizado para parada forçada?

Resposta: ...............................................................................................................................

O processo retornou automaticamente?

Resposta: ...............................................................................................................................

Comando eficaz para parar definitivamente o serviço?

Resposta: ...............................................................................................................................

13.3. Desativação e limpeza

Comando utilizado para remover definitivamente o serviço?

Resposta: ...............................................................................................................................

Comando utilizado para remover os arquivos gerados?

Resposta: ...............................................................................................................................

13.4. Questões de compreensão

Por que kill -9 é insuficiente contra certos serviços?

Resposta: ...............................................................................................................................

O que significa Restart=always em um arquivo .service?

Resposta: ...............................................................................................................................

Comando para recarregar a configuração dos serviços systemd?

Resposta: ...............................................................................................................................

BÔNUS (OPCIONAL)

Criar um serviço hello.service que escreve a data atual a cada 5 segundos em /tmp/bonjour.log:

Script: /opt/bonjour.sh
Serviço: /etc/systemd/system/hello.service

Inclua sua solução no relatório final se concluída.

ENTREGÁVEL FINAL ESPERADO

Conteúdo obrigatório:

Todos os comandos utilizados em anexo
Observações detalhadas
Respostas completas às perguntas
Solução bônus se realizada

Prova criada em: Dezembro de 2024

PARTE 1 – INVESTIGAÇÃO DE UM SERVIÇO systemd JÁ ATIVO (PORTA 3000)​

1. PRÉ-REQUISITOS​

2. CONTEXTO DO CENÁRIO​

3. ETAPAS DA INVESTIGAÇÃO​

Etapa 1 – Verificação da porta utilizada​

Etapa 2 – Tentativa de parada manual​

Etapa 3 – Identificação do serviço responsável​

Etapa 4 – Verificação do vínculo entre serviço e porta​

Etapa 5 – Desativação definitiva do serviço​

PARTE 2 – DETECÇÃO E NEUTRALIZAÇÃO DE UM SERVIÇO MALICIOSO (systemd)​

1. INSTRUÇÕES GERAIS IMPORTANTES​

2. CONTEXTO TÉCNICO​

3. OBJETIVO​

3.1. Criar o script malicioso​

3.2. Tornar o script executável​

3.3. Criar o serviço systemd malicioso​

3.4. Ativar e iniciar o serviço​

3.5. Verificar o comportamento​

4. ETAPAS A REALIZAR​

Etapa 1 – Identificação do problema​

Etapa 2 – Tentativas de parada​

Etapa 3 – Desativação completa do serviço​

Etapa 4 – Validação final​

13.1. Identificação​

13.2. Parada do processo​

13.3. Desativação e limpeza​

13.4. Questões de compreensão​

BÔNUS (OPCIONAL)​

ENTREGÁVEL FINAL ESPERADO​

PARTE 1 – INVESTIGAÇÃO DE UM SERVIÇO `systemd` JÁ ATIVO (PORTA 3000)

1. PRÉ-REQUISITOS

2. CONTEXTO DO CENÁRIO

3. ETAPAS DA INVESTIGAÇÃO

Etapa 1 – Verificação da porta utilizada

Etapa 2 – Tentativa de parada manual

Etapa 3 – Identificação do serviço responsável

Etapa 4 – Verificação do vínculo entre serviço e porta

Etapa 5 – Desativação definitiva do serviço

PARTE 2 – DETECÇÃO E NEUTRALIZAÇÃO DE UM SERVIÇO MALICIOSO (`systemd`)

1. INSTRUÇÕES GERAIS IMPORTANTES

2. CONTEXTO TÉCNICO

3. OBJETIVO

3.1. Criar o script malicioso

3.2. Tornar o script executável

3.3. Criar o serviço `systemd` malicioso

3.4. Ativar e iniciar o serviço

3.5. Verificar o comportamento

4. ETAPAS A REALIZAR

Etapa 1 – Identificação do problema

Etapa 2 – Tentativas de parada

Etapa 3 – Desativação completa do serviço

Etapa 4 – Validação final

13.1. Identificação

13.2. Parada do processo

13.3. Desativação e limpeza

13.4. Questões de compreensão

BÔNUS (OPCIONAL)

ENTREGÁVEL FINAL ESPERADO