DEV Community: João Pedro

Guia Warcraft III de Etiqueta para Pull Requests

João Pedro — Fri, 16 Jan 2026 15:09:09 +0000

Se os orcs e humanos fossem desenvolvedores, o Code Review seria assim:

Avisos e Erros:

"Can't build there": Quando a build quebra ou o código está no lugar errado.
"Work complete": PR aprovado e mergeado.

No Meio do Caos (A vida de Dev):

"What?": Vendo aquele código legado sem sentido.
"Me busy!" / "Leave me alone!": Quando pedem review no meio do foco.
"No time for play!": Subindo correção de bug em produção.
"Me not that kind of Orc!": Quando sugerem uma gambiarra técnica.

Aceitando Desafios:

"Ready to work!": Abrindo um novo PR.
"Something need doing?": Caçando PRs na fila para revisar.
"I can do that!" / "Be happy to!": Aplicando as sugestões do revisor.
"Work, work!": Codando a próxima task.
"Okie dokie!": O último comentário antes do Approve.

Basic Server Hardening for Ubuntu/Debian: SSH Access and Firewall

João Pedro — Mon, 04 Aug 2025 22:54:01 +0000

Contrary to what many tutorials suggest, simply changing the SSH port or installing Fail2Ban is not enough. This documentation shows the exact steps to harden the security of an Ubuntu/Debian server by configuring key-based authentication, disabling insecure defaults, and reducing the attack surface.

Author: joaoprd | joaopedrord2001@gmail.com

Create a Secure Administrator User

Create a user with sudo privileges:

adduser whiterose
usermod -aG sudo whiterose

The user whiterose will be the only one authorized to connect via SSH after hardening.

Generate Public Key and Manually Configure SSH Login

Public key authentication avoids the use of passwords and is essential for a secure server. This step will be done manually, without using ssh-copy-id.

On the Client

Generate the RSA key pair (if it doesn’t already exist):

ssh-keygen -t rsa -b 4096 -C "whiterose@server"

Press Enter to accept the default path (~/.ssh/id_rsa) and, if desired, set a passphrase for the private key.

The generated keys:

Private: ~/.ssh/id_rsa → must never leave the client
Public: ~/.ssh/id_rsa.pub → will be copied to the server

Display the contents of the public key:

cat ~/.ssh/id_rsa.pub

Copy the displayed content (starts with ssh-rsa).

On the Server

Create the .ssh directory for the user whiterose (if it doesn’t exist):

sudo mkdir -p /home/whiterose/.ssh
sudo chown whiterose:whiterose /home/whiterose/.ssh
sudo chmod 700 /home/whiterose/.ssh

Create (or edit) the authorized_keys file:

sudo vim /home/whiterose/.ssh/authorized_keys

Paste the public key copied from the client.

Set the correct permissions

sudo chown whiterose:whiterose /home/whiterose/.ssh/authorized_keys
sudo chmod 600 /home/whiterose/.ssh/authorized_keys

From now on, the user whiterose will be able to connect via SSH using the private key corresponding to the uploaded public key.

Disable root login and password authentication in SSH

On the Ubuntu/Debian server, edit the SSH configuration file:

sudo vim /etc/ssh/sshd_config

Modify or add the following lines:

PermitRootLogin no
PasswordAuthentication no

Restart the SSH service:

sudo systemctl restart ssh

!!! Only do this after confirming that public key access is working for the user whiterose !!!

Enable Firewall (UFW)

Install and activate UFW:

sudo apt update && sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw --force enable

All unauthorized services will be blocked. Only SSH (port 22) will be accessible.

Fix Permissions of Sensitive Files

Adjust permissions of the /etc/shadow file:

sudo chmod 640 /etc/shadow

This ensures that only root and the shadow group have read access to password contents.

Install and Configure Fail2Ban (Protection Against Brute Force Attacks)

Fail2Ban monitors authentication logs and automatically blocks IPs that attempt malicious access to the server. Even with key-based authentication, it is important to protect the server against scanners and brute force attempts.

Installation

sudo apt update && sudo apt install -y fail2ban

Basic Configuration

Fail2Ban comes with default settings, but it’s recommended to create a local configuration file for customization (to avoid conflicts during updates):

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo vim /etc/fail2ban/jail.local

Recommended Adjustments (in jail.local)

In the [DEFAULT] section, modify existing fields or add the following:

[DEFAULT]
ignoreip = (IPs that will never be banned)
bantime = 1h
maxretry = 3
findtime = 10m

Restart Fail2Ban

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

Check the logs

sudo tail -f /var/log/fail2ban.log

Conclusion

By following these steps, you ensure a basic and effective protection for your Ubuntu/Debian server. Using SSH keys, disabling root login, enabling the firewall, and configuring Fail2Ban helps prevent common attacks and makes your system more secure.

Hardening Básico de Servidor Ubuntu/Debian: Acesso SSH e Firewall

João Pedro — Mon, 04 Aug 2025 22:40:30 +0000

Ao contrário do que muitos tutoriais sugerem, alterar apenas a porta SSH ou instalar Fail2Ban não é suficiente. Esta documentação mostra os passos exatos para endurecer a segurança de um servidor Ubuntu / Debian configurando autenticação por chave, desabilitando padrões inseguros e reduzindo a superfície de ataque.

Autor: joaoprd | joaopedrord2001@gmail.com

Criar usuário administrador seguro

Criar um usuário com privilégios sudo:

adduser whiterose
usermod -aG sudo whiterose

O usuário whiterose será o único autorizado a conectar via SSH após o hardening.

Gerar chave pública e configurar login SSH manualmente

A autenticação por chave pública evita o uso de senhas e é essencial para um servidor seguro. Essa etapa será feita manualmente, sem o uso do ssh-copy-id.

No cliente

Gerar o par de chaves RSA (caso ainda não exista):

ssh-keygen -t rsa -b 4096 -C "whiterose@servidor"

Pressione Enter para aceitar o caminho padrão (~/.ssh/id_rsa) e, se desejar, defina uma senha para a chave privada.

As chaves geradas:

Privada: ~/.ssh/id_rsa → nunca deve sair do cliente
Pública: ~/.ssh/id_rsa.pub → será copiada para o servidor

Exibir o conteúdo da chave pública:

cat ~/.ssh/id_rsa.pub

Copie o conteúdo exibido (começa com ssh-rsa).

No servidor

Criar o diretório .ssh para o usuário whiterose (caso não exista):

sudo mkdir -p /home/whiterose/.ssh
sudo chown whiterose:whiterose /home/whiterose/.ssh
sudo chmod 700 /home/whiterose/.ssh

Criar (ou editar) o arquivo authorized_keys:

sudo vim /home/whiterose/.ssh/authorized_keys

Cole a chave pública copiada do cliente.

Ajustar permissões

sudo chown whiterose:whiterose /home/whiterose/.ssh/authorized_keys
sudo chmod 600 /home/whiterose/.ssh/authorized_keys

A partir de agora, o usuário whiterose poderá se conectar via SSH utilizando a chave privada correspondente à pública inserida.

Desativar login root e autenticação por senha no SSH

No servidor Ubuntu / Debian deve-se editar o arquivo de configuração do SSH:

sudo vim /etc/ssh/sshd_config

Modificar ou adicionar:

PermitRootLogin no
PasswordAuthentication no

Reiniciar o serviço SSH:

sudo systemctl restart ssh

!!! Faça isso somente após confirmar que o acesso com chave pública está funcionando para o usuário whiterose !!!

Ativar firewall (UFW)

Instalar e ativar o UFW:

sudo apt update && sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw --force enable

Todos os serviços não autorizados serão bloqueados. Apenas SSH (porta 22) estará acessível.

Corrigir permissões de arquivos sensíveis

Ajustar permissões do arquivo /etc/shadow:

sudo chmod 640 /etc/shadow

Garante que apenas root e o grupo shadow tenham acesso de leitura ao conteúdo das senhas.

Instalar e Configurar Fail2Ban (Proteção contra Brute Force)

O Fail2Ban monitora logs de autenticação e bloqueia automaticamente IPs que tentam acessar o servidor de forma maliciosa. Mesmo com autenticação por chaves, é importante protegê-lo contra scanners e tentativas de força bruta.

Instalação

sudo apt update && sudo apt install -y fail2ban

Configuração Básica

O Fail2Ban já vem com configurações padrão, mas é recomendável criar um arquivo local para personalização (evitando conflitos em atualizações):

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo vim /etc/fail2ban/jail.local

Ajustes Recomendados (em jail.local)

Na seção [DEFAULT], modifique os campos se já existirem ou adicione:

[DEFAULT]
ignoreip = (IPs que nunca serão banidos)
bantime = 1h
maxretry = 3
findtime = 10m

Reinicie o Fail2Ban

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

Verificar os logs

sudo tail -f /var/log/fail2ban.log

Conclusão

Seguindo estes passos, você garante uma proteção básica e eficiente para seu servidor Ubuntu/Debian. Usar chave SSH, desativar o login root, ativar o firewall e configurar o Fail2Ban ajuda a evitar ataques comuns e deixa seu sistema mais seguro.

GLPI - Closing Ticket with API

João Pedro — Tue, 13 Aug 2024 20:53:25 +0000

Unlike what is described in the official GLPI documentation, the system does not work as expected and does not correctly respond to the provided parameters. The documentation found at "https://YOUR_GLPI_DOMAIN.COM/apirest.php" states that some parameters should be passed in the request body, but this doesn't always work. The only method that seems to work is passing the parameters directly in the URL.

Autor: joaoprd | joaopedrord2001@gmail.com

Starting a Session

To initiate any call, we need the session_token and app-token. To generate the session_token, we make a request to "https://YOUR_GLPI_DOMAIN.COM/apirest.php/initSession" with the app-token and user_token parameters, which are available in the user account we are working with.

The following request generates the session_token:

curl --location 'https://DOMINIO_GLPI.COM/apirest.php/initSession?app-token={YOUR-APP-TOKEN}&user_token={YOUR-USER-TOKEN}'

Ticket Search

With the session_token in hand, we can perform searches for tickets. However, according to the GLPI documentation, it appears that the endpoint does not function as per the provided examples, as it does not allow sending a payload to this endpoint, resulting in the following error:

[
    "ERROR_JSON_PAYLOAD_FORBIDDEN",
    "GET Request should not have json payload (http body); view documentation in your browser at /#ERROR_JSON_PAYLOAD_FORBIDDEN"
]

To circumvent this limitation, we will pass the parameters directly in the URL of the request, using the link "https://YOUR_GLPI_DOMAIN.COM/apirest.php/search/Ticket". You must include the app-token and session-token to connect, and then add the desired filters to locate the necessary information.

curl --location --globoff 'https://DOMINIO_GLPI.COM/apirest.php/search/Ticket
?app-token={YOUR-APP-TOKEN}
&session_token={YOUR-SESSION-TOKEN}
&criteria[0][field]=1
&criteria[0][searchtype]=contains
&criteria[0][value]=Verifica%C3%A7%C3%A3o%20diaria
&criteria[1][link]=AND
&criteria[1][field]=12
&criteria[1][searchtype]=equals
&criteria[1][value]=2
&glpilist_limit=1000' \
--header 'Content-Type: application/json'

"Criteria" refers to the filtering criteria, where fields are specific filters to be applied to find something. For example, "criteria[0][field]=1" is designated for the title, where we pass "criteria[0][searchtype]=contains" indicating that it contains "criteria[0][value]=Verifica%C3%A7%C3%A3o%20diaria", which, in this case, is 'Verificação diária' that was encoded. This is where the ticket title should be placed. Another filter is applied below in "criteria[1][link]=AND", where an AND is performed, indicating a new search following the previous one.

To analyze all filtering options, you can make a request to:

curl --location 'https://DOMINIO_GLPI.COM/apirest.php/listSearchOptions/Ticket?app-token={YOUR-APP-TOKEN}&session_token={YOUR-SESSION-TOKEN}' \
--data ''

Some example responses:

{
    "common": {
        "name": "Características"
    },
    "1": {
        "name": "Título",
        "table": "glpi_tickets",
        "field": "name",
        "datatype": "itemlink",
        "nosearch": false,
        "nodisplay": false,
        "available_searchtypes": [
            "contains",
            "notcontains"
        ],
        "uid": "Ticket.name"
    },
    "21": {
        "name": "Descrição",
        "table": "glpi_tickets",
        "field": "content",
        "datatype": "text",
        "nosearch": false,
        "nodisplay": false,
        "available_searchtypes": [
            "contains",
            "notcontains"
        ],
        "uid": "Ticket.content"
    },
    "2": {
        "name": "ID",
        "table": "glpi_tickets",
        "field": "id",
        "datatype": "number",
        "nosearch": false,
        "nodisplay": false,
        "available_searchtypes": [
            "contains",
            "notcontains"
        ],
        "uid": "Ticket.id"
    },
...

Creating a Task

With the previous request, we performed the search for tickets, which will be returned in JSON format. With this information, we can handle the necessary tasks. In this specific documentation, we will close the ticket. However, before completely closing the ticket, we need to create a task linked to the ticket that must be completed.

Some GLPI systems require specific methods for closing tickets. In the system I am working with, it is necessary to create a task and a solution before closing the ticket.

Below is the request that creates the task in the ticket (remember that the ticket I am passing was generated in the previous search in "Ticket Search"). In my automation code, I implemented a loop to process all returned tickets, but that will not be covered in this documentation.

curl --location 'https://DOMINIO_GLPI.COM/apirest.php/TicketTask?session_token={YOUR-SESSION-TOKEN}' \
--header 'app_token: {YOUR-APP-TOKEN}' \
--header 'Authorization: user_token {YOUR-USER-TOKEN}' \
--header 'Content-Type: application/json' \
--data '{
    "input": {
        "tickets_id": 2408020023, 
        "taskcategories_id": 0, 
        "content": "Verificação diária - Tarefa realizada.",
        "actiontime": 60, 
        "state": 3 
    }
}
'

We should note that in all cases, we pass the app_token in the header, and the Authorization, which contains the user_token for API authentication.

Key points to consider are the parameters passed in the request body:

content: The content that will be added to the task.
actiontime: The time spent on the task.
state: The status the ticket will have after the task is created.

Closing the Ticket

With the task added to the ticket, it is only necessary to close the ticket, which follows the same process used to add the task.

The following request is used:

curl --location --request PUT 'https://DOMINIO_GLPI.COM/apirest.php/Ticket/2408020023?session_token={YOUR-SESSION-TOKEN}' \
--header 'app_token: {YOUR-APP-TOKEN}' \
--header 'Authorization: user_token {YOUR-USER-TOKEN}' \
--header 'Content-Type: application/json' \
--data '{
  "input": {
    "status": 6, 
    "solution": "<p>Chamado finallizado</p>",  
    "content": "<p>Chamado finallizado</p>",
    "solutiontypes_id": 3, 
    "solutiontemplates_id": 5  
  }
}'
'

The status: 6 indicates the ticket is closed. For this, it is necessary to pass the solution and content as the texts for the solution. An important point in this request is the solutiontemplates_id, which must be created by the GLPI system administrator, with this ID serving as a reference for a standard solution.

GLPI - Fechar ticket com API

João Pedro — Tue, 13 Aug 2024 20:29:28 +0000

Diferente do que está descrito na documentação oficial do GLPI, o sistema não funciona como deveria e não responde corretamente aos parâmetros fornecidos. A documentação encontrada em "https://DOMINIO_GLPI.COM/apirest.php" informa que alguns parâmetros devem ser passados no corpo da requisição, mas isso nem sempre funciona. O único jeito que parece funcionar é passando os parâmetros diretamente na URL.

Autor: joaoprd | joaopedrord2001@gmail.com

Iniciando sessão

Para iniciar qualquer chamada, precisamos do session_token e do app-token. Para gerar o session_token, fazemos uma requisição para "https://DOMINIO_GLPI//apirest.php/initSession" com os parâmetros app-token e user_token, que estão disponíveis na conta do usuário com a qual estamos trabalhando.

A requisição abaixo gera o session_token:

curl --location 'https://DOMINIO_GLPI.COM/apirest.php/initSession?app-token={YOUR-APP-TOKEN}&user_token={YOUR-USER-TOKEN}'

Pesquisa de tickets

Com o session_token em mãos, podemos realizar pesquisas sobre os chamados. No entanto, de acordo com a documentação do GLPI, parece que o endpoint não funciona conforme os exemplos fornecidos, pois não é permitido enviar PAYLOAD para esse endpoint, resultando no seguinte erro:

[
    "ERROR_JSON_PAYLOAD_FORBIDDEN",
    "GET Request should not have json payload (http body); view documentation in your browser at /#ERROR_JSON_PAYLOAD_FORBIDDEN"
]

Para contornar essa limitação, vamos passar os parâmetros diretamente na URL da requisição, utilizando o link "https://DOMINIO_GLPI.COM/apirest.php/search/Ticket". É necessário incluir o app-token e o session-token para se conectar, e em seguida, adicionar os filtros desejados para localizar as informações necessárias.

curl --location --globoff 'https://DOMINIO_GLPI.COM/apirest.php/search/Ticket
?app-token={YOUR-APP-TOKEN}
&session_token={YOUR-SESSION-TOKEN}
&criteria[0][field]=1
&criteria[0][searchtype]=contains
&criteria[0][value]=Verifica%C3%A7%C3%A3o%20diaria
&criteria[1][link]=AND
&criteria[1][field]=12
&criteria[1][searchtype]=equals
&criteria[1][value]=2
&glpilist_limit=1000' \
--header 'Content-Type: application/json'

"Criteria" é a chamada de filtro, os fields são determidos filtros a serem colocados para encontrar algo. Por exemplo, "criteria[0][field]=1" é designado para o título onde passamos "criteria[0][searchtype]=contains" informando que contém "criteria[0][value]=Verifica%C3%A7%C3%A3o%20diaria", no caso seria 'Verificação diária' que foi encodado, mas ali seria o local a colocar o título do chamado. É feito outra filtragem abaixo em criteria[1][link]=AND, onde se é feito o AND informando uma nova pesquisa seguindo a anterior.

Para analisar todas as filtragens pode-se fazer a requisição para:

curl --location 'https://DOMINIO_GLPI.COM/apirest.php/listSearchOptions/Ticket?app-token={YOUR-APP-TOKEN}&session_token={YOUR-SESSION-TOKEN}' \
--data ''

Alguns retornos para exemplo:

{
    "common": {
        "name": "Características"
    },
    "1": {
        "name": "Título",
        "table": "glpi_tickets",
        "field": "name",
        "datatype": "itemlink",
        "nosearch": false,
        "nodisplay": false,
        "available_searchtypes": [
            "contains",
            "notcontains"
        ],
        "uid": "Ticket.name"
    },
    "21": {
        "name": "Descrição",
        "table": "glpi_tickets",
        "field": "content",
        "datatype": "text",
        "nosearch": false,
        "nodisplay": false,
        "available_searchtypes": [
            "contains",
            "notcontains"
        ],
        "uid": "Ticket.content"
    },
    "2": {
        "name": "ID",
        "table": "glpi_tickets",
        "field": "id",
        "datatype": "number",
        "nosearch": false,
        "nodisplay": false,
        "available_searchtypes": [
            "contains",
            "notcontains"
        ],
        "uid": "Ticket.id"
    },
...

Criação de tarefa

Com a requisição anterior, realizamos a busca dos chamados, que retornarão em formato JSON. Com essas informações, podemos realizar as tratativas necessárias. No caso específico desta documentação, vamos fechar o chamado. No entanto, antes de fechar o chamado completamente, precisamos criar uma tarefa vinculada ao ticket que deve ser concluída.

Alguns sistemas GLPI requerem o fechamento de chamados de formas específicas. No sistema em que estou trabalhando, é necessário criar uma tarefa e uma solução antes de fechar o chamado.

Abaixo está a requisição que cria a tarefa no ticket (lembre-se de que o ticket que estou passando foi gerado na busca anterior em "Pesquisa de tickets"). Em meu código de automação, foi implementado um loop para processar todos os tickets retornados, mas isso não será abordado nesta documentação.

curl --location 'https://DOMINIO_GLPI.COM/apirest.php/TicketTask?session_token={YOUR-SESSION-TOKEN}' \
--header 'app_token: {YOUR-APP-TOKEN}' \
--header 'Authorization: user_token {YOUR-USER-TOKEN}' \
--header 'Content-Type: application/json' \
--data '{
    "input": {
        "tickets_id": 2408020023, 
        "taskcategories_id": 0, 
        "content": "Verificação diária - Tarefa realizada.",
        "actiontime": 60, 
        "state": 3 
    }
}
'

Devemos observar que, em todos os casos, passamos o app_token no header, e o Authorization, que contém o user_token para autenticação da API.

Pontos importantes a serem considerados são os parâmetros passados no corpo da requisição:

content: O conteúdo que será inserido na tarefa.
actiontime: O tempo gasto na tarefa.
state: O estado que o chamado terá após a criação da tarefa.

Fechamento do chamado

Com a tarefa adicionada ao chamado, é necessário apenas realizar o fechamento do chamado, que segue o mesmo processo utilizado para adicionar a tarefa.

Utiliza-se a seguinte requisição:

curl --location --request PUT 'https://DOMINIO_GLPI.COM/apirest.php/Ticket/2408020023?session_token={YOUR-SESSION-TOKEN}' \
--header 'app_token: {YOUR-APP-TOKEN}' \
--header 'Authorization: user_token {YOUR-USER-TOKEN}' \
--header 'Content-Type: application/json' \
--data '{
  "input": {
    "status": 6, 
    "solution": "<p>Chamado finallizado</p>",  
    "content": "<p>Chamado finallizado</p>",
    "solutiontypes_id": 3, 
    "solutiontemplates_id": 5  
  }
}'
'

O status: 6 indica o fechamento do chamado. Para isso, é necessário passar o solution e o content como os textos do corpo para a solução. Um ponto importante nessa requisição é o solutiontemplates_id, que deve ser criado pelo administrador do sistema GLPI, sendo esse ID um referencial para uma solução padrão.

Signing VirtualBox Kernel Modules

João Pedro — Tue, 29 Aug 2023 16:58:42 +0000

When facing issues with module signing and errors in the 'vboxdrv, vboxnetflt, vboxnetadp, vboxpci' modules, these were the steps I followed to enable VirtualBox on my Fedora 38 machine without disabling UEFI Secure Boot.

And this method creates a layer of protection between VirtualBox and the kernel.

Installing the package `mokutil`:

sudo dnf update
sudo dnf install mokutil

mokutil will be used to sign your own modules for use with UEFI Secure Boot and to add certificates to the kernel's trusted certificate keyring.

Creating folder for module signing and RSA key:

sudo su
mkdir /root/signed-modules
cd /root/signed-modules
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=VirtualBox/"
chmod 700 MOK.priv

Creating the password for MOK (this password will be needed for the reboot):

sudo mokutil --import MOK.der

Restart the system and follow the MOK processes:

Select 'Enroll MOK
Select Continue
Select 'Yes' to add the keys
Enter the password created with mokutil"
Proceed to reboot

Creating the script to perform the signatures:

cd /root/signed-modules
vi sign-virtual-box

Add the following inside 'sign-virtual-box':

#!/bin/bash

for modfile in $(dirname $(modinfo -n vboxdrv))/*.ko; do
  echo "Signing $modfile"
  /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 \
                                /root/signed-modules/MOK.priv \
                                /root/signed-modules/MOK.der "$modfile"
done

Check for any errors in the script using the command:

find /usr/src -name sign-file

Add permissions to the script and execute it:

chmod 700 sign-virtual-box
./sign-virtual-box

Run VirtualBox:

modprobe vboxdrv

Final conclusions:

If the process doesn't work, an option is to disable Secure Boot, but for various reasons, it's not a recommended practice.

Another option is to check the quality of the VMs you're trying to run. In some cases, they might be corrupted, or even the ISO you're trying to install from.

Assinando módulos VirtualBox Kernel

João Pedro — Tue, 29 Aug 2023 14:29:43 +0000

Ao enfrentar os problemas de assinatura e erros nos módulos "vboxdrv, vboxnetflt, vboxnetadp, vboxpci". Essas foram as etapas que segui para ativar o VirtualBox em minha máquina Fedora 38 sem desativar o UEFI Secure Boot.

Instalar o pacote `mokutil`:

sudo dnf update
sudo dnf install mokutil

mokutil será usado para assinar seus próprios módulos para usar com a Inicialização Segura UEFI, e adicionar certificados ao chaveiro de certificados confiáveis do kernel.

Criar pasta para assinatura de módulos e chave RSA:

Criar a senha para o MOK (será necessário esta senha para a reinicialização):

sudo mokutil --import MOK.der

Reinicie o equipamento e siga os processos do MOK:

Seleciona Enroll MOK
Selecione Continue
Selecione Yes para adicionar as chaves
Coloque a senha
Continue para o Reboot

Criar o script para fazer as assinaturas:

cd /root/signed-modules
vi sign-virtual-box

Adicione dentro de sign-virtual-box:

#!/bin/bash

for modfile in $(dirname $(modinfo -n vboxdrv))/*.ko; do
  echo "Signing $modfile"
  /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 \
                                /root/signed-modules/MOK.priv \
                                /root/signed-modules/MOK.der "$modfile"
done

Verifique se há algum erro no script com o comando:

find /usr/src -name sign-file

Adicione as permissões ao script e o execute:

chmod 700 sign-virtual-box
./sign-virtual-box

Execute o VirtualBox:

modprobe vboxdrv

Conclusões finais:

Caso o processo não funcione, uma opção é desligar o Secure Boot, porém por diversos motivos não é uma prática recomendada.

Outra opção é verificar a qualidade das VM's que está tentando rodar. Em alguns casos ela pode estar corrompida ou até mesmo a ISO na qual tenta instalar.

The Duality of Bitcoin: Privacy versus Transparency

João Pedro — Fri, 14 Jul 2023 12:34:45 +0000

Bitcoin is one of the most well-known and widely used cryptocurrencies in the world. The decentralized and pseudonymous nature of Bitcoin makes transactions difficult to trace, but there are still ways in which they can be tracked. There are several techniques that investigators can use to trace Bitcoin transactions and identify criminals who use the cryptocurrency for illegal activities.

Public addresses

Every transaction in Bitcoin is recorded on a public address in the blockchain, making it visible to anyone. This allows transactions to be traced and investigated if associated with a person or company. Investigators can track the origin and destination of the funds by monitoring the public addresses used in illegal transactions.

Transactions are permanently recorded on a ledger called the blockchain, which is public and can be accessed by anyone through a blockchain explorer, such as Blockchain.info. This means that all transactions ever made in Bitcoin can be viewed.

Blockchain analysis

Blockchain analysis is a technique that allows tracking Bitcoin transactions and identifying the Bitcoin addresses involved in a transaction. While the identity of the Bitcoin address owner is not known, blockchain analysis can be used to track the activity of a specific address and, in some cases, link that address to a person or entity.

One way to track a Bitcoin address is by analyzing the blockchain to identify all the addresses that have sent or received Bitcoin from that specific address. If a person uses a Bitcoin address to transact on an exchange or trading platform, for example, it is possible to link that address to a user account on the exchange.

Furthermore, blockchain analysis can also be utilized to track transaction patterns that may indicate illegal or suspicious activities, such as money laundering, drug trafficking, or terrorist financing.

User identification

While Bitcoin users are generally pseudonymous, it is still possible to identify individuals through transactions involving other fiat currencies, personal information, or connections to IP addresses. For example, if a person uses the same IP address to make a Bitcoin transaction and to connect to a social media account, it is possible to identify that person based on information from the social media account.

Cryptocurrency exchanges

Cryptocurrency exchanges are required to comply with anti-money laundering regulations, which may include collecting personal information from users and verifying their identity before allowing transactions. Investigators can use the information collected by cryptocurrency exchanges to trace transactions and identify users involved in illegal activities.

One real example of how Bitcoin was traced and a criminal was arrested is the case of Silk Road. Silk Road was an online marketplace on the dark web that facilitated the sale of illegal products, including drugs, weapons, and counterfeit documents, in exchange for Bitcoin. The creator of Silk Road, Ross Ulbricht, also known as "Dread Pirate Roberts," was arrested in 2013 and sentenced to life imprisonment in 2015 on various charges, including conspiracy to commit money laundering, drug trafficking, and conspiracy to hack computers.

Ulbricht's arrest was made possible through a coordinated investigation among multiple government agencies, including the FBI, DEA, and IRS. The agencies traced Bitcoin transactions on Silk Road and were able to identify some addresses belonging to Dread Pirate Roberts. They then conducted blockchain analysis to track the flow of Bitcoin between these addresses and other addresses associated with illegal activities on Silk Road. This allowed them to identify several suspicious transactions and eventually trace back to the Bitcoin address Ulbricht used to pay for the Silk Road server.

Through the analysis of the IP address associated with that transaction and other information collected from online forums, investigators were able to identify Ross Ulbricht as the owner of the address. He was arrested in 2013 and subsequently convicted for his illegal activities on Silk Road.

The Silk Road case illustrates how Bitcoin can be traced and how government agencies can work together to identify and apprehend criminals who use the cryptocurrency for illegal activities. While the pseudonymous and decentralized nature of Bitcoin may make transactions more difficult to trace, there are still various techniques and tools available to investigators and government agencies who aim to identify and apprehend criminals using cryptocurrency for illicit purposes.

Conclusion

Bitcoin is a fascinating technology that offers many benefits and opportunities for people around the world. However, like any technology, there are also risks and challenges associated with its use. The ability of Bitcoin to be traced and monitored by government agencies can be seen both as an advantage and a disadvantage. On one hand, it can help prevent illegal and criminal activities, but on the other hand, it can be viewed as an invasion of privacy and a threat to financial freedom.

It is important for Bitcoin users to understand the implications and risks involved in its use and take steps to protect their privacy and financial security.

Join a Linux machine to the Active Directory

João Pedro — Fri, 14 Jul 2023 12:14:25 +0000

Step-by-step guide to configure a Linux machine in an Active Directory domain:

Preparations and package installation

Start by updating the packages already present on the machine, and then proceed to install only what we actually need.

Update the dependencies using the command:

Debian

sudo apt update

RHEL

sudo yum update

And proceed with the installation of the packages:

Debian

sudo apt install -y realmd libnss-sss sssd sssd-tools adcli samba-common-bin oddjob oddjob- mkhomedir packagekit

RHEL

sudo dnf install realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools -y

Configuring the realm

In short, Realm helps us discover and manage the domains we have on the machine.

To start, we first need to discover the domain we are looking for.

Use the following command:

realm discover DOMAIN-NAME

We will have a response similar to this.

Now that we have discovered the domain, we will need to log in to it with a user. Use the following command:

sudo realm join -U USUARIO DOMINIO

If no errors have occurred so far, we can verify if we are indeed connected by using the following command to check the user's permissions and groups.

id USUARIO@DOMINIO

Another method to verify if everything is going correctly is the following:

realm list

This way, we can verify if we are already connected to the desired domain.

Pam-configs (ubuntu)

The pam-configs configuration was only necessary on Ubuntu to ensure that the user's folder is created upon logging into the system.

You just need to execute the command:

sudo pam-auth-update --enable mkhomedir

Configuring SSSD

We need to access the file /etc/sssd/sssd.conf to make the modifications. In this file, we will change the use_fully_qualified_names option from False to True. With this option enabled, users will be in the format user@domain instead of just user.

In our case, we will change it to True since we have only one AD. However, please note that this change should only be made if you are certain that no other domain will be added to the AD forest.

In fallback_homedir = /home/%u@%d, we will modify it to fallback_homedir = /home/%u. By removing the "@%d" part, the user's folder will be created with only the username.

In the access_provider = ad option, change it to access_provider = simple.

Now let's add an option that is not present in our file, which is simple_allow_groups. In this option, we will add the groups we have in AD and want to grant access to the Linux machine.

In our case, we have two groups: linuxuser and linuxadmin. To add them, we should include simple_allow_groups = linuxuser, linuxadmin in the file.

As a result, the file will look like this:

Note: in the places where it says 'Domain.local', you should use the domain you are integrating with the system. And in 'simple_allow_users = groups, linuxuser, linuxadmin', it is an option that will be added automatically in the next item.

Thus, concluding the SSSD configuration process, we will allow access for users who are in the groups we added in simple_allow_groups. Use the following commands:

realm permit [group]

Example:

realm permit linuxuser

realm permit linuxadmin

SUDOERS

With the processes performed in the above steps, we will be able to access the machine using the AD user. However, the user won't have root access to the system. To solve this, we need to add the groups to the /etc/sudoers file. The result will be as follows:

We added the %linuxuser group to allow all users in the linuxuser group to access the machine and obtain root access.

Conclusion

By following these steps, Active Directory users will be able to authenticate on the Linux machine and have the appropriate privileges. Always ensure to follow best security practices when performing these configurations.

Atrelar máquina Linux ao Active Directory

João Pedro — Sun, 18 Jun 2023 16:22:40 +0000

Passo a passo de como configurar uma máquina Linux em um domínio do Active Directory.

Preparações e instalação de pacotes

Comece atualizando os pacotes que já possuímos na máquina e, logo após, instale o que realmente precisamos.

Atualize as dependências com o comando:

Debian

sudo apt update

RHEL

sudo yum update

E prossiga com a instalação dos pacotes:

Debian

sudo apt install -y realmd libnss-sss sssd sssd-tools adcli samba-common-bin oddjob oddjob- mkhomedir packagekit

RHEL

sudo dnf install realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools -y

Configurando o realm

De forma resumida, o Realm nos ajuda a descobrir e controlar os domínios que possuímos na máquina.

Para começar, precisamos primeiro descobrir o domínio que estamos procurando.

Utilize o seguinte comando:

realm discover NOME-DO-DOMINIO

Teremos uma resposta semelhante a esta:

Agora que descobrimos o domínio, precisaremos fazer login nele com um usuário. Utilize o seguinte comando:

sudo realm join -U USUARIO DOMINIO

Se até o momento não ocorreram erros, podemos verificar se realmente estamos conectados, utilizando o comando abaixo para verificar as permissões e grupos do usuário.

id USUARIO@DOMINIO

Outro método para verificar se está tudo ocorrendo corretamente é o seguinte:

realm list

Dessa forma, verificamos se já estamos conectados ao domínio desejado.

Pam-configs (ubuntu)

A configuração no pam-configs foi necessária apenas no Ubuntu para que a pasta do usuário seja criada no momento em que ele entra no sistema.

Apenas é necessário executar o comando:

sudo pam-auth-update --enable mkhomedir

Configurando SSSD

Devemos acessar o arquivo /etc/sssd/sssd.conf para realizar as modificações. Nele, vamos alterar a opção use_fully_qualified_names de False para True. Com essa opção ativada, os usuários estarão no formato user@domain, em vez de apenas user.

No nosso caso, vamos alterar para True, pois possuímos apenas um AD. No entanto, observe que essa alteração deve ser feita somente se você tiver certeza de que nenhum outro domínio será adicionado à floresta do AD.

Em fallback_homedir = /home/%u@%d, vamos modificar para fallback_homedir = /home/%u. Removendo o "@%d", a pasta do usuário será criada apenas com o nome do usuário.

Na opção access_provider = ad, muda-se para access_provider = simple.

Agora vamos adicionar uma opção que não está presente em nosso arquivo, que é o simple_allow_groups. Nessa opção, vamos adicionar os grupos que temos no AD e desejamos que tenham acesso à máquina Linux.

No nosso caso, temos dois grupos: linuxuser e linuxadmin. Para adicioná-los, devemos incluir simple_allow_groups = linuxuser, linuxadmin no arquivo.

Como resultado, o arquivo ficará da seguinte maneira:

Observação: nos lugares onde está escrito "Domain.local", deve ser o domínio que você está integrando ao sistema. E em "simple_allow_users = groups, linuxuser, linuxadmin" é uma opção adicionada automaticamente no próximo item.

Assim, finalizando o processo de configuração do SSSD, vamos permitir o acesso dos usuários que estão nos grupos que adicionamos em simple_allow_groups. Utilize os seguintes comandos:

realm permit [group]

Exemplo:

realm permit linuxuser

realm permit linuxadmin

SUDOERS

Com os processos realizados nos itens acima, já conseguiremos acessar a máquina utilizando o usuário do AD. No entanto, ele não terá acesso root no sistema. Para resolver isso, devemos adicionar os grupos dentro do arquivo /etc/sudoers. O resultado será o seguinte:

Adicionamos o grupo %linuxuser para permitir que todos os usuários do grupo linuxuser possam acessar a máquina e obter acesso root.

Conclusão

Ao seguir essas etapas, os usuários do Active Directory poderão autenticar-se na máquina Linux e ter os privilégios adequados. Certifique-se sempre de seguir as melhores práticas de segurança ao realizar essas configurações.

A Dualidade do Bitcoin: Privacidade versus Transparência

João Pedro — Wed, 12 Apr 2023 18:36:22 +0000

Bitcoin é uma das criptomoedas mais conhecidas e amplamente utilizadas no mundo. A natureza descentralizada e pseudônima do Bitcoin torna as transações difíceis de rastrear, mas ainda assim existem maneiras pelas quais elas podem ser rastreadas. Existem várias técnicas que os investigadores podem usar para rastrear as transações de Bitcoin e identificar criminosos que usam a criptomoeda para atividades ilegais.

Endereços públicos

Cada transação em Bitcoin é gravada em um endereço público na blockchain, tornando-a visível para qualquer um. Isso permite que as transações sejam rastreadas e investigadas, se associadas a uma pessoa ou empresa. Investigadores podem rastrear a origem e o destino do dinheiro monitorando os endereços públicos usados em transações ilegais

As transações são permanentemente registradas em um livro-razão chamado "Blockchain", que é público e pode ser acessado por qualquer pessoa por meio de um explorador de blockchain, como o Blockchain.info. Isso significa que todas as transações já realizadas em Bitcoin podem ser visualizadas.

Análise de cadeia de blocos

A análise de cadeia de blocos é uma técnica que permite rastrear as transações do Bitcoin e identificar os endereços de Bitcoin envolvidos em uma transação. Embora a identidade do proprietário do endereço de Bitcoin não seja conhecida, a análise da cadeia de blocos pode ser usada para rastrear a atividade de um endereço específico e, em alguns casos, vincular esse endereço a uma pessoa ou entidade.

Uma maneira de rastrear um endereço de Bitcoin é analisando a cadeia de blocos para identificar todos os endereços que enviaram ou receberam Bitcoin desse endereço específico. Se uma pessoa usar um endereço de Bitcoin para realizar transações em uma exchange ou plataforma de negociação, por exemplo, é possível vincular esse endereço a uma conta de usuário na exchange.

Além disso, a análise da cadeia de blocos também pode ser usada para rastrear padrões de transação que possam ser indicativos de atividades ilegais ou suspeitas, como lavagem de dinheiro, tráfico de drogas ou financiamento terrorista.

Identificação de usuários

Embora os usuários de Bitcoin sejam geralmente pseudônimos, ainda é possível identificar indivíduos por meio de transações que envolvem outras moedas fiduciárias, informações pessoais ou conexões com endereços de IP. Por exemplo, se uma pessoa usa o mesmo endereço de IP para fazer uma transação de Bitcoin e para se conectar a uma conta de mídia social, é possível identificar essa pessoa com base em informações da conta de mídia social.

Intercâmbios de criptomoedas

Os intercâmbios de criptomoedas são obrigados a seguir as regulamentações contra lavagem de dinheiro, o que pode incluir a coleta de informações pessoais dos usuários e a verificação de identidade antes de permitir transações. Os investigadores podem usar as informações coletadas pelos intercâmbios de criptomoedas para rastrear transações e identificar os usuários envolvidos em atividades ilegais.

Um exemplo real de como o Bitcoin foi rastreado e um criminoso foi preso é o caso da Silk Road. A Silk Road foi um mercado online na dark web que facilitou a venda de produtos ilegais, incluindo drogas, armas e documentos falsificados, em troca de Bitcoin. O criador da Silk Road, Ross Ulbricht, também conhecido como "Dread Pirate Roberts", foi preso em 2013 e condenado a prisão perpétua em 2015 por uma série de acusações, incluindo conspiração para lavagem de dinheiro, tráfico de drogas e conspiração para hackear computadores.

A prisão de Ulbricht foi possível graças a uma investigação coordenada entre várias agências governamentais, incluindo o FBI, a DEA e o IRS. As agências rastrearam as transações de Bitcoin na Silk Road e conseguiram identificar alguns endereços que pertenciam ao Dread Pirate Roberts. Eles então realizaram uma análise da cadeia de blocos para rastrear o fluxo de Bitcoin entre esses endereços e outros endereços associados a atividades ilegais na Silk Road. Isso permitiu que eles identificassem várias transações suspeitas e, eventualmente, chegaram ao endereço de Bitcoin que Ulbricht usou para pagar o servidor da Silk Road.

Através da análise do endereço IP associado a essa transação e outras informações coletadas em fóruns online, os investigadores conseguiram identificar Ross Ulbricht como o proprietário do endereço. Ele foi preso em 2013 e posteriormente condenado por suas atividades ilegais na Silk Road.

O caso da Silk Road ilustra como o Bitcoin pode ser rastreado e como as agências governamentais podem trabalhar juntas para identificar e prender criminosos que usam a criptomoeda para atividades ilegais. Embora a natureza pseudônima e descentralizada do Bitcoin possa tornar as transações mais difíceis de rastrear, ainda existem várias técnicas e ferramentas disponíveis para investigadores e agências governamentais que desejam identificar e prender criminosos que usam a criptomoeda para atividades ilegais.

Conclusão

O Bitcoin é uma tecnologia fascinante que oferece muitos benefícios e oportunidades para as pessoas em todo o mundo. No entanto, como com qualquer tecnologia, há também riscos e desafios associados ao seu uso. A capacidade do Bitcoin de ser rastreado e monitorado pelas agências governamentais pode ser vista tanto como uma vantagem quanto como uma desvantagem. Por um lado, isso pode ajudar a prevenir atividades ilegais e criminosas, mas, por outro lado, pode ser visto como uma invasão de privacidade e uma ameaça à liberdade financeira.

É importante que os usuários de Bitcoin entendam as implicações e riscos envolvidos em seu uso e tomem medidas para proteger sua privacidade e segurança financeira.

DEV Community: João Pedro

Guia Warcraft III de Etiqueta para Pull Requests

Basic Server Hardening for Ubuntu/Debian: SSH Access and Firewall

Create a Secure Administrator User

Generate Public Key and Manually Configure SSH Login

On the Client

On the Server

Set the correct permissions

Disable root login and password authentication in SSH

Enable Firewall (UFW)

Fix Permissions of Sensitive Files

Install and Configure Fail2Ban (Protection Against Brute Force Attacks)

Installation

Basic Configuration

Recommended Adjustments (in jail.local)

Restart Fail2Ban

Check the logs

Conclusion

Hardening Básico de Servidor Ubuntu/Debian: Acesso SSH e Firewall

Criar usuário administrador seguro

Gerar chave pública e configurar login SSH manualmente

No cliente

No servidor

Ajustar permissões

Desativar login root e autenticação por senha no SSH

Ativar firewall (UFW)

Corrigir permissões de arquivos sensíveis

Instalar e Configurar Fail2Ban (Proteção contra Brute Force)

Instalação

Configuração Básica

Ajustes Recomendados (em jail.local)

Reinicie o Fail2Ban

Verificar os logs

Conclusão

GLPI - Closing Ticket with API

Starting a Session

Ticket Search

Creating a Task

Closing the Ticket

GLPI - Fechar ticket com API

Iniciando sessão

Pesquisa de tickets

Criação de tarefa

Fechamento do chamado

Signing VirtualBox Kernel Modules

Installing the package mokutil:

Creating folder for module signing and RSA key:

Creating the password for MOK (this password will be needed for the reboot):

Restart the system and follow the MOK processes:

Creating the script to perform the signatures:

Add permissions to the script and execute it:

Run VirtualBox:

Final conclusions:

Assinando módulos VirtualBox Kernel

Instalar o pacote mokutil:

Criar pasta para assinatura de módulos e chave RSA:

Criar a senha para o MOK (será necessário esta senha para a reinicialização):

Reinicie o equipamento e siga os processos do MOK:

Criar o script para fazer as assinaturas:

Adicione as permissões ao script e o execute:

Execute o VirtualBox:

Conclusões finais:

The Duality of Bitcoin: Privacy versus Transparency

Public addresses

Blockchain analysis

User identification

Cryptocurrency exchanges

Conclusion

Join a Linux machine to the Active Directory

Preparations and package installation

Configuring the realm

Pam-configs (ubuntu)

Configuring SSSD

SUDOERS

Conclusion

Atrelar máquina Linux ao Active Directory

Preparações e instalação de pacotes

Configurando o realm

Pam-configs (ubuntu)

Configurando SSSD

Installing the package `mokutil`:

Instalar o pacote `mokutil`: