Скомпрометированный сервер Debian, отправляющий DDOS-атаку
У меня есть сервер онлайн, который, очевидно, был скомпрометирован, и он отправляет DDOS-атаки на другой ip. Система представляет собой сервер Debian 7, на котором размещены несколько WordPress, веб-сайты Joomla и эфирное время для размещения радио. Fail2ban установлен и настроен.
У меня есть доступ в режиме восстановления, но я не смог найти ничего подозрительного в логах. Как только я загружаю систему в обычном режиме, она начинает посылать пакеты, и я не могу удаленно войти (ssh).
На следующем рисунке показаны пакеты, отправленные, как только я попытаюсь загрузить систему.
Любая помощь приветствуется.
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 и последней перезагрузки.
Система теперь чистая и снова работает.