Вопросы Теги

Как найти причину использования ssh-сканирования?

Это - просто предупреждение, можно просто проигнорировать его. Существует флаг командной строки к Python, чтобы заставить его проигнорировать тот класс предупреждений: -W ignore::DeprecationWarning (это проигнорировано значением по умолчанию, запускающимся в версии 2.7),

Лично я все еще использую bttrack даже при том, что это становится старым и не поддерживает последние улучшения протокола Bittorrent: это эффективно, просто в использовании и надежно. У меня есть несколько средств отслеживания и сеялок и работающий для поддержки дистрибутива Linux.

6
13.05.2012, 02:39
2 ответа

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

Большинство машин опрыскивается такими пакетами все время. Как общее решение, мне нравится делать две вещи на брандмауэре:

  • Использовать geoip и ipset предоставить доступ для портирования 22/tcp из определенных стран только. Существует необычно высокий процент этих нападений, происходящих в .cn netblocks, например.

  • Используйте ограничение уровня на 22/tcp SYN пакеты так, чтобы тот же IP-адрес мог только соединить времена N за минуту до быть заблокированным в течение 10 или 15 минут. Это удерживает программное обеспечение сканирования и также замедляет потенциальный ущерб к сетям других людей. Это - сервис сообщества.

Существуют другие пути также в зависимости от Ваших потребностей и ограничений.

На самих целевых компьютерах необходимо также заблокировать вниз системные учетные записи и реализовать политику паролей, которая запрещает легкие пароли (проверка списка слов, минимальная длина, и т.д.).

3
27.01.2020, 20:29
  • 1
    Откровенно говоря, я сказал бы, запрещают пароли для аутентификации с SSH, поскольку это намного более безопасно, чем пароль, если каждый не использует некоторые ключи пострадавших от разгрома Debian. попытка –  0xC0000022L 14.05.2012, 00:19
  • 2
    Yikes, не напоминайте мне. Не легший спать всю ночь, повторно вводя хосты, VPNs и т.д., когда объявление вышло. И я использую Кластерный SSH. Debian выпустил пакеты, которые предупреждают Вас об изворотливых ключах, хотя поэтому, если кто-либо все еще влиял на ключи, они - идиоты. Так или иначе, об авторе SSH: Я соглашаюсь в принципе, но я заметил, что некоторым людям так же, как легко иметь жалостный пароль (или никакой пароль вообще, вздох), таким образом, полная безопасность может быть еще ниже, чем аутентификация по паролю. По крайней мере, Вы наложить качественная серверная сторона ограничений пароля. –  Alexios 14.05.2012, 02:43
  • 3
    никакой пароль не является никаким грехом пока ключ, хранится надежно (например, в зашифрованном контейнере). Но я предполагаю, что понимаю то, что Вы имеете в виду и согласовываете. Безопасность и удобство все еще противоречат друг другу слишком часто, и пользователи будут всегда выбирать удобство. –  0xC0000022L 14.05.2012, 03:24

Проверьте журналы веб-сервера на шаблоны в журналы доступа и ошибках. Запустите с журналов ошибок. То же для auth.log, для грубой силы входит в нападения. Если Вы просто восстановите свой сервер с тем же веб-приложением или паролем на SSH, то это будет только за несколько дней до того, как Вы будете взломаны снова.

1
27.01.2020, 20:29

Теги

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