Какие меры можно / нужно предпринять, чтобы убедиться, что безопасность моего SSH-сервера абсолютно непроницаема?
Это будет вики сообщества с самого начала, поэтому давайте посмотрим, что люди делают для защиты своих серверов.
Какие меры можно / нужно предпринять, чтобы убедиться, что безопасность моего SSH-сервера абсолютно непроницаема?
Это будет вики сообщества с самого начала, поэтому давайте посмотрим, что люди делают для защиты своих серверов.
Ответы:
Используйте пароли открытого / секретного ключей для аутентификации вместо паролей.
Создайте ключ SSH, защищенный парольной фразой, для каждого компьютера, которому требуется доступ к серверу:
ssh-keygen
Разрешите SSH-доступ с открытым ключом с разрешенных компьютеров:
Скопируйте содержимое ~/.ssh/id_rsa.pub
каждого компьютера в отдельные строки ~/.ssh/authorized_keys
на сервере или запустите ssh-copy-id [server IP address]
на каждом компьютере, к которому вы предоставляете доступ (вам нужно будет ввести пароль сервера в командной строке).
Отключить пароль доступа по SSH:
Откройте /etc/ssh/sshd_config
, найдите строку с надписью #PasswordAuthentication yes
и измените ее на PasswordAuthentication no
. Перезапустите демон сервера SSH, чтобы применить изменение ( sudo service ssh restart
).
Теперь единственный возможный способ SSH на сервер - это использовать ключ, соответствующий строке в ~/.ssh/authorized_keys
. Используя этот метод, я не забочусь о грубой атаке, потому что даже если он угадает мой пароль, он будет отклонен. Грубое принуждение пары открытый / закрытый ключ невозможно с современной технологией.
Я бы предложил:
Использование fail2ban для предотвращения попыток входа в систему методом перебора.
Отключение входа в систему как root через SSH. Это означает, что злоумышленник должен был определить как имя пользователя, так и пароль, что затрудняет атаку.
Добавьте PermitRootLogin no
к своему /etc/ssh/sshd_config
.
Ограничение пользователей, которые могут SSH к серверу. Либо по группе, либо только по конкретным пользователям.
Добавить AllowGroups group1 group2
или AllowUsers user1 user2
ограничить, кто может SSH к серверу.
sshd
конфигурации перед тем, как перезапустить sshd, чтобы избежать блокировки самостоятельно. Смотрите этот блог для деталей - просто запустите sshd -T
после изменения конфигурации, прежде чем перезапустить основной sshd
. Кроме того, когда вы вносите изменения в конфигурацию, на компьютере должен быть открыт сеанс SSH , и не закрывайте его, пока вы не проверили конфигурацию, как было упомянуто, и, возможно, не выполнили тестовый вход в систему SSH.
Другие ответы обеспечивают безопасность, но есть одна вещь, которую вы можете сделать, чтобы сделать ваши журналы тише и снизить вероятность того, что вы будете заблокированы из своей учетной записи:
Переместите сервер с порта 22 на другой. Либо на вашем шлюзе, либо на сервере.
Это не повышает безопасность, но означает, что все случайные интернет-сканеры не будут загромождать ваши файлы журналов.
Включите двухфакторную аутентификацию с помощью HOTP или TOTP . Это доступно с 13.10 года.
Это включает использование аутентификации с открытым ключом поверх аутентификации по паролю, как в другом ответе здесь, но также требует, чтобы пользователь доказал, что он держит свое устройство второго фактора в дополнение к его личному ключу.
Резюме:
sudo apt-get install libpam-google-authenticator
Пусть каждый пользователь выполнит google-authenticator
команду, которая генерирует ~/.google-authenticator
и помогает им настроить два факторных устройства (например, приложение Google Authenticator для Android).
Редактировать /etc/ssh/sshd_config
и установить:
ChallengeResponseAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive
Беги, sudo service ssh reload
чтобы забрать свои изменения в /etc/ssh/sshd_config
.
Отредактируйте /etc/pam.d/sshd
и замените строку:
@include common-auth
с участием:
auth required pam_google_authenticator.so
Более подробную информацию о различных параметрах конфигурации можно найти в моем блоге за прошлый год: Лучшая двухфакторная аутентификация ssh в Ubuntu .
Сделайте так, чтобы клиентские IP-адреса блока sshd, которые не предоставили правильную информацию для входа в систему " DenyHØsts ", могут выполнять эту работу довольно эффективно. Я установил это на все свои Linux-боксы, которые каким-то образом доступны снаружи.
Это гарантирует, что силовые атаки на SSHD не будут эффективными, но помните (!), Что вы можете заблокировать себя, если забудете пароль. Это может быть проблемой на удаленном сервере, к которому у вас нет доступа.
Вот одна простая вещь: установить ufw («несложный брандмауэр») и использовать его для ограничения количества входящих соединений.
В командной строке введите:
$ sudo ufw limit OpenSSH
Если ufw не установлен, сделайте это и попробуйте снова:
$ sudo aptitude install ufw
Многие злоумышленники попытаются использовать ваш SSH-сервер для перебора паролей. Это позволит только 6 подключений каждые 30 секунд с одного и того же IP-адреса.
Если я хочу иметь дополнительную безопасность или мне нужен доступ к SSH-серверам в глубине корпоративной сети, я устанавливаю скрытый сервис с помощью программного обеспечения анонимизации Tor .
localhost
./etc/tor/torrc
. Установите HiddenServiceDir /var/lib/tor/ssh
и HiddenServicePort 22 127.0.0.1:22
.var/lib/tor/ssh/hostname
. Есть имя как d6frsudqtx123vxf.onion
. Это адрес скрытого сервиса.Откройте $HOME/.ssh/config
и добавьте несколько строк:
Host myhost
HostName d6frsudqtx123vxf.onion
ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
Кроме того, мне нужен Tor на моем локальном хосте. Если он установлен, я могу войти, ssh myhost
и SSH открывает соединение через Tor. Сервер SSH на другой стороне открывает свой порт только на локальном хосте. Так что никто не может подключить его через «обычный интернет».
На эту тему есть статья по администрированию Debian. Он охватывает базовую конфигурацию сервера SSH, а также правила брандмауэра. Это может быть также интересно для защиты SSH-сервера.
Смотрите там статью: Обеспечение безопасности доступа по SSH .
Мой подход к укреплению SSH ... сложен. Следующие пункты касаются того, как я это делаю, от самой крайней границы моей сети (сетей) до самих серверов.
Фильтрация трафика на пограничном уровне через IDS / IPS с помощью известных сервисных сканеров и подписей в черном списке. Я достигаю этого с Snort через мой пограничный межсетевой экран (это мой подход, устройство pfSense). Иногда я не могу этого сделать, например, с моими VPS.
Межсетевой экран / Сетевая фильтрация портов SSH. Я явно разрешаю только определенным системам доступ к моим SSH-серверам. Это делается либо через брандмауэр pfSense на границе моей сети, либо через брандмауэры на каждом сервере, которые явно настраиваются. Однако есть случаи, когда я не могу этого сделать (что почти никогда не происходит, за исключением частных лабораторий, занимающихся ручным тестированием или тестированием безопасности, где брандмауэры не помогают при тестировании).
В сочетании с моим pfSense или пограничным межсетевым экраном, который подключается к внутренней сети и отделяет ее от Интернета и систем, VPN-доступ только к серверам . Нужно подключить VPN к моим сетям, чтобы добраться до серверов, потому что нет портов с выходом в Интернет как таковых. Это определенно не работает для всех моих VPS, но в сочетании с # 2, я могу сделать один VPS «шлюзом» путем VPN-подключения к этому серверу, а затем разрешить его IP-адреса другим блокам. Таким образом, я точно знаю, что может или не может SSH - моя единственная коробка, которая является VPN. (Или в моей домашней сети за pfSense, моим VPN-соединением, и я единственный с VPN-доступом).
Там, где № 3 не выполнимо, fail2ban, настроенный на блокировку после 4 неудачных попыток и блокировку IP-адресов на час или более, является достойной защитой от людей, постоянно атакующих с помощью брутфорсинга - просто блокируйте их на брандмауэре автоматически с помощью fail2ban и meh. Настройка fail2ban это боль, хотя ...
Обфускация порта путем изменения порта SSH. Тем не менее, это НЕ хорошая идея, чтобы обойтись без каких-либо дополнительных мер безопасности - мантра «Безопасность через неизвестность» уже опровергнута и во многих случаях оспаривается. Я сделал это в сочетании с IDS / IPS и сетевой фильтрацией, но это все еще ОЧЕНЬ плохо, что делать самому по себе.
ОБЯЗАТЕЛЬНАЯ двухфакторная аутентификация с помощью решений Duo Security для двухфакторной аутентификации . На каждом из моих SSH-серверов настроен Duo, так что для того, чтобы даже войти, появляются запросы 2FA, и мне приходится подтверждать каждый доступ. (Это очень полезная функция - потому что, даже если кто-то получит мою фразу-пароль или взломает, он не сможет пройти мимо плагинов Duo PAM). Это одна из самых больших защит на моих SSH-серверах от несанкционированного доступа - каждый логин пользователя ДОЛЖЕН связываться с настроенным пользователем в Duo, и, поскольку у меня есть ограничительный набор, новые пользователи не могут быть зарегистрированы в системе.
Мои два цента для обеспечения безопасности SSH. Или, по крайней мере, мои мысли о приближении.
Возможно, вы захотите зайти в приложение FreeOTP из RedHat вместо использования Google Authenticator. Иногда при обновлении приложения они блокируют вас! ;-)
Если вы хотите использовать другие аппаратные токены, такие как Yubikey или eToken PASS или NG, или если у вас много пользователей или много серверов, вы можете использовать бэкэнд двухфакторной аутентификации с открытым исходным кодом.
В последнее время я написал Howto об этом .
Я недавно написал небольшой учебник по этому вопросу. По сути, вам нужно использовать PKI, и в моем руководстве также показано, как использовать двухфакторную аутентификацию для еще большей безопасности. Даже если вы не используете ни одну из этих вещей, есть также некоторые хитрости относительно защиты сервера путем удаления слабых комплектов шифров и других основ. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/
Для большого количества пользователей / сертификатов рассмотрите интеграцию LDAP. Крупные организации используют LDAP в качестве хранилища для учетных данных пользователей и сертификатов, хранящихся на бейджах или брелках, независимо от того, используются ли сертификаты для аутентификации или подписывания электронных писем. Примеры включают openLDAP, openDJ, Active Directory, Oracle Universal Directory, IBM Directory Server, snareWorks ...
Компьютерами и группами также можно управлять в LDAP, что обеспечивает централизованное управление учетными данными. Таким образом, справочные службы могут иметь единый магазин для работы с большим населением.
Вот ссылка на интеграцию с CentOS: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html
Вы также можете заблокировать в зависимости от страны происхождения, используя базу данных geoIP.
По сути, если вы живете в США, у кого-то в России нет причин подключаться к вашему SSH, поэтому они будут автоматически заблокированы.
Сценарий можно найти здесь: https://www.axllent.org/docs/view/ssh-geoip/
Вы также можете добавить к нему команды iptables (я сделал это для моих дроплетов), чтобы автоматически отбрасывать весь трафик на / с этих IP-адресов.