Инструмент Дня
Новый сервер после установки открыт для всего мира: SSH слушает порт 22, вход под root разрешён, пароль часто приходит в письме от хостера. Сканеры находят такую машину за несколько часов. Три настройки — файрвол UFW, нестандартный порт SSH и sudo-пользователь вместо root — закрывают самый частый сценарий взлома и занимают меньше часа.
Порядок важен: сначала создайте рабочего пользователя и проверьте вход по ключу, потом меняйте порт, потом включайте файрвол. Каждый шаг проверяется из нового окна терминала — иначе можно запереть себя снаружи.
- Подойдёт: владельцам VPS на Ubuntu и Debian, которые впервые настраивают сервер.
- Инструменты: ufw, openssh-server, sudo — всё уже есть в системе.
Порядок, который не запирает снаружи
Все три настройки легко превратить в способ потерять собственный сервер. Причина одна: SSH — единственная дверь, а её меняют изнутри. Поэтому правило простое: сначала готовим новый вход, проверяем его в отдельном окне терминала и только потом закрываем старый. Никогда не выходим из единственной рабочей сессии, не убедившись, что новый вход работает.
Второе правило — одна правка за раз. Сначала пользователь, потом порт, потом файрвол. Если после шага вход перестал работать, понятно, что именно откатывать. При настройке «всё сразу» приходится разбираться вслепую, через консоль хостера, а она есть не у всех провайдеров.
Шаг 1. Рабочий пользователь вместо root
Вход под root опасен не сам по себе, а тем, что у него нет ограничений: любая ошибка в команде сразу бьёт по системе, а подбор пароля даёт атакующему всё. Рабочий пользователь с sudo решает обе проблемы: повседневная работа идёт с обычными правами, а повышение — по одной команде и с паролем.
- Создайте пользователя и дайте ему sudo:
adduser alex, затемusermod -aG sudo alex. - Скопируйте ключ:
rsync --archive --chown=alex:alex ~/.ssh /home/alex— так ключ, которым вы уже входите под root, появится у нового пользователя. - Проверьте вход в новом окне:
ssh alex@IP. Не закрывая старое окно, убедитесь, что видите приглашение и чтоsudo -vспрашивает пароль. - Только теперь запретите вход root: в
/etc/ssh/sshd_configпоставьтеPermitRootLogin noи перезапустите службу.
Заодно отключите вход по паролю — PasswordAuthentication no. Это самая важная строка из всех: пока пароль разрешён, любой бот может подбирать его круглосуточно. С ключом подбирать нечего, а брутфорс в логах исчезает почти полностью. Перед изменением проверьте, что ключ действительно работает, иначе останется только консоль хостера.
Шаг 2. Нестандартный порт SSH
Порт 22 сканируют все кому не лень: в первые сутки на новом сервере в логах появляются тысячи попыток входа. Перенос на другой порт не делает сервер неприступным, но убирает фоновый шум и снижает нагрузку на журналы и fail2ban.
- Выберите порт из диапазона 1024–65535, например 2222, и проверьте, что он свободен.
- В
/etc/ssh/sshd_configдобавьте строкуPort 2222. Не удаляйте строку с портом 22 сразу — на время проверки лучше оставить оба. - Перезапустите SSH и проверьте вход:
ssh -p 2222 alex@IP. - Убедившись, что новый порт работает, удалите строку с 22 из конфига и перезапустите службу ещё раз.
Если на сервере включён файрвол — а его мы включим на следующем шаге — новый порт нужно открыть до перезапуска SSH. Иначе получится неприятная комбинация: служба слушает 2222, а файрвол пускает только 22.
Шаг 3. Файрвол UFW: закрыто по умолчанию
UFW — простая обёртка над iptables, которая читается как обычный английский. Логика такая: запретить всё входящее, разрешить только нужное, исходящее не трогать. Для сервера с сайтом это обычно SSH, HTTP и HTTPS.
- Разрешите SSH на новом порту:
sudo ufw allow 2222/tcp. Это делается до включения файрвола — иначе доступ закроется вместе с ним. - Разрешите веб:
sudo ufw allow 80,443/tcp— если на сервере есть сайт. - Включите:
sudo ufw enable. Утилита предупредит о разрыве текущего соединения — это нормально, новая сессия уже разрешена. - Проверьте правила:
sudo ufw status verbose. В списке должны быть только те порты, которые действительно нужны.
Не открывайте «на всякий случай» базу данных, панель управления и порт 8080. Если сервис должен быть доступен только вам, лучше не открывать порт наружу, а ходить внутрь через SSH-туннель: ssh -L 8080:localhost:8080 -p 2222 alex@IP. Тогда сервис вообще не виден из интернета.
Что даёт каждая настройка
| Настройка | Что закрывает | Риск при ошибке |
|---|---|---|
| Ключи вместо пароля | Подбор пароля, слабые и повторно использованные пароли | Потеря ключа — вход только через консоль хостера |
| Запрет root | Полный доступ по одному паролю, ошибки с правами | Остаться без sudo-пользователя |
| Нестандартный порт | Фоновый брутфорс и шум сканеров | Забыть открыть порт в файрволе |
| UFW | Лишние открытые сервисы: базы, панели, отладка | Закрыть SSH вместе с включением |
Четыре ошибки, после которых сервер недоступен
- Включить UFW, не разрешив порт SSH. Самая частая. Правило добавляют до
ufw enable, а не после. - Поменять порт и закрыть старую сессию. Пока новая сессия не проверена, старую не трогают — она единственный путь назад.
- Отключить пароли до проверки ключа. Сначала
ssh alex@IPв новом окне, потом правка конфига. - Забыть про дополнительные сервисы. Если на сервере живёт панель на своём порту, после включения UFW она перестанет открываться — это не поломка, а незакрытое правило.
Чек-лист первого часа
- Создан sudo-пользователь, вход по ключу проверен в отдельном окне.
PasswordAuthentication noиPermitRootLogin noпрописаны, служба перезапущена.- SSH слушает новый порт, старый закрыт, вход проверен.
- UFW включён: открыты только SSH, 80 и 443.
ufw status verboseне показывает лишних портов.- Логи входа чистые: боты больше не стучатся в 22.
Вывод: базовая защита сервера — это не набор сложных инструментов, а порядок действий. Ключи вместо пароля, рабочий пользователь вместо root, файрвол с закрытой логикой по умолчанию и порт, который не сканируют первым делом. Час работы — и сервер перестаёт быть лёгкой добычей, а в логах остаются только те, кто знает адрес.
Частые вопросы
- Смена порта SSH — это реальная защита или только скрытность?
- Против целевой атаки порт не спасёт: того, кто целится именно в ваш сервер, скан портов не остановит. Но автоматические боты перебирают пароли в основном на стандартном порте 22, поэтому после переноса логи становятся чистыми, а нагрузка на fail2ban падает в разы. Настоящую защиту дают ключи, запрет паролей и запрет root — смена порта убирает шум.
- Что делать, если после настройки я не могу войти на сервер?
- У большинства хостеров есть веб-консоль (VNC), которая работает мимо SSH, — через неё можно открыть конфиг и откатить последнюю правку. Именно поэтому настройки меняют по одной: после каждого шага проверяют вход из нового терминала и только потом переходят к следующему. Если у провайдера консоли нет — сначала проверьте это до изменений.
- Нужно ли ставить fail2ban после этих трёх настроек?
- Желательно, но уже не критично: когда вход по паролю и под root запрещён, перебор становится бессмысленным — боту нечего подбирать. Fail2ban остаётся полезным для чистоты логов и защиты веб-панелей и почты, где парольная аутентификация всё ещё включена. Ставится одной командой и работает из коробки.