Защита sshd от несанкционированного доступа

Узнайте, как обеспечить безопасность своих систем и предотвратить несанкционированный доступ через SSH, следуя этим простым рекомендациям.

SSH, или Secure SHell, заменил Telnet где-то в 1990-х годах в качестве протокола удаленного доступа, и на то есть веские причины. SSH позволяет администраторам или пользователям получить доступ к удаленной оболочке через защищенный туннель, подключив свой SSH-клиент к SSH-серверу. SSH также может обрабатывать передачу файлов, что должно заменить FTP, хотя существует удивительное количество ситуаций, в которых все еще используется старый добрый FTP с открытым текстом.

По вышеуказанным причинам современные системы Linux управляются через SSH. Большинство опытных системных администраторов любят прямой доступ и власть, которую они получают, безопасно подключаясь к оболочке своей системы с относительной легкостью. В этой статье я расскажу конкретно о демоне сервера OpenSSH, sshd. Мы рассмотрим некоторые проблемы безопасности, с которыми вы можете столкнуться, и способы их смягчения или полного решения.

Зачем нам нужен SSH

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

SSH также лежит в основе таких инструментов автоматизации, как Ansible. Ansible может вносить изменения в систему через SSH без использования агента. Все изменения выполняются с помощью SSH и Python.

SSH также можно использовать, как я уже говорил, для безопасной передачи файлов. Например, rsync туннелирует через SSH для безопасной синхронизации данных. SSH также можно использовать для туннелирования через одну систему, чтобы добраться до другой, что очень удобно для устранения неполадок, но также удобно для злоумышленников.

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

Защитите SSH

Самой распространенной атакой на SSH является перебор. В моих системах я лично никогда не сталкивался с атакой "грубой силы" против SSH. Однако до того, как я начал следовать простым правилам блокировки, я могу сказать, что они, конечно, пытались.

Быстрый поиск на Shodan - поисковой системе, предназначенной для устройств, подключенных к Интернету, - показывает 20 984 090 систем с открытым SSH. Нужно ли их настраивать таким образом? Я могу почти гарантировать вам, что каждая из этих систем получает несколько атак перебором SSH в секунду.

Короче говоря, плохой пароль на стандартной установке sshd может быть всем, что стоит между плохими парнями и вашей системой. Хотя стандартная конфигурация OpenSSH достаточно безопасна, ее можно усилить. К счастью для вас, у меня есть предложения.

Ограничьте доступ к порту 22

Начните с проверки того, открыт ли порт SSH по умолчанию (порт 22) для всего мира. Это можно сделать, запустив Nmap, который проверит вашу сеть в соответствии с вашими спецификациям.

Ограничение доступа к порту 22 - это самое основное, что вы можете сделать для защиты своей системы. Я понимаю, что эта тактика может сработать не для всех сценариев. Может быть, вы используете систему общего пользования, или ИТ-директор много путешествует и может иметь доступ к системам из разных мест (мы немного поговорим о VPN). Я хочу сказать, что у вас может быть веская причина, по которой SSH должен быть абсолютно открыт для широкой публики. Однако очень хорошо подумайте о том, чтобы избежать такой конфигурации. Я делал это, но в основном из лени. Обычно есть лучший способ.

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

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

Не забывайте, что корпоративная среда имеет свои преимущества. Если ваш сервер находится в корпоративной сети, велика вероятность, что там есть сетевой брандмауэр, который можно использовать для блокировки доступа к SSH, так что используйте этот факт в своих интересах. Глубокая оборона, друзья, это вещь!

Требуйте VPN для удаленного доступа

Итак, давайте поговорим о путешествующем ИТ-директоре, которому абсолютно необходим доступ к ssh из гостиничного номера. Решение кажется очевидным для тех из нас, кто бывал в таких ситуациях, но если вы рассматриваете возможность открытия доступа к SSH для всего мира, возможно, вам стоит услышать следующее: VPN, или виртуальная частная сеть, позволяет создать зашифрованный туннель от конечной точки - например, ноутбука вашего ИТ-директора в отеле на Мауи - обратно к корпоративной сети в Сиэтле. Это соединение по-своему защищено и зашифровано.

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

Запретить доступ root

Теперь мы переходим к фактической конфигурации sshd. Демон OpenSSH имеет опцию PermitRootLogin. По умолчанию эта опция установлена в Yes, поскольку при установке некоторых систем сначала существует только root. В такой ситуации вам нужна учетная запись root, чтобы получить доступ к системе и выполнить начальную настройку.

Я рекомендую добавить пользователя в процессе установки или как часть золотого образа и отключить вход в систему под root с самого начала. Нет причин входить в систему как root, и уж точно нет причин входить как root по SSH. Итак, измените строку конфигурации на:

Внедрите аутентификацию на основе ключей

Первоначально я использовал аутентификацию на основе ключей для удобства. Я генерировал закрытый ключ, добавлял открытый ключ в файл authorized_keys на серверах, которыми я управлял, и затем мог безопасно подключаться к своим системам без пароля. Это экономило время и делало возможной автоматизацию. WIN! Только позже я узнал, что аутентификацию на основе ключей SSH можно использовать для устранения попыток перебора паролей.

Чтобы сгенерировать ключ, запустите ssh-keygen на компьютере Mac или Linux. Возможно, пользователи Windows теперь могут делать это встроенными средствами, но на машинах Windows я всегда использовал PuTTYGen (а затем использовал ключ в клиенте PuTTY). Вам будет предложено выбрать тип ключа и его длину. В последнее время я создаю ключи RSA длиной 4096 бит. Чем больше битов, тем сложнее взломать ключ. Так почему бы и нет?

В итоге вы получите новый файл /root/.ssh/id_rsa (в данном случае) и /root/.ssh/id_rsa.pub. Ключ в id_rsa - это мой закрытый ключ, а id_rsa.pub содержит открытый ключ. Защитите закрытый ключ!!! Вы можете оставить открытый ключ где угодно, так как без закрытого ключа он бесполезен.

На машинах, к которым вы хотите подключаться без пароля, скопируйте открытый ключ в .ssh/authorized_keys (или попросите пользователя сделать это, в зависимости от ситуации). Я говорю "без пароля", но вам все равно нужно разблокировать закрытый ключ с помощью пароля, который вы задали при генерации. Вы ведь задали пароль, верно?

Вы также можете удаленно скопировать этот ключ на сервер с помощью ssh-copy-id.

Отключите аутентификацию на основе пароля

Помните, я говорил, что аутентификация на основе ключей открывает вам возможность полностью блокировать попытки перебора SSH? Вот как. Если у вас есть закрытый и открытый ключи, SSH больше не запрашивает пароль, верно? Так зачем оставлять этот путь открытым в качестве вектора атаки?

На каждом сервере Linux, который я запускаю, я добавляю свой открытый ключ как часть нашей базовой установки, и я отключаю аутентификацию пароля SSH еще до того, как система попадает в сеть. Это настройка прямо в конфигурационном файле sshd. Опять же, по умолчанию аутентификация пароля разрешена, поскольку эта функция должна работать для конфигурации. Однако, как только вы установите ключи, отключите эту функцию.

Поздравляем, теперь вы защищены от атак перебора паролей.

Тюрьма для пользователей SSH с помощью chroot

Команда chroot - обычно произносится как "chi-root" или "ch-root" - это очень удобный инструмент. Она позволяет изменить корневой каталог, видимый процессом и его дочерними программами, отсюда и название. Она отлично подходит для устранения неполадок в системе, где вы можете получить доступ к диску, но она не загружается. Вы просто монтируете диск и выполняете chroot в /mnt/whatever.

Это также хороший инструмент безопасности для чего-то вроде shell-сервера. Вы можете сделать chroot для пользователя при входе в систему, чтобы он буквально не мог видеть остальную часть файловой системы. Я делаю это не часто, но это очень жизнеспособная тюрьма для пользователей. Здесь я нашел, похоже, достойную статью.

Ротация

Стоит подумать о ротации паролей и ssh-ключей. Здесь я постараюсь описать все плюсы и минусы.

Политика паролей и ротация

Я объединю политику паролей с ротацией паролей, потому что они связаны. Политика паролей, обеспечивающая сложность, - отличный способ заставить пользователей выбирать "надежные" пароли. Однако здесь есть некоторые оговорки, особенно в сочетании с произвольным (т.е. ограниченным по времени) истечением срока действия пароля.

Несколько лет назад NIST сделал нечто вроде переворота в своих рекомендациях по паролям, изменив несколько своих предложений, которые были укоренившимися в сознании большинства из нас на протяжении всей нашей карьеры. Сообщество Infosec уже много лет говорит о том, что 8-символьные случайные пароли или 8-символьные пароли минимальной длины со строгими правилами сложности больше вредят гигиене паролей, чем помогают ей. Сочетайте строгие правила сложности с политикой ротации паролей на 3-6 месяцев, и вы настраиваете своих пользователей на разочарование. Это разочарование приводит к повторному использованию паролей и другим вредным привычкам. Поэтому хорошо подумайте, хотите ли вы навязывать это своим пользователям. Новые рекомендации склоняются к тому, что срок действия пароля должен истекать только при подозрении на взлом или компрометацию, а также к политике, которая заставляет пользователей использовать не пароли, а надежные парольные фразы. "This 1s my p@ssw0rd 2023." гораздо сложнее угадать и взломать, чем "W1nt3r2023". Что, кстати, часто используется как разработчиками паролей, так и "красными командами". Однако имейте в виду, что если вы просите умных администраторов менять свои пароли, у вас может не возникнуть этой проблемы (потому что они понимают, зачем они это делают и насколько это важно). Но для ваших пользователей в целом произвольное истечение срока действия и сложные "проходные слова" уходят в прошлое.

Ротация закрытого ключа SSH

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

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

MFA

Многофакторная аутентификация становится нормой. Некоторые люди пытаются утверждать, что SSH-ключи являются формой MFA, но это не так. Особенно если вы отключили аутентификацию по паролю. Однако вы можете интегрировать MFA, например TOTP или YubiKey, в конфигурацию PAM вашей системы. Центральные решения аутентификации, такие как FreeIPA, упрощают эту задачу.

Заключение

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