Как защитить SSH за 15 минут

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

Хорошая новость: базовая защита занимает около пятнадцати минут и закрывает подавляющее большинство таких попыток.

Кто и зачем стучится в ваш сервер

Это почти никогда не целенаправленная атака. По интернету постоянно ходят автоматические сканеры: перебирают адреса, находят открытый SSH и начинают пробовать распространённые пары логин-пароль — root и root, admin и 123456, и ещё несколько тысяч вариантов из готовых списков.

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

Пять действий, которые закрывают вопрос

1. Отключить вход по паролю, перейти на ключи. Ключ — это пара файлов: закрытый остаётся у вас, открытый кладётся на сервер. Подобрать его перебором невозможно. Это самая важная мера из всех: она одна убирает целый класс атак.

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

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

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

4. Сменить порт — но без иллюзий. Перенос SSH с 22-го порта на нестандартный убирает массовый автоматический шум, но не защищает от того, кто ищет именно вас: порт находится сканированием за минуту. Мера полезная, но косметическая. Вместо ключей её делать нельзя, вместе с ключами — можно.

5. Ограничить доступ по адресам, если это применимо. Если вы всегда подключаетесь из офиса или через собственный VPN, разрешите SSH только с этих адресов, а остальным закройте на уровне брандмауэра. Это самая сильная мера после ключей — и самая неудобная, если адрес динамический или вы работаете из разных мест.

Чего делать не стоит

  • Не отключайте пароли, не проверив ключ. Самая частая причина потери доступа к собственному серверу. Держите вторую сессию открытой, пока проверяете первую.
  • Не храните закрытый ключ без парольной фразы на компьютере, к которому есть доступ у других. Такой ключ равен паролю, записанному на бумажке под клавиатурой.
  • Не раздавайте один ключ на всех. У каждого человека свой — тогда доступ можно отозвать точечно, когда человек уходит из проекта.
  • Не рассчитывайте на то, что «нас никто не знает». Сканерам совершенно всё равно, что у вас за проект и сколько у него посетителей.

Как проверить, что помогло

Через день загляните в журнал авторизаций — в Debian и Ubuntu это /var/log/auth.log. Картина должна измениться: попытки входа никуда не денутся, но будут обрываться сразу, потому что сервер больше не предлагает подбирать пароль. Плюс в списке блокировок fail2ban появятся забаненные адреса — значит, он работает.

Заодно убедитесь в двух вещах: вход по ключу работает с того компьютера, с которого вы обычно подключаетесь, и у вас остался запасной способ попасть на сервер. Обычно это аварийная консоль в панели хостинга — стоит проверить заранее, что вы знаете, где она и как в неё войти.

Коротко

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

Если сервер уже работает, а что там настроено — вопрос открытый, это первое, на что мы смотрим при разборе инфраструктуры.