Настройка безопасности SSH соединения — залог спокойствия. Спокойствие бывает двух типов. Первое — это когда ты не знаешь о том что проблема есть. Так называемое «меньше знаешь — спокойнее спишь». Второе и пожалуй самое ценное — это когда ты знаешь что проблема есть, но она решена. Это пожалуй самая ценная разновидность спокойствия. И сегодня будет рассмотрен способ как обезопасить ваш SSH сервер.
Далеко не все, установив линуксовый сервер заморачиваются за то, чтобы как-то обезопасить на нём авторизацию. Во-первых зачем? Ведь всё зачастую происходит в локальной сети, кто тут может пакостить? Во-вторых как и кто может напакостить? Там же пароль длинною стотыщ символов, умрут перебирать. В свою очередь за настройку всяких fail2ban и подобных служб никто не заморачивается.
Таки что в итоге может случиться? Чисто гипотетически к вам в локальную сеть может пробраться какой-нибудь зловред, который планомерно будет подбирать пароли. Чтобы не вызывать какую-то небывалую нагрузку и избежать срабатывания fail2ban и подобных служб, он будет делать попытки раз в минуту, или раз в 5 минут. Или раз в час, это не критично. Перебрать например пачку стандартных паролей от кучи всяких апплаенсов — вообще не проблема край за неделю. Если делать по одному запросу в час, 24*7 = 168 запросов за неделю. Достаточно солидный список кандидатов стандартных паролей. Если найдена хотя бы одна успешная комбинация, можно уже пытаться авторизоваться под рутом. Если получилось авторизоваться под рутом — можно подтаскивать на этот хост какой-нибудь пейлоад. На этом этапе количество вариантов векторов развития атаки стремится к бесконечности. А вы, если не заморачивались за защиту — даже и не узнаете что в ваших рядах самозванец.
Настройка безопасности SSH соединения — подготовка
Подготовку стоит начать с настройки SSH авторизации по сертификатам. Все приведённые ниже действия описываются исходя из того что у вас она уже настроена. Что мы имеем перед тем как начать настройку:
- Вы уже авторизуетесь под своей учётной записью, на настраиваемых вами серверах через сертификаты SSH. В моём случае имя учётной записи под которой я авторизуюсь на серверах: adminguideru
- Ваши сервера, если есть такая необходимость, авторизуются друг на друге по сертификатам. Учётная запись под которой это происходит у меня: root
- Я буду проводить настройку на двух серверах. ag-dc-1 и ag-dc-2.
- Вы можете пользоваться этой инструкцией если настраиваете защиту для одного отдельностоящего хоста и уже выполнили настройку авторизации через Putty с помощью сертификатов. Выполнение этой инструкции без настройки авторизации через Putty приведёт к потери возможности авторизации через SSH.
Закручиваем гайки
Все приведённые ниже настройки производятся в файле sshd_config если не указано обратное. Сразу же сделаем бекап этого файла
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bkp
Открыть его на редактирование можно следующей командой:
sudo nano /etc/ssh/sshd_config
В зависимости от операционной системы и версии сервера, в файле конфигурации могут присутствовать или отсутствовать те или иные настройки. В случае отсутствия в нём приведённых ниже настроек, их необходимо добавить. Так же возможно что они отсутствуют в связи с тем что инструкция устарела. Так что если что-то не работает, необходимо актуализировать информацию в соответствии со справкой из официального источника. Настройки приведены на 11.11.2020.
Жестко прописываем IP адрес ssh сервера
Например у вашего хоста IP адрес 192.168.1.100. А опция отвечающая за интерфейс на котором работает SSH сервер прописана как «*». А потом к примеру вы нечаянно добавляете этому хосту ещё один сетевой интерфейс. И ещё неожиданно этот интерфейс начинает смотреть жопкой прямо в инторнет. Опция «*» — автоматом сделает возможным подключение к SSH серверу через тот новый интерфейс. Чтобы этого не произошло — необходимо ограничить IP адрес на котором работает SSH сервер. Прописать там можно как жестко IP адрес этого сервера. В случае с ag-dc-1 — это 192.168.1.100, так и подсеть: 192.168.1.0/24.
Для ag-dc-1
ListenAddress 192.168.1.100 #ip ag-dc-1
Для ag-dc-2
ListenAddress 192.168.1.101 #ip ag-dc-2
Изменяем порт SSH сервера
22 порт — первое что будут сканировать всякие зловреды. Крайне желательно сменить этот порт на любой другой нестандартный и не занятый другим сервисом.
#Port <желаемый номер нестандартного порта> Port 54322
Включаем только протокол второй версии
Первая версия протокола SSH не безопасна. Нам необходимо оставить доступной лишь 2ю версию SSH
Protocol 2
Ограничиваем время предоставляемое для авторизации
Будь то юзер или скрипт, у него будет всего несколько секунд на то чтобы авторизоваться. Иначе его кикнет с логинскрина.
LoginGraceTime 10s
Ограничиваем количество попыток авторизации
Если подключающийся владеет всеми необходимыми данными, то при авторизации по сертификатам ему хватит двух попыток авторизации. В противном случае сеанс будет прерван. Если количество попыток авторизации сделать равным единице, авторизация по сертификатам не будет работать.
MaxAuthTries 2 # Две неудачные попытки и разрыв связи
Включаем разделение прав пользователей
В момент подключения к серверу, до момента авторизации пользователя, будет создан отдельный процесс с ограниченными правами. После прохождения пользователем авторизации, будет создан уже новый процесс, с правами соответствующими правам пользователя. Данная настройка повышает безопасность, не давая пользователю повышать свои права
UsePrivilegeSeparation yes
Ограничиваем список доступа по SSH.
Важный момент, для того чтобы исключить доступ к терминалу со стороны нежелательных пользователей.
При этом запись adminguideru — разрешает доступ по ssh для этого юзера с любого источника подключения. Запись же root@192.168.1.101 — разрешает доступ к серверу под учёткой рута только с ip 192.168.1.101 и 192.168.1.101
AllowUsers adminguideru root@192.168.1.100 root@192.168.1.101
Отключаем пустые пароли.
PermitEmptyPasswords no
Отключим список доверенных хостов
IgnoreRhosts yes
Отключим авторизацию на стороне клиента
HostbasedAuthentication no
Сохраним все настройки (Ctrl+O) и закроем файл (Сtrl+X).
Перезапускаем SSH сервер
sudo systemctl restart ssh sshd
Настройка безопасности SSH — Пробуем подключиться к серверу через Putty
Не разрывая подключение с которого происходила настройка. Запускаем Putty и пытаемся установить подключение с админской машины, под админской учёткой, с помощью сертификата. Если не подключает — значит в настройках косяк. Вносим правки в файл конфигурации в том окне где происходила настройка. Несмотря на то что уже работают новые настройки, старое подключение будет работать пока мы не отключимся. Поэтому важно не разрывать его пока вы не убедитесь что всё заработало. Если всё заработало идём к следующему пункту.
Настройка безопасности SSH — Ограничим допущенные к подключению IP адреса
Необходимо отредактировать файл hosts.allow . Открываем его на редактирование
sudo nano /etc/hosts.allow
И добавляем IP адреса всех участников локальной сети, допущенных к подключению (включая IP адрес настраиваемого сервера)
sshd: 127.0.0.1 192.168.1.100 192.168.1.101 192.168.1.254
.254 — админская машина. 100 раз проверьте что у вас стоит IP адрес вашей админской машины. Иначе вы сможете авторизоваться на сервере только через консоль или сменив свой IP на тот что вы указали (если сервер примет с него подключение).
Настройка безопасности SSH — Проверяем авторизацию по паролю
Заходим в конфиг
sudo nano /etc/ssh/sshd_config
Находим пункт PasswordAuthentication раскомментируем и ставим no если там что-то другое.
PasswordAuthentication no
Настройка безопасности SSH — Заключение
Для верности, перезагрузим настраиваемые хосты. Если вы где-то накосячили с настройками , вас ждёт жирный сочный факап. Исправить который можно будет только подключившись через консоль сервера и заменив текущий файл sshd_config на бекап.
sudo cp /etc/ssh/sshd_config.bkp /etc/ssh/sshd_config
Ну или ручками найдя в нём ошибку.
Проверяем что на настраиваемые хосты пускает по сертификату через Putty. Если настраивалось межсерверное взаимодействие, проверяем что под рутом каждого из хостов пускает на другие хосты. Радуемся. Отныне вероятнее всего напакостить вам по SSH сможете только вы сами.
Ещё больше интересного контента в моём блоге в Zen и на моём канале YouTube. Подписывайтесь на канал, ставьте лайки, делайте репосты, это поможет развитию контента проекта AdminGuide.Ru
Vkontakte Comments
Default Comments