Как очистить данные при стирании / переустановке скомпрометированного сервера?
У меня есть сервер, который был взломан, где журналы были взорваны, и у меня нет ни возможности, ни времени, чтобы узнать, какие именно части системы были изменены. Сервер был отключен, и около 400 гигабайт исследовательских данных от нескольких пользователей было перенесено в другую автономную резервную копию. Я сканировал каталоги с помощью Clam, но обеспокоен тем, что в тысячах файлов могут быть остатки вредоносного кода.
Файлы представляют годы регистрации данных, но у меня нет резервных копий, с которыми я мог бы их сравнивать (это проникновение было первым, когда мне сообщили об этих серверах «под моим контролем», и грядут некоторые серьезные изменения), ни знаний из того, что должно / не должно содержаться внутри. Есть ли какой-то более тщательный способ убедиться, что данные не содержат неактивных фрагментов вредоносного кода? Я могу попытаться помешать выполнению сценариев из моих каталогов резервного копирования, но я предполагаю, что в какой-то момент один из пользователей будет удивлен, почему какой-то код, который они написали 2 года назад, не работает, и в результате он отменит любую добавленную мной систему безопасности.
TL; DR : я был в собственности. Как мне убедиться, что данные, которые я копирую на новую установку сервера, не содержат потенциально вредоносный код?
1 ответ
Ответ новичка:
- монтируются с
noexecопция так, исполняемые файлы и библиотеки не могут работать вообще (сценарии не могут работать также, но они могут все еще быть вызваны сbash malicious.sh).
Или
- устанавливают некоторый сейф chroot среда , таким образом, Вы не делаете сногсшибательный вся "система", когда вирус пытается уничтожить Вас, Г la honeypot.
Опция 1 имеет очевидный недостаток, Вы не можете выполнить законный код, опция 2 имеет очевидный недостаток, один единственный неправильно себя ведущий исполняемый файл может уничтожить все Ваши законные данные.
, Кроме того, хороший дизайн разрешения (пользователи, группы, липкий бит, setuid бит, и т.д.) и строгий umask должен гарантировать, что пользователь только в состоянии к аварийно завершенному его собственные файлы (или в его ответственности), который лучше, чем полное разрушение в случае нападения.
можно также использовать файловая система с поддержкой снимка (я не буду рекламировать ZFS слишком много, это имеет хорошие вещи и плохие вещи, можно дать ему попытку). Это не предотвратит корень получения нападения полномочия эскалации и удаление Ваших снимков, но если это - просто разрушение данных, можно вернуться назад к предыдущему состоянию).