Introdução ao Qubes OS

Teoria, Fundamentos e Setups Manuais Necessários que Poucos Usuários Usam

Neste artigo, você terá uma visão geral sobre como funciona e como usar o Qubes da forma mais segura, além de aprender sobre os erros de uso que permitem desanonimizar a maioria dos usuários, mesmo utilizando um sistema tão robusto em anonimato e segurança! Você também encontrará um comparativo entre Qubes, distribuições Linux normais não virtualizadas e o Tails, que é um sistema não virtualizado, e entenderá por que o Qubes se destaca em anonimato. Além disso, descobrirá as deficiências anti-forense do Qubes e os caminhos avançados que já foram identificados e que precisam ser aperfeiçoados para torná-lo tão anti-forense quanto o Tails!

  Figura: Diagrama de arquitetura do Qubes OS!   
  

Considerações Iniciais no Qubes que o iniciante precisa saber

Devemos considerar que nossos sistemas podem ser invadidos ou já possuem falhas ou backdoors furtivas que não conseguimos identificar. Poucos privilegiados têm acesso a essas informações. Por isso, é essencial adotar uma postura de cibersegurança mais avançada contra essa verdadeira ameaça. Assim, mesmo se invadidos, continuaremos anônimos! Lembre-se de que um whistleblower, um denunciador ou um jornalista pode ser ameaçado e eliminado se sua identidade for descoberta. Portanto, precisamos nos submeter à condição de que, mesmo se invadidos, estaremos invisíveis e, assim, sobreviveremos!

Virtualização de Hardware no Qubes OS

Uma das capacidades do Qubes OS é virtualizar e isolar hardware, como placas de rede, Wi-Fi, periféricos USB (como mouse e teclado) e mídias USB (pendrives ou HDs externos). Este hardware contém números seriais, endereços MAC ou metadados de marca que são visíveis para usuários comuns no sistema. Esses dados estão em notas fiscais e registros de lojistas, transportadoras, reguladores, etc., permitindo identificar quem comprou esses dispositivos.

O usuário comum no Qubes, por falta de conhecimento, infelizmente poderá cometer um grande erro ao anexar pendrives e HDs externos à VM de anonimato que está usando com o Whonix-Gateway, permitindo que os metadados do número de série fiquem acessíveis e registrados em sua VM! O Qubes não trata isso automaticamente e requer que o usuário opere manualmente a manipulação de arquivos de pendrives e HDs externos, de forma que esses metadados não sejam acessíveis em sua VM! Independentemente de você estar usando uma VM para anonimato em modo PVH (Paravirtualized Hardware), no caso de pendrives e HDs externos, esse número de série terá que ficar acessível na VM para anonimato! Por isso, é necessário que o primeiro conhecimento que um leigo precisa ter antes de usar o Qubes com segurança seja saber disso em detalhes e como mitigar esse problema!

Exemplo de Risco

Um pendrive, SSD ou HD importado ou fabricado em um país possui números seriais que podem estar registrados em notas fiscais e outros documentos nos seguintes locais:

• Alfândega
• Transportadoras em geral
• Reguladores
• Fornecedores
• Lojistas

Nota fiscal do cliente: Se você comprou uma placa de rede ou um HD avulso, poderá ter esse dado na nota fiscal, correlacionando isso ao seu CPF. Se você adquiriu um PC que já vem com HD e placa de rede, o PC terá um número serial deles associado a você. Há registros do último proprietário da placa de rede e do HD pelos rastros documentais, possibilitando investigar a instalação desses componentes em um PC específico. A mesma lógica se aplica a smartphones, laptops, etc.

Risco de Invasão

Se alguém invade sua máquina ou se ela já tem uma backdoor por meio de um programa que você instalou, o atacante poderá verificar o número serial dos dispositivos não virtualizados ou endereços MAC, mesmo sem ter acesso como superusuário em muitos casos.

Isolamento no Qubes

No Qubes, é possível impedir que o número serial de um pendrive ou HD externo seja registrado na qube que você está usando para anonimato, anexando os dispositivos em uma qube específica para essa finalidade. Você pode copiar os arquivos que precisa dessa qube para uma qube onde você precisa ser anônimo, garantindo que o número serial do pendrive ou HD não seja registrado nos logs ou acessível para atacantes. A aniquilação desse metadado depende da ação manual do usuário, pois o Qubes não faz isso automaticamente, mas é uma opção viável devido à sua estrutura.

Limitações de Outros Sistemas

No Tails ou em outra distribuição Linux normal, isso não é possível. O HD ou SSD que está instalado com Linux tem um número serial que é inerente ao sistema operacional, e o pendrive utilizado para dar boot no Tails também mantém sua identificação. No Linux, seria possível ter um nível semelhante de controle seguindo a utilização apenas de máquinas virtuais e construindo várias VMs. Teríamos que usar um disco virtual para receber os arquivos de uma VM ligada a um pendrive ou HD externo e, na VM anônima, anexar esse disco virtual e coletar ou enviar arquivos nesse disco virtual. Assim, os números seriais dos dispositivos não ficariam acessíveis nessa VM.

Desafios Operacionais

Entretanto, essa abordagem é operacionalmente difícil de implementar. O Qubes já oferece uma estrutura pronta para uso, facilitando a construção de estruturas de isolamento e compartimentalização avançada.

Gerenciamento de Dispositivos no Linux e Qubes

No Linux, comandos podem ser usados para checar o número serial de pendrives ou HDs que estão conectados, assim como os que foram conectados anteriormente e permanecem nos logs.

Gestão de Placas de Rede e Dispositivos USB no Qubes

No Qubes, a sys-net gerencia as placas de rede, e os endereços MAC reais ficam lá. As outras VMs recebem endereços MAC randômicos diferentes. Já a sys-usb gerencia os dispositivos USB. Quando adicionamos um dispositivo USB em outra VM, ele é virtualizado. Contudo, o número serial aparece na qube onde anexamos o pendrive!

Exemplo de Funcionamento

Por exemplo, ao adicionar o pendrive número CC445 na sys-usb e anexá-lo à qube vault, o número serial aparecerá. Isso significa que não se pode anexar pendrives, HDs externos ou outros dispositivos que têm número serial em qubes usadas para anonimato. Em vez disso, é necessário criar uma qube apenas para gerenciar pendrives e HDs com arquivos, mantê-la totalmente offline e copiar os arquivos dessa qube isolada para a qube utilizada para anonimato.

Fluxo de Arquivos

Considerando o seguinte exemplo:

• qubes para gerenciar arquivos: vault (sempre offline)
• qubes para anonimato: anon-whonix
• arquivo a ser transferido: top_secret.pdf (no pendrive com serial CC445, visível na máquina com comandos simples de usuário normal)

Ao conectar o pendrive no Qubes, o serial CC445 aparecerá na sys-usb. Ao anexar o pendrive na vault, o serial também aparecerá lá. Acessamos o pendrive pela qube vault e, utilizando o botão direito do mouse, clicamos no arquivo top_secret.pdf e selecionamos copy_to_other_qube, escolhendo anon-whonix.

A qube anon-whonix receberá top_secret.pdf na pasta QubesIncoming. Na qube anon-whonix, o pendrive de serial CC445 não tem registros porque nunca se conectou lá. Usando esse setup, que é possível pela estrutura de isolamento e virtualização do Qubes, você aniquila o metadado do número serial desses dispositivos em sua máquina para manter o anonimato.

Segurança na Transferência de Arquivos

O arquivo top_secret.pdf foi copiado de uma qube, passando por uma qube de transferência que transferiu a cópia para a qube anon-whonix. As qubes vault e anon-whonix sempre permanecerão isoladas.

O comando copy to other qube utiliza um serviço de transferência dom0. O sistema de cópia de arquivos entre qubes é seguro porque não permite que outras qubes roubem os arquivos que estão sendo copiados, nem permite que a qube de origem sobrescreva arquivos arbitrários na qube de destino. Além disso, esse sistema não utiliza dispositivos de bloco virtual para a cópia, mas sim a memória compartilhda do Xen, o que elimina uma grande parte do processamento de dados não confiáveis. Por exemplo, a qube receptora não é forçada a analisar partições ou sistemas de arquivos não confiáveis. Nesse aspecto, o sistema de cópia de arquivos entre qubes oferece ainda mais segurança do que a cópia de arquivos entre duas máquinas fisicamente separadas (isoladas).

Erros Comuns dos Usuários do Qubes

Um erro grave cometido pela maioria dos usuários do Qubes é anexar pendrives e HDs nas qubes utilizadas para anonimato, resultando em registros do número serial dos dispositivos, o que pode levar à desanonimização. Você deve sempre anexar e abrir pendrives diretamente na sys-usb, copiando arquivos do pendrive para outra qube por meio dos comandos copy-to-other-vm ou move-to-other-vm, ou enviando arquivos para a sys-usb usando esses comandos a partir de outras qubes. Depois, você poderá mover esses arquivos que estão na pasta QubesIncoming na sys-usb para o pendrive ou HD externo conectado a ela.

Desafios com Arquivos Grandes

O problema surge ao tratar arquivos grandes, já que você terá que aumentar o tamanho da sys-usb. Por isso, prefiro usar uma qube específica para gerenciar arquivos em pendrives e HDs externos, onde eu possa definir o tamanho necessário ou criar rapidamente várias qubes com tamanhos adequados, realizando as operações e depois descartando.

Por exemplo, se um HD contém um arquivo de 50 gigas que precisa ser copiado para a qube work, que também deve ter espaço suficiente, sigamos esses passos:

• Criar uma qube chamada vault-60g que ficará offline;
• Configurá-la para ter 60 gigas;
• Anexar o HD externo a ela;
• Utilizar o comando copy-to-other-vm para transferir o arquivo para a qube work, finalizando a operação.

O problema ocorre quando precisamos copiar um arquivo grande de 50 gigas da qube work para o HD anexado na qube vault-60g. Se a qube vault-60g não tiver pelo menos 50 gigas disponíveis, não será possível copiar o arquivo para o HD conectado a ela, pois o comando copy-to-other-qube ou move-to-other-qube só funciona para mover arquivos para a pasta QubesIncoming de qualquer qube no sistema. Portanto, essa qube precisa ter pelo menos 50 gigas disponíveis.

Um desafio adicional ocorre em relação à sys-usb. Se ela se utiliza como template do default-dvm, que é um template descartável, teríamos que aumentar seu tamanho, que é limitado a 20 gigas.

Se essa operação for temporária, é mais viável criar uma qube de 60 gigas, realizar a operação com o pendrive e, depois, deletá-la, pois aumentar o tamanho de uma qube é sem complicações; no entanto, há erros ao tentar diminuir o tamanho após o aumento!

Mouse, Teclado e Seus Metadados

Os metadados de marca ou número serial de mouse e teclado ficam na sys-usb offline. Podemos pelo menos identificar a marca, que já é um metadado que pode ajudar a desanonimizar você. No Qubes, o mouse e o teclado podem ser verificados na sys-usb, que gerencia esses dispositivos e não será a qube utilizada para anonimato. Nas outras qubes, a marca do teclado, mouse ou o número serial não aparecem.

Número Serial e Metadados da Memória RAM, Processador e Placa Mãe

É possível, com o comando no Linux sudo dmidecode, verificar o número de série das memórias RAM em uso. Um atacante que se torne root da máquina pode verificar essas informações sem precisar checar a memória RAM fisicamente. Os números de série das memórias RAM são registrados em diversos documentos de compra, venda e transporte, desde a fabricação até chegar ao lojista e comprador, além de possibilitar identificar qual foi o último computador em que foram montadas e para quem foram vendidas! Nem na sys-usb ou sys-net esses dados aparecem com sudo dmidecode ou outros comandos, e não aparecem nas outras VMs que o usuário estiver utilizando. Esse metadado é visível apenas no dom0, que gerencia todas as outras VMs e fica offline e isolado!

O isolamento e a virtualização do Qubes impedem essa coleta de metadados, ao contrário de um Linux normal que não está em máquina virtual ou do Tails. Outros metadados incluem a marca e o modelo do processador e o modelo da placa-mãe. Com essas informações, um atacante pode correlacionar você como usuário do computador invadido, pois, se você adquiriu esses modelos de placa-mãe e processador, existe uma correlação ou coincidência com os equipamentos que você usa e comprou. Todavia, saber o número de série da RAM proporciona ainda mais precisão na rastreabilidade do usuário do PC.

Experiência Prática para Comprovação da Identificação do Número de Série de Dispositivos Conectados à Máquina Linux!

Como realizar o teste: Digamos que você tenha um pendrive com o número de série CC445. Então:

Coloque o pendrive no Qubes e faça os testes usando os comandos que serão ensinados mais à frente na sys-usb. Anexe o pendrive na qube vault e faça os testes lá, copiando um arquivo da vault para outra qube qualquer!

Você deve verificar que o número de série dos dispositivos aparecerá na sys-usb e na vault quando foi anexado o pendrive nela, mas na qube que recebeu o arquivo e nas outras qubes não aparecerá!

No Tails ou Outro Linux: insira o pendrive e faça o mesmo teste; você verá que tudo fica registrado nos logs e acessível!

Comandos e Ferramentas a Serem Usados:

Como o gnome-disks, kde-partitionmanager ou gparted, você pode checar o número de série em interface GUI!

Observação: Nos testes, com o dispositivo conectado, será possível ver o número de série. No Qubes, a experiência mostra que não fica registro persistente nos logs; no Linux Debian, mostrou que o número de série fica registrado em certos logs do sistema! Depende das configurações e restrições que o usuário definiu para seu Linux!

Rastreando por lsblk

lsblk -o NAME,SERIAL | grep -E '^sd'

udevadm info --query=all --name=/dev/sda

udevadm info --query=all --name=/dev/sdb

Registro do Número de Série nos Logs do Linux

Depois de conectado, o número de série fica registrado nos logs do sistema! Se invadirem o sistema, poderão checar os números de série de dispositivos conectados para desanonimizar você!

Se conectou 10 pendrives ou HDs diferentes, o número de série de cada um fica registrado nos logs!

Comandos para Checar Histórico!

dmesg | grep -i "serial"

journalctl -k | grep -i "serial"

Logs persistentes: Se a persistência estiver habilitada, os logs são armazenados em /var/log/journal/.

Logs voláteis: Se a persistência não estiver habilitada, os logs são armazenados em /run/log/journal/.

Para checar usando o exemplo de um pendrive com o número de série CC445:

Para logs persistentes para CC445

journalctl | grep "CC445"

Para logs voláteis para CC445

journalctl --directory=/run/log/journal/ | grep "CC445"

Outros logs

sudo grep -r "CC445" /var/log/

Teclados via USB:

Troque "marca_seu_teclado" pelo nome da marca do teclado identificado em lsusb:

lsusb

lsusb -v | grep -i "marca_seu_teclado"

dmesg | grep -i "marca_seu_teclado"

ls /dev/input

Checar Histórico

Para logs persistentes para marca_seu_teclado

journalctl | grep "marca_seu_teclado"

Para logs voláteis para marca_seu_teclado

journalctl --directory=/run/log/journal/ | grep "marca_seu_teclado"

Outros logs

sudo grep -r "marca_seu_teclado" /var/log/

Mouse via USB

lsusb

ls /dev/input/

Agora, você precisa pesquisar onde fica seu mouse. Fazendo vários testes, você encontrará pastas relacionadas ao mouse vigente no sistema; no nosso caso, foi mouse0!

sudo udevadm info --query=all --name=/dev/input/mouse0

E: ID_SERIAL=2188_USB_OPTICAL_MOUSE: Esta linha mostra o número de série do mouse, que é 2188_USB_OPTICAL_MOUSE.

E: ID_USB_SERIAL=2188_USB_OPTICAL_MOUSE: Esta linha também confirma o número de série, indicando que é o mesmo.

Checar

Para logs persistentes para 2188_USB_OPTICAL_MOUSE

journalctl | grep "2188_USB_OPTICAL_MOUSE"

Para logs voláteis para 2188_USB_OPTICAL_MOUSE

journalctl --directory=/run/log/journal/ | grep "2188_USB_OPTICAL_MOUSE"

Outros logs

sudo grep -r "2188_USB_OPTICAL_MOUSE" /var/log/

Logs:

dmesg | grep -i 'sd'

sudo grep -i 'sd' /var/log/syslog

Perceba que, com comandos simples que usuários normais sem privilégio de root podem executar, é possível saber o número de série dos dispositivos conectados!

lsusb para obter a marca do mouse e teclado.

lsblk -o NAME,SERIAL | grep -E '^sd' para obter o número de série dos dispositivos pendrives, SSDs e HDs conectados!

O Qubes anula automaticamente os metadados de marca de mouse e teclado para outras VMs; só é possível ver isso na sys-usb!

Já o número de série de pendrives e HDs deve ser evitado, nunca anexando-os nas qubes que você deseja ter anonimato absoluto, como mostrado no setup anteriormente!

Desanonimização por MAC Address Impossibilitada Automaticamente

O sys-net atua como um isolante, permanecendo online e virtualizando a placa de rede para outras qubes. Este componente registra o MAC original do PC ou laptop, mas não é utilizado diretamente pelo usuário; serve unicamente para gerenciar os dispositivos de rede de forma isolada.

As qubes recebem MACs randomizados. Se um invasor acessar uma qube que está sendo usada para anonimato, não conseguirá descobrir a identidade do usuário pelo metadado do MAC Address de fabricação, que provavelmente está registrado em numerosos documentos de transporte, compra, venda e notas fiscais.

A única maneira de identificar o MAC Address original é invadindo a qube sys-net, que está isolada da qube invadida com o MAC randomizado anônimo!

Em um Linux em um PC sem essas camadas de virtualização em contato direto com o hardware, se o usuário estiver usando MAC spoofing, um invasor com privilégios adequados poderá desativar o spoofing do MAC e descobrir o MAC real ou verificar se o MAC original aparece em alguns dos logs do sistema. Se o invasor tiver acesso root na invasão, poderá desativar todas as barreiras e determinar o MAC real!

Desanonimização por Número de Série de Memória RAM e Modelo/Marca de Placa Mãe, GPU e Processador Impossibilitada Automaticamente

Para obter informações sobre os componentes da placa mãe e da própria placa mãe, você pode usar o comando:

sudo dmidecode

Memória RAM: Verifique na seção "Memory Device". Esse registro pode incluir metadados do tipo de memória e o número de série, que pode constar em vários documentos até o componente chegar ao cliente ou ao computador do cliente!

Placa Mãe: Procure em "Motherboard" para checar o metadado da marca da placa mãe. O número de série geralmente não está presente!

GPU (Placa de Vídeo Dedicada): Utilize os seguintes comandos para verificar metadados:

cat /sys/class/drm/card0/device/uevent | grep SERIAL

cat /sys/class/drm/card0/device/serial

Pelo menos, será possível determinar se a GPU é AMD ou NVIDIA, e isso já é um metadado que pode ser usado contra você. No Qubes, essa informação é impossibilitada, pois esses dados ficam no dom0, que é o host das qubes que você usa. Nas qubes, mesmo com acesso root, você não conseguirá acessar esses dados devido ao isolamento!

Whonix Gateway | Tor Isolado em netVM

Fornece a conexão Tor para outra VM ou qube (que você vai usar) a partir de uma qube também isolada (sys-whonix)! Se um atacante tem acesso à sua VM, ele não consegue desativar o Tor para saber seu IP real, pois o Tor é fornecido por uma VM isolada (whonix-gateway). O Qubes possui o Whonix que faz isso!

No Whonix, usando um Linux normal, também é possível usar duas VMs: o whonix-gateway (roteador Tor) e o whonix-workstation para navegação! O Qubes tem o Whonix Workstation que usa o whonix-gateway; porém, você pode disponibilizar o whonix-gateway para rotear a rede de qualquer qube para qualquer atividade de anonimato com programas diferentes dentro dela! Você pode personalizar isso!

Desvantagem do Tails e Outros Sistemas Linux:

Ele não usa um whonix-gateway virtual ou externo (servidor físico ou algum tipo de roteador físico que fornece conexão Tor)! Por isso, se ele for invadido, o Tor e o firewall poderão ser desativados, e o atacante saberá seu IP, desanonimizando você. O mesmo pode ocorrer com qualquer Linux que roteia todo o seu tráfego pelo Tor, usando por exemplo o Tor Bridger, o Tor-Ghost ou o Tor-Router!

Regra Suprema do Anonimato e Cibersegurança: Mesmo Invadido, Eu Continuo Anônimo

O ápice da cibersegurança é continuar anônimo mesmo se for invadido. Isso é possível tendo o poder de aniquilar os metadados, como números de série e informações de hardware, incluindo pendrives, HDs, placa de rede, número de série da memória RAM, modelo da placa mãe, modelo do processador, entre outros. O Qubes permite isso usando a estratégia ensinada no começo deste artigo e um gateway Tor isolado, pois o invasor não conseguirá desativar o Tor para saber meu IP real, mesmo com acesso root, já que o gateway Tor está isolado em outra qube!

O Qubes permite tudo isso! Com essas duas potencialidades, eu tenho o poder de estar anônimo mesmo com minha máquina invadida. Todavia, é importante alertar que é preciso saber como navegar e usar a máquina com anonimato. Portanto, não podem existir metadados que lhe identifiquem dentro dessa máquina, e o usuário não poderá digitar e se expressar da mesma forma ou movimentar o mouse como de costume, pois há impressões digitais na movimentação do mouse e digitação que podem ter sido captadas por redes sociais, e-mails etc., que você usa e que o identificam! O atancante poderá coletar esses dados para lhe desanonimizar!

Ou seja, depende do usuário saber navegar com anonimato! Denunciadores, jornalistas e outras pessoas que forem descobertas poderão ser eliminadas, dependendo do contexto e risco de suas operações. Por isso, o mais importante na cibersegurança é o anonimato absoluto. Isso é viável quando temos uma postura de criar uma estrutura onde, mesmo invadidos, permanecemos anônimos. O Qubes permite isso, mas ainda depende do usuário saber navegar e operar as qubes anonimamente!

Xen Hypervisor, Dom0 e DomU

O Xen roda diretamente sobre o hardware, criando uma camada de virtualização que fica entre o equipamento físico e as máquinas virtuais. Dessa forma, o hardware deixa de ser usado como um único recurso e passa a ser tratado como um conjunto lógico de recursos de computação. O hipervisor pode distribuir esses recursos de maneira dinâmica para qualquer sistema operacional convidado, que vê e utiliza os recursos virtuais como se fossem recursos reais do hardware.

Composição do Xen: Primeiro, existe o dom0. No contexto do Xen, esse termo designa o sistema operacional que atua como host embora não funcione exatamente como um host tradicional comparado a outras máquinas virtuais (VMs).

Os domínios, segundo a nomenclatura do Xen, não precisam acessar diretamente o hardware do servidor host. Contudo, o dom0 é o único responsável por lidar com os drivers, e sempre que houver necessidade de coordenação entre as VMs, essa tarefa será realizada pelo dom0. Além do dom0, há as demais VMs, que são referidas como domU.

No Qubes, temos as qubes padrões criadas na instalação, chamadas de vault, work, personal, sys-whonix, anon-whonix, etc. Elas são domU!

• Dom0: é a única VM privilegiada que roda diretamente sobre o hipervisor Xen. Ela tem acesso aos drivers de hardware e controla todo o restante do sistema. Todas as operações de criação, destruição, configuração e comunicação entre as VMs são mediadas por dom0.
• DomU: são as máquinas virtuais normais, sem acesso direto ao hardware. Cada qube que você vê na interface do Qubes (personal, work, sys-whonix, anon-whonix, vault, etc.) é, de fato, um domU. Elas recebem recursos (CPU, memória, disco, rede) do pool que o Xen disponibiliza e interagem com esses recursos como se fossem físicos, embora tudo seja virtualizado.
• Hipervisor Xen: fica logo abaixo de dom0, rodando diretamente sobre o hardware. Ele fornece o mecanismo de isolamento e a camada de virtualização que permite que dom0 e todos os domU coexistam de forma segura.

Portanto, o Qubes OS é uma camada de software construída sobre o Xen que inclui um conjunto de extensões próprias para entregar a experiência de segurança por isolamento de VMs.

TemplateVM e AppVM

No Qubes OS, o software que usamos diariamente é instalado nos templates; as app qubes são criadas a partir desses templates e herdam seu sistema de arquivos raiz. Alterações no sistema da app qube não são gravadas no template, portanto, programas instalados nela desaparecem ao desliga-la (exceto pacotes Flatpak/Snap, que ficam no home do usuário). Já as standalone qubes possuem todo o sistema de arquivos próprio, preservando todas as mudanças. Esse modelo traz quatro benefícios principais:

• Segurança: acesso somente leitura ao template impede que uma qube comprometida contamine outras.
• Economia de espaço: qubes compartilham o mesmo raiz.
• Velocidade: criar novas app qubes é quase imediato.
• Atualizações centralizadas: basta atualizar o template para que todas as qubes o utilizem.

O Qubes oferece templates baseados em Fedora, Debian, Whonix e outras distribuições, permitindo escolher diferentes níveis de confiança, ambientes ou conjuntos de ferramentas conforme a necessidade.

A diferença para uma máquina virtual comum é que cada uma tem que ter seu próprio sistema raiz e é muito mais pesada! Ter 10 appVM do mesmo template é muito mais leve que ter 10 VMs normais com o mesmo sistema raiz cada uma!

Clonagem de Templates para Construção de Templates Personalizados para Específicas AppVMs

Se você precisa de uma appVM com o Session instalado e outra appVM com o Simplex, e para maior segurança compartimentalizar tendo um template para cada appVM, basta clonar um template base principal! Temos o Debian-xfce-12; ele não vem com o Session nem com o Simplex. Se instalar nele, outras appVM podem ser comprometidas se um desses softwares ficarem comprometidos. Portanto, podemos:

Clonar o template debian-xfce-12 e instalar o Session. (nomeie para debian-xfce-12-session)

E clonar de novo o template debian-xfce-12 e instalar o Simplex. (nomeie para debian-xfce-12-simplex)

A appVM para Simplex configuramos para usar o template com o Simplex, e a appVM para Session, configuramos para usar o template com o Session! Desta forma, você pode ter vários templates personalizados com novas instalações e compartimentalizar usando 1 ou poucos softwares por atividades e por qubes!

Um erro é criar um template e instalar vários softwares e usá-lo para diferentes VMs! Vamos usar o caso do Session e Simplex instalados no template padrão Debian-xfce-12, onde muitas appVM sensíveis não precisam do Session nem do Simplex! Se o pacote do Simplex, na atualização, passa a ter uma backdoor com um ataque de supply chain furtivo, todas as suas appVMs ficam vulneráveis e comprometidas! Então, é preciso usar os templates com essa consciência de compartimentalizar o máximo que for possível e abandonar a conveniência que pode custar caro!

Disposable VMs

Podemos transformar as appVMs em disposable VMs, que são VMs que se auto-destroem no desligamento ou reinicialização! As disposable VMs não são amnésicas 100% na memória RAM como no Tails, então ficará rastro para extração forense no Qubes dessa appVM, e isso deve ser considerado dependendo da operação de segurança e anonimato que o usuário deseja executar!

A utilidade da disposable VM é que podemos reinstalar um software em uma condição inicial na AppVM, que provavelmente não foi comprometida, e voltar ao estado inicial a cada novo boot! Se a VM for comprometida durante o uso, na reinicialização, ela volta ao estado original!

Exemplo:

• Crie a appVM
• Baixe o Telegram do GitHub e cheque o hash
• Instale o Telegram na máquina e faça o login com meu usuário!
• Transforme a appVM em disposable template e depois crie uma appVM baseada nesse disposable template

Então tanto o template Debian-xfce-12 será volátil como a appVM será volátil. Qual é a vantagem disso?

O Telegram poderá sofrer com ataques de zero cliques que não têm defesa se estiver vulnerável por meio de fotos ou mensagens enviados ao usuário. Se o privilégio do atacante ficar como usuário normal, então ao reiniciar uma appVM normal que é persistente, o acesso do atacante continuará na appVM. Mas se for uma disposable VM, ela se auto-destruirá ao desligar a máquina e voltará à condição inicial!

Instalando o Telegram em uma disposable VM, ao usar a appVM, o atacante com zero clicks perderá acesso ao Telegram quando a VM for desligada. Ao reiniciar, ele teria que atacar de novo, tornando mais difícil o processo de persistência contra esse usuário!

Usar apps de mensagem com esse setup é muito útil e rápido de criar, oferecendo esse nível de segurança contra zero clicks, que são brechas que não têm defesa. Com isso é possível aniquilar a persistência por essa natureza das disposable VMs! Você pode usar isso em appVMs de redes sociais, pois seu navegador pode ser hackeado e o atacante ter controle da appVM, mantendo persistência. Porém, usando uma disposable VM, você vira o jogo contra ele a cada reinicialização da appVM!

Qubes USB: sys-usb

Isola o dom0 de conexão USB.

Uma USB Qube funciona como um manipulador seguro para dispositivos USB que podem ser maliciosos, impedindo que eles entrem em contato direto com o dom0. Um dispositivo USB conectado diretamente ao dom0 poderia comprometer gravemente a segurança de todo o sistema. Dessa forma, ela reduz alguns dos riscos associados ao uso de dispositivos USB.

Acessando o Qubes Manager, sys-usb e settings, na opção devices, vemos quais dispositivos USB estão selecionados e conectados a essa Qube. Entretanto, se formos para outras Qubes (sys-firewall, sys-whonix, personal, anon-whonix, etc.) e verificarmos em Qubes Manager, settings e devices, isso não ocorre, pois a sys-usb é quem cuida das conexões USB do mouse, teclado e outros dispositivos por padrão.

Se você anexar um pendrive malicioso a uma VM, ele pode hackear a Qube que aceitou a conexão?

Sim, pode comprometer a VM que recebeu o pendrive (por meio de exploits de driver, scripts maliciosos, etc.). Mas, por design, não pode comprometer o dom0 nem outras VMs diretamente!

No início, alertei sobre o metadado de serial number de pendrives e HDs externos, que a maioria dos usuários não tem consciência e que pode levar à desanonimização. Por isso, você deve realizar o seguinte procedimento manual e consciente para remover esse metadado crucial!

Você deve sempre anexar pendrives ou discos externos à Qube sys-usb e, a partir daí, usar os comandos copy-to-other-vm ou move-to-other-vm para transferir os arquivos para a Qube que realmente processará esses dados. Da mesma forma, se outra Qube precisar enviar algo para o pendrive anexado a sys-usb, ela usa esses mesmos comandos com destino a sys-usb; depois, basta mover o conteúdo da pasta QubesIncoming para o dispositivo conectado à sys-usb.

Esse fluxo funciona bem para arquivos pequenos, mas quando o tamanho dos dados aumenta, você acaba esbarrando no limite de armazenamento da sys-usb (por padrão, 20 GB). Portanto, prefiro criar uma Qube dedicada exclusivamente ao gerenciamento de mídias externas, ajustando seu disco virtual ao tamanho necessário e descartando-a logo após a operação.

Crie uma Qube chamada vault2 com o total de gigabytes necessários para manipular os arquivos copiados ou movidos, exatamente como foi feito na sys-usb! Essa Qube pode ser temporária ou não!

No caso dos metadados de marca e modelo de teclado e mouse, eles são removidos automaticamente pela virtualização do Qubes. Esses dados só aparecem na sys-usb, e você pode usar o mouse e o teclado nas outras Qubes sem enxergá-los!

Os metadados de placa mãe, processador e serial number de memória RAM só são visíveis no dom0; nas outras VMs, esses metadados do hardware utilizado não aparecem.

Você apenas precisa usar manualmente a sys-usb e/ou Qubes específicas para manipular pendrives e HDs externos e seus arquivos, a fim de evitar expor o metadado de serial number desses dispositivos ao anexá-los às AppVMs sensíveis, que são destinadas ao anonimato!

A sys-usb utiliza o modo de virtualização HVM (Hardware Virtual Machine), que tem acesso direto ao hardware. Já as outras VMs que usam PVH (Paravirtualized Hardware) não têm acesso direto ao hardware, e esse é o modo utilizado por padrão nas AppVMs ou templates. Essas opções podem ser encontradas em Qubes Manager. Selecione a AppVM ou template, vá para settings, depois advanced, e na opção de virtualização você encontrará as opções HVM, PVH e PV. Portanto, todas as AppVMs e templates não ficam vulneráveis a ataques a nível de hardware dos dispositivos USB! Por isso, você deve sempre usar a sys-usb por segurança para manipular pendrives e HDs externos e seus arquivos, ou criar outra AppVM especificamente para isso!

Problemas de Funcionamento com Certos Dispositivos USB Paravirtualizados em AppVMs e Templates

Microfones USB: Experiências comprovam que muitas placas de som USB com microfone, microfones USB ou até mesmo microfones com conector de cabo não são reconhecidos pela AppVM e o som não é gravado! Nesse caso, é necessário mudar a AppVM de PVH para HVM e adicionar apenas esse dispositivo USB ou o microfone com conector de cabo para que funcione! Contudo, existe um risco de segurança grave, pois a AppVM ficará exposta a ameaças devido ao contato direto com o hardware!

Esse problema se torna relevante quando você deseja, por exemplo, usar um aplicativo de mensagens e conversar por voz, necessitando de um microfone funcional nessa AppVM!

Digamos que você tenha uma AppVM com o aplicativo de mensagens Simplex e não consegue fazer o microfone funcionar com a AppVM em PVH. Ao mudar para HVM, o microfone provavelmente funcionará, mas sua AppVM ficará vulnerável a esse vetor de ataque, que poderia ser mitigado se houvesse paravirtualização desse hardware! Portanto, para maior segurança, é melhor evitar usar AppVMs sensíveis com HVM habilitado para microfones ou qualquer outro dispositivo como GPUs que possam melhorar a imagem!

E quando é urgente usar o microfone no Simplex?

Você pode realizar uma gestão de risco e avaliar quais contatos precisam ser abordados por voz e quais podem ser contatados por texto.

Crie uma AppVM com Simplex em PVH, garantindo a segurança e evitando o uso do microfone em HVM. Crie outra AppVM com Simplex em HVM apenas para os contatos que exigem comunicação por microfone. Nesse caso, se a appVM com simplex em HVM for comprometida devido ao acesso direto ao hardware do microfone ou placa de som USB ou PCI, você ficaria vulnerável somente nessa appVM, enquanto a outra permanecerá intacta contra essa vulnerabilidade!

Isso é um exemplo de gestão de risco que deve ser considerado quando é extremamente necessário utilizar AppVMs com HVM (Hardware Virtual Machine), já que o modelo de segurança do Qubes propõe o uso de AppVMs e templates sempre em PVH (Paravirtualized Hardware)!

Qubes Network com Base em sys-net e sys-firewall

No Qubes, a rede funciona com o modelo padrão do Xen: há um driver de back-end rodando no domínio de driver (normalmente a sys-net) e drivers de front-end instalados nas VMs. Para impedir ataques de camada 2 que possam surgir de uma VM comprometida, a arquitetura utiliza roteamento em vez do tradicional bridge dos dispositivos vif. Além disso, o NAT é aplicado em cada salto da rede, garantindo que o tráfego seja mascarado e controlado a cada passagem.

Acessando o Qubes Manager, sys-net e settings, na opção devices, veremos que dispositivos ethernet ou wifi que estão nas entradas PCI do PC ou estão onboard na placa mãe, estão selecionados e conectados a essa Qube. Entretanto, se formos para outras Qubes (sys-firewall, sys-whonix, personal, anon-whonix, etc.) e verificarmos em Qubes Manager, settings e devices, isso não ocorre, pois a sys-net é quem cuida das conexões de hardware para internet, como placas de rede em geral, por padrão.

O metadado do MAC address do fabricante real não aparece nas outras VMs, apenas na Qube sys-net, usando os comandos ip addr, nmcli, etc. O dom0 também não fica conectado à placa de rede ethernet, wifi ou bluetooth, e por isso esses metadados não ficam acessíveis no dom0! Isso é delegado à sys-net.

Esse metadado do MAC address real poderia desanonimizar você, caso fosse acessível, pelos motivos explicados no começo do artigo! A virtualização impede isso!

Visão Geral do Modelo de Rede em Qubes e Benefícios

• sys-net: É a VM responsável por se conectar ao hardware físico (Wi-Fi ou Ethernet).
• sys-firewall: Fica entre sys-net e todas as demais VMs de usuário. Ela aplica regras de filtragem de pacotes (iptables/nftables) e pode fazer NAT.
• AppVMs: São as VMs onde você roda suas aplicações. Elas recebem tráfego já filtrado e, se necessário, podem ter acesso à internet através da cadeia sys-firewall e sys-net.

Por que o tráfego passa por sys-firewall antes das outras VMs?

• Isolamento de segurança: Em Qubes, cada VM tem seu próprio domínio de segurança. Se sys-net fosse exposta diretamente às AppVMs, qualquer vulnerabilidade no driver de rede ou no firmware poderia ser usada para comprometer todas as VMs de usuário. Ao colocar sys-firewall como camada intermediária, você garante que um eventual comprometimento da interface física afete apenas sys-net, que está isolada do resto do sistema.
• Política de controle de tráfego centralizada: sys-firewall permite definir regras de firewall uma única vez e aplicá-las a todas as VMs que precisam de acesso externo. Isso evita a necessidade de configurar firewalls individuais em cada AppVM, reduzindo a superfície de ataque e simplificando a administração.
• NAT e roteamento controlado: sys-firewall normalmente faz NAT (Network Address Translation) para que as VMs internas compartilhem o mesmo endereço IP público fornecido por sys-net. Assim, as AppVMs não precisam conhecer a topologia externa e permanecem ocultas atrás da camada de firewall.
• Separação de funções: Qubes segue o princípio separação de privilégios: cada componente tem uma responsabilidade bem definida. sys-net lida apenas com a comunicação de baixo nível com o hardware; sys-firewall cuida da política de segurança de rede; as AppVMs concentram-se na execução de aplicativos. Essa divisão facilita auditorias e revisões de código.
• Facilidade de substituição/upgrade: Caso você queira trocar a interface de rede (por exemplo, mudar de Ethernet para Wi-Fi) ou atualizar o driver, basta substituir ou reconfigurar sys-net sem tocar nas regras de firewall ou nas AppVMs. O isolamento garante que mudanças locais não se propaguem inesperadamente.

Fluxo Típico de Pacotes

• Entrada: Pacote chega pela placa de rede em contato com a sys-net.
• Filtragem inicial: sys-net pode aplicar filtros muito básicos (ex.: bloquear tráfego malformado), mas geralmente encaminha tudo para sys-firewall.
• Firewall/NAT: sys-firewall avalia o pacote contra suas regras. Se permitido, ele realiza NAT (se necessário) e encaminha o pacote para a VM de destino (uma AppVM ou outra NetVM).
• Entrega à AppVM: A AppVM recebe o tráfego já filtrado e pode responder. A resposta segue o caminho inverso: AppVM, sys-firewall, sys-net, rede externa.

Benefícios Práticos

• Menor risco de vazamento de dados: Mesmo que sys-net seja comprometida, o atacante ainda precisaria contornar as regras de sys-firewall para alcançar as AppVMs.
• Gerenciamento centralizado: Alterar uma regra de firewall afeta todas as VMs simultaneamente, evitando inconsistências.
• Flexibilidade: Você pode criar NetVMs adicionais (por exemplo, sys-whonix para Tor) que também se conectam a sys-firewall, mantendo a mesma política de filtragem.

A sys-net usa o modo de virtualização HVM (Hardware Virtual Machine) e este modo tem acesso direto ao hardware; já as outras VMs que usam PVH (Paravirtualized Hardware) não têm acesso direto ao hardware, e isso é usado por padrão nas AppVMs ou templates quando criamos uma! Essas opções estão disponíveis no Qubes Manager; selecione a AppVM ou template, vá para settings, depois advanced, e na opção de virtualização você encontrará as opções HVM, PVH e PV.

Por isso, as AppVMs que estão no modo PVH não possuem o MAC original da placa de rede Wi-Fi ou Ethernet, usando os comandos ip addr, nmcli, etc., pois o hardware é paravirtualizado e o MAC é randômico, diferente do MAC original do fabricante, que poderia desanonimizar você, conforme as considerações demonstradas e provadas no início do artigo!

Usar AppVMs em modo HVM acarreta o risco de desanonimização pelo MAC, além das implicações do acesso direto ao hardware, que poderia comprometer sua VM se a placa de rede for maliciosa!

Gateway Tor Isolado: Whonix-Gateway + Whonix-Workstation ou AppVM

O template whonix-gateway é usado pela AppVM sys-whonix, que é uma netVM! NetVMs são VMs que compartilham sua conexão com a internet com outras VMs do sistema que a selecionam como gateway de rede! A sys-firewall também é uma netVM, mas ela usa a internet normal e não é roteada por VPN, proxy ou pelo Tor! A sys-whonix roteia tudo para a rede Tor, com a vantagem de ser uma VM isolada da VM que recebe a conexão Tor.

Com isso, um atacante que dominar a AppVM que usa o sys-whonix para ter a conexão Tor e esconder seu IP real precisará desativar a conexão Tor e desanonimizar o usuário dessa máquina. Para isso, ele teria que acessar a sys-whonix, mas ela fica isolada e o atacante não consegue desativa-la! Mesmo que o atacante tenha uma backdoor que vem de fábrica em um software que o usuário esteja usando ou domine o sistema por meio de vulnerabilidade via zero-click, que não tem defesa, o isolamento do gateway Tor pelo sys-whonix impede que ele desative o Tor para saber seu IP real, pois está em uma VM isolada!

A Whonix Workstation no Qubes é a AppVM chamada por padrão anon-whonix, baseada no template whonix-workstation, e possui o objetivo de navegação com o Tor Browser e outras ferramentas!

Da mesma forma que o sys-whonix é um gateway de rede Tor isolado, podemos criar netVMs personalizados com VPN ou proxy! Basta configurar uma AppVM para prover internet para outras VMs, selecionando a opção [provide network access to other qubes] e projetá-la para que toda a conexão de saída seja por uma VPN ou proxy, além de outras configurações adicionais!

Desta forma, a AppVM que usa a netVM que provê uma VPN não poderá ter a VPN desligada pelo atacante para saber seu IP real e desanonimizá-lo, pois a conexão é fornecida por uma netVM isolada!

VPNs centralizadas e proxies não são seguros para anonimato. O Tor, I2P e a NYM VPN, que é descentralizada, são ferramentas confiáveis para um anonimato robusto! Criar netVMs com essas ferramentas para ter um gateway isolado e suas vantagens é o ideal, ou usar novas ferramentas de anonimato descentralizadas similares!

Existe um mito de que basta usar o sys-whonix em uma AppVM ou whonix-workstation em modo PVH (Paravirtualized Hardware) para garantir anonimato. Errado! Se o usuário cometer o erro de anexar um pendrive ou HD nessa AppVM para anonimato com o sys-whonix, para acessar ou copiar arquivos para ela, ou enviar arquivos para o dispositivo pendrive ou HD externo, infelizmente, o serial number desses dispositivos ficará acessível no sistema da AppVM, podendo ser acessível a um usuário sem poder de root e com baixos privilégios!

Basta usar os comandos como usuário normal:

lsblk -o NAME,SERIAL | grep -E '^sd'
udevadm info --query=all --name=/dev/sda
udevadm info --query=all --name=/dev/sdb

Como já demonstrado no início do artigo, o serial number do pendrive e HDs externos pode estar em diversos documentos de transporte, notas fiscais e registros, permitindo rastrear o último comprador e saber quem é o dono ou chegar até o dono e partir desse último comprador!

Então, mesmo invadido, usando o sys-whonix em uma AppVM para anonimato, você é invisível se não cometer esse erro!

AppVMs Personal, Work e Vault e o Básico de Como Usar para Compartimentalização

Essas AppVMs são criadas por padrão se você configurar o Qubes OS com elas prontas! A Qube Personal e Work são as mesmas e usam o sys-firewall para internet, ou seja, sem conexão Tor! A Qube Vault fica sem netVM ou offline!

Os nomes indicam o que você deve fazer com elas e o que instalar nelas! Personal é para atividades pessoais, então instale programas pessoais ou de lazer, etc. Work é para trabalho, então instale e use programas de trabalho para realizar atividades de trabalho! Vault é para armazenar arquivos, conectar pendrives e manter tudo offline por segurança em isolamento!

Isso lhe dá uma ideia de compartimentalização que você pode fazer no Qubes, porém há algumas deficiências em pensar em compartimentalizar tão pouco e o quão inseguro você pode ficar por isso!

Exemplo: Digamos que na Qube Personal, para lazer, você instala o Telegram, usa o Firefox e conecta várias redes sociais, usa o Google Chrome para Netflix, tem o GIMP para editar imagens, e você usa os quatro programas em uma única AppVM para o lazer! A pobre compartimentalização pode comprometer sua AppVM!

Se um dos quatro programas ficar vulnerável, todas as atividades e todo o resto poderão ser comprometidos se, na exploração da falha de um dos programas, ocorrer escalada de privilégios até o controle total da máquina!

Uma compartimentalização mais inteligente seria ter quatro AppVMs pessoais, cada uma para um programa:

• personal-firefox: para logar nas redes sociais de lazer com o Firefox
• personal-chrome: para assistir Netflix no google-chrome
• personal-gimp: para manipular imagens no gimp
• personal-telegram: para usar o Telegram com amigos

Ligue as quatro AppVMs e opere independentemente em cada uma! Se a AppVM personal-telegram for comprometida por um ataque zero-click no Telegram, que não tem defesa, e o atacante controlar a máquina inteira, suas redes sociais logadas e cookies estarão em uma AppVM separada, sua conta Netflix e seus arquivos de imagens também, pois cada atividade e cada programa foi atribuído a uma AppVM isolada em específico!

Isso é uma compartimentalização inteligente. Embora dê mais trabalho para construir e seja mais difícil de usar, é uma questão de segurança e não de conveniência!

Quem usa o Qubes OS, criando um template e usando uma AppVM que tem todos os programas do seu antigo Linux instalado, e tudo em uma AppVM só, está usando o Qubes de forma errada! É preciso compartimentalizar o máximo possível, considerando uma análise de risco e levando em conta a produtividade que você necessita. Se compartimentalizar demais, pode prejudicar sua produtividade, talvez compense compartimentalizar algumas atividades e programas mais críticos do trabalho, deixando o resto das atividades para apenas uma AppVM!

O Qubes vai ajudar quem entender como usá-lo, e você precisa entender como ele funciona profundamente para construir e proceder com o melhor aproveitamento em segurança e privacidade!

Deficiências e Desvantagens do Qubes

Amnésia 100% na RAM como o Tails não existe: O Qubes não tem opção para deixar uma AppVM 100% na RAM, igual ao Tails. Porém, existe um atalho para fazer isso que é rodar o dom0 100% na RAM e usar certos procedimentos mais técnicos para deixar uma AppVM 100% na RAM. Contudo, existem consequências negativas para isso, e será preciso reparar essas consequências para voltar a usar o Qubes normalmente! Além disso, é preciso ter muita memória RAM e alocar mais memória RAM para o dom0. Dependendo da quantidade de AppVMs que você usará, precisará de mais RAM ainda para o dom0 e terá que ter o suficiente para as outras VMs persistentes funcionarem!

Consequência de usar o Qubes sempre com o dom0 na memória RAM: Você não conseguirá atualizar o dom0, pois ele fica amnésico e, ao reiniciar, a atualização sumirá! As AppVMs que estão na RAM também não conseguem ser atualizadas da mesma forma! Portanto, você precisa retornar ao estado anterior do Qubes original para conseguir realizar as atualizações!

Leandroibov conseguiu realizar isso e reparou todos os problemas e limitações, porém requer um conhecimento técnico bem avançado para realizar essas operações 100% na RAM com anti-forense e anti-cold-boot-attack, como é possível no Tails!

Incompatibilidade para acessar pendrives e copiar e receber arquivos de outras AppVMs: Usando máquinas virtuais do VirtualBox ou KVM, ou distribuições live como Tails, Kali Live, Ubuntu Live e outras, é possível rodar, mas não há compatibilidade para copiar ou mover arquivos para outras appVMs com os comandos copy-to-other-vm ou move-to-other-vm. Além disso, não há compatibilidade para anexar pendrives ou HDs externos para acessar arquivos ou guardar arquivos, o que torna inviável usar o Tails em muitos casos e outras distros live! Em um Linux normal, eu consigo usar KVM ou VirtualBox e usar outras máquinas virtuais com compatibilidade para anexar pendrives, copiar arquivos da VM para o host, etc.

Usar o Qubes para tudo por causa da virtualização massiva dele é seguro?

Depende do seu nível de risco! Se as operações com uma wallet de criptomoedas são críticas e sensíveis, não é ideal usar o Qubes OS para tudo, como lazer, trabalho, estudos, pesquisas, streaming, games, etc. Embora você possa usá-lo para criptomoedas, vale lembrar que o Xen hypervisor já apresentou vulnerabilidades no passado; ele não é infalível. Se uma AppVM for comprometida e o usuário conseguir explorar o Xen, ele pode ter acesso a outras VMs e ao dom0, possibilitando o acesso a suas AppVMs relacionadas a operações sensíveis com criptomoedas.

Verifique a lista das falhas do Xen Hypervisor no link abaixo:

https://www.qubes-os.org/security/xsa/

Portanto, o Qubes não faz milagres, e situações como as citadas acima podem ocorrer, causando muitos danos!

Para operações ultra-sensíveis, é recomendável compartimentalizar ainda mais, criando um Qubes, por exemplo, para operações com certas criptomoedas, e outro Qubes para trabalho, pesquisa, lazer, etc. Além disso, considere ter outro Qubes dedicado a operações de anonimato e comunicação mais robustas.

Preciso, então, nesse caso, de três computadores?

Não, você precisa apenas de um PC desktop e três SSDs ou HDs. Em cada um, instale um Qubes diferente para usar em casos específicos! Instale um HD, instale o Qubes, remova-o e coloque outro; instale o Qubes para outro uso, desinstale e faça isso até terminar. Por exemplo, você pode instalar o Qubes para criptomoedas com operações secretas em XMR na SSD da Kingston, e um Qubes para lazer e trabalho no HD da Samsung. Isso facilita a identificação de qual mídia contém o Qubes que deseja usar!

Ao usar o Qubes para criptomoedas no SSD da Kingston, desligue o outro HD diretamente pela BIOS ou remova manualmente o cabo SATA dele! Faça o inverso para usar o outro HD com o Qubes para lazer e trabalho! Ao ligar o computador para dar boot, acesse a BIOS usando Del, Esc, F2, F7, F10 ou outra tecla para acessar sua BIOS!

Coloque o Qubes para dar boot! Entre nele e use mais um nível de compartimentalização avançada para criptomoedas!

Com apenas um computador, usando diferentes HDs ou SSDs, e seguindo esse procedimento, você poderá ter uma camada mais robusta de segurança para os casos citados acima, mitigando o problema do hypervisor estar vulnerável e protegendo certas operações de anonimato por causa dessa compartimentalização!

Outra medida, embora menos robusta, mas válida, é que, ao realizar uma operação ultra-sensível, desligue o máximo de Qubes possível e realize apenas essa atividade nas AppVMs necessárias para aquela tarefa!

Uma situação menos segura seria ligar várias AppVMs para lazer, trabalho, e aplicativos de mensagens, e deixá-las ativas enquanto você realiza operações ultra-sensíveis com criptomoedas. Se hackearem uma AppVM que tem o WhatsApp para vendas no seu trabalho, com ataques de zero-click (muito comuns no WhatsApp), e conseguirem explorar o hypervisor, suas Qubes com criptomoedas podem ser comprometidas! Portanto, desligar o máximo de AppVMs que não fazem parte de uma atividade ultra-sensível é uma estratégia de hardening válida contra esse vetor de ataque!

Outro ponto forte é usar o Qubes para criptomoedas em HDDs e não em SSDs, pois em HDDs conseguimos realizar o secure erase com mais eficácia, usando métodos como zero fill e Guttman, enquanto as memórias flash costumam falhar na maioria dos métodos de secure erase, mesmo com softwares dos fabricantes!

Em HDD, infelizmente, mesmo com um processador de ultra qualidade e 100 gigas de memória RAM, o Qubes funciona de forma mais lenta por causa do HDD, pois ele consome muitos recursos, e um SSD atende melhor em velocidade! Todavia, vale a pena usar HDDs no Qubes pela segurança na sanitização!

Conclusão do Review sobre o Qubes OS

Qubes não faz milagres; ele é falho e você deve se prevenir com mais hardening e ter conhecimento para realizar isso! Para aniquilar os metadados de serial number do pendrive e HDs, não é automatizado, e o usuário precisa usar uma AppVM só para manipular arquivos e copiar ou receber arquivos para esse pendrive, apenas nessa AppVM especial 100% offline, onde o pendrive e HD não podem ter contato com as AppVMs online para evitar acessibilidade a esse metadado de serial number que o desanonimiza! O Xen Hypervisor para a estrutura do Qubes não faz isso automaticamente, mas consegue impedir automaticamente o acesso das AppVMs aos MACs reais das placas de rede e informações da BIOS pelo comando dmidecode, que contém um metadado crítico: o serial number das suas memórias RAM, conforme explicado antes!

Infelizmente, ele não tem a opção para rodar uma AppVM 100% na memória RAM, impedindo operações anti-forenses que requerem AppVMs 100% na RAM para aniquilar totalmente os rastros, como o Tails faz! Esse é o maior desfalque do Qubes para torná-lo uma máquina de guerra para anonimato robusto, mas tudo isso é viável com estratégias avançadas e operações manuais para usuários experientes, que não são abordadas neste artigo! Leigos terão dificuldades, mas é possível!

A estrutura do Qubes permite:

• Whonix com gateway isolado com TOR, que impede desanonimização por seu IP, pois o gateway é isolado e o invasor fica preso dentro da Qube que controla, não conseguindo acessar o Whonix para desativar o TOR e saber seu IP!
• Obliteração dos metadados de serial number de pendrive e HDs com métodos manuais ensinados neste artigo e outros metadados mencionados, impossibilitando o invasor de acessar esses dados para desanonimizá-lo!
• O invasor não consegue acesso aos metadados de hardware, como marca da placa-mãe, processador, serial number de RAM e MAC do fabricante da placa de rede, pois a AppVM que ele controla é PHV e tem o hardware paravirtualizado, o que oblitera esse acesso, impedindo a desanonimização por esses metadados!

Isso é uma vantagem absurda em anonimato, que não é possível em outros sistemas normais, devido à estrutura de virtualização e paravirtualização do Qubes! A estrutura do Qubes nos permite realizar tudo isso; tudo já está pronto, basta aprender e executar as técnicas e as ferramentas! Com essas principais vantagens que outros SOs não possibilitam, o Qubes se torna o SO mais seguro para anonimato, onde, mesmo que o usuário seja invadido, ele poderá continuar com sua identidade protegida e sua integridade física invulnerável, permanecendo anônimo mesmo após a invasão!

Em um sistema Linux normal, como Debian ou Tails, se o atacante obtiver privilégios de root, ele poderá acessar informações críticas!

Se o Linux ou Tails está sendo roteado pelo TOR via Ethernet com uma espécie de roteador TOR físico isolado, isso faria exatamente o que o Whonix faz, mas sem virtualização. Isso impediria a desanonimização por IP real, pois o atacante ficaria preso na máquina com Debian ou Tails e não conseguiria saber o IP, certo?

Negativo! Infelizmente, a falta de virtualização e paravirtualização de hardware permitirá acesso a metadados que desanonimizará o usuário!

No Tails, saberá o serial number do pendrive que o Tails está usando para operar aquele que você conectou no pendrive para dar boot! No Debian, saberá o serial number do HD ou SSD que contém o Debian instalado, permitindo que o sistema esteja operante! Saberá o serial number de qualquer pendrive ou HD externo conectado no Tails ou Debian e até conseguirá acessar o histórico de todos os que foram conectados durante um tempo, dependendo da configuração do registro desses logs, tanto no Tails quanto no Debian!

Se o atacante obtiver privilégios de root e controle total do Tails ou Debian, ele poderá acessar os dados de hardware do real MAC address e descobrir o MAC do fabricante real da sua placa de rede, tanto do Qubes quanto do Tails! Ele poderá identificar metadados de marca e modelo da placa-mãe, processador, e outros metadados, além de saber o serial number e part number das memórias RAM que o sistema está utilizando, via sudo dmidecode!

Tudo isso desanonimizará você se o atacante for um agente governamental, que poderá usar esses dados para investigá-lo e desanonimizá-lo com precisão! Por isso, usar sistemas normais que não utilizam uma estrutura igual ou similar à do Qubes permite a sua desanonimização completa por meio desses metadados!

Esse artigo foi escrito por leandroibov em 4 de outubro de 2025. Seu desejo é que isso se propague para conscientizar as pessoas!

Tutoriais avançados sobre Qubes OS: Clique aqui!

Qubes OS Espectro Proibido: Clique aqui!