Действительно ли установка является очень сильным паролем достаточно для обеспечения SSH на порте 22?

tuaca dpashley% dpkg -L apache2.2-common | grep ldap
/etc/apache2/mods-available/ldap.load
/etc/apache2/mods-available/authnz_ldap.load
/usr/lib/apache2/modules/mod_authnz_ldap.so
/usr/lib/apache2/modules/mod_ldap.so

Это встраивают в апачские 2.2 и называют authnz-ldap.

8
задан 9 July 2010 в 02:24
5 ответов

хотя редкий, существует все еще 0-дневное использование..., таким образом, Вы никогда не знаете. возможно, Вы действительно ли ограничиваете, может получить доступ для портирования 22 [на уровне брандмауэра] только к немногим хостам/сетям?

или возможно можно ли пойти security-though-obscurity путем и реализовать ли стук порта?

3
ответ дан 2 December 2019 в 22:47
  • 1
    я думаю стук порта, является лучшей идеей затем. Ограничение сетей/хостов является лесами, я очень мобилен и склонен использовать другой Wi-Fi и сети 3G. –  Ivan 9 July 2010 в 02:07

Помните, что ВАШ пароль может быть очень сильным, в то время как у других пользователей могут возможно быть действительно слабые пароли. Поместить AllowGroups или AllowUsers в /etc/ssh/sshd_config выключать ssh доступ для других пользователей.

Также помните, что Ваш пароль может быть слишком безопасным: Этот пароль будет почти наверняка записан.

Сказав, что я думаю, что Вы довольно в безопасности; если Вы объединяетесь со стуком порта или таким образом, Вы очень в безопасности.

8
ответ дан 2 December 2019 в 22:47

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

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

4
ответ дан 2 December 2019 в 22:47
  • 1
    "Все это зависит от того, как быстро взломщик может стучать на Вашем tcp/22 порте для логинов. Если Вы не используете что-то для завершения, такие повторные соединения" - Не настроенный во всех общих дистрибутивах по умолчанию в наше время? –  Ivan 9 July 2010 в 02:10
  • 2
    @Ivan Неутешительно, нет, это не. apt-get install denyhosts (debian базирующийся) pkg_add -r denyhosts (FreeBSD) является одной из первых вещей сделать на новом поле. –  Pete 9 July 2010 в 02:27
  • 3
    Не всегда. Ubuntu не имеет его по умолчанию, и ни один не делает openSUSE или Fedora/Centos. Предварительно созданные пакеты существуют для всех трех, но необходимо принять положительные меры для включения его. –  sysadmin1138♦ 9 July 2010 в 02:27

Используйте denyhosts. Также рассмотрите использование основанного на ключе входа в систему, а не пароля.

3
ответ дан 2 December 2019 в 22:47
  • 1
    Да, я действительно использую ключ (и с хорошим случайно-символьным паролем, записанным только в моем уме и с датой истечения срока, которая имеет смысл). Но существует все еще пароль для пользователя, который я установил способ, которым я описал. –  Ivan 9 July 2010 в 03:10

Перемещение sshd к нестандартному порту, вероятно, было бы тривиально для добавления к конфигурации, и это, вероятно, устранит 99% ssh трафика бота. Почему подвергают себя всем атакам перебором, когда можно скрыться так легко.;-)

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

Как другой комментатор уже указал, это не защищает Вас от использования 0 дней в самом sshd. Это всегда - хорошая идея ограничить трафик просто машинами, которые должны соединиться через правила брандмауэра.

1
ответ дан 2 December 2019 в 22:47

Теги

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