Скомпрометированный сервер Debian, отправляющий DDOS-атаку

Question

У меня есть сервер онлайн, который, очевидно, был скомпрометирован, и он отправляет DDOS-атаки на другой ip. Система представляет собой сервер Debian 7, на котором размещены несколько WordPress, веб-сайты Joomla и эфирное время для размещения радио. Fail2ban установлен и настроен.

У меня есть доступ в режиме восстановления, но я не смог найти ничего подозрительного в логах. Как только я загружаю систему в обычном режиме, она начинает посылать пакеты, и я не могу удаленно войти (ssh).

На следующем рисунке показаны пакеты, отправленные, как только я попытаюсь загрузить систему.

Любая помощь приветствуется.

Answer 1

Я наконец решил ее, и я должен отметить, что на изображении, прикрепленном в вопросе, показаны отправленные исходящие пакеты, не из-за какой-либо атаки ddos, а из-за трафика, генерируемого при перезагрузке в "режиме восстановления".

Вот шаги, которые я предпринял, чтобы решить эту проблему:

1 - Запустите режим восстановления с консоли online.net.

2- ssh в "режиме восстановления" и смонтируйте проблемную файловую систему, обратите внимание, что ваше устройство может отличаться от следующей команды:

$ mount /dev/sda2 /mnt

3- Проверьте логи на сервере:

$ cat /var/log/syslog
$ cat /var/log/dmesg
$ cat /var/log/messages
$ cat /var/log/fail2ban.log
$ cat /var/log/auth.log

Кроме того, ваш apache2 access.log и / или любые другие важные журналы в вашей системе.

4. Поиск любого файла, измененного за день или два до атаки:

$ find /mnt -mtime -3 -ls

5- Проверьте систему на наличие руткитов (rkhunter) или вирусов (clamav)

Поскольку я не мог найти ничего подозрительного, я проверил, есть ли какая-либо служба удаленного доступа в консоли online.net (я хотел бы подумать об этом раньше), и так оно и было. Затем я перезагружаюсь в обычном режиме и могу убедиться, что система не загружается из-за ошибок в /dev /sda2. Чтобы решить эту проблему, я перезагрузился в режиме восстановления и сделал

$ fsck2 /dev/sda2

Были некоторые поврежденные иноды, я ответил Да, чтобы восстановить их все.

6- Затем я снова перезагрузил систему, но процесс загрузки получил "чистку временных файлов". Чтобы решить эту проблему, я изменил TMPTIME на 60 в следующем файле:

/ И т.д. / по умолчанию / RCS

Примечание. Не забудьте решить эту проблему и вернуть этот параметр на 0 при успешном входе в систему, оставив TMPTIME для удаления файлов tmp старше 60 дней, это угроза безопасности

7. После нескольких незначительных ошибок я мог наконец войти в систему, вернуть необходимые настройки к значениям по умолчанию и заново отсканировать всю систему с помощью rkhunter и clamav, apt-get update && apt-get upgrade и последней перезагрузки.

Система теперь чиста и снова работает.