Відновлюємо сервер після злому
Отже, розглянемо на прикладі сервера, який був зламаний шляхом закачування експлоїта через помилку в php скрипт, запуск через нього ж і отримання доступу до shell з правами веб-сервера. Про це красномовно свідчать "сліди" в директоріях, доступних на запис для всіх: / tmp, / var / tmp, / dev / shm.
[Ad # ad-5]
Злому можна було б уникнути на цьому етапі, примонтировать розділи для тимчасових файлів без права запуску, відключенням небезпечних функцій php і просто більш ретельно кодом в php. Однак нічого цього зроблено не було.
Хакер не втрачав часу дарма. Він закачав різноманітні експлоїти, скомпілював їх і після запуску отримав права суперкористувача root, скориставшись однією з вразливостей.
І на цьому моменті можна було б його зупинити, відключивши wget і компілятори для непривілейованих користувачів і поставивши патч, який забороняє виконання коду в стеці або libsafe. Але, на жаль, і це не було зроблено.
Ситуація була неоднозначною. З одного боку - дуже важливі дані, втрата яких критична, з іншого боку - проблема backdor, коли хакер міг би зайти за допомогою якогось користувача або виславши певний набір пакетів демона, хто слухає порт. Було прийнято рішення про відновлення сервера і надалі ретельно спостереженні за ним.
Відключивши ряд процесів, які явно носили в собі щось чуже системі, насамперед був встановлений, оновлений і запущений rkhunter - утиліта для вилову троянів.
Висновок rkhunter був невтішний - мінімум два руткита, маса змінених бінарників.
У такій ситуації допоможе тільки одне - заміна зараженого руткітом бінарники на чистий. Однак необхідно знати, які саме бінарники замінювати. Але тут трохи пощастило. Хакер поставив на змінені файли атрибути, які забороняють зміна, видалення або заміну файлу за допомогою команди chatter. Для неофітів, знайомих тільки з chmod, це створило б ефект контролю над системою з боку хакера - заражені бінарники НЕ переписуються, хоча права на запис стоять.
Створивши список заражених бінарників, всі атрибути вдалося відновити командами
chattr -iacsuASDd / bin / *
chattr -iacsuASDd / sin / *
chattr -iacsuASDd / sbin / *
chattr -iacsuASDd / usr / sbin / *
chattr -iacsuASDd / usr / bin / *
chattr -iacsuASDd / usr / local / bin / *
chattr -iacsuASDd / usr / local / sbin / *
Однак ряд бінарників, які не були захищені від зміни, все-таки були заражені. Це показав rkhunter. Таким чином, стало ясно, що це неординарний зломщик, який спеціально залишив зламані файли з метою їх відновлення. Відповідно, в системі встановлений backdor.
Також не працював ряд команд, хоча rkhunter цього не показав. Наприклад, top не виводив ряд присутніх в системі процесів. По всій видимості, зараження було на рівні модуля ядра, що забезпечувало стелс-захист заражених бінарників.
Однак хакер не передбачив, що в rpm-based дистрибутивах Linux є можливість дізнатися, чи був змінений файл чи ні за допомогою rpm.
Методика досить проста - спочатку дізнаємося, де розташований підозрілий бінарник, наприклад:
Ця команда видасть повний шлях до утиліти top - / usr / bin / top. Тепер за допомогою rpm дізнаємося, до якого пакунку відноситься дане зображення:
rpm -qf / usr / bin / top
Ця команда повідомить, що утиліта top входить в пакет procps. Перевстановити його за допомогою менеджера apt командою:
apt-get --reinstall install procps
Під час установки було повідомлення, що попередній top був слінкован з бібліотекою /lib/libext-2.so.7. Можливо, це і є частина стелс-механізму. Запитавши за допомогою rpm інформацію про бібліотеці
rpm -qf /lib/libext-2.so.7
була отримана інформація, що даний файл не є частиною системи. Природно, що він був видалений:
chattr -iacsuASDd / lib / *
rm /lib/libext-2.so.7
Далі виявилося кілька прихованих процесів, які були вбиті за допомогою утиліти killall.
Природно, що перевстановити довелося не тільки procps, але і ряд інших пакетів, підозрюваних у зломі: util-linux, psmisc, net-tools, kernel, dev, initscripts і багато інших.
Після заміни ядра сервер був перезавантажений і була проведена перевірка зміни всіх файлів за допомогою команди
rpm -Va
Були помічені непрямі ознаки наявності в системі backdor. Після невеликого дослідження системи бекдор був виявлений. Також було виявлено, що у всіх системних користувачів змінена оболонка на / bin / sh. Таким чином, це дозволяло звернутися до backdor від імені будь-якого користувача. Для уникнення такої ситуації був відключений ряд небажаних сервісів і створений новий користувач, який може заходити через мережу в оболонку через ssh. Всі інші були відключені.
В даний час не помічено ніяких спроб несанкціонованого доступу, що свідчить про досить високий рівень зломщика і небажанні його засвітитися.
Дана історія описана за згодою власника зламаного сервера. За його словами, все що він зробив, це додав підтримку php в apache. Про те, до яких наслідків це може призвести, він навіть і не підозрював.
Будьте пильні! Під час літніх канікул відбувається дуже багато зломів. Захищайте свій виділений сервер до того, як його зламають. Запобігайте злом на різних рівнях. І головне - періодично перевіряйте вміст каталогів для тимчасових файлів. Можливо, що там вже щось є.
Особливо остерігайтеся файлів, що починаються з точки або складаються з одних прогалин, - це пряме свідчення успішного злому.