Мой первый VPS: Чек-лист по превращению «голой» машины в маленькую крепость (Часть 1)

Привет, Хабр! У каждого из нас бывает этот момент. Ты нажимаешь кнопку «Заказать», и вот он — твой первый, сияющий, свежеустановленный VPS. Ощущение, как будто получил ключи от собственной цифровой квартиры. Можно ставить что угодно, экспериментировать, запускать свои пет‑проекты... Но есть один нюанс.

Эта «квартира» сейчас стоит с дверью нараспашку посреди самого темного и опасного района интернета. И пока ты радуешься, к этой двери уже тянутся сотни автоматизированных ботов, чтобы проверить, не забыл ли ты закрыть замок.

Я сам прошел через это. Мой первый сервер прожил в «диком» виде около часа, прежде чем я заглянул в логи и увидел непрекращающийся поток попыток входа по SSH. Это было мое «приключение» — превратить уязвимый кусок железа в безопасное убежище. Я наступил на пару граблей, но в итоге собрал «сокровище» — этот чек‑лист, которым хочу поделиться с вами.

Это не исчерпывающее руководство по пентесту, а набор первых, самых важных шагов, которые отсекут 99% автоматических атак и дадут вам спокойно спать по ночам.

Тот самый момент, когда твоя «незначительная уязвимость» оказалась проходным двором.

Шаг 0: Входим на сервер

Первое, что мы делаем — заходим на наш свежий сервер под пользователем root и паролем, который прислал хостер.

ssh root@ВАШ_IP_АДРЕС

Это единственный раз, когда мы так делаем. Обещаю.

Шаг 1: Меняем замки на главной двери (Root)

Работать под root — это как ходить по минному полю с завязанными глазами. Одна опечатка в команде rm -rf — и прощай, сервер. Первым делом создадим надежный пароль для root (он нам еще понадобится для sudo) и немедленно выйдем из-под него.

Лайфхак: Никогда, слышите, никогда не работайте под root на постоянной основе. Это аксиома.

# Система сразу попросит вас сменить пароль. 
# Задайте что-то очень сложное и сохраните в менеджере паролей.
passwd

Шаг 2: Создаем личного помощника (пользователь с sudo)

Теперь создадим обычного пользователя, от имени которого мы и будем работать. Назовем его, например, admin.

# Создаем пользователя
adduser admin

# Даем ему права суперпользователя (добавляем в группу sudo)
usermod -aG sudo admin

Теперь мы можем выполнять команды от имени root, используя префикс sudo. Это гораздо безопаснее, так как система будет каждый раз спрашивать пароль вашего пользователя (admin), защищая от случайных деструктивных действий.

Шаг 3: Настраиваем VIP-вход (SSH по ключам)

Пароли — это зло. Их можно подобрать, перехватить, они могут утечь. SSH-ключи — наш стандарт де-факто. Это криптографическая пара: приватный ключ хранится у вас на компьютере, а публичный — на сервере. Подделать его практически невозможно.

На вашем локальном компьютере:

1. Если у вас еще нет ключа, генерируем: ssh-keygen (просто жмите Enter на все вопросы).

2. Копируем ваш публичный ключ на сервер.

# Эта команда скопирует ваш ~/.ssh/id_rsa.pub на сервер 
# и правильно положит его в нужный файл для пользователя admin
ssh-copy-id admin@ВАШ_IP_АДРЕС

Теперь на сервере (заходим уже под admin):
Открываем конфигурационный файл SSH:

sudo nano /etc/ssh/sshd_config

Ищем и меняем эти строки. Это самые важные изменения в статье:

# Запрещаем вход под root вообще. Это маст-хэв!
PermitRootLogin no

# Разрешаем вход только по ключам, отключая пароли.
PasswordAuthentication no

# Можно еще сменить стандартный порт 22 на любой другой (например, 2222)
# Это не столько безопасность, сколько "гигиена" - боты перестанут долбиться в логи.
# Port 2222

Важно! Прежде чем перезагружать SSH, откройте новое окно терминала и попробуйте зайти по ключу: ssh admin@ВАШ_IP_АДРЕС. Если пустило — вы все сделали правильно!

Теперь применяем изменения:

sudo systemctl restart ssh

Шаг 4: Ставим простого, но злого охранника (Файрвол UFW)

UFW (Uncomplicated Firewall) — это простой интерфейс для управления файрволом. Наша задача — закрыть все порты, кроме тех, что нам нужны.

# Разрешаем подключения по нашему новому SSH порту (если меняли)
sudo ufw allow 2222/tcp # Или 22, если не меняли

# Разрешаем стандартные веб-порты, если планируется сайт
sudo ufw allow 'Nginx Full' # или 'Apache Full'

# И включаем нашего охранника
sudo ufw enable

# Проверяем статус
sudo ufw status

Теперь на ваш сервер можно попасть только через разрешенные «двери».

Шаг 5: Нанимаем вышибалу (Fail2ban)

Fail2ban — это утилита, которая сканирует логи и автоматически банит IP-адреса, с которых идет слишком много неудачных попыток входа. Даже если у нас отключены пароли, боты все равно будут «стучаться». Зачем нам этот мусор в логах?

# Установка простая
sudo apt update
sudo apt install fail2ban

# Запускаем и добавляем в автозагрузку
sudo systemctl start fail2ban
sudo systemctl enable fail2ban

И все! Fail2ban уже работает «из коробки» с настройками по умолчанию для SSH. Он будет защищать ваш сервер, пока вы пьете кофе.

Список заблокированных IP-адресов в Fail2ban.

Крепость построена, но что насчет шпионов?

Правило честного компромисса: Конечно, это лишь базовый набор. Для серьезного продакшена я бы еще настроил автоматические обновления безопасности и многое другое. Но эти шаги — тот самый фундамент, без которого строить что-либо дальше просто опасно. Это как ремень безопасности в машине — не гарантирует 100% защиты, но критически повышает ваши шансы.

Мы построили стены (UFW), поставили вышибалу на входе (Fail2ban) и создали VIP-пропуска (SSH-ключи). Наша крепость защищена от лобовых атак. Но что, если враг уже внутри? Или пытается проникнуть не через парадную дверь, а через хитрые, замаскированные запросы?

В следующей части мы поднимем планку: установим и настроим Maltrail — систему обнаружения вредоносного трафика. Это наш личный «датчик движения», который будет ловить подозрительную активность внутри периметра, о котором не догадываются известные нам UFW и Fail2ban.

А теперь вопрос к вам, сообщество: Какие еще обязательные первые шаги вы делаете на свежеустановленном сервере? Какие грабли собирали вы, забыв про какой-нибудь из этих пунктов? Давайте делиться опытом в комментариях