Как безопасно настроить VPS-сервер и защитить сайт, бот и веб-приложение

С необходимостью запуска кода на сервере сегодня сталкиваются далеко не только профессиональные айтишники. В наше время популярна разработка через ИИ (Claude, Gemini, ChatGPT и др.). Любой человек с идеей и доступом к моделям может быстро сгенерировать работающий код. Проблема в том, что люди зачастую слабо представляют, какие базовые уязвимости тащит за собой сгенерированный проект.

На стадии деплоя безопасность критична. Ниже мы разберём, как настраивать сервер и проверять код на наличие самых базовых уязвимостей на примере бота и сайта.

А в самом конце покажем, как безопасно развернуть код совсем без настройки сервера, воспользовавшись PaaS-облаком Amvera. Где можно просто привязать GitHub репозиторий (или закинуть файлы в интерфейсе) и сервис сам все запустит и настроит.

Безопасная настройка сервера

Для начала нам нужно войти на сервер. После покупки VPS провайдер пришлёт вам на почту (или покажет в личном кабинете) заветные данные для доступа. Обычно это три строчки:

IP-адрес сервера (например, 192.168.1.50);

имя пользователя (для Linux по умолчанию это почти всегда root);

пароль (длинный набор случайных символов).

Поскольку графического стола у сервера нет, мы будем подключаться через безопасный протокол SSH (Secure Shell).

Шаг 1. Открываем терминал. Если у вас Windows 10/11: нажмите Win + R, введите cmd и нажмите Enter. Откроется стандартная командная строка. Никаких сторонних программ вроде PuTTY скачивать больше не нужно. Если у вас macOS: нажмите Cmd + Пробел, введите слово «Терминал» (Terminal) в поиске Spotlight и нажмите Enter. Если у вас Linux: откройте терминал привычным для себя способом.

Шаг 2. Вводим команду подключения. В терминале введите следующую команду, подставив IP-адрес своего сервера, и нажмите Enter:

Шаг 3. Проходим проверку безопасности. При самом первом подключении терминал выдаст предупреждение: The authenticity of host... can't be established. Are you sure you want to continue connecting? Не пугайтесь, сервер просто сообщает, что ваш компьютер видит его впервые. Наберите слово yes и нажмите Enter.

Шаг 4. Вводим пароль. Теперь сервер попросит пароль:

Важнейший момент для новичков: когда вы будете вводить или вставлять (через Ctrl+V или правый клик мыши) пароль, в терминале ничего не изменится. Не появятся ни звёздочки, ни точки, курсор останется на месте. Это базовая безопасность Linux, чтобы никто не подсмотрел длину вашего пароля. Просто вставьте его один раз и нажмите Enter.

Если всё сделано правильно, перед вами появится приветственный текст от Ubuntu и приглашение к вводу, оканчивающееся на значок # . Теперь вы внутри своего собственного сервера!

Подготовка сервера к безопасному деплою

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

Шаг 1. Обновление пакетного менеджера. В Windows программы скачивают через браузер, а на смартфонах — через App Store или Google Play. В Linux за это отвечает встроенный пакетный менеджер. В Ubuntu он называется APT (Advanced Package Tool). APT — это консольный менеджер пакетов. Пакет в Linux — это аналог установочного файла .exe или .msi. Пакетный менеджер сам знает, откуда безопасно скачать нужную программу, как её установить и какие дополнительные библиотеки для этого потребуются.

В любой непонятной ситуации на новом сервере первым делом обновляйте списки доступных пакетов и сами программы. Это закроет старые уязвимости и предотвратит ошибки несовместимости при установке библиотек. Выполните команду:

apt update — скачает свежие списки программ из репозиториев Ubuntu.

apt upgrade — обновит установленные в системе утилиты до актуальных версий. Флаг -y автоматически ответит «да» на все вопросы системы в процессе обновления.

Защита VPS сервера: вход по ключам и отключение root

Оставлять вход по обычному паролю опасно: хакерские боты непрерывно сканируют сеть и пытаются подобрать пароли к root-пользователям. Защитим сервер по стандарту: настроим вход по SSH-ключам, создадим обычного пользователя, а удалённый доступ для root заблокируем. Все действия по генерации делаются на вашем домашнем компьютере (выйдите из сервера командой exit или откройте новое окно терминала на ПК).

Шаг 1. Генерируем пару ключей на домашнем ПК. В терминале своего компьютера введите:

Утилита задаст два вопроса: куда сохранить ключ и нужно ли установить кодовую фразу. На оба вопроса просто нажимайте Enter. В папке .ssh вашего компьютера создадутся два файла: id_ed25519 (приватный ключ, ваш секрет) и id_ed25519.pub (публичный ключ, замок).

Шаг 2. Отправляем публичный ключ на сервер. Для macOS и Linux выполните одну команду:

Дальше надо просто ввести пароль от VPS, который вам дал провайдер.

Для Windows (вручную): выведите ключ на экран type %USERPROFILE%\.ssh\id_ed25519.pub и скопируйте строку. Зайдите на сервер по паролю, откройте файл ключей nano ~/.ssh/authorized_keys . Вставьте строку, нажмите Ctrl+O, Enter (сохранить) и Ctrl+X (выход). Убедитесь, что теперь при команде ssh root@ваш_IP_адрес вас пускает на сервер мгновенно без ввода пароля.

Дальше нужно сделать вход не от root. Выполните следующие команды на вашем VPS, подключившись к нему пока ещё под учётной записью root.

Создайте нового пользователя (замените username на любое желаемое имя):

Система попросит вас дважды ввести пароль для нового аккаунта.

Добавьте пользователя в группу администраторов — это позволит ему выполнять команды от имени суперпользователя через sudo:

Скопируйте ваш SSH-ключ новому пользователю, чтобы не потерять доступ по ключу:

Проверьте подключение: откройте новое окно терминала на вашем компьютере и попробуйте войти. Не закрывайте текущую сессию root, пока не убедитесь, что новый вход работает.

Отключите вход для root (опционально): если вход прошёл успешно, откройте файл /etc/ssh/sshd_config и установите запрет на прямое подключение root-пользователя, введя PermitRootLogin no . После этого перезапустите службу SSH: sudo systemctl restart ssh .

Защита от брутфорса с помощью Fail2ban

Даже если вход по паролю отключён, боты будут постоянно сканировать ваш SSH-порт. Это тратит ресурсы сервера и забивает логи. Утилита Fail2ban решает эту проблему: она анализирует логи в реальном времени и временно блокирует IP-адреса, которые ведут себя подозрительно.

Шаг 1. Установка утилиты. Установите Fail2ban из стандартного репозитория Ubuntu (команда выполняется под вашим новым пользователем с использованием sudo):

Шаг 2. Настройка конфигурации (создание jail.local). По умолчанию Fail2ban хранит настройки в файле /etc/fail2ban/jail.conf . Трогать его напрямую нельзя, так как при первом же обновлении программы все ваши изменения затрутся. Правильный подход в Linux — создать копию конфигурации с расширением .local:

Теперь откройте созданный файл в текстовом редакторе:

Шаг 3. Задаём правила блокировки. Пролистайте файл вниз до секции [DEFAULT] . Нам нужно найти и настроить три главных параметра, которые управляют логикой банов (если перед строкой стоит знак # , удалите его):

Давайте разберём, что значат эти цифры и как их лучше изменить новичку:

maxretry — количество разрешённых неудачных попыток авторизации подряд. Для безопасности стоит поставить в районе 3–5.

findtime — окно времени, в течение которого считаются эти неудачные попытки. Оставляем 10m (10 минут).

bantime — время, на которое бот отправляется в чёрный список. 10 минут (10m) маловато — боты вернутся снова. Лучше выставить 1d (1 день) или 1w (1 неделя), чтобы отвадить взломщиков надолго.

Шаг 4. Включаем защиту SSH. Найдите в файле секцию [sshd] . Убедитесь, что она выглядит следующим образом (если строки enabled = true нет, обязательно допишите её вручную сразу под заголовком):

Сохраните изменения (нажмите Ctrl + O, затем Enter) и выйдите из редактора (нажмите Ctrl + X).

Шаг 5. Запуск и проверка службы. Перезапустите Fail2ban, чтобы он применил новые правила, и добавьте его в автозапуск системы:

Чтобы убедиться, что защита от брутфорса работает, проверьте статус утилиты:

В выводе вы увидите список активных защитных зон (Jails). Там должно быть написано: Number of jail: 1 и Jail list: sshd .

Шпаргалка: полезные команды для работы с Fail2ban. Посмотреть, сколько ботов уже забанено прямо сейчас:

Вы удивитесь, но уже через пару часов в строке Banned IP list появятся первые десятки заблокированных адресов со всего мира. Как разбанить самого себя (если вы случайно трижды ошиблись паролем): если вы настраивали сервер с телефона или другого ПК и попали под горячую руку файрвола, зайдите со своего основного компьютера и введите:

Проверка кода на уязвимости (SAST) перед запуском

В современном вебе используется огромное количество языков программирования. Настроить сервер под каждый из них в рамках одной статьи невозможно, поэтому мы рассмотрим два полярных примера, которые покроют 90% задач новичка:

Telegram-бот на Python — пример классического скриптового (интерпретируемого) языка, который работает в фоне.

Полноценный веб-сайт — бэкенд напишем на компилируемом Go (Golang), базу данных сделаем на SQLite, а фронтенд развернём на чистом JavaScript (Pure JS) без тяжёлых фреймворков.

Но перед тем как отправлять файлы на сервер, код необходимо проверить на уязвимости, скрытые баги и забытые пароли. Этот этап называется статическим анализом (SAST). Давайте разберём, как проверить каждую часть нашего будущего стека.

Бот работает. Пишете ему 2+2*10 — отвечает 22. Красота, можно показывать друзьям. Только под капотом два жирных бага:

Уязвимость №1: Hardcoded credentials (зашитый токен). Токен бота — это пароль. С ним кто угодно может: читать всю переписку с вашим ботом, отвечать пользователям от его имени (привет, фишинг), забанить вас как владельца. Главная беда — вы, скорее всего, зальёте код на GitHub. Даже если репозиторий «приватный», его можно случайно сделать публичным, или вы случайно закоммитите токен раньше, чем сделаете репозиторий приватным. Сканеры утечек прочёсывают новые коммиты на GitHub за минуты. Токен утечёт раньше, чем вы допьёте кофе.

Уязвимость №2: eval() = RCE. Функция eval() берёт строку и выполняет её как Python-код. Вы ждёте 2+2. А злоумышленник пришлёт боту:

И ваш сервер скачает и запустит чужой скрипт. От имени того пользователя, под которым работает бот. Это и есть RCE — Remote Code Execution (удалённое выполнение кода). Что хакер сделает дальше: сольёт вашу БД, украдёт переменные окружения (а там, скорее всего, ещё и другие токены), поставит майнер, использует ваш сервер как прокси для атак на чужие сайты, сотрёт всё подчистую. Один eval() — и сервер больше не ваш.

Шаг 2. Запуск проверки (Bandit). Bandit — это статический анализатор для Python. Он не запускает код, а просто читает его и ищет паттерны опасных конструкций: eval, exec, pickle.loads, захардкоженные пароли, использование md5 для паролей и так далее.

Структура проекта:

Установка и запуск:

Грабли, на которые легко наступить. Если запустить просто bandit -r . , Bandit полезет внутрь venv/ и найдёт сотни «проблем» в коде сторонних библиотек (rich, httpx и т.д.). Это не ваш код, чинить его не нужно. Всегда исключайте venv/ флагом -x .

Что выведет терминал (реальный вывод на нашем коде):

Bandit чётко указал:

B105 означает, что на 4-й строке программы написан реальный пароль или секретный ключ. Это опасно. Если чужой человек увидит код, он может украсть этот секрет.

B307 — опасный eval() на 13-й строке (и даже подсказал замену — ast.literal_eval).

Шаг 3. Как НАДО делать. Чиним обе проблемы:

Что мы сделали и почему это сработало:

Токен — в переменной окружения. Он больше не лежит в коде. На сервере токен будет читаться из защищённого файла, который видит только root. В исходниках — пусто.

eval() заменён на собственный мини-интерпретатор. Мы парсим выражение в AST (абстрактное синтаксическое дерево) и обходим узлы сами. Разрешены только числа и базовые операции. Если хакер пришлёт import(‘os’).system(…), парсер увидит узел Call (вызов функции) — а его в белом списке нет → ValueError. Это и называется whitelist-подход: «разрешено только то, что в списке, всё остальное — запрещено».

Ограничение длины ввода. Защита от выражений вроде 9 9 9**9 — они валидны как арифметика, но считаются вечность и съедают всю память.

Запускаем Bandit ещё раз:

Получаем:

Всё чисто.

Код проверен и чист. Считаем, что у вас уже есть VPS, вы подключены к нему по SSH под своим пользователем (не root) и сервер защищён Fail2ban. Осталось доставить файлы и запустить бота так, чтобы он работал круглосуточно и сам перезапускался после перезагрузки сервера.

Шаг 1. Копируем файлы на сервер (scp). Утилита scp (secure copy) копирует файлы по тому же защищённому каналу, что и SSH. Команды выполняются на вашем домашнем компьютере:

Не заливайте папку venv/ на сервер. Она собрана под вашу операционную систему и на сервере просто не заработает. Вместо этого переносите файл requirements.txt и собирайте окружение заново уже на сервере.

Создайте файл requirements.txt рядом с main.py со списком зависимостей:

Проект перед отправкой выглядит так:

Отправьте файлы в домашнюю директорию на сервере:

Шаг 2. Подготавливаем окружение на сервере. Подключитесь к серверу:

Создадим отдельного системного пользователя без прав входа и собственную папку для бота, а затем перенесём туда файлы:

Почему отдельный пользователь: флаг --system создаёт служебный аккаунт без пароля и без возможности войти по SSH. Если бота взломают, атакующий получит права этого ограниченного пользователя, а не вашего аккаунта с sudo.

Собираем окружение и ставим зависимости прямо на сервере:

Шаг 3. Прячем токен в отдельный файл. Токен мы вынесли из кода — теперь надо где-то его хранить на сервере. Положим его в отдельный файл, который сможет читать только root:

Внутри напишите одну строку:

Ограничим права на файл, чтобы его мог читать только владелец (root):

Шаг 4. Создаём systemd-сервис. systemd — это «дирижёр» всех фоновых процессов в Linux. Он сам запустит бота при старте сервера, перезапустит при падении и будет писать логи. Создайте файл описания службы:

Содержимое файла:

Настройки усиления безопасности означают:

NoNewPrivileges=true — процесс никогда не сможет получить больше прав, чем у него есть (даже через sudo или SUID-бинарники).

PrivateTmp=true — у службы своя изолированная папка /tmp, чужие процессы её не видят.

ProtectSystem=full — системные папки (/usr, /boot, /etc) доступны только для чтения.

ProtectHome=true — бот не видит домашние папки пользователей.

Шаг 5. Запускаем. Перезагружаем systemd, включаем автозапуск и сразу стартуем бота:

С ботом всё, теперь переходим к сайту.

Безопасное развёртывание и настройка защиты сайта

Бот — это один файл и один процесс. С сайтом всё сложнее: есть веб-сервер, база данных, статика, зависимости разных версий. Чтобы всё это не превратилось в хаос «у меня на компе работало, а на сервере нет», используют Docker. В Docker приложение и все его зависимости упакованы в отдельную коробку (контейнер). Оно не конфликтует с другими программами на сервере. Образ собирается один раз и работает одинаково везде: на вашем ноутбуке, на сервере коллеги, в облаке.

Когда хочется не просто бота, а полноценный сайт с доменом и HTTPS, защита строится слоями. Каждый слой решает свою задачу:

DNS — это телефонная книга интернета. Люди помнят имена, а компьютеры общаются по IP-адресам (например, 192.0.2.10). DNS переводит одно в другое. Чтобы ваш домен указывал на сервер, нужно в панели регистратора домена добавить DNS-записи:

Имя (Host)

300

www

300

Запись типа A связывает имя с IPv4-адресом. Имя @ означает сам домен ( example.com ), а www — поддомен ( www.example.com ). TTL — это время кэширования записи в секундах; на время настройки удобно выставить небольшое значение (300), чтобы изменения применялись быстрее.

Проверить, куда ведёт домен, можно с домашнего компьютера:

Файрвол — это охранник на входе, который решает, какие порты открыты для мира. В Ubuntu удобно использовать UFW (Uncomplicated Firewall):

Если у вашего провайдера есть ещё и облачный файрвол (в панели управления), настройте и его по тем же правилам — получится двойная защита.

Nginx — это веб-сервер, который стоит перед вашим приложением и берёт на себя несколько ролей:

Принимает все запросы из интернета и перенаправляет их вашему приложению (reverse proxy).

Шифрует трафик по HTTPS, чтобы данные пользователей нельзя было перехватить.

Ограничивает частоту запросов (rate limit) и прячет технические детали от атакующих.

Конфигурация Nginx (положите её в /etc/nginx/sites-available/ example.com ):

Разберём ключевые строки:

return 301 https://…

весь HTTP-трафик принудительно перенаправляется на шифрованный HTTPS

limit_req_zone / limit_req

защита от наплыва запросов и простейших DDoS

proxy_pass http://127.0.0.1:8080

перенаправляет запросы вашему приложению на локальном порту

браузер запоминает, что сайт только по HTTPS

location ~ /.

закрывает доступ к .git, .env и другим скрытым файлам

Активируем конфиг и проверяем синтаксис:

Выпускаем бесплатный SSL-сертификат от Let’s Encrypt через certbot — он сам пропишет пути к сертификатам в конфиг Nginx:

Типичные ошибки с Nginx:

Забыли выполнить nginx -t перед перезагрузкой и выкатите сломанный конфиг, сайт ляжет.

Не убрали стандартный конфиг default. Он перехватывает запросы.

Не открыли порты 80 и 443 в файрволе. Certbot не сможет подтвердить домен.

Контейнер нужен, чтобы приложение работало в изоляции и, даже если его взломают, атакующий остался внутри коробки, а не получил весь сервер. Разберём Dockerfile для Go-приложения:

Разберём строки:

Две стадии (builder и рантайм)

в итоговый образ попадает только готовый бинарник, без исходников и компилятора

статичный бинарник, который работает без системных библиотек

distroless

образ без shell и утилит — атакующему нечего запускать внутри

USER nonroot

приложение работает не от root

Запускаем контейнер с ограничениями:

Разберём флаги:

-p 127.0.0.1:8080:8080

порт виден только локально (через Nginx), а не всему интернету

–read-only

файловая система контейнера только для чтения

–cap-drop=ALL

снимаем все привилегии ядра

–memory / --cpus

лимиты ресурсов, чтобы один контейнер не съел весь сервер

Типичная ошибка с Docker это запуск контейнер от root и без ограничений. Следовательно взлом приложения равен взлому сервера. Еще можно опубликовать на порту 0.0.0.0 вместо 127.0.0.1, и где торчит в интернет в обход Nginx. Есть и менее критичные ситуации, как использование тега latest с потерей контроля над версиями. Версию образа лучше зафиксировать.

Все предыдущие слои не помогут, если само приложение написано небрежно. Разберём шесть правил, которые закрывают большинство типовых дыр.

Правило №1. SQL-инъекции. Нужно всегда использовать плейсхолдеры. Никогда не склеивайте SQL-запрос со строкой, пришедшей от пользователя.

Плохо (уязвимо):

Хорошо (безопасно):

Представьте, что вы пишете бланк с пустым полем (плейсхолдер?). База сначала видит структуру запроса, а потом аккуратно вставляет ваше значение именно как данные, а не как часть команды. Чтобы ни ввёл пользователь, это останется просто текстом для поиска.

Правило №2. XSS - экранируйте вывод. Если вы показываете на странице текст, который ввёл пользователь, нельзя просто вставлять его в HTML. Иначе кто-то пришлёт <script> и выполнит свой код в браузерах других посетителей.

Опасный подход - ручная склейка HTML со строкой, на любом языке:

Go: fmt.Fprintf(w, "<div>%s</div>", userInput)

JS: el.innerHTML = userInput

Python: f"<div>{user_input}</div>"

PHP: echo "<div>$userInput</div>"

Безопасный подход - использовать шаблонизатор, который сам экранирует опасные символы. В Go это пакет html/template:

Не используйте для HTML пакет text/template. Он не экранирует вывод и не защищает от XSS. Только html/template.

Правило №3. Security-заголовки. Добавляйте заголовки (X-Content-Type-Options, X-Frame-Options и др.) на уровне Nginx или самого приложения. Они подсказывают браузеру, как себя вести, и закрывают целый класс атак.

Правило №4. Таймауты. Всегда выставляйте таймауты на чтение и запись у веб-сервера. Без них одно медленное соединение может висеть вечно и исчерпать ресурсы сервера.

Правило №5. Не показывайте полные ошибки пользователю. Полный текст ошибки (со стеком и путями) пишите только в лог. Пользователю показывайте нейтральное «Что-то пошло не так». Иначе вы сами подскажете атакующему версии библиотек и структуру проекта.

Правило №6. Ограничивайте размер входящих данных. Задавайте лимит на размер тела запроса (и на Nginx, и в приложении). Иначе кто-то загрузит файл на несколько гигабайт и забьёт диск или память.

То самое удобное решение без настройки сервера

Всё вышеописанное, это настройка сервера руками. Но есть путь проще, это PaaS-платформы, которые берут рутину на себя. Одна из таких - Amvera . Вот что сервис делает за вас:

Встроенная, бесплатная защита доменов сайтов.

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

Деплой через git push или через интерфейс. Достаточно загрузить код, сборка и запуск происходят автоматически.

HTTPS и SSL из коробки. Сертификаты выпускаются и продлеваются сами, без certbot и ручных настроек.

Управляемые базы данных. БД поднимается в один клик, резервные копии хранятся в трёх экземплярах.

Встроенный reverse proxy. Есть даже бесплатное проксирование OpenAI API, если вашему приложению это нужно.

Мы прошли путь от первых команд в терминале до полноценного защищённого сайта и телеграм-бота. Для автоматизации этих процессов можно использовать CI/CD-пайплайны, настроить собственный VPS. Главное, выстроить процесс так, чтобы вы могли сосредоточиться на логике приложения. Пишите безопасный код и пусть автоматика работает на вас!