Назад | Перейти на главную страницу

Может ли DDoS-атака помешать мне подключиться к моему серверу по SSH?

Может ли DDoS-атака помешать мне ssh'ing на мой сервер?

Мой босс говорит нет, значит, что-то не так с сервером. Однако мы получаем боты от 4-5 разных ботов даже с robots.txt и .htaccess переписывает.

Мой парень, занимающийся PHP, считает, что это боты, и я склонен согласиться, но возможно ли, чтобы атака помешала мне самому войти по ssh на мой сервер?

Абсолютно да, потому что DDoS-атака предназначена для перегрузки ресурсов сервера. Это означает, что ваша средняя нагрузка резко возрастает, а ваша память заполнена до точки, в которой вы можете ее выгружать на диск. И это не обязательно должна быть просто атака на порт 22. Я управлял множеством веб-серверов, которые становились недоступными из-за описанного выше сценария.

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

Другой альтернативой является мучительное ожидание установления SSH-соединения, пока ваш сервер подвергается DDoS-атаке. Иногда получается. Но иногда мне нужно открыть несколько окон и посмотреть, какое из них пройдет первым.

РЕДАКТИРОВАТЬ: И если вы хотите заранее определить, использует ли ваша система ресурсы, я настоятельно рекомендую использовать Монит. Я использую подобный сценарий в Monit, который помимо отправки мне сообщений по электронной почте, когда что-то происходит, выполняет две функции. Один из них определяет, недоступен ли ваш веб-сервер (он же недоступен), и автоматически перезагружает его. Но для вас возможно loadavg площадь имеет наибольший смысл. У меня здесь установлено значение 7, и он пытается перезапустить сервер, чтобы очистить соединения и попытаться вернуть его под контроль, если средняя нагрузка постоянно составляет 7 или выше. Такие вещи, как использование Monit, в значительной степени гарантируют, что вы лучше справитесь с DDoS, когда это произойдет.

check process apache with pidfile /var/run/apache2.pid
        start "/etc/init.d/apache2 start"
        stop  "/etc/init.d/apache2 stop"
        if failed host 127.0.0.1 port 80
                with timeout 15 seconds
        then restart
        if loadavg (1min) greater than 7
                for 5 cycles
        then restart
        alert username@myserver.com only on { timeout, nonexist, resource }

От кого-то, кто подвергался атакам DDOS, работал в индустрии хостинга и имел нулевые IP-адреса жертв, да, DDOS может вывести из строя весь сервер и любые услуги, которые он предоставляет, а также плохо спроектированную сеть и все такое. серверов в этой сети.

Это правда, что боты тоже могут вывести из строя сервер; вот почему вы захотите настроить хороший robots.txt с crawl-delay чтобы уменьшить частоту сканирования сайта роботами (некоторые боты игнорируют crawl-delay и просто нужно заблокировать; Baidu, например, игнорирует crawl-delay хотя там написано, что они не игнорируют это на своем сайте).

Вы можете заблокировать вредоносных ботов с помощью RewriteRules в пределах .htaccess файл. Ниже приведен пример блокировки Baidu:

RewriteCond %{HTTP_USER_AGENT} Baiduspider/2\.0
RewriteRule ^.* - [R=404,L]

Да, но есть и другие причины.

Я предполагаю, что вы сначала исключили iowait, поэтому следующим моим предложением будет захват пакетов вашего DNS-трафика и проверка правильности работы обратного DNS-поиска. В экстремальных сценариях из-за сбоев DNS время входа в систему может истекать, даже если аутентификация прошла успешно. (конечно, если UseDNS no установлен в sshd_config, это совершенно спорный вопрос)

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

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