5 рекомендаций по защите SSH-подключения к вашему серверу

ВАЖНО! Рекомендации ниже — для тех, кто умеет настраивать вход по SSH и двухфакторную аутентификацию и понимает, о чём идёт речь в статье. Если вы не умеете это делать, сначала изучите документацию по теме. Иначе вы рискуете не защитить SSH-доступ к сервер, а навредить себе.

Есть и другой способ получить легко масштабируемый сервер, который легко управляется, имеет высокий уровень защиты и доступности: арендовать облачные сервера Cloud4Y. Госкорпорации, бизнес, НКО — провайдер успешно предоставляет инфраструктуру для работы самых разных компаний. Подробности — у менеджеров Cloud4Y.

Смена порта SSH

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

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

Смена номера порта выполняется в файле конфигурации /etc/ssh/sshd_config. Укажите там другой порт и сохраните файл. Уровень безопасности повышен.

Отключение входа по паролю

У каждого пользователя по умолчанию имеется пароль для подключения через SSH. Используя пару логин/пароль и зная нужный IP-адрес, можно без труда войти в систему. Причём это может сделать кто угодно. Если пароль неизвестен — не проблема. SSH не устанавливает лимит на количество попыток авторизации. Если три раза неверно ввести пароль, пользователю будет отказано в подключении. Но продолжать попытки залогиниться не помешает никто.

Стандартные настройки SSH не предусматривают возможности исправить эту уязвимость. Проблема решается только путём установки стороннего ПО (например, fail2ban).

Если отключить вход по паролю, пользователи будут вынуждены использовать ключи авторизации на вашем сервере для входа в систему. Под ключом авторизации понимают особым образом созданный электронный ключ, состоящий из открытой и закрытой части. Открытая, или публичная часть ключа хранится на сервере. Закрытая (приватная) — на компьютере пользователя.

При таком подходе войти в систему смогут только пользователи с действующим SSH-ключом, авторизованным на сервере. А попытка авторизоваться по логину и паролю закончится неудачей. Важно создать ключи авторизации и настроить вход по этим ключам перед отключением входа по паролю. Иначе вы не сможете войти на сервер по SSH.

Настройка устаревания пароля

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

Если пароли меняются регулярно, их воровство становится неэффективным. Злоумышленники рискуют получить информацию, которая через день-два-неделю станет бесполезной. У них сокращается время подготовки на атаку, что повышает ваши шансы на успешную защиту данных. Само собой, все пароли должны быть сложными, чтобы их нельзя было подобрать.

Отключение root-доступа

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

Linux позволяет отключать доступы для root-пользователя через SSH, и этой возможностью надо воспользоваться. Так вы заставите злоумышленника искать доступы к вашей системе через обычную учётку. А у них (мы верим в это) жёстко ограничены права, а доступ имеется только к тем данным, которые нужны для работы.

Внеся изменения в /etc/ssh/sshd_config, мы сможете снизить ущерб с потери всего сервера до потери нескольких папок. Выбор, как говорится, за вами. Но перед любыми изменениями убедитесь, что у вас есть минимум один пользователь, которому разрешён вход по SSH, он действительно может это сделать и способен выполнять административные задачи через sudo. Или хотя бы есть возможность переключиться на пользователя с root через su. Иначе вы не сможете войти на сервер по SSH или войти сможете, а управлять им — нет.

Нужно уточнить, что не все версии Linux поддерживают такие изменения. Например, в популярной Cent OS по умолчанию нет пользователей кроме root.

Двухфакторная аутентификация для SSH

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

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

Это хороший способ защиты SSH-доступа к вашему серверу. Заранее изучите документацию по настройке аутентификации, чтобы правильно действовать, если она перестанет работать.

Заключение

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

Советы о том, как защитить SSH-доступ, полезны не только тем, кто пользуется облачной инфраструктурой. Они пригодятся и компаниям, использующим своё оборудование. Впрочем, облака по многим параметрам безопаснее локальной инфраструктуры. Более аргументированно об этом рассказывается в статье «Облака: в чем преимущество перед корпоративным сервером».


Вверх!