Сложная атака по словарю

Похоже, что один из моих серверов подвергается изощренной атаке по словарю на ssh, в которой я вижу, как на моих серверах в алфавитном порядке пробуются имена пользователей с ошибками пароля.

Необычные вещи об этом:

  • Есть только одна попытка каждые 2 минуты
  • каждая попытка происходит с другого IP-адреса

Can you help me understand how this can be done from different IP addresses, can it be effectively blocked? and does the slow persistence of the attack (probably will take several months to go through the alphabet) mean anything specific?

I'd also be interested to know if anyone else is currently seeing similar activity on their public ssh servers (ie. are we a specific target, or is this attacker blanketing thousands of ssh servers with this attack?)

Also, is there any way for me to reveal what passwords (or even hashes) are being tried? I notice that each name is only tried once or twice. I assume they are trying "password" or the user's username - but can i verify this?

Источник

5 ответов

Простой ответ на это - не используйте пароли!!!

Вы можете:

  • используйте ключи SSH. Зашифруйте их для дополнительной безопасности
  • использовать генератор одноразовых паролей, такой как Mobile-OTP
  • использовать Kerberos

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

В ответах на ваши конкретные вопросы:

  • Я встречал такого рода атаки на любом хосте, на котором у меня работает публичный ssh-сервер.
  • Я подозреваю, что они используют словарь имен пользователей / паролей, разработанный из прошлого опыта с тем, что работает. Например, мои журналы имеют
    • 18 попыток против пользователя "ftp"
    • 23 попытки против пользователя "форум"
    • 3 для пользователя "Бернард"
    • 1 для пользователя "bret"
  • Я также видел подобную атаку, когда они использовали реальные логины, специфичные для сайта, но они, вероятно, были получены с широко открытого сервера ldap этого сайта (университеты, должны любить их!)
  • Эти атаки, вероятно, исходят от зомби- компьютеров, которые имеют впечатляющий централизованный контроль.
  • эти атаки происходят со скоростью один раз в 1-5 минут, весь день, каждый день
  • Я просто попытался связать sshd, чтобы узнать, является ли тривиально собирать пароль, который пытается взломщик, и похоже, что вам придется исправлять код.
    • эти люди сделали именно это и обнаружили, что пароли часто были перестановками имени пользователя или известного пароля, такого как sql или admin.
Источник

Лучший ответ - ничего с этим не делать. Пока ваши пользователи имеют надежные пароли из 8 или более символов, в таком случае, скорее всего, потребуется около 3000 миллионов лет, чтобы перебор!

Источник

Вот некоторые обсуждения и анализ атаки ботнета "медленные зверюшки", которая началась в 2008 году: финальный обзор Slow Brutes

Другое обсуждение того же периода времени на этом сайте предполагает

Fail2ban - это всего лишь один инструмент для повышения безопасности сервера. Конечно, первый шаг состоит в том, чтобы избежать использования паролей и вместо этого использовать аутентификацию с использованием ключа сервера. Кроме того, ограничьте разрешенный трафик для определенных IP-адресов, запретите диапазоны IP-адресов, используйте таблицы IP-адресов, используйте черные списки, такие как rsync-mirrors.uceprotect.net, чтобы обновить свои iptables для известных источников происхождения SSH-хакеров и исходных сетей. Для получения более подробной информации о трех уровнях черного списка см. Uceprotect.net.

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

Источник

Установите denyhosts или fail2ban - он заблокирует по IP после определенного количества атак. denyhosts работает с /etc/hosts.deny, и я считаю, что fail2ban работает по правилам iptables.

Источник

Я не уверен в вашей реальной реализации, но вот несколько общих советов:

Проведите аудит ваших паролей (с помощью john the ripper или аналогичных) и посмотрите, сможете ли вы увеличить время ожидания для входа.

Источник
Другие вопросы по тегам