2

Моды: Обратите внимание, что этот вопрос конкретно касается сервера, который управляется через cPanel и WHM, что отличает его от предполагаемого дублирующего вопроса.

В прошлом месяце мой личный веб-сервер получил тысячи таких уведомлений. Обратите внимание, что мой сервер в основном управляется WHM/cPanel, хотя у меня есть root ssh, ftp и другие традиционные точки доступа.

Эти атаки начались с попытки root , но с тех пор перешли к попытке учетных записей пользователей, где я не уверен, как они даже угадали правильные имена пользователей (хотя и неправильные пароли).

Есть ли способ предотвратить такие атаки?

Кроме того, вот число автобанов, перечисленных только сегодня, и небольшое количество источников IP-адресов - время атаки в прошлом месяце в основном составляет около 6:30 утра по восточному побережью до 23:00:

2 ответа2

4

Вы говорите это:

В прошлом месяце мой личный веб-сервер получил тысячи таких уведомлений.

Не паникуйте! Просто отключите учетную запись root в системе.

Добро пожаловать в современный интернет! Не принимайте никакие из этих уведомлений лично и не принимайте их как признак целенаправленной атаки на ваш веб-сервер. Скорее, это обычная часть любого веб-сервера, существующего каким-либо образом в сети: армии ботнетов постоянно сканируют веб-серверы на наличие слабых мест, а затем иногда используют эти недостатки по разным причинам / взломам.

Если вы обеспокоены, лучшая, самая простая и легкая вещь, которую вы можете сделать, чтобы исправить эту ситуацию, - отключить пользователя root на сервере, а затем назначить права sudo другому пользователю в системе. Делая это, вы устраняете проблему, не устанавливая никакого дополнительного программного обеспечения.

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

Самый простой способ сделать это в вашей системе - это сначала назначить права sudo любому другому пользователю в системе, кроме root . И как только это будет сделано, войдите в систему как этот пользователь через SSH и выполните эту команду:

sudo passwd -l root

Это эффективно заблокирует учетную запись пользователя root . Так пусть эти боты не пытаться войти через root теперь , пока навсегда ... С root отключенной усилия тщетны.

Тем не менее ... Может быть, вы должны быть обеспокоены.

Но тогда вы говорите это; Акцент мой:

Эти атаки начались с попытки root , но с тех пор перешли к попытке учетных записей пользователей, где я не уверен, как они даже угадали правильные имена пользователей (хотя и неправильные пароли).

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

Итак, вы говорите, что они пытаются «учетные записи пользователей», но какие пользователи? Соответствуют ли они действительным пользователям в системе? Если они не соответствуют действительным пользователям в системе, не волнуйтесь ... Даже если время от времени вы видите попытку войти в систему как tomcat или testuser . Эти боты просто перебирают десятки / сотни / тысячи имен пользователей, которые они имеют в своей библиотеке, чтобы увидеть, в какую учетную запись они могут войти ... И я бы не стал спать из-за этого.

Но если попытки «взлома» направлены против чисто определенных / известных аккаунтов? Тогда ты должен волноваться.

Но, тем не менее, если атаки каким-то образом направлены только на пользователей, которые существуют в вашей системе, вы можете предположить, что хакеры каким-то образом получили копию вашего файла /etc/passwd . Во-первых, несмотря на то, что в истории есть имя passwd этот файл не содержит пароли пользователей, а содержит основную информацию о пользователях. И если у злоумышленников есть этот файл /etc/passwd , то у вас НАМНОГО большая проблема .

Если определенные / известные учетные записи «взломаны», возможно, ваше веб-приложение взломано.

Обычно на веб-серверах основной компромисс заключается не в SSH или чем-то подобном, а в самом веб-приложении / сервере. То есть, если ваш сайт основан на известной системе CMS, такой как WordPress или Joomla! хакерам удалось проникнуть в вашу систему через это веб-приложение, которое затем проникло в систему на более глубоком уровне, что эквивалентно наличию SSH-доступа, но не глубокому SSH-доступу.

Это означает, что веб-серверы, работающие на программном обеспечении, таком как Apache, управляются пользователем без полномочий root, таким как www-data или что-то в этом роде. Компрометация вашего веб-приложения будет означать, что хакер имеет тот же уровень доступа, который имеет Apache, но не имеет ничего общего с уровнем «записи»… Но все же страшный уровень доступа на уровне «чтения».

Таким образом, вполне возможно, что веб-приложение на вашем сервере было взломано, полезная нагрузка была сброшена на ваш сервер на уровне пользователей Apache, и они каким-то образом получили файл /etc/passwd через этот взломанный доступ. И теперь они пытаются получить доступ через имена пользователей в этом /etc/passwd .

Что делать, если ваше веб-приложение было взломано.

Так ты должен бояться? Если это так, то да. Но Fail2ban не спасет тебя сейчас. Отключение root прежнему может спасти вас до некоторой степени. Но если ваше веб-приложение скомпрометировано, оно должно быть очищено. Попытки SSH просто взламывают «соус» поверх сервера, который уже чем-то заражен.

Как очистить ваше веб-приложение? Простого ответа не существует, но если вы используете WordPress, например, рассмотрите возможность переустановки WordPress, а затем переустановите настройки своего сайта с помощью резервных копий.

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

1

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

В этом случае есть очень полезный инструмент под названием Fail2Ban. Этот инструмент в основном проверяет некоторый файл журнала, ища шаблоны, которые вы определили при сбое конфигурации, и, если есть X попыток в Y сек с того же IP, IP блокируется на некоторое время, поэтому он не может пытаться продолжить.

Поскольку вы говорите, что Dev-ops не ваша сильная сторона, есть ссылка, которая хорошо иллюстрирует необходимые детали, поэтому она работает без особых проблем. Так что вам просто нужно найти файл журнала, в котором ведутся ваши попытки грубой силы, определить новую тюрьму, которая является просто комбинацией описанного выше, и, возможно, самая "сложная" вещь - это получить шаблон, который будет соответствовать этим записям. в вашем журнале, которые основаны на регулярных выражениях. Если вам нужна помощь, вы можете обновить свой вопрос некоторыми из этих строк, и я могу помочь вам синтезировать регулярное выражение, которое будет соответствовать.

Остальное - просто запустить демона и больше не беспокоиться об этих попытках грубой силы.

Примечание: в Fail2Ban уже есть несколько встроенных джейлов, которые работают довольно хорошо (например, SSH).

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .