Вопрос: Нормально ли получать сотни попыток взлома в день?


Я просто проверил сервер /var/log/auth.log и обнаружил, что я получаю более 500 неудачных уведомлений о попытке ввода пароля / взлома в день! Мой сайт небольшой, и его URL-адрес неясен. Это нормально? Должен ли я принимать какие-либо меры?


196
2018-03-08 11:26


Источник


До тех пор, пока мы не закроем все ненужные внешние порты, я помню, что у нас не было много попыток взлома, но однажды было так плохо, что нас взламывали из двух разных стран - в то же время! Так что да, 100-секундные попытки взлома совершенно нормальны. - Django Reinhardt
У нас есть серверы, которые испытывают новую «последовательность» атаки каждые 16 секунд. Одна последовательность, как правило, представляет собой пакет из примерно 100 попыток в разных портах. Как раз для ударов в один прекрасный день я включил незагруженный сервер за пределами нашего брандмауэра; он занял менее 10 минут с момента, когда он был включен, чтобы получить pwnd. Точка - это по-настоящему интернет-джунгли; постарайтесь не съесть. - NotMe
Я вижу, что я отправил свой вопрос на неправильный сайт: superuser.com/questions/200896/... - Justin C
в то время как я согласен с другими, это нормально для обычных портов (80, 443). Я практически устранил эти попытки против моего SSH-порта, просто изменив порт по умолчанию с 22 на что-то неясное, например 6022. Только это, в одиночку, почти устранило 99% этого типа атаки. - Kilo
Если вы собираетесь изменить свой SSH-порт, есть соображения безопасности, чтобы поддерживать его ниже порта 1024 (только root может открывать порты <1024, поэтому он защищает вас от других пользователей, угоняющих SSH). - Brendan Long


Ответы:


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

Цели атаки не найдены через записи Google или DNS, но злоумышленники просто пытаются использовать каждый IP-адрес в определенной подсети (например, известных хостинговых компаний root-сервера). Поэтому не имеет значения, что ваш URL (следовательно, запись DNS) довольно неясен.

Вот почему так важно:

  • запретить root-login в SSH (как)
  • использовать надежные пароли везде (также в ваших веб-приложениях)
  • для SSH используйте аутентификацию с открытым ключом, если это возможно, и полностью отключите пароль-auth (как)

Кроме того, вы можете установить fail2ban который сканирует authlog, и если он обнаружит определенное количество неудачных попыток входа в систему с IP-адреса, он добавит, что IP-адрес /etc/hosts.deny или iptables / netfilter, чтобы заблокировать атакующего в течение нескольких минут.

В дополнение к атак SSH, также становится обычным сканировать ваш веб-сервер для уязвимых веб-приложений (некоторые приложения для ведения блога, CMS, phpmyadmin и т. Д.). Поэтому следите за тем, чтобы они были в актуальном состоянии и надежно настроены!


207
2018-03-08 11:35



Такие приложения, как fail2ban, могут помочь многим «временно» остановить этих ботов от удара вашего сервера в глупые часы утром :-) У меня есть моя установка, чтобы запретить 3 неправильных попытки за 24 часа. - emtunc
И переместите порт ssh с 22 на 222. Это работает очень хорошо. - Tom O'Connor
+1, только аутентификация с открытым ключом :) - 0xC0000022L
@STATUS_ACCESS_DENIED: действия fail2ban принимают только списки команд оболочки для запуска. Так что это очень гибко и легко сделать работу с любой настраиваемой конфигурацией. Лучше всего загрузить его и посмотреть на action.d/iptables.conf, - mattdm
Блокировка таких злоумышленников - это пустая трата времени. Если вы отключите регистрацию root, есть хороший шанс, что никто даже не угадает ваше правильное имя пользователя, не говоря уже о пароле. Сам SSH уже ограничивает скорость запросов пароля, поэтому даже если они знают ваше имя пользователя (случайные боты не будут), если у вас есть приличный пароль, они никогда не догадаются. - Brendan Long


Несколько 100 просто отлично ... В прошлом месяце я обнаружил, что на одном из моих серверов было 40k неудачных попыток. Я столкнулся с проблемой их заговора: карта

Как только я изменил порт ssh и реализовал Port Knocking, число упало до 0 :-)


58
2018-03-08 11:36



Хорошая карта. Я хотел бы знать, как это сделать! - jftuga
@jftuga Я получил все IP-адреса из журналов. grep 'Failed password' /var/log/secure* | grep sshd | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq(удалите | uniq в конце, если вы хотите разрешить дубликаты). Затем вы можете поместить их в CSV и загрузить его на zeemaps.com. Я видел лучшие карты, кроме моих, где они будут использовать подсчет, чтобы покрасить карту (от зеленого до красного для количества попыток на графство), но у меня нет струй, - Bart De Vos
Что вы подразумеваете под «реализованным Port Knocking»? Есть ли приложение, которое я могу установить через apt-get, чтобы это сделать? Число сбрасывается до 0 звуков
Безопасность через безвестность становится плохой. Это прекрасно, пока часть общей стратегии, а не всей стратегии. В конце концов, что еще является паролем, кроме неясной строки? - Joel Coel
@Joel Coel, это секрет строка, в отличие от большей безопасности через проблемы безвестности - неясный, но не обязательно секретный процесс. - tobyodavies


Я для одного использую «tarpit» в дополнение к только разрешению аутентификации открытого ключа и запрету входа root.

В netfilter Eсть recent модуль, который вы можете использовать с (INPUT цепь):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Что это значит, что каждая попытка подключения к порту 22 указана в recent модуль с IP и некоторые другие вещи под названием «tarpit» (если вам интересно, посмотрите /proc/net/xt_recent/tarpit). Очевидно, вы можете использовать другие имена.

Чтобы перечислить или делистировать IP-адреса, используйте:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Эта скорость ограничивает попытки до 5 за 300 секунд. Обратите внимание, что пользователи с существующим соединением не обеспокоены этим ограничением, поскольку у них уже установлено соединение и им разрешено создавать больше (даже выше предельного значения скорости).

Отрегулируйте правила по своему вкусу, но убедитесь, что они добавлены в этом порядке (т. Е. При добавлении, затем используйте их в этом порядке, при вставке в обратном порядке).

Это значительно уменьшает шум. Он также обеспечивает фактическую безопасность (против грубой форсировки), в отличие от воспринимаемой безопасности изменения порта. Тем не менее, я по-прежнему рекомендую изменить порт, если это возможно в вашей среде. Он также значительно снизит уровень шума ...

Вы все равно можете комбинировать это с fail2ban, хотя я без проблем справляюсь с ним и только вышеприведенные правила.

РЕДАКТИРОВАТЬ:

Вы можете заблокировать себя от этого, так что вы можете добавить что-то вроде следующего, что позволяет вам очистить вас от запрета, постукивая по определенному порту:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

29
2018-03-08 14:24



Я использую это и иногда блокирую себя, поэтому, чтобы установить другой порт, который вы можете «постучать», чтобы очистить свой запрет. - benlumley
@benlumley: хорошая точка. Смещение порта может быть также полезно для изменения порта по умолчанию - или даже для обоих из них в комбинации ... - 0xC0000022L
@benlumley: увидел ваш комментарий (теперь снятый Сэмом). Я абсолютно не против, если ответ будет отредактирован / улучшен;) - 0xC0000022L


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


15
2018-03-08 11:32



Если вы используете SSH, рассмотрите проверку подлинности с открытым ключом. Это немного более безопасно, чем аутентификация паролем. - Piskvor


да, В наши дни это нормально.

Если возможно, используйте только аутентификацию открытого ключа для административных целей. Создайте закрытый ключ на рабочей станции:

$ ssh-keygen -t dsa

Copypaste - содержание ~ / .ssh / id_dsa.pub вам серверы ~ / .ssh / authorized_keys (и /root/.ssh/authorized_keys, если вам нужен прямой вход в root).

Настройте свои серверы / И т.д. / SSH / sshd_config только для аутентификации с открытым ключом:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Если у вас слишком много серверов, вы можете использовать Кукольный для запуска открытых ключей и конфигураций.

Посмотрите DenyHosts а также fail2ban блокировать повторные попытки входа в систему SSH и посмотреть фырканье если вам требуется полная IDS / IPS.


12
2018-03-09 23:32



Я бы не рекомендовал использовать аутентификацию открытого ключа в SSH для доступа оболочки к вашему серверу. Если ваша рабочая станция скомпрометирована или, что еще хуже, украдена, у кого-то теперь есть открытый доступ к вашим серверам без необходимости в пароле. Аутентификация с открытым ключом больше подходит для ситуаций, когда вам нужно что-то вроде скрипта или программы, чтобы иметь доступ к SSH для другой системы, не требуя пароля, поэтому вам не нужно вставлять простые текстовые пароли в ваш скрипт / программу. - Registered User
@Deleted Account: вы можете установить кодовую фразу для закрытого ключа SSH. - Phil Cohen
Комментарий «Зарегистрированный пользователь» ошибочен. Просто уточнить: всегда устанавливайте хороший пароль на свой секретный ключ и не храните закрытый ключ на любых серверах. Храните закрытый ключ на своей рабочей станции. Когда вы добавите ключ в программу ssh-agent и введите свой пароль, вы можете войти в систему, в которой установлен открытый ключ, без повторного ввода пароля. Включите агент-переадресацию в своем ssh-клиенте, чтобы вы могли входить с сервера на сервер. Получение украденного закрытого ключа плохое, но с приличным паролем на нем это не так плохо, как украденный пароль. - Martijn Heemels
Правильно, даже не думайте хранить секретные ключи администратора незашифрованные. - yarek


использование http://denyhosts.sourceforge.net/

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


8
2018-03-09 09:37



Отключение пароля auth не всегда является жизнеспособным решением. - Publiccert


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


6
2018-03-08 11:33