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

196

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

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

Ответы:

207

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

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

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

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

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

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

Хольгер Джаст
источник
21
Такие приложения, как fail2ban, могут помочь «временно» остановить этих ботов от глупого утреннего удара по вашему серверу :-) У меня есть моя установка, чтобы запретить 3 неправильные попытки на 24 часа.
Emtunc
46
И перенести порт ssh с 22 на 222. Это работает довольно хорошо.
Том О'Коннор
40
+1, только аутентификация с открытым ключом :)
0xC0000022L
3
@STATUS_ACCESS_DENIED: действия fail2ban - это просто списки команд оболочки для запуска. Так что это действительно гибкий и простой способ правильно работать с любой пользовательской конфигурацией. Лучшая ссылка для загрузки и просмотра action.d/iptables.conf.
Mattdm
4
Блокировать нападающих, как это, пустая трата времени. Если вы отключите root-вход, есть большая вероятность, что никто никогда не будет угадывать ваше правильное имя входа, не говоря уже о пароле. Сам SSH уже ограничивает скорость запросов пароля, поэтому, даже если они знают ваше имя пользователя (случайные боты не будут), если у вас есть приличный пароль, они никогда не догадаются.
Брендан Лонг
58

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

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

Барт Де Вос
источник
2
Хорошая карта. Я хотел бы знать, как это сделать!
Jftuga
9
@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. Я видел карты получше, чем мои, где они использовали бы счетчик, чтобы раскрасить карту (от зеленого до красного для количества попыток на графство), но я не рассчитывал, что это получится
Барт Де Вос
3
Что вы подразумеваете под «реализованным стуком портов»? Есть ли приложение, которое я могу установить через apt-get для этого? Число, понижающееся до 0, звучит хорошо
18
Безопасность через неизвестность получает плохую окраску. Это прекрасно, если это часть общей стратегии, а не всей стратегии. В конце концов, что еще является паролем, кроме неясной строки?
Джоэл Коэль
5
@Joel Coel, это секретная строка, в отличие от большей безопасности из-за проблем с неизвестностью - неясный, но не обязательно секретный процесс.
tobyodavies
29

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

В netfilterнем есть 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
0xC0000022L
источник
2
Я использую это и иногда блокирую себя, поэтому мне нравится устанавливать другой порт, чтобы вы могли «постучать», чтобы снять запрет.
Бенлумли
@benlumley: хорошая мысль. Стук в порт также может быть полезен для изменения порта по умолчанию - или даже для их обоих в комбинации ...
0xC0000022L
@benlumley: видел твой комментарий (теперь Сэм удалил). Я абсолютно не против, если ответ будет отредактирован / улучшен;)
0xC0000022L
15

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

Иаков
источник
3
Если вы используете SSH, рассмотрите возможность аутентификации с открытым ключом. Это немного более безопасно, чем аутентификация по паролю.
Писквор
12

Да . Это вполне нормально в наши дни.

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

$ ssh-keygen -t dsa

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

Сконфигурируйте ваши серверы / etc / ssh / sshd_config так, чтобы они принимали только аутентификацию с открытым ключом:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

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

Посмотрите на Denyhosts и fail2ban, чтобы заблокировать повторные попытки входа по SSH, и посмотрите Snort, если вам требуется полная IDS / IPS.

JKJ
источник
2
Я бы не рекомендовал использовать аутентификацию с открытым ключом в SSH для доступа к вашему серверу. Если ваша рабочая станция скомпрометирована или, что еще хуже, украдена, тогда кто-то теперь имеет открытый доступ к вашим серверам без пароля. Аутентификация с открытым ключом больше подходит для ситуаций, когда вам нужно что-то вроде скрипта или программы, чтобы иметь возможность иметь SSH-доступ к другой системе без пароля, чтобы вам не нужно было вставлять простые текстовые пароли в ваш скрипт / программу.
Зарегистрированный пользователь
5
@ Удаленная учетная запись: Вы можете установить фразу-пароль для закрытого ключа SSH.
Фил Коэн
2
Комментарий «Зарегистрированный пользователь» ошибочен. Просто для пояснения: всегда устанавливайте надежный пароль на свой закрытый ключ и не храните закрытый ключ ни на каких серверах. Храните закрытый ключ на своей рабочей станции. Как только вы добавите ключ в программу ssh-agent и введете свой пароль, вы сможете войти в любую систему, в которой установлен открытый ключ, без необходимости повторного ввода пароля. Включите переадресацию агента в вашем ssh-клиенте, чтобы вы могли войти с сервера на сервер. Кража вашего закрытого ключа - это плохо, но с приличным паролем он не так плох, как украденный пароль.
Мартин Хеемельс
Да, даже не думайте хранить секретные ключи администратора незашифрованными.
2012 года
8

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

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

number5
источник
Отключение аутентификации по паролю не всегда является жизнеспособным решением.
Publiccert
6

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

Adamo
источник
6

Я бы сказал, что получить только 500 - это очень мало.

У предыдущего работодателя один из исследователей компьютерной безопасности назвал постоянный поток попыток взлома «интернет-эквивалентом космического шума ». Он описал это как нормальный непрерывный поток вредоносного трафика, который искал системы в Интернете и автоматически использовал сценарии для попытки взлома системы. Бот-сети и другие вредоносные системы постоянно сканируют и повторно сканируют Интернет на наличие уязвимых систем, таких как SETI.

Джеймс Шек
источник
6

Да,

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

Избегайте DNS связанных IP-адресов

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

Используйте VPN для всего доступа SSH

Если вы находитесь в среде, в которой вы можете внедрить IPsec / VPN в частную сеть в вашей серверной среде, это идеально. Отключите весь доступ к SSH-Интернету, убедитесь, что у вас есть интегрированное решение для отключения света. Настройте VPN и разрешите доступ по SSH только через VPN.

Внедрить правила IP-адреса для доступа по SSH

Если VLAN не подходит, настройте маршрутизатор или правила брандмауэра, чтобы разрешить только SSH-соединения из известного диапазона IP-адресов.

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

Бен ДеМотт
источник
5

Довольно нормально видеть сотни неудачных соединений SSH.

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

Адриан Макнейл
источник
5

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

Чтобы найти адрес злоупотребления, начните с arin.net и найдите IP-адрес с помощью whois. Вы можете быть перенаправлены в другой региональный реестр, но в конечном итоге вы можете найти ответственного интернет-провайдера для блока IP, который содержит адрес. Ищите адрес злоупотребления или просто отправьте техническую информацию по почте.

Отправьте им вежливое сообщение с соответствующими записями в файле журнала (обязательно удалите любую личную информацию) и попросите их принять меры против хоста-нарушителя.

JRW
источник
4
Мы привыкли делать это. Однако количество потраченного времени и полученная выгода были настолько малы, что это не имеет значения.
NotMe
1
Вариант этой тактики, который является более эффективным, но гораздо более рискованным, состоит в том, чтобы сообщить ISP промежуточному узлу. Но вы ДОЛЖНЫ иметь доказательства в своем отчете. Однажды у меня возникли серьезные проблемы с целым провайдером, потому что они игнорировали свои сообщения о злоупотреблениях.
staticsan
1
Однажды, когда я сделал это, сообщение о злоупотреблении достигло хакера, а не человека, отвечающего за серверы. С тех пор я больше не беспокоюсь, просто слишком много проблем.
wump
Это действительно не поможет в большинстве случаев и может занять много времени
RichVel
4

Я бы порекомендовал не использовать fail2ban, а использовать SSH (и другие) на нестандартном порту. Я не верю в безопасность по незаметности, но думаю, что это отличный способ уменьшить шум в ваших журналах.

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

Вы даже можете пойти дальше и установить приманку SSH, такую ​​как Kippo, чтобы «впустить» брутфорсеров и посмотреть, что они будут делать, если у них будет такая возможность.

Энди Смит
источник
Ха-ха, Киппо выглядит очень мило. Я собираюсь установить его на сервер, чтобы посмотреть, что они пытаются сделать.
wump
4

Да, это нормально. Что я говорю клиентам в вашей ситуации с небольшими сайтами.

Всегда будьте готовы быть взломанными.

Имейте копию своего сайта на сервере разработки. Это может быть ваш рабочий стол Windows с использованием XAMPP, который вы можете получить бесплатно.

ВСЕГДА вносите изменения в свой сервер разработки, а затем загружайте их на свой действующий веб-сайт. Если это CMS, похожая на Wordpress, разместите свои сообщения на сервере разработчика, затем скопируйте и вставьте их в оперативный сервер.

НИКОГДА не загружайте ничего с вашего живого веб-сайта на ваш сервер разработки.

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

Если вы скомпрометированы. Оповестите свой хост, удалите все, измените все пароли и загрузите свой чистый сервер разработки на теперь пустой веб-сервер. Работайте с вашим хостом, чтобы предотвратить повторение.

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

Надеюсь это поможет.

Дж Литтен
источник
2
+1 за «Всегда будь готов к взлому».
user78940
3

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

Записи WHOIS локальных интернет-провайдеров помогли мне сократить количество атак до 1-2 попыток входа в месяц (тогда это было около 1 тыс. В день). Я обнаружил это, все еще используя denyhosts .

weeheavy
источник
3

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

Пример:

AllowUsers admin jsmith jdoe

Опция AllowUsers указывает и контролирует, какие пользователи могут получить доступ к службам ssh. Можно указать нескольких пользователей, разделенных пробелами.

сойка
источник
3

Да, это нормально. Ты можешь :

  • Уменьшите возможность атаки с помощью fwknop

Fwknop - это одна из лучших реализаций стука портов, поскольку она не подделывается и фактически аутентифицируется, а не просто авторизует соединение.

  • Вы можете изменить порт, который использует Openssh, но вы не улучшаете безопасность.

  • Укрепить SSH-аутентификацию, используя Google-authenticator или wikid

Это защитит парольные атаки и возможность решительного нападения / целевой атаки скомпрометировать ваш компьютер администратора и украсть вашу комбинацию ssh-key & password.

Достаточно взглянуть на последнюю версию pwn2own, чтобы понять, насколько легко для опытного злоумышленника может быть скомпрометировано ваше полностью исправленное окно администратора.

Хилтон Д
источник
1

К сожалению, это вполне нормально. Вы должны рассмотреть возможность добавления чего-то вроде fail2ban в вашу систему, чтобы автоматически обнаруживать и блокировать злоумышленников. Если вы этого еще не сделали, вам также следует рассмотреть возможность использования только ssh с открытыми ключами и не разрешать вход в систему root через ssh. Если для передачи файлов в систему используется ftp, рассмотрите возможность использования scp / sftp.

user619714
источник
1

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

Я также запустил fail2ban с Shorewall в качестве брандмауэра, чтобы временно занести в черный список постоянных злоумышленников.

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

Ограничение доступа к авторизованным ключам также может быть полезным.

BillThor
источник
0

Я использую pam_ablдля временного черного списка грубых силовиков, и это прекрасно работает. Я думаю, что лучше иметь авторизацию в PAM, используя свою собственную базу данных, а не зависеть от hosts.denyили iptables.

Еще одним плюсом является то, pam_ablчто не зависит от сканирования файлов журнала.

Кристофер Хаммарстрём
источник
0

В наши дни это совершенно нормально.
Вы можете установить «пакетный» лимит на брандмауэр для входящих новых соединений через порт SSH,
или установить один из многих парсеров журнала a'la fail2ban или изменить порт SSH;).

Последний самый простой. На тяжело нагруженных машинах такие попытки взлома могут очень сильно повлиять на всю систему.

-
С уважением,
Роберт

Роберт
источник
0

Да это нормально.

Я просто изменил порт ssh в отличие от стандартного 22. Мой сервер, мои правила :), просто отредактируйте / etc / ssh / sshd_config, измените порт и перезапустите службу. Единственным недостатком является то, что вы должны не забыть добавить этот порт в конфигурацию для каждого используемого вами ssh-клиента.

Джон
источник
0
  • Отключите вход в систему с правами root (в каждой системе Linux есть пользователь root, чтобы боты могли легко угадать имя пользователя). После входа в систему как обычный пользователь вы можете переключиться на root с помощью su или sudo.

  • изменить порт по умолчанию с 22

  • Разрешить ssh доступ только с известных ip

  • Используйте надежный буквенно-цифровой пароль для пользователя с доступом по SSH

Кевин Паркер
источник