установить max login ssh [duplicate]

Question 1

Какие меры я могу предпринять, чтобы убедиться, что безопасность вокруг моего SSH-сервера абсолютно непроницаема?

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

Question 2

Сделать IP-адрес клиента блока sshd, который не смог предоставить правильную регистрационную информацию, «DenyHØsts» может эффективно выполнять эту работу. У меня это установлено на всех моих Linux-боксах, которые каким-то образом достижимы с отличной внешней стороны.

Это позволит убедиться, что силовые атаки на SSHD не будут эффективными, но запомните (!) Это вы можете закончить себя, если вы забудете пароль. Это может быть проблемой на удаленном сервере, к которому у вас нет доступа.

Question 3

Question 4

Сделать IP-адрес клиента блока sshd, который не смог предоставить правильную регистрационную информацию, «DenyHØsts» может эффективно выполнять эту работу. У меня это установлено на всех моих Linux-боксах, которые каким-то образом достижимы с отличной внешней стороны.

Это позволит убедиться, что силовые атаки на SSHD не будут эффективными, но запомните (!) Это вы можете закончить себя, если вы забудете пароль. Это может быть проблемой на удаленном сервере, к которому у вас нет доступа.

Question 5

Мой подход к упрощению SSH ... сложный. Следующие пункты относятся к тому, как я это делаю, от самой граничной границы моей сети (ов) до самих серверов.

Фильтрация трафика на уровне границ через IDS / IPS с известными сервисными сканерами и подписи в списке блокировок. Я достигаю этого с помощью Snort через мой пограничный брандмауэр (это мой подход, устройство pfSense). Иногда я не могу этого сделать, например, с помощью моих VPS. Брандмауэр / Сетевая фильтрация портов (ов) SSH. Я явно разрешаю некоторым системам доступ к моим серверам SSH. Это делается либо через брандмауэр pfSense на границе моей сети, либо брандмауэры на каждом сервере, явно настроенные. Бывают случаи, когда я не могу этого сделать, хотя это почти никогда не происходит, за исключением частных лабораторий проверки подлинности или тестирования безопасности, где брандмауэры не помогут проверить вещи). В сочетании с моим pfSense или пограничным брандмауэром NAT-внутренней внутренней сетью и отделением от Интернета и систем, VPN-Only Access to Servers. Gotta VPN в мои сети, чтобы добраться до серверов, потому что нет портов, ориентированных на Интернет как таковых. Это определенно не работает для всех моих VPS, но в сочетании с # 2 я могу иметь один VPS-шлюз через VPN-соединение на этом сервере, а затем разрешать его IP-адреса другим блокам. Таким образом, я точно знаю, что может или не может SSH в моей моей коробке, которая является VPN. (Или, в моей домашней сети за pfSense, мое VPN-соединение, и я единственный, у кого есть доступ к VPN). Там, где # 3 не выполнимо, fail2ban, настроенный на блокировку после 4 неудачных попыток и блокирования IP-адресов в течение часа или более, является достойной защитой от людей, постоянно атакующих с помощью bruteforcing - просто блокируйте их на брандмауэре автоматически с помощью fail2ban и meh. Настройка fail2ban - это боль, хотя ... Обфускация портов путем изменения SSH-порта. Однако это не является хорошей идеей обойтись без каких-либо дополнительных мер безопасности, а мантра «Безопасность через Obscurity» уже была опровергнута и оспаривается во многих случаях. Я сделал это в сочетании с IDS / IPS и сетевой фильтрацией, но это все еще очень плохо для себя. ОБЯЗАТЕЛЬНАЯ двухфакторная аутентификация с помощью двухфакторной аутентификации Duo Security. На каждом из моих SSH-серверов есть Duo, настроенный на нем, так что для того, чтобы даже войти, появляются подсказки 2FA, и я должен подтвердить каждый доступ. (Это самая полезная функция - потому что даже если у кого-то есть кодовая фраза или перерывы, они не могут пройти через плагины Duo PAM). Это одна из самых больших защит на моих серверах SSH от несанкционированного доступа - каждый пользовательский логин ДОЛЖЕН привязываться к настроенному пользователю в Duo, и поскольку у меня есть ограничительный набор, в системе не могут быть зарегистрированы новые пользователи.

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

Question 6

В последнее время я написал небольшой учебник. В принципе, вам нужно использовать PKI, и мой учебник также показывает, как использовать двухфакторную аутентификацию для еще большей безопасности. Даже если вы не используете ни одну из этих вещей, есть также некоторые лакомые кусочки о защите сервера, удаляя слабые шифрованные сюиты и другие основы. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/

Question 7

Question 8

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

Установите Tor и настройте сам SSH-сервер. Убедитесь, что sshd прослушивает только 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 с другой стороны открывает свой порт только на локальном хосте. Поэтому никто не может подключить его через «обычный интернет».

Question 9

Включить двухфакторную аутентификацию с помощью 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

Подробнее о различных параметрах конфигурации - это мой пост в блоге из прошлого года: HOTP .

Question 10

Возможно, вы захотите проверить приложение FreeOTP от RedHat вместо использования Google Authenticator. Иногда при обновлении приложения они блокируют вас! ; -)

Если вы хотите использовать другие аппаратные токены, такие как Yubikey или eToken PASS или NG, или если у вас много пользователей или на многих серверах, вы можете использовать брандмауэр с двумя ключами с открытым исходным кодом. ! d1]

В последнее время я написал об этом.

Question 11

Я бы предложил:

Использование fail2ban для предотвращения попыток входа в грубую силу. Отключение входа в систему с правами администратора через SSH. Это означает, что злоумышленнику приходилось определять сложнее и имя пользователя, и пароль, делающий атаку. Добавьте PermitRootLogin no к вашему /etc/ssh/sshd_config. Ограничение пользователей, которые могут использовать SSH на сервере. Либо группа, либо только определенные пользователи. Добавьте AllowGroups group1 group2 или AllowUsers user1 user2, чтобы ограничить, кто может SSH на сервер.

Question 12

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

Создайте защищенный паролем ключ 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. Используя этот метод, мне не нужны атаки с грубой силой, потому что даже если они угадают мой пароль, он будет отклонен. Жесткое принуждение пары открытого / закрытого ключа невозможно с сегодняшней технологией.

Question 13

Question 14

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

См. Статью: Сохранение доступа SSH.

Question 15

Вы также можете блокировать базу в стране происхождения с использованием базы данных geoIP.

В принципе, если вы живете в США, тогда у кого-то в России нет причин подключаться к вашему SSH, поэтому они будут автоматически заблокированы.

Сценарий можно найти здесь: https://www.axllent.org/docs/view/ssh-geoip/

Вы также можете добавить к нему команды iptables (я сделал для моих капель), чтобы автоматически удалить весь трафик на / из этих IP-адресов.

Question 16

Вот одна простая задача: установить ufw («несложный брандмауэр») и использовать его для оценки ограничений входящих соединений.

В командной строке введите:

$ sudo ufw limit OpenSSH

Если ufw не установлен, выполните это и повторите попытку:

$ sudo aptitude install ufw

Многие злоумышленники попытаются использовать ваш SSH-сервер для перебора паролей. Это позволит только 6 подключений каждые 30 секунд с одного и того же IP-адреса.

Question 17

Для большого числа пользователей / сертификатов рассматривается интеграция 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

Question 18

Мой подход к упрощению SSH ... сложный. Следующие пункты относятся к тому, как я это делаю, от самой граничной границы моей сети (ов) до самих серверов.

Фильтрация трафика на уровне границ через IDS / IPS с известными сервисными сканерами и подписи в списке блокировок. Я достигаю этого с помощью Snort через мой пограничный брандмауэр (это мой подход, устройство pfSense). Иногда я не могу этого сделать, например, с помощью моих VPS. Брандмауэр / Сетевая фильтрация портов (ов) SSH. Я явно разрешаю некоторым системам доступ к моим серверам SSH. Это делается либо через брандмауэр pfSense на границе моей сети, либо брандмауэры на каждом сервере, явно настроенные. Бывают случаи, когда я не могу этого сделать, хотя это почти никогда не происходит, за исключением частных лабораторий проверки подлинности или тестирования безопасности, где брандмауэры не помогут проверить вещи). В сочетании с моим pfSense или пограничным брандмауэром NAT-внутренней внутренней сетью и отделением от Интернета и систем, VPN-Only Access to Servers. Gotta VPN в мои сети, чтобы добраться до серверов, потому что нет портов, ориентированных на Интернет как таковых. Это определенно не работает для всех моих VPS, но в сочетании с # 2 я могу иметь один VPS-шлюз через VPN-соединение на этом сервере, а затем разрешить его IP-адрес для других ящиков. Таким образом, я точно знаю, что может или не может SSH в моей моей коробке, которая является VPN. (Или, в моей домашней сети за pfSense, мое VPN-соединение, и я единственный, у кого есть доступ к VPN). Там, где # 3 не выполнимо, fail2ban, настроенный на блокировку после 4 неудачных попыток и блокирования IP-адресов в течение часа или более, является достойной защитой от людей, постоянно атакующих с помощью bruteforcing - просто блокируйте их на брандмауэре автоматически с помощью fail2ban и meh. Настройка fail2ban - это боль, хотя ... Обфускация портов путем изменения SSH-порта. Однако это не является хорошей идеей обойтись без каких-либо дополнительных мер безопасности, а мантра «Безопасность через Obscurity» уже была опровергнута и оспаривается во многих случаях. Я сделал это в сочетании с IDS / IPS и сетевой фильтрацией, но это все еще очень плохо для себя. ОБЯЗАТЕЛЬНАЯ двухфакторная аутентификация с помощью двухфакторной аутентификации Duo Security. На каждом из моих SSH-серверов есть Duo, настроенный на нем, так что для того, чтобы даже войти, появляются подсказки 2FA, и я должен подтвердить каждый доступ. (Это самая полезная функция - потому что даже если у кого-то есть кодовая фраза или перерывы, они не могут пройти через плагины Duo PAM). Это одна из самых больших защит на моих серверах SSH от несанкционированного доступа - каждый пользовательский логин ДОЛЖЕН привязываться к настроенному пользователю в Duo, и поскольку у меня есть ограничительный набор, в системе не могут быть зарегистрированы новые пользователи.

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

Question 19

Question 20

я написал небольшой учебник по ведению последнее время этот. В основном, вы должны быть с использованием PKI и мой учебник показывает, как использовать двухфакторную аутентификацию для еще большей безопасности. Даже если вы используете ни один из этих вещей, есть также некоторые лакомые кусочки О защите сервера, убрав слабых шифров и других основах. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/

Question 21

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

Установите Tor и настройте сам SSH-сервер. Убедитесь, что sshd прослушивает только 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 с другой стороны открывает свой порт только на локальном хосте. Поэтому никто не может подключить его через «обычный интернет».

Question 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

Подробнее о различных параметрах конфигурации - это мой пост в блоге из прошлого года: HOTP .

Question 23

Возможно, вы захотите проверить приложение FreeOTP от RedHat вместо использования Google Authenticator. Иногда при обновлении приложения они блокируют вас! ; -)

Если вы хотите использовать другие аппаратные токены, такие как Yubikey или eToken PASS или NG, или если у вас много пользователей или на многих серверах, вы можете использовать брандмауэр с двумя ключами с открытым исходным кодом. ! d1]

В последнее время я написал об этом.

Question 24

Я бы предложил:

Использование fail2ban для предотвращения попыток входа в грубую силу. Отключение входа в систему с правами администратора через SSH. Это означает, что злоумышленнику приходилось определять сложнее и имя пользователя, и пароль, делающий атаку. Добавьте PermitRootLogin no к вашему /etc/ssh/sshd_config. Ограничение пользователей, которые могут использовать SSH на сервере. Либо группа, либо только определенные пользователи. Добавьте AllowGroups group1 group2 или AllowUsers user1 user2, чтобы ограничить, кто может SSH на сервер.

Question 25

Question 26

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

Создайте защищенный паролем ключ 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. Используя этот метод, мне не нужны атаки с грубой силой, потому что даже если они угадают мой пароль, он будет отклонен. Жесткое принуждение пары открытого / закрытого ключа невозможно с сегодняшней технологией.

Question 27

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

См. Там статью: Сохранение доступа SSH.

Question 28

Вы также можете блокировать базу в стране происхождения с использованием базы данных geoIP.

В принципе, если вы живете в США, тогда у кого-то в России нет причин подключаться к вашему SSH, поэтому они будут автоматически заблокированы.

Сценарий можно найти здесь: https://www.axllent.org/docs/view/ssh-geoip/

Вы также можете добавить к нему команды iptables (я сделал для моих капель), чтобы автоматически удалить весь трафик на / из этих IP-адресов.

Question 29

Вот одна простая задача: установить ufw («несложный брандмауэр») и использовать его для оценки ограничений входящих соединений.

В командной строке введите:

$ sudo ufw limit OpenSSH

Если ufw не установлен, выполните это и повторите попытку:

$ sudo aptitude install ufw

Многие злоумышленники попытаются использовать ваш SSH-сервер для перебора паролей. Это позволит только 6 подключений каждые 30 секунд с одного и того же IP-адреса.

Question 30

Для большого числа пользователей / сертификатов рассматривается интеграция 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

3 revs, 3 users 77% · Accepted Answer · 18 July 2018 в 03:28

Сделать IP-адрес клиента блока sshd, который не смог предоставить правильную регистрационную информацию, «DenyHØsts» может эффективно выполнять эту работу. У меня это установлено на всех моих Linux-боксах, которые каким-то образом достижимы с отличной внешней стороны.

Это позволит убедиться, что силовые атаки на SSHD не будут эффективными, но запомните (!) Это вы можете закончить себя, если вы забудете пароль. Это может быть проблемой на удаленном сервере, к которому у вас нет доступа.

3 revs, 3 users 77% · Accepted Answer · 24 July 2018 в 17:51

Сделать IP-адрес клиента блока sshd, который не смог предоставить правильную регистрационную информацию, «DenyHØsts» может эффективно выполнять эту работу. У меня это установлено на всех моих Linux-боксах, которые каким-то образом достижимы с отличной внешней стороны.

Это позволит убедиться, что силовые атаки на SSHD не будут эффективными, но запомните (!) Это вы можете закончить себя, если вы забудете пароль. Это может быть проблемой на удаленном сервере, к которому у вас нет доступа.

2 revs · Answer 3 · 18 July 2018 в 03:28

Мой подход к упрощению SSH ... сложный. Следующие пункты относятся к тому, как я это делаю, от самой граничной границы моей сети (ов) до самих серверов.

Фильтрация трафика на уровне границ через IDS / IPS с известными сервисными сканерами и подписи в списке блокировок. Я достигаю этого с помощью Snort через мой пограничный брандмауэр (это мой подход, устройство pfSense). Иногда я не могу этого сделать, например, с помощью моих VPS. Брандмауэр / Сетевая фильтрация портов (ов) SSH. Я явно разрешаю некоторым системам доступ к моим серверам SSH. Это делается либо через брандмауэр pfSense на границе моей сети, либо брандмауэры на каждом сервере, явно настроенные. Бывают случаи, когда я не могу этого сделать, хотя это почти никогда не происходит, за исключением частных лабораторий проверки подлинности или тестирования безопасности, где брандмауэры не помогут проверить вещи). В сочетании с моим pfSense или пограничным брандмауэром NAT-внутренней внутренней сетью и отделением от Интернета и систем, VPN-Only Access to Servers. Gotta VPN в мои сети, чтобы добраться до серверов, потому что нет портов, ориентированных на Интернет как таковых. Это определенно не работает для всех моих VPS, но в сочетании с # 2 я могу иметь один VPS-шлюз через VPN-соединение на этом сервере, а затем разрешать его IP-адреса другим блокам. Таким образом, я точно знаю, что может или не может SSH в моей моей коробке, которая является VPN. (Или, в моей домашней сети за pfSense, мое VPN-соединение, и я единственный, у кого есть доступ к VPN). Там, где # 3 не выполнимо, fail2ban, настроенный на блокировку после 4 неудачных попыток и блокирования IP-адресов в течение часа или более, является достойной защитой от людей, постоянно атакующих с помощью bruteforcing - просто блокируйте их на брандмауэре автоматически с помощью fail2ban и meh. Настройка fail2ban - это боль, хотя ... Обфускация портов путем изменения SSH-порта. Однако это не является хорошей идеей обойтись без каких-либо дополнительных мер безопасности, а мантра «Безопасность через Obscurity» уже была опровергнута и оспаривается во многих случаях. Я сделал это в сочетании с IDS / IPS и сетевой фильтрацией, но это все еще очень плохо для себя. ОБЯЗАТЕЛЬНАЯ двухфакторная аутентификация с помощью двухфакторной аутентификации Duo Security. На каждом из моих SSH-серверов есть Duo, настроенный на нем, так что для того, чтобы даже войти, появляются подсказки 2FA, и я должен подтвердить каждый доступ. (Это самая полезная функция - потому что даже если у кого-то есть кодовая фраза или перерывы, они не могут пройти через плагины Duo PAM). Это одна из самых больших защит на моих серверах SSH от несанкционированного доступа - каждый пользовательский логин ДОЛЖЕН привязываться к настроенному пользователю в Duo, и поскольку у меня есть ограничительный набор, в системе не могут быть зарегистрированы новые пользователи.

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

2 revs, 2 users 67% · Answer 4 · 18 July 2018 в 03:28

В последнее время я написал небольшой учебник. В принципе, вам нужно использовать PKI, и мой учебник также показывает, как использовать двухфакторную аутентификацию для еще большей безопасности. Даже если вы не используете ни одну из этих вещей, есть также некоторые лакомые кусочки о защите сервера, удаляя слабые шифрованные сюиты и другие основы. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/

2 revs, 2 users 88% · Answer 5 · 18 July 2018 в 03:28

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

Установите Tor и настройте сам SSH-сервер. Убедитесь, что sshd прослушивает только 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 с другой стороны открывает свой порт только на локальном хосте. Поэтому никто не может подключить его через «обычный интернет».

2 revs, 2 users 98% · Answer 6 · 18 July 2018 в 03:28

Включить двухфакторную аутентификацию с помощью 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

Подробнее о различных параметрах конфигурации - это мой пост в блоге из прошлого года: HOTP .

3 revs, 2 users 78% · Answer 7 · 18 July 2018 в 03:28

Возможно, вы захотите проверить приложение FreeOTP от RedHat вместо использования Google Authenticator. Иногда при обновлении приложения они блокируют вас! ; -)

Если вы хотите использовать другие аппаратные токены, такие как Yubikey или eToken PASS или NG, или если у вас много пользователей или на многих серверах, вы можете использовать брандмауэр с двумя ключами с открытым исходным кодом. ! d1]

В последнее время я написал об этом.

3 revs, 2 users 79% · Answer 8 · 18 July 2018 в 03:28

Я бы предложил:

Использование fail2ban для предотвращения попыток входа в грубую силу. Отключение входа в систему с правами администратора через SSH. Это означает, что злоумышленнику приходилось определять сложнее и имя пользователя, и пароль, делающий атаку. Добавьте PermitRootLogin no к вашему /etc/ssh/sshd_config. Ограничение пользователей, которые могут использовать SSH на сервере. Либо группа, либо только определенные пользователи. Добавьте AllowGroups group1 group2 или AllowUsers user1 user2, чтобы ограничить, кто может SSH на сервер.

6 revs, 4 users 62% · Answer 9 · 18 July 2018 в 03:28

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

Создайте защищенный паролем ключ 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. Используя этот метод, мне не нужны атаки с грубой силой, потому что даже если они угадают мой пароль, он будет отклонен. Жесткое принуждение пары открытого / закрытого ключа невозможно с сегодняшней технологией.

Huygens · Answer 10 · 18 July 2018 в 03:28

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

См. Статью: Сохранение доступа SSH.

Michael A Mike · Answer 11 · 18 July 2018 в 03:28

Вы также можете блокировать базу в стране происхождения с использованием базы данных geoIP.

В принципе, если вы живете в США, тогда у кого-то в России нет причин подключаться к вашему SSH, поэтому они будут автоматически заблокированы.

Сценарий можно найти здесь: https://www.axllent.org/docs/view/ssh-geoip/

Вы также можете добавить к нему команды iptables (я сделал для моих капель), чтобы автоматически удалить весь трафик на / из этих IP-адресов.

mpontillo · Answer 12 · 18 July 2018 в 03:28

Вот одна простая задача: установить ufw («несложный брандмауэр») и использовать его для оценки ограничений входящих соединений.

В командной строке введите:

$ sudo ufw limit OpenSSH

Если ufw не установлен, выполните это и повторите попытку:

$ sudo aptitude install ufw

Многие злоумышленники попытаются использовать ваш SSH-сервер для перебора паролей. Это позволит только 6 подключений каждые 30 секунд с одного и того же IP-адреса.

weller1 · Answer 13 · 18 July 2018 в 03:28

Для большого числа пользователей / сертификатов рассматривается интеграция 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

2 revs · Answer 14 · 24 July 2018 в 17:51

Мой подход к упрощению SSH ... сложный. Следующие пункты относятся к тому, как я это делаю, от самой граничной границы моей сети (ов) до самих серверов.

Фильтрация трафика на уровне границ через IDS / IPS с известными сервисными сканерами и подписи в списке блокировок. Я достигаю этого с помощью Snort через мой пограничный брандмауэр (это мой подход, устройство pfSense). Иногда я не могу этого сделать, например, с помощью моих VPS. Брандмауэр / Сетевая фильтрация портов (ов) SSH. Я явно разрешаю некоторым системам доступ к моим серверам SSH. Это делается либо через брандмауэр pfSense на границе моей сети, либо брандмауэры на каждом сервере, явно настроенные. Бывают случаи, когда я не могу этого сделать, хотя это почти никогда не происходит, за исключением частных лабораторий проверки подлинности или тестирования безопасности, где брандмауэры не помогут проверить вещи). В сочетании с моим pfSense или пограничным брандмауэром NAT-внутренней внутренней сетью и отделением от Интернета и систем, VPN-Only Access to Servers. Gotta VPN в мои сети, чтобы добраться до серверов, потому что нет портов, ориентированных на Интернет как таковых. Это определенно не работает для всех моих VPS, но в сочетании с # 2 я могу иметь один VPS-шлюз через VPN-соединение на этом сервере, а затем разрешить его IP-адрес для других ящиков. Таким образом, я точно знаю, что может или не может SSH в моей моей коробке, которая является VPN. (Или, в моей домашней сети за pfSense, мое VPN-соединение, и я единственный, у кого есть доступ к VPN). Там, где # 3 не выполнимо, fail2ban, настроенный на блокировку после 4 неудачных попыток и блокирования IP-адресов в течение часа или более, является достойной защитой от людей, постоянно атакующих с помощью bruteforcing - просто блокируйте их на брандмауэре автоматически с помощью fail2ban и meh. Настройка fail2ban - это боль, хотя ... Обфускация портов путем изменения SSH-порта. Однако это не является хорошей идеей обойтись без каких-либо дополнительных мер безопасности, а мантра «Безопасность через Obscurity» уже была опровергнута и оспаривается во многих случаях. Я сделал это в сочетании с IDS / IPS и сетевой фильтрацией, но это все еще очень плохо для себя. ОБЯЗАТЕЛЬНАЯ двухфакторная аутентификация с помощью двухфакторной аутентификации Duo Security. На каждом из моих SSH-серверов есть Duo, настроенный на нем, так что для того, чтобы даже войти, появляются подсказки 2FA, и я должен подтвердить каждый доступ. (Это самая полезная функция - потому что даже если у кого-то есть кодовая фраза или перерывы, они не могут пройти через плагины Duo PAM). Это одна из самых больших защит на моих серверах SSH от несанкционированного доступа - каждый пользовательский логин ДОЛЖЕН привязываться к настроенному пользователю в Duo, и поскольку у меня есть ограничительный набор, в системе не могут быть зарегистрированы новые пользователи.

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

2 revs, 2 users 67% · Answer 15 · 24 July 2018 в 17:51

я написал небольшой учебник по ведению последнее время этот. В основном, вы должны быть с использованием PKI и мой учебник показывает, как использовать двухфакторную аутентификацию для еще большей безопасности. Даже если вы используете ни один из этих вещей, есть также некоторые лакомые кусочки О защите сервера, убрав слабых шифров и других основах. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/

0

ответ дан 2 revs, 2 users 67% 24 July 2018 в 17:51

1

Для тех, кто верит в безопасность по неизвестности ( ru.wikipedia.org/wiki/Security_through_obscurity ), имеет смысл использовать другой порт. Я не понимаю. – LassePoulsen 15 August 2010 в 15:19
2

Речь идет не о безопасности через Obscurity (хотя неясность может иметь незначительный положительный эффект). Речь идет об уменьшении фонового шума бесконечных попыток грубой силы. Вы не можете с пользой провести аудит журналов сбоев доступа, если они полны автоматических атак; fail2ban не уменьшает объем, достаточный, учитывая количество нападавших и распространенность распределенных (ботнет) и дросселированных атак. С помощью ssh на необычном порту вы знаете атаки, которые вы видите в журналах, приходят от реального злоумышленника, заинтересованного вашей коробкой. Я настоятельно рекомендую. – bobince 12 October 2010 в 05:19
3

Поскольку вы можете запрашивать интернет-услуги, такие как shodan для веб-серверов ssh, или использовать nmap и захват баннеров, делает изменение порта по умолчанию довольно бессмысленным. я бы советовал против этого. – SLow Loris 2 August 2017 в 16:38
4

Shodan не захватывает все порты 65k, поэтому переход на высокий порт скорее всего удалит его из сканирования. Также, если вы перейдете на случайный высокий порт, злоумышленнику, вероятно, потребуется выполнить 65K TCP-сканирование (очень шумно), чтобы найти ваш сервис, чтобы начать атаковать его. Оба они выигрывают с точки зрения безопасности, поэтому переход к высокому порту обычно является хорошим планом. Другое дело, что, перейдя на высокий порт, вы можете лучше понять, что кто-то, кто атакует вас, нацеливается на ваши системы, а не только на общий фоновый интернет-шум – Rоry McCune 23 December 2017 в 12:51

2 revs, 2 users 88% · Answer 16 · 24 July 2018 в 17:51

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

Установите Tor и настройте сам SSH-сервер. Убедитесь, что sshd прослушивает только 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 с другой стороны открывает свой порт только на локальном хосте. Поэтому никто не может подключить его через «обычный интернет».

Безопасность с помощью передовой неясности, но очень интересная. — Johannes, 29 August 2013 в 14:25

2 revs, 2 users 98% · Answer 17 · 24 July 2018 в 17:51

Включить двухфакторную аутентификацию с помощью 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

Подробнее о различных параметрах конфигурации - это мой пост в блоге из прошлого года: HOTP .

3 revs, 2 users 78% · Answer 18 · 24 July 2018 в 17:51

Возможно, вы захотите проверить приложение FreeOTP от RedHat вместо использования Google Authenticator. Иногда при обновлении приложения они блокируют вас! ; -)

Если вы хотите использовать другие аппаратные токены, такие как Yubikey или eToken PASS или NG, или если у вас много пользователей или на многих серверах, вы можете использовать брандмауэр с двумя ключами с открытым исходным кодом. ! d1]

В последнее время я написал об этом.

3 revs, 2 users 79% · Answer 19 · 24 July 2018 в 17:51

Я бы предложил:

Использование fail2ban для предотвращения попыток входа в грубую силу. Отключение входа в систему с правами администратора через SSH. Это означает, что злоумышленнику приходилось определять сложнее и имя пользователя, и пароль, делающий атаку. Добавьте PermitRootLogin no к вашему /etc/ssh/sshd_config. Ограничение пользователей, которые могут использовать SSH на сервере. Либо группа, либо только определенные пользователи. Добавьте AllowGroups group1 group2 или AllowUsers user1 user2, чтобы ограничить, кто может SSH на сервер.

67

ответ дан 3 revs, 2 users 79% 24 July 2018 в 17:51

1

Разрешающие [D0] AllowUsers и AllowGroups не принимают запятую , как разделитель. Убедитесь, что вы не пробовали это дистанционно. Я все время отключаюсь от своего NAS, делая это неправильно. – artless noise 21 April 2015 в 22:42
2

Всегда проверяйте , что ваша конфигурация sshd правильная, прежде чем перезапустить sshd, чтобы избежать блокировки себя из машины. Подробнее см. [D1] в этом блоге - просто запустите sshd -T после изменения конфигурации перед перезапуском основного sshd. Кроме того, открывают сеанс SSH на компьютере, когда вы вносите изменения в конфигурацию, и не закрывайте его до тех пор, пока вы не подтвердите конфигурацию, как упомянуто, и, возможно, выполнили проверку SSH-входа. – RichVel 10 August 2017 в 08:47

6 revs, 4 users 62% · Answer 20 · 24 July 2018 в 17:51

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

Создайте защищенный паролем ключ 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. Используя этот метод, мне не нужны атаки с грубой силой, потому что даже если они угадают мой пароль, он будет отклонен. Жесткое принуждение пары открытого / закрытого ключа невозможно с сегодняшней технологией.

100

ответ дан 6 revs, 4 users 62% 24 July 2018 в 17:51

1

-1: Обычно доступ предоставляется отдельным не компьютерам, создание ключа для каждого потенциального клиентского компьютера, подключенного к серверу, необоснованно. Ваше последнее утверждение неверно, в соответствии с вашим предложением и потому, что вы не предлагали устанавливать кодовую фразу для закрытых ключей, имеющих доступ / компрометацию любой из клиентских систем, автоматически предоставляли бы доступ к SSH-серверу. Рекомендуется использовать аутентификацию ключа SSH, но частные ключи должны быть надлежащим образом защищены, и их следует использовать на индивидуальной основе, а не в распределенной форме, как описано. – João Pinto 14 August 2010 в 23:41
2

«Обычно доступ предоставляется индивидуально не компьютерам, создание ключа для каждого потенциального клиентского компьютера, подключенного к серверу, необоснованно» Есть много вариантов, и я думаю, что описание того, как безопасно передавать закрытый ключ каждому клиенту, выходит за рамки этого вопроса. Я не представляю все варианты, просто простые, которые, как я думаю, люди могут понять. «... следует использовать на индивидуальной основе, а не в распределенном виде, как описано« Это, похоже, противоречит вашему предыдущему утверждению, и я не описывал ничего как распространенное. – Asa Ayers 15 August 2010 в 08:17
3

& Quot; невозможно & Quot; возможно, немного переусердствует. – Thorbjørn Ravn Andersen 16 August 2010 в 20:46
4

Вот почему я говорю «невозможно». У кого-то нет компьютеров, которые бы быстро это мало, это много или много времени. «Представьте себе компьютер, размер песка, который может проверять ключи от некоторых зашифрованных данных. Также представьте, что он может проверять ключ в количестве времени, которое требуется для прохождения света. Затем рассмотрим кластер из этих компьютеров, так много, что, если бы вы покрыли землю ими, они покрывали бы всю планету на высоту 1 метр. Кластер компьютеров взломает 128-битный ключ в среднем за 1000 лет. & Quot; – Asa Ayers 16 August 2010 в 21:22

Huygens · Answer 21 · 24 July 2018 в 17:51

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

См. Там статью: Сохранение доступа SSH.

8

ответ дан Huygens 24 July 2018 в 17:51

1

Немного поздно, но, пожалуйста, при ответе на вопросы, скопируйте важные части из ссылки, чтобы, если связь распадается, информация все еще здесь. – umop aplsdn 28 August 2012 в 09:54
2

Хорошая идея. Хотя я переживаю период с гораздо меньшим временем для участия. Мой ответ - это «вики сообщества». поэтому не стесняйтесь добавлять информацию о ссылке, если у вас есть время. – Huygens 12 September 2012 в 00:42

Michael A Mike · Answer 22 · 24 July 2018 в 17:51

Вы также можете блокировать базу в стране происхождения с использованием базы данных geoIP.

В принципе, если вы живете в США, тогда у кого-то в России нет причин подключаться к вашему SSH, поэтому они будут автоматически заблокированы.

Сценарий можно найти здесь: https://www.axllent.org/docs/view/ssh-geoip/

Вы также можете добавить к нему команды iptables (я сделал для моих капель), чтобы автоматически удалить весь трафик на / из этих IP-адресов.

Иногда базы данных GeoIP могут быть ошибочными - меня спросили, был ли я вчера в Москве ... а нет! :) — Sean, 24 October 2017 в 15:19

mpontillo · Answer 23 · 24 July 2018 в 17:51

Вот одна простая задача: установить ufw («несложный брандмауэр») и использовать его для оценки ограничений входящих соединений.

В командной строке введите:

$ sudo ufw limit OpenSSH

Если ufw не установлен, выполните это и повторите попытку:

$ sudo aptitude install ufw

Многие злоумышленники попытаются использовать ваш SSH-сервер для перебора паролей. Это позволит только 6 подключений каждые 30 секунд с одного и того же IP-адреса.

19

ответ дан mpontillo 24 July 2018 в 17:51

1

+1 Использование лимита может быть хорошим. Однако следует указать, что я столкнулся с проблемами при использовании встроенного сервера sftp, поскольку он также ограничивает соединения для этого. – Mark Davidson 15 August 2010 в 14:40
2

@Mark - хороший момент, но разве это не похоже на плохо написанный SFTP-клиент? Почему они должны переподключиться к порту SSH, когда они могут просто открыть больше SSH-каналов? – mpontillo 24 August 2010 в 09:32

weller1 · Answer 24 · 24 July 2018 в 17:51

Для большого числа пользователей / сертификатов рассматривается интеграция 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

установить max login ssh [duplicate]

24 ответа

Другие вопросы по тегам:

Похожие вопросы: