Я установил OSSEC на свой сервер и получаю отчеты, похожие на следующие:
11 января, 19:27:03 Папа sshd [14459]: pam_unix (sshd: auth): ошибка аутентификации; logname = uid = 0 euid = 0 tty = ssh ruser = rhost = 58.215.184.93 пользователь = root
11 января, 19:26:54 Папа sshd [14457]: pam_unix (sshd: auth): ошибка аутентификации; logname = uid = 0 euid = 0 tty = ssh ruser = rhost = 58.215.184.93 пользователь = root
Повторяется примерно 10 раз в электронном письме. До сих пор не прошло и дня без 3 или 4 таких писем от OSSEC. Конечно, моя первоначальная эмоция - это немного ярости и «как они смеют пытаться взломать мой ящик!» но я думаю, что в любом случае это состояние сети в наши дни. На днях у меня тоже кто-то пробовал использовать bin bin
Я также получил это сообщение:
12 января 02:04:07 Daddy sshd [16109]: проверка обратного сопоставления getaddrinfo для static-52-53.mk-net.ru [91.211.52.53] завершилась неудачно - ВОЗМОЖНАЯ ПОПЫТКА ВЗРЫВА!
(опять же, с многократным повторением)
Я знаю, что по крайней мере один благоприятный источник обратного сопоставления исходит из freenode, когда они пытаются убедиться, что вы не являетесь вероятным ботнетом, но я не проверял этот источник.
Мы очень болезненно относимся к проблеме уязвимостей, особенно с учетом того, что предыдущий сервер был взломан (вероятно) через phpMyAdmin.
Очевидно, что любые советы / ресурсы по защите нашего сервера будут оценены, но мой главный вопрос таков: стоит ли нам беспокоиться об этих попытках взлома? У пользователя root нет пароля (вход в систему отключен), поэтому можно ли игнорировать эти неудачные попытки входа в систему? Что еще я мог или должен сделать, чтобы ограничить возможные уязвимости на этом пути? Эта система находится за маршрутизатором с открытыми только необходимыми (например, службами, которые мы используем) портами (ssh, apache и postfix).
Да, вы можете определенно игнорировать неудачные попытки root-доступа, если root-вход через SSH отключен - и о сбоях обратного DNS не стоит беспокоиться; они вполне могут быть от злоумышленника, но это просто несогласованная конфигурация их провайдера.
Если вы хотите немного поспать, обратите внимание на fail2ban - его можно настроить на временную блокировку IP-адресов злоумышленников после повторных сбоев.
Я должен беспокоиться? только если вы не уверены, как это защищено.
С SSH наивысшая форма безопасности - это принудительный вход по ключу и парольной фразе.
Вы можете значительно сократить (но не остановить) попытки входа в систему по SSH, но изменив номер порта с 22 по умолчанию на другой. Он не делает ничего для повышения безопасности, но откладывает множество автоматических зондов, которые проверяют общие номера портов, чтобы узнать, есть ли служба прослушивания.
Если это возможно, разрешите TCP-подключения к порту 22 из известных мест только с помощью правил вашего брандмауэра. В противном случае существуют способы заблокировать / заблокировать брандмауэром несколько неудачных попыток подключения из этих мест. fail2ban - один из скриптов, который это делает (как уже упоминал Шейн). Я могу порекомендовать его, так как использовал его раньше.