Серверы и VDS

Первые 10 минут с новым сервером: что сделать сразу, чтобы потом не было мучительно больно

Эдгар Косулин 7 мин чтения

Содержание

Окей, ситуация знакомая. Ты только что нажал заветную кнопку «Create» у своего облачного провайдера, тебе прилетел свеженький IP-адрес, рутовый пароль в письме, и вот он, твой новый VPS, чистенький, как первый снег. Сервер дышит, пингуется, манит.

И тут есть два пути.

Путь первый: ты заходишь, ставишь свой проект, всё работает, ты счастлив, идёшь спать. А через недельку обнаруживаешь, что твой сервер уже месяц как чужой, грузит процессор на 100%, рассылает спам и состоит в каком-то ботнете, о котором ты узнаёшь из гневного письма от хостера.

Путь второй: ты тратишь десять минут в самом начале, и потом живёшь долго и счастливо.

Давай по второму пути, ладно? Погнали.


Минута 0: заходим и не паникуем

Первым делом заходим по SSH. Скорее всего, у тебя есть рутовый пароль из письма:

ssh root@ВАШ_IP

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


Минута 1: обновляем всё, что движется

Образ, из которого подняли твой сервер, почти наверняка собран не вчера. А значит, в нём уже есть пакеты с известными дырами, которые добрые люди давно нашли и которыми не очень добрые люди давно пользуются.

apt update && apt upgrade -y

(Если у тебя не Debian/Ubuntu, а какая-нибудь Alma/Rocky/CentOS, там будет dnf upgrade -y, и ты, скорее всего, и сам это знаешь.)

Пока оно качается и ставится, налей чаю. Это самая скучная минута, дальше будет веселее.


Минута 2: заводим себе человеческого юзера

Сидеть под рутом - это как ходить по дому с включённой бензопилой. Вроде удобно, всё рубится с полтычка, но одно неловкое движение, и ты уже без ноги (читай: без файловой системы, потому что rm -rf с правами рута не задаёт лишних вопросов).

Заводим нормального пользователя:

adduser anton

Подставь своё имя, конечно, если ты не Антон. Тебя попросят пароль и кучу необязательных вопросов про «полное имя» и «номер комнаты»: на всё это можно жать Enter, никому твоя комната не интересна.

Теперь дадим этому юзеру право становиться рутом по требованию (через sudo), чтобы он мог делать важные дела, но не ходил с бензопилой постоянно:

usermod -aG sudo anton

На RPM-системах группа называется wheel, а не sudo, имей в виду.


Минута 3-4: SSH-ключи, или как перестать вводить пароли

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

Если у тебя ещё нет ключа, на своём компьютере (не на сервере!) делаешь:

ssh-keygen -t ed25519 -C "anton@ноутбук"

ed25519 - это современный, быстрый и компактный тип ключа. Бери его, не прогадаешь. Жмёшь Enter на все вопросы (можно задать пароль на ключ, это плюс к безопасности, но дело вкуса).

Теперь закидываем публичную часть ключа на сервер. Самый простой способ: ssh-copy-id:

ssh-copy-id anton@ВАШ_IP

Эта команда сама создаст нужные папки, проставит правильные права и положит твой публичный ключ куда надо. Если ssh-copy-id у тебя нет (привет, пользователи Windows), ключ можно скопировать руками: содержимое файла ~/.ssh/id_ed25519.pub нужно добавить строкой в ~/.ssh/authorized_keys на сервере, под нужным юзером.

Проверяем, что заходит по ключу:

ssh anton@ВАШ_IP

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


Минута 5-6: закручиваем гайки в SSH

Открываем конфиг (через sudo, потому что мы теперь приличные люди):

sudo nano /etc/ssh/sshd_config

Находим и приводим к такому виду несколько строк (они могут быть закомментированы решёткой, раскомментируй):

PermitRootLogin no
PasswordAuthentication no

Что мы сделали:

  • PermitRootLogin no: теперь напрямую рутом зайти нельзя. Все боты мира, которые круглосуточно долбятся в root с паролем 123456, идут лесом.
  • PasswordAuthentication no: заходить можно только по ключу. Никаких паролей. Брутфорс окончательно теряет смысл.

Сохраняем (в nano это Ctrl+O, потом Enter, потом Ctrl+X) и перезапускаем SSH:

sudo systemctl restart ssh

⚠️ Момент истины. Помнишь то окно, которое я просил не закрывать? Открой новое окно терминала и попробуй зайти заново: ssh anton@ВАШ_IP. Если зашёл, отлично, всё работает, старое окно можно отпускать. Если не зашёл, у тебя всё ещё есть живая сессия в старом окне, в которой можно спокойно откатить настройки и разобраться, что пошло не так. Вот почему мы не закрывали то окно. Я же говорил.

Кстати, про смену стандартного порта 22 на какой-нибудь 2222 споры не утихают. Это не «безопасность», это «гигиена логов»: боты перестанут засорять тебе журнал бесконечными попытками входа. Реальной защиты это не даёт (порт сканируется за секунды), но логи чище. Хочешь, меняй (Port 2222 в том же конфиге), не хочешь, забей, это не обязательно.


Минута 7: ставим файрвол и закрываем лишнее

По умолчанию у сервера могут быть открыты порты, о которых ты даже не подозреваешь. Давай решать, кого пускать, а кого нет. На Ubuntu/Debian проще всего через ufw (Uncomplicated Firewall, он и правда uncomplicated):

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

Что тут происходит по-человечески: всё входящее по умолчанию запрещаем, всё исходящее разрешаем, и аккуратно проделываем дырочку для SSH, чтобы самим не остаться снаружи (опять же, не запри себя!).

Если меняли порт SSH на 2222, тогда вместо allow OpenSSH пиши sudo ufw allow 2222/tcp, иначе будет грустно.

Поднимаешь веб-сервер? Добавь, что нужно:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Проверить, что в итоге открыто:

sudo ufw status

Минута 8: fail2ban, вышибала на входе

Даже с ключами и файрволом в логи будут ломиться боты. fail2ban - это такой автоматический вышибала: следит за логами, видит, что с какого-то IP третий раз подряд лезут с кривыми кредами, и просто банит этот IP на время. Тихо, без скандалов.

sudo apt install fail2ban -y

Приятная новость: для SSH он начинает работать практически из коробки, дефолтных настроек на старте хватает. Хочешь потюнить, копируешь /etc/fail2ban/jail.conf в /etc/fail2ban/jail.local и крутишь там (править .conf напрямую не надо, его перезапишет обновление). Но для «первых десяти минут» достаточно просто поставить, он уже работает.


Минута 9: автоматические обновления безопасности

Ты же не будешь каждый день заходить и делать apt upgrade вручную, давай честно. А дырки в софте находят постоянно. Решение: пусть сервер сам подтягивает обновления безопасности, пока ты спишь:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

В появившемся диалоге выбираешь «Yes». Всё, теперь критические патчи прилетают автоматом, и ты не превращаешься в лёгкую мишень из-за того, что забыл обновиться.

Маленькая оговорка: на боевых проде-серверах автообновления иногда отключают и катят патчи по расписанию вручную, чтобы какое-нибудь обновление внезапно не уронило сервис посреди ночи. Но для личного сервера, пет-проекта или чего-то некритичного автообновления безопасности это чистое добро.


Минута 10: мелочи, которые потом сэкономят тебе нервы

Осталась минута, добьём по-быстрому пару приятных штук.

Часовой пояс. Чтобы логи были в твоём времени, а не в UTC, и ты не считал в уме каждый раз:

sudo timedatectl set-timezone Europe/Moscow

(Подставь свой, список: timedatectl list-timezones.)

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

sudo hostnamectl set-hostname my-cool-server

Swap-файл, если у сервера мало RAM (привет, дешёвые VPS на 1 ГБ). Когда память кончается, swap не даёт всему упасть с гордым Out of memory:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Последняя строка добавляет swap в /etc/fstab, чтобы он включался сам после перезагрузки, а не только сейчас.


Всё, время вышло. Что в итоге?

За десять минут ты:

  • обновил систему и включил автообновления безопасности;
  • завёл человеческого юзера и слез с рута;
  • настроил вход по SSH-ключу и выключил пароли с рутовым логином;
  • поднял файрвол и пускаешь только то, что нужно;
  • посадил на входе fail2ban;
  • навёл порядок со временем, именем и памятью.

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

А главное: ты сделал это сразу, на чистом сервере, пока на нём ничего нет и не страшно что-нибудь сломать. Потому что делать это потом, на работающем проде, с пользователями и данными, вот это и есть то самое «мучительно больно» из заголовка.

Десять минут сейчас. Или бессонная ночь и письмо от хостера потом. Выбор, как говорится, очевиден.

Ну что, погнали деплоить? 🚀

Безопасность

Поделиться: Telegram ВКонтакте

Новые статьи и разборы — в канале Siteko: Telegram MAX

Подписчикам: +30 дней к пробному хостингу, клиентам: +150 ₽ на баланс

Пошаговые инструкции по нашим услугам — в базе знаний

Ещё по теме

PTR-запись принадлежит IP-адресу, а не домену, поэтому в DNS домена её не добавить. Кому писать, что проверить до письма и как убедиться, что всё сошлось.

«Свой сервер с нуля», часть 13

Сервер магазина пропал целиком. Как мы сделали резерв с репликой базы, почему облачный балансировщик не подошёл и что стоит проверить у себя.

«Сервер в бою», часть 15

Серверы и VDS 8 мин чтения

Переезд на другой VPS без даунтайма: чек-лист миграции

Поводов переехать у VPS-владельца за жизнь накапливается достаточно: у соседнего провайдера вдвое дешевле и втрое быстрее диски; старый тариф стал тесен; провайдер начал чудить; или (помните шестую статью?) вы выбрали «путь Б»: вместо release-upgrade на живую поднять свежую систему рядом. Повод есть...

«Сервер в бою», часть 14