Blog do CAOTI

Local para compartilhamento de ideias e projetos

VDI

Projetos e ideias relacionadas a Infraestrutura de Desktop Virtual

VDI

VDI Remoto com Raspberry Pi e VPN Forcepoint

Versão do Hardware tratado no documento: Raspberry Pi 3B+
Versão do Software tratado no documento: Raspbian GNU/Linux 10 (buster)

1.0) Introdução

Diante da perspectiva crescente de trabalho remoto e de acesso a poder de computação, dados e serviços independente do local, iniciamos experimentos para proporcionar estes recursos através de técnicas de VDI ( Infraestrutura de Desktop Virtual) utilizando o Raspberry Pi e Firewall Forcepoint de forma a proporcionar um acesso barato e livre aos recursos internos da instituição.

Através da solução abaixo, podemos criar um acesso a uma estação Windows remota e segura utilizando apenas um Raspberry Pi e alguns softwares Livres pré configurados.

O acesso remoto a uma estação Windows exigirá a aquisição de licenciamento para tal com a Microsoft.

Os experimentos demonstrados abaixo fazem referencia a conexão de VDI com estação da Reitoria do IFSP e deve ser adaptada para outros ambientes.

2.0) Implantação em RP3B+ (Raspberry Pi 3B+) com interface gráfica pré instalada

Os procedimentos abaixo permitem a implantação do serviço em um RP3B+ com sistema operacional configurado com interface gráfica em sua instalação.

Esta solução possui como pré-requisito a implantação da VPN C2S com a reitoria, os procedimentos para tal podem ser encontrados AQUI.

2.1) Instalação dos pacotes necessários

Instale o software necessário para realizar a conexão remota com Windows via protocolo RDP com os comandos abaixo:

sudo apt-get update && sudo apt-get install rdesktop
2.2) Configuração e inicialização do serviço

Agora vamos criar um serviço do SystemD que ficará encarregado de verificar se a conexão VPN já está pronto para utilização e iniciará o serviço de conexão Remote Desktop:

Crie e edite o arquivo "/lib/systemd/system/remote.service":

sudo nano /lib/systemd/system/remote.service

Adicione o conteúdo a seguir no arquivo:

[Unit]
Description=Remote Desktop
Requires=network-online.target

[Service]
Type=idle
Environment=DISPLAY=:0
Environment=XAUTHORITY=/home/pi/.Xauthority
ExecStart=/usr/bin/rdesktop -k pt-br -n <HOSTNAME-DO-RASPBERRY-PI> -g 100% -z -r sound:local -x 0x80 -u <USUARIO-REMOTO> -P -f <IP-DO-SERVIDOR-DE-DESTINO>
ExecStartPre=/bin/sh -c 'until ping -c1 <IP-DO-SERVIDOR-DE-DESTINO>; do sleep 1; done;'
Restart=always
RestartSec=3

[Install]
WantedBy=graphical.target

Não se esqueça de alterar os parâmetros para seu ambiente.

O serviço acima fará todas as checagens necessárias e também irá reiniciar o terminal remoto caso ele seja fechado pelo cliente.

Agora temos que instalar o serviço e inicializa-lo:

Reload das configurações do serviço:

sudo systemctl daemon-reload

Instalação do serviço:

sudo systemctl enable remote.service

Iniciar o serviço:

systemctl start remote.service

DICA: Você pode verificar o status do serviço trocando o "start" do comando anterior por "status"

Está feito! ao reiniciar o equipamento, se estiver tudo certo, o sistema irá inicializar e logo em seguida realizar a conexão RDP com a estação remota!

3.0) Implantação em RP3B+ (Raspberry Pi 3B+) sem interface gráfica pré instalada

Fonte: SITE

Até o presente momento esta solução não foi validada completamente pela nossa equipe.

Os procedimentos abaixo permitem a implantação do serviço em um RP3B+ com sistema operacional configurado sem interface gráfica em sua instalação.

3.1) Instalação dos pacotes necessários

Instale o software necessário para realizar a conexão remota com Windows via protocolo RDP com os comandos abaixo:

sudo apt-get update && sudo apt-get install xinit xserver-xorg xserver-xorg-video-fbdev rdesktop
3.2) Configuração e inicialização do serviço

Crie o arquivo ".xinitrc" que irá servir para executarmos o Remote Desktop automaticamente, uma vez que o ambiente gráfico inicie:

nano /home/pi/.xinitrc

Adicione a seguinte linha neste arquivo e salve (Substitua o IP com o o endereço IP do seu Desktop, lembre de configura-lo com um IP Fixo para que você não tenha que ficar mudando isso no futuro):

exec /usr/bin/rdesktop -k pt-br -n <HOSTNAME-DO-RASPBERRY-PI> -g <RESOLUCAO-DESEJADA> -z -r sound:local -x 1 -u <USUARIO-REMOTO> -f <IP-DO-SERVIDOR-DE-DESTINO>

Agora vamos criar um serviço do SystemD que ficará encarregado de verificar se a conexão VPN já está pronto para utilização e iniciará o serviço de conexão Remote Desktop:

Crie e edite o arquivo "/lib/systemd/system/remote.service":

sudo nano /lib/systemd/system/remote.service

Adicione o conteúdo a seguir no arquivo:

[Unit]
Description=Remote Desktop
Requires=network-online.target

[Service]
Type=idle
Environment=DISPLAY=:0
Environment=XAUTHORITY=/home/pi/.Xauthority
ExecStart=xinit /home/pi/.xinitrc
ExecStartPre=/bin/sh -c 'until ping -c1 <IP-DO-SERVIDOR-DE-DESTINO>; do sleep 1; done;'
Restart=always
RestartSec=3
KillMode=process
TimeoutSec=infinity

[Install]
WantedBy=graphical.target​

Não se esqueça de alterar os parâmetros para seu ambiente.

O serviço acima fará todas as checagens necessárias e também irá reiniciar o terminal remoto caso ele seja fechado pelo cliente.

Agora temos que instalar o serviço e inicializa-lo:

Reload das configurações do serviço:

sudo systemctl daemon-reload

Instalação do serviço:

sudo systemctl enable remote.service

Iniciar o serviço:

systemctl start remote.service

DICA: Você pode verificar o status do serviço trocando o "start" do comando anterior por "status"

Está feito! ao reiniciar o equipamento, se estiver tudo certo, o sistema irá inicializar e logo em seguida realizar a conexão RDP com a estação remota!

4.0) Aumento do tempo de espera por login na estação remota

Fonte: SITE

Para que a tela de login fique esperando as credenciais por mais tempo (normalmente 1 minuto), você pode criar uma chave no registro do Windows.

Crie uma chave DWORD chamada  LogonTimeout no container:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Coloque o valor da chave em segundos (3600 segundos = 1 hora):

image-1601583746008.png

Dessa forma quando o Raspberry Pi iniciar e a sessão RDP começar ele aguardará por 1 hora até que você faça o login.

Se você não logar em tempo, o rdesktop vai fechar, reinicie o Raspberry Pi ou o serviço remote.service:

sudo systemctl restart remote.service

5.0) Extras

5.1) Escala de tela

Se o seu Raspberry Pi não estiver preenchendo a tela inteira quando ligado a um monitor, exibindo barras pretas nas laterais, execute a seguinte alteração:

Altere o arquivo de configuração padrão do RP:

sudo nano /boot/config.txt

Em seguida descomente a linha abaixo e salve as alterações:

...
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=1
...

Reinicie o equipamento e a tela deve agora estar com a cobertura correta.

5.2) Login sem senha no RDP do Windows Server

Para que o login sem senha funcione no Windows server, de forma a apresentar a tela de login somente após a conexão RDP, execute as seguinte alteração no sistema:

 Você deve desabilitar o "Network Level Authentication (NLA)" logo após ativar a permissão para acesso remoto via RDP:

image-1602092599567.png

5.3) Raspberry Pi reiniciando sem motivo

O superaquecimento pode ser uma das causas de reboot aleatório do equipamento, assim como uma fonte de energia insuficiente e/ou equipamentos que demandam muita energia ligados ao USB ou GPIO do equipamento, tais como HDs externos, etc.

Para verificar que houve throttling (redução de frequência do processador devido a temperatura), execute:

sudo vcgencmd get_throttled

Se o resultado for 0x0 está tudo bem neste quesito, caso não seja é melhor verificar a refrigeração do equipamento.

 

 

 

Linux Desktop

Capitulo com dicas e tutoriais gerais relacionados ao uso de Linux no Desktop

Linux Desktop

Tutorial: Montar e Desmontar Volumes BitLocker no Linux

Este tutorial ensina como detectar, montar e desmontar unidades BitLocker no Linux Mint usando dislocker e um script automatizado.

Requisitos

sudo apt update
sudo apt install dislocker -y

1. O Script bitlocker-manager.sh

O script permite montar e desmontar volumes BitLocker automaticamente.

Conteúdo do Script

#!/bin/bash
set -e

WORK_BASE="/mnt"
MOUNT_BASE="/media/$USER"

usage() {
    echo "Uso: $0 [mount|umount]"
    echo "  mount   - Desbloqueia e monta o volume BitLocker"
    echo "  umount  - Desmonta volumes BitLocker montados"
    exit 1
}

if [ $# -ne 1 ]; then
    usage
fi

MODE="$1"

if [ "$MODE" == "mount" ]; then
    device=$(lsblk -o NAME,FSTYPE -r | grep -i "BitLocker" | awk '{print $1}' | head -n 1)
    if [ -z "$device" ]; then
        echo "[!] Nenhuma partição BitLocker detectada."
        exit 1
    fi
    device="/dev/$device"
    echo "[*] Volume BitLocker detectado em: $device"

    read -sp "Digite a senha ou chave de recuperação do BitLocker: " input
    echo

    # Detecta se é chave de recuperação (48 dígitos)
    clean_input=$(echo "$input" | tr -d '-') # Remove hífens, se houver
    if [[ "$clean_input" =~ ^[0-9]{48}$ ]]; then
        auth_param="-p$clean_input"
        echo "[*] Detectado chave de recuperação."
    else
        auth_param="-u$input"
        echo "[*] Detectada senha do BitLocker."
    fi

    mapper_dir="$WORK_BASE/bitlk-$(basename $device)"
    mount_dir="$MOUNT_BASE/bitlocker-$(basename $device)"

    sudo mkdir -p "$mapper_dir" "$mount_dir"

    echo "[*] Desbloqueando com dislocker..."
    sudo dislocker -V "$device" $auth_param -- "$mapper_dir"

    echo "[*] Montando NTFS..."
    sudo mount -o loop "$mapper_dir/dislocker-file" "$mount_dir"

    echo "[✓] Volume BitLocker montado em: $mount_dir"

elif [ "$MODE" == "umount" ]; then
    for dir in "$MOUNT_BASE"/bitlocker-*; do
        if mountpoint -q "$dir"; then
            echo "[*] Desmontando NTFS em $dir ..."
            sudo umount "$dir" || echo "[!] Falha ao desmontar $dir"
        fi

        mapper_dir="$WORK_BASE/$(basename $dir | sed 's/bitlocker-/bitlk-/')"
        if mountpoint -q "$mapper_dir"; then
            echo "[*] Desmontando mapper em $mapper_dir ..."
            sudo umount "$mapper_dir" || echo "[!] Falha ao desmontar $mapper_dir"
        fi

        # limpa diretórios
        sudo rmdir "$dir" 2>/dev/null || true
        sudo rmdir "$mapper_dir" 2>/dev/null || true

        echo "[✓] Desmontagem concluída para $dir"
    done
else
    usage
fi

2. Como usar o Script

2.1 Preparação

Salve o script em seu computador, por exemplo:

nano ~/bitlocker-manager.sh

Cole o conteúdo acima e salve.

Torne o script executável:

chmod +x ~/bitlocker-manager.sh

2.2 Montar Volume BitLocker

Insira a unidade BitLocker USB.

Execute o script no modo mount:

~/bitlocker-manager.sh mount

Digite a senha ou chave de recuperação quando solicitado.

Se tudo der certo, o volume será montado em:

/media/<seu_usuario>/bitlocker-<nome_dispositivo>

Você pode acessar os arquivos normalmente pelo gerenciador de arquivos.

2.3 Desmontar Volume BitLocker

Para desmontar, rode o script no modo umount:

~/bitlocker-manager.sh umount

O script vai:

3. Observações Importantes

echo "options usb-storage quirks=0bc2:2322:u" | sudo tee /etc/modprobe.d/seagate-uas-blacklist.conf
sudo update-initramfs -u
sudo reboot

4. Benefícios do Script

Forcepoint

Capitulo com dicas e tutoriais gerais relacionados aos produtos Forcepoint

Forcepoint

Desativando o Módulo da VPN Forcepoint na Interface do WSL2 no Windows 11

Introdução

Alguns usuários enfrentam problemas ao utilizar o Windows Subsystem for Linux 2 (WSL2) quando a VPN Forcepoint está ativa. Isso ocorre porque o módulo da VPN é automaticamente instalado em todas as interfaces de rede, incluindo a interface virtual do WSL2, o que pode bloquear o tráfego de rede dentro do ambiente Linux.

Como a interface do WSL2 não aparece na interface gráfica do Windows, a remoção do módulo da VPN precisa ser feita via PowerShell.

Este tutorial ensina como desativar o módulo da VPN apenas na interface do WSL2, sem afetar outras conexões de rede do sistema.

Passo 1: Abrir o PowerShell Como Administrador

  1. Pressione Win + X e clique em Terminal do Windows (Admin) ou PowerShell (Admin).
  2. Confirme a execução como administrador, caso solicitado.
Passo 2: Identificar o Nome da Interface de Rede do WSL2

O WSL2 cria uma interface virtual chamada vEthernet (WSL), mas seu nome exato pode variar. Para listar todas as interfaces, incluindo as ocultas, execute o seguinte comando no PowerShell:

Get-NetAdapter -IncludeHidden | Format-Table -AutoSize

Isso exibirá todas as interfaces de rede disponíveis. Procure por um nome semelhante a:

vEthernet (WSL (Hyper-V firewall))

Anote esse nome, pois ele será necessário nos próximos passos.

Passo 3: Listar os Módulos Ativos na Interface do WSL2

Agora que sabemos o nome da interface do WSL2, podemos listar os módulos de rede ativos nela. Execute:

Get-NetAdapterBinding -Name "vEthernet (WSL (Hyper-V firewall))" | Format-Table -AutoSize

Isso retornará uma lista de componentes ativos na interface. Algo semelhante a:

Name                                      DisplayName                                       ComponentID       Enabled
----                                      -----------                                       -----------       -------
vEthernet (WSL (Hyper-V firewall))        Cliente para redes Microsoft                     ms_msclient       True
vEthernet (WSL (Hyper-V firewall))        Protocolo TCP/IPv4                               ms_tcpip          True
vEthernet (WSL (Hyper-V firewall))        Forcepoint VPN Client Driver                         sgra_vpn          True

O ComponentID do módulo da VPN Forcepoint geralmente é "sgra_vpn", mas pode variar conforme a versão do software.

Passo 4: Desativar o Módulo da VPN Somente no WSL2

Agora que identificamos o módulo da VPN, podemos desativá-lo apenas na interface do WSL2. Para isso, execute:

Disable-NetAdapterBinding -Name "vEthernet (WSL (Hyper-V firewall))" -ComponentID "sgra_vpn"

Isso desativará o módulo somente na interface do WSL2, sem afetar as demais conexões de rede.

Passo 5: Confirmar Que o Módulo Foi Desativado

Para garantir que a configuração foi aplicada corretamente, execute novamente:

Get-NetAdapterBinding -Name "vEthernet (WSL (Hyper-V firewall))" | Format-Table -AutoSize

Verifique se o campo Enabled para sgra_vpn agora está False:

Name                                      DisplayName                                       ComponentID       Enabled
----                                      -----------                                       -----------       -------
vEthernet (WSL (Hyper-V firewall))        Cliente para redes Microsoft                     ms_msclient       True
vEthernet (WSL (Hyper-V firewall))        Protocolo TCP/IPv4                               ms_tcpip          True
vEthernet (WSL (Hyper-V firewall))        Driver da VPN Forcepoint                         sgra_vpn          False
Passo 6: Reiniciar o WSL2

Para aplicar as mudanças, reinicie o WSL2 com o comando:

wsl --shutdown

Depois, inicie o WSL (ou abra sua distro instalada) novamente e teste a conexão de rede:

ping google.com

Se o ping responder normalmente, o problema foi resolvido! ?

Passo 7: Como Reativar o Módulo da VPN (Se Necessário)

Caso precise reativar o módulo da VPN no WSL2, basta executar o seguinte comando:

Enable-NetAdapterBinding -Name "vEthernet (WSL (Hyper-V firewall))" -ComponentID "sgra_vpn"

E reiniciar o WSL novamente:

wsl --shutdown

Case de estudo: Anatomia de um incidente cibernético

Caso de estudo técnico com base no cenário de incidente cibernético envolvendo rede e ativos, onde ativos comprometidos podem executar atividades maliciosas na rede interna, causando impactos severos aos princípios de segurança da informação na infraestrutura afetada.

Caso de estudo elaborado por:

Colaboração:

Case de estudo: Anatomia de um incidente cibernético

Apresentação da Equipe de Prevenção, Tratamento e Resposta a Incidentes Cibernéticos do IFSP

Apresentação da ETIR/IFSP:

image.pngimage.png

image.png

Case de estudo: Anatomia de um incidente cibernético

O Incidente

Descrição resumida do ambiente e cenário do case de incidente:

Case de estudo: Anatomia de um incidente cibernético

Como realizar a identificação de incidentes com estas características?

Os principais sintomas quantitativos e qualitativos:

1) Queda no desempenho da rede local e link de internet;

2) Queda de desempenho de um determinado host;

3) Detecção do consumo excessivo de recursos de ativos de rede, principalmente do firewall de borda (conexões, cpu, memória e tráfego);

image.png

4) Logs do firewall apresentando sucessivas conexões originadas nas redes internas e destinadas a redes externas (internet); Mas também podem haver cenário com sucessivas conexões de rede interna para rede interna, indicando possíveis reconhecimentos do ambiente, deslocamentos laterais ou exiltração de dados.

image.png

5) Verificação das requisições resolvidas pelo servidor de DNS;

Podem apontar domínios e IPs ainda não identificados, por estarem agindo de maneira mais furtiva, usando técnicas de evasão de defesas ou por não terem atingirem números altos de conexões e/ou não causado impactos no desempenho da rede ou do host.

image.png

IP relacionado a um dos endereços externos ligados a este cenário de incidente, identificados como malicioso. Ele realiza requisições ao servidor DNS para resolver um domínio igualmente malicioso, que tenta se passar pelo "hotmail.com" como "hltmail.com" usando técnica chamada "typosquatting", tentando explorar um erro de digitação do usuário ou sua desatenção ao lê-lo.

Por isso é importante realizar o mesmo monitoramento de IPs que já explicamos no firewall, também sobre o servidor de DNS e armazenar logs das resoluções de DNS realizadas. Elas são um outro grande indicador para incidentes com estas características.

Case de estudo: Anatomia de um incidente cibernético

Juntando o quebra cabeças e entendendo a anatomia

Cruzamento do endereço IP suspeito, identificado como maior gerador de conexões, com as informações de inteligência da plataforma https://virustotal.com e o desenvolvimento de pensamento analítico sobre os ativos que compõe o cenário.

Análise de reputação do endereço IP identificado:

VirusTotal confirmou a ligação da reputação desse CIDR do endereços IP com casos de malware, incluindo domínio maliciosos que estes IPs já foram vinculados, e através de informações indexadas em uma terceira plataforma de inteligência, apontada nos indicadores, que ao ser consultada detalhou ainda mais, como sendo um "malware" ligado a uma "Botnet".

image.png

image.png

Que tipo de dispositivo da rede originou tais requisições e quais as características sistêmicas desse dispositivo?

Dispositivo identificado, conforme a gestão de ativos, incluindo sua localização, como uma TvBox MXQ-PRO 4K, confirmado de forma presencial e visual. O dispositivo possui sistema operacional Android na versão 10.1.

image.png

Com o conjunto de informações que temos até aqui, existe algo em fontes abertas que pode refinar ainda mais nossa detecção?

Recapitulando através de palavras-chave, quais as informações que temos até aqui?

MALWARE + ANDROID + TVBOX + BOTNET

O que podemos fazer com estas palavras-chave? Busca em fontes abertas na internet, como por exemplo o próprio buscado do Google, e.... INFORMAÇÕES VALIOSAS!

image.png

Com as informações obtidas em fontes abertas, foi possível identificar precisamente que o modelo da TvBox que estamos analisando, e confirmar que ele possui ligação com a Botnet "ANDROID BADBOX 2.0", pois pertencia a um grupo de dispositivos sabidamente comprometidos, com estudo detalhado por pesquisadores de segurança da informação:

https://www.bleepingcomputer.com/news/security/badbox-malware-disrupted-on-500k-infected-android-devices/

https://www.humansecurity.com/learn/blog/satori-threat-intelligence-disruption-badbox-2-0/

image.png

image.png

Fonte: https://dashboard.shadowserver.org

Brasil liderando o número de infecções globais.

Como este dispositivo pode operar de maneira maliciosa para comprometer a infraestrutura onde estava inserido?

DE:

image.png

PARA:

image.png

image.png

image.png

image.png

Case de estudo: Anatomia de um incidente cibernético

Medidas de contenção em caso de ocorrência

Ainda é preciso buscar tentativas de evasão do malware na rede. Sim, malwares possuem inteligência em seu código, suficiente para trocar seus servidores de comandos e controle mediante a suspeita e/ou bloqueios. Estes métodos são chamados de TÉCNICAS DE EVASÃO:

Assim, utilizando o endereço CIDR completo, que nos foi retornado pela plataforma VirusTotal, ampliamos nossa análise, e outros dispositivos, que não foram identificados inicialmente, passam a ser identificados como comprometidos, se comunicando com tais servidores de comando e controle maliciosos.

image.png

Ações de contenção:

Remoção física e virtual imediata de todos os dispositivos e suas interfaces de rede vinculadas a este tráfego. Mesmo dispositivos que não sejam TvBox, podem ter sido comprometidos pelo malware, através da exploração de vulnerabilidades para se deslocar na rede. O impacto positivo sobre a qualidade e quantidade da rede é imediato:

image.png

Imediata desconexão/isolamento do segmento de rede onde o incidente foi detectado, evitando contato com as demais redes.

Bloqueio local vertical (entrada e saída para internet) e horizontal (redes internas) dos ranges de IPs externos envolvidos no incidente.

Revisão completa de todas as regras de segmentação entre vlans, recriando-as e incluindo a microsegmentação por origem, destino, serviço, porta e protocolo.

Recriação do ZERO de todos os serviços afetados (que não sejam TvBox), através de instalações íntegras. TvBox devem permanecer fora da rede (em casos de estudos acadêmicos, devem ser usadas redes totalmente segmentadas, sem contatos com as demais redes, em caso de impossibilidade, tais dispositivos não devem ser utilizados).

Atualização de todos os serviços e appliances da rede, mesmo os que não afetados pelo incidente;

ATENÇÃO REDOBRADA AO MONITORAMENTO DE REDE E DE ACESSOS.

Case de estudo: Anatomia de um incidente cibernético

Impactos verificados para este tipo de incidente

Indisponibilidade das redes locais;

Comprometimento e a interrupção de serviços diversos da rede local;

Possibilidade do roubo de dados sensíveis;

Redirecionamento de acessos para sites falsos/malicioso;

Risco da implantação e comprometimento da infraestrutura por variantes de ransomwares;

Risco de comprometimento de outras redes interconectadas de forma local, remota ou por VPN;

Muito retrabalho para as equipes de TI que devem refazer/sanitizar todos os serviços comprometidos e atualizar serviços e appliances que não tenham sido comprometidos, mas estejam sem o update adequado;

Case de estudo: Anatomia de um incidente cibernético

Aprendizados e recomendações

Para a prevenção e contenção, MICROSEGMENTAÇÃO! É A REGRA PARA VLANS- PRIVILÉGIO MÍNIMO;

ALGUMAS VANTAGENS DO USO DE NGFW em redes (FIREWALL DE PRÓXIMA GERAÇÃO) que fazem diferença neste cenário de incidente:

Medidas que fazem a diferença na prevenção, tratamento e resposta a esse cenário de incidente:

image.png

Case de estudo: Anatomia de um incidente cibernético

Referências: