SonicWALL нагрузочный тест блоков SRA как DoS-атака

A) осуществите проверку своей системы с ClamAV, чтобы видеть, обнаруживается ли что-либо необычное.

B) Выполненные средства проверки руткита, чтобы видеть, находят ли они что-нибудь необычным.

C) Выполните анализатор пакетов (tcpdump, wireshark) на Вашем рассматриваемом сервере, чтобы видеть, существует ли необычный трафик, пробегающий его.

D) проверьте/tmp,/var/log, и т.д. чтобы видеть, существуют ли какие-либо необычные временные файлы или файлы журнала, депонированные там.

E) окажись, иметь какие-либо программы как растяжка, установленная для поиска необычных изменений в системных файлах?

F) Согласуйте с другими администраторами, чтобы видеть, делали ли они что-то с тем сервером, который мог бы инициировать проверку в удаленной системе.

То, что точно делает журнал, ГОВОРЯТ, происходит? Запрос конкретного файла? Просто проверка с помощью ping-запросов его? Они выполняют процесс слушания на 443, который регистрирует то, что происходит, или у них есть законное вручение процесса запросами на том порте? Можно сузить немного (или устранить другие возможности) путем взгляда на то, что находится в запросе. Кроме того, IP Вашего сервера обнаруживается где-то в другом месте в их журналах, как запрос веб-страниц не-SSL или чего-то как этот?

Ваша система сканирует другие машины в Вашей сети? IP собирается для необычного действия в журналах другого сервера?

Можно также настроить что-то как Snort или Honeyd в сети для длительного контроля, чтобы видеть, продолжается ли что-то. Мой совет относительно моллюска и средств проверки руткита является только полурешениями с тех пор, если Ваша система поставлена под угрозу, только офлайновая проверка может на самом деле найти вредоносное программное обеспечение, если системные двоичные файлы были поставлены под угрозу (если у Вас нет другого сервера той же конфигурации, против которой можно выполнить md5 контрольные суммы на определенных двоичных файлах, чтобы видеть, вмешались ли в них).

0
задан 18 June 2012 в 14:23
1 ответ

I worked around this issue by lowering the number of load test clients from 25 to 20. After doing so, the device no longer dropped my requests as a DoS attack.

0
ответ дан 5 December 2019 в 16:16

Теги

Похожие вопросы