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

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

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

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

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

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

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

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

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

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

Я, например, использую «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

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

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

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

$ 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.

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

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

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

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

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

Да,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

AllowUsers admin jsmith jdoe

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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