Как проверить безопасность скриптов Python (.py) перед запуском - PEFile — Безопасность и технологии простым языком

Ты скачал скрипт с GitHub, получил его от коллеги или нашёл в чате — и хочешь запустить. Но что, если в нём есть вредоносный код? Он может стереть файлы, украсть пароли, подключиться к вашему серверу или превратить ваш компьютер в зомби-узел для ботнета. И всё это — без каких-либо предупреждений. Python-скрипты выглядят безобидно: чистый код, понятные строки. Но именно это и делает их опасными.

Я не говорю, что все сторонние скрипты — вредные. Но я работал с командами, которые теряли данные из-за того, что кто-то запустил «просто один скрипт». Потом — часы восстановления, увольнения, разборы. Не хочешь, чтобы это случилось с тобой. Вот как проверять скрипты перед запуском — шаг за шагом, без паники, но с умом.

Содержание

1. Не запускай скрипт, пока не прочитаешь его
2. Запускай в изолированной среде
Вариант 1: Docker (быстро и надёжно)
Вариант 2: Виртуальное окружение + ограничение прав
3. Смотри на поведение, а не на код
4. Сравнивай поведение с ожидаемым
5. Таблица: что проверять и как
6. Частые ошибки
7. Что выбрать в зависимости от ситуации
8. Как лучше сделать — практические рекомендации
9. Итог: что делать прямо сейчас

1. Не запускай скрипт, пока не прочитаешь его

Самая частая ошибка: «Он же работает — я просто запущу». Нет. Не работает. Он выполняется. А это разница как между «открываю книгу» и «выполняю инструкции из книги».

Открой файл в текстовом редакторе — не в IDE, не в Jupyter, а в простом редакторе: Notepad++, VS Code, Sublime Text. Прокрути его целиком. Ищи:

import os, subprocess, sys, urllib, requests — если это не явно нужно для задачи (например, скачивание файла), это красный флаг.
exec(), eval(), compile() — почти всегда вредоносно. Эти функции выполняют код как строку. Если ты видишь их в чужом скрипте — остановись.
open(…, ‘w’) или os.remove() — если скрипт пишет или удаляет файлы без явного объяснения — это тревога.
Попытки подключиться к внешним адресам: requests.get('http://185.123.45.67/api') — это не API от GitHub, это возможный C2-сервер (command & control).
Скрытые строки в base64: exec(base64.b64decode('aGVsbG8gd29ybGQ=')) — это код, скрытый под видом «закодированной строки». Декодируй его вручную — и посмотри, что там.

Если скрипт больше 50 строк — и ты не понимаешь, что он делает — не запускай. Даже если он «от известного автора».

2. Запускай в изолированной среде

Если ты всё-таки решил проверить скрипт — не запускай его на своём основном компьютере. Даже если он «выглядит безопасно».

Создай изолированную среду — это не про виртуальные машины (хотя они тоже подходят), а про простой, быстрый способ отключить скрипт от твоей системы.

Вариант 1: Docker (быстро и надёжно)

Установи Docker (если ещё не установлен). Создай пустой контейнер и запусти скрипт в нём:

docker run -it --rm -v "$(pwd)":/app python:3.11-slim python /app/script.py

Что это даёт?

Скрипт не имеет доступа к твоим файлам — только к той папке, которую ты явно смонтировал.
Он не может подключиться к твоей сети, кроме как через интернет (если ты не разрешишь).
Если он что-то сломает — просто закрой контейнер. Всё исчезнет.

Вариант 2: Виртуальное окружение + ограничение прав

Если Docker не подходит — используй Python-виртуальное окружение, но запускай его от имени пользователя без прав администратора:

Создай виртуальное окружение: python -m venv sandbox
Активируй его: sandbox\Scripts\activate (Windows) или source sandbox/bin/activate (Linux/macOS)
Установи только нужные пакеты: pip install requests — но только те, что реально нужны.
Запускай скрипт из этого окружения.

Плюс: ты увидишь, какие зависимости скрипт пытается установить. Если он хочет установить pycryptodome и paramiko — возможно, он шифрует данные. Если он хочет psutil и pyautogui — он может читать твои окна и нажимать кнопки. Это не всегда вредно, но требует внимания.

3. Смотри на поведение, а не на код

Код может быть запутанным, но поведение — нет. Запусти скрипт в изолированной среде и смотри, что он делает.

Используй инструменты мониторинга:

На Windows: открой Диспетчер задач → вкладка «Процессы» → смотри, какие файлы создаются, какие порты открываются.
На Linux/macOS: запусти в терминале htop или lsof -i -p <PID>, чтобы увидеть сетевые соединения.
Все ОС: запусти скрипт с логированием: python script.py 2>&1 | tee log.txt — всё, что он выводит в консоль, сохранится в файл.

Если скрипт начинает:

создавать файлы в /tmp, C:\Users\...\AppData\Local\Temp — это нормально, если он временные данные пишет.
открывать порт 4444, 5555, 8080 — это подозрительно. Это типичные порты для обратных соединений.
писать в файл ~/.bashrc или registry — это попытка сделать себя постоянным.

Если ты видишь, что скрипт подключается к http://192.168.1.100:8080 — это твой же локальный адрес. Возможно, он пытается «позвонить» другому устройству в твоей сети. Это плохо.

4. Сравнивай поведение с ожидаемым

Скрипт должен делать то, что заявлено. Если он называется download_images.py — он должен скачивать изображения. Не должен:

читать твои файлы из Documents
отправлять данные на https://api.example.com/track
записывать в файл keylog.txt

Если он делает больше — это не «дополнительная функция». Это угроза.

5. Таблица: что проверять и как

Что проверять	Как проверить	Когда опасно	Когда нормально
Использование `exec()` или `eval()`	Открой файл, найди строки с этими функциями	Если есть — почти всегда вредоносно	Редко: в учебных скриптах или генераторах конфигов (если ты сам их пишешь)
Подключение к внешним IP/доменам	`lsof -i` или `netstat -an` во время запуска	Если адрес неизвестен, не принадлежит компании, не указан в документации	Скрипт скачивает данные с GitHub, PyPI, или официального API
Доступ к файлам вне папки скрипта	Запусти с мониторингом файловой системы: `strace -e trace=openat python script.py` (Linux)	Если читает `~/.ssh/id_rsa`, `C:\Users\...\Passwords.txt`	Читает `config.json` в той же папке
Установка новых пакетов	Смотри, что пишет `pip install` при запуске	Устанавливает пакеты, которых не было в `requirements.txt`	Устанавливает только те, что перечислены в `requirements.txt`
Скрытый код в base64	Декодируй строку: `echo "aGVsbG8=" \| base64 --decode`	Если декодированная строка — это `exec(...)` или `import os; os.system(...)`	Если это просто строка с данными, например, API-ключ (но и его лучше не хранить в коде)

6. Частые ошибки

«Он же с GitHub — всё в порядке». Многие вредоносные скрипты публикуются как «полезные инструменты». Их клонируют, добавляют вредоносный код, и люди качают.
«Я запустил в виртуалке — всё ок». Если виртуалка подключена к твоей сети, скрипт может атаковать другие устройства. Используй изолированную сеть или Docker без сетевого доступа.
«Я просто запущу — если ничего не произойдёт, значит, безопасно». Вредоносный код может ждать 3 дня, чтобы сработать. Или запускать себя при старте системы.
«Я удалил файл — и всё». Скрипт может уже создать автозагрузку, изменить переменные окружения, установить фоновый сервис. Удаление файла — не решение.
«Я не админ — мне не страшно». Даже обычный пользователь может запустить скрипт, который крадёт файлы, пароли из браузера, или шифрует документы.

7. Что выбрать в зависимости от ситуации

Если скрипт от коллеги, который тебе доверяешь, и он маленький (меньше 30 строк) — открой его, прочитай, запусти в виртуальном окружении. Не в Docker — просто python -m venv и запуск.
Если скрипт скачан с GitHub, но не от официального репозитория — не запускай. Найди альтернативу. Или проверь через Docker с отключённым интернетом: docker run --network none ...
Если скрипт большой (100+ строк) и ты не понимаешь, что он делает — не запускай. Найди другой способ. Спроси у автора, что он делает. Если не отвечает — не рискуй.
Если скрипт должен работать в продакшене — проверь его через статический анализ (например, Bandit), запусти в изолированной среде с мониторингом, протестируй на тестовых данных. Не используй «чужой» код в продакшене без аудита.
Если ты не уверен — но хочешь попробовать — запусти в Docker с флагом --network none и -v /tmp:/tmp. Это изолирует его от сети и ограничит доступ к файлам.

8. Как лучше сделать — практические рекомендации

Всегда читай код перед запуском. Даже если он «от друга».
Используй Docker для тестирования: docker run --rm --network none -v "$(pwd)":/app python:3.11-slim python /app/script.py — это самый простой способ изолировать скрипт.
Не запускай скрипты с exec(), eval(), compile() — если ты не понимаешь, зачем они там.
Если скрипт требует установки пакетов — проверь requirements.txt. Если его нет — это тревожный знак.
Не используй скрипты, которые «самообновляются» или скачивают код с интернета во время работы — это почти всегда вредоносно.
Для регулярного использования — перепиши скрипт сам. Это займёт время, но ты будешь знать, что в нём есть.

9. Итог: что делать прямо сейчас

Если ты держишь в руках .py-файл и хочешь его запустить — сделай так:

Открой файл в текстовом редакторе. Прокрути до конца. Ищи exec, eval, subprocess, requests.get, open(..., 'w').
Если что-то подозрительное — не запускай. Найди альтернативу.
Если всё выглядит нормально — создай пустую папку, в ней: python -m venv sandbox, активируй, установи только нужные пакеты, запусти скрипт.
Смотри, что делает скрипт: создаёт ли файлы, подключается ли к сети, меняет ли системные настройки.
Если ведёт себя странно — останови его. Удали папку sandbox.
Если всё ок — скопируй нужные результаты, удали скрипт и виртуальное окружение.

Не запускай код, который не понимаешь. Даже если он красивый. Даже если он «быстро решает проблему». Лучше потратить 20 минут на проверку, чем 2 дня на восстановление системы.

Информация в этой статье носит ознакомительный характер. При работе с кодом, особенно в производственной среде, рекомендуется привлекать специалиста по информационной безопасности.