Блин, неприятно оказываться взломанным… Злые хацкеры из Бразилии поломали мне хостинги – дефейснули, точнее, через очередную дырку в пхп-софте клиентов, в принципе, это фигня, но вот дальнейший разбор полетов показал, что взлом зашел слишком далеко – на серваке обнаружился rootkit. Штука весьма неприятная, но тоже лечимая – поскольку удалось вычислить кто и как им управляет и я это дело быстренько закрыл, но потом оказалось, что половина системных файлов уже пропатчена для того, чтобы руткит нельзя было вычислить. Помогла штука под названием busybox – она включает в себя практически все файлы, которые обычно подменяются. С ее помощью я начал вычищать и восстанавливать файлы. Хакеры (или руткит) использовали очень интересную штуку – аттрибуты файлов (у ext2 файловой системы есть набор некоторых аттрибутов, которые так просто и не увидишь). Когда я пытался удалить “зараженный” файл, система сообщала мне, что Operation not permitted. И это при том, что я был рутом! Спасли команды lsattr, chattr – которые как раз и показывают и меняют эти хитрые аттрибуты. В общем процесс более-менее наладился, пока я не напоролся на файл ifconfig – он не удалялся никак… Дальнейшие проверки показали, что файловая система повреждена – inode файла был отрицательным. Я попробовал запустить fsck – меня предупредили о неприятностях и я ребутнул машину. Больше я ее удаленно не видел. Звонок к провайдеру обрадовал – на консоли висела надпись Unable to mount root file system.
Пришлось ехать на площадку к провайдеру, большое спасибо товарищу apl, за содействие в последующем. На месте оказалось, что fsck после 2х часовой работы не принес никаких результатов и linux пришлось снести… Хорошо, что были бэкапы юзерских данных и конфигов. Правда я уже вторые сутки занимаюсь восстановлением сервера и спал за это время только часа четыре, но все-равно, могло быть и хуже.
Теперь там вместо линукса стоит FreeBSD и я надеюсь, что с безопасностью будет полегче, все ж под фрю ставить необходимый софт и его потом апдейтить значительно легче, чем под линух. Да и саму фрю держать в свежем виде легче.
Из всего произошедшего можно сделать следующие выводы:
-Паранойя в среде админов – это правильное явление.
-Самое большое внимание надо уделять php – именно тудой происходит большинство “пролезаний” в систему.
-Нужно ставить системы мониторинга целостности системы и регулярно читать их отчеты.
-Вполне неплохим решением может быть установка системы обнаружения проникновения или осуществления попыток.
-Фаерволл должен находится в режиме default to deny и держать открытым ограниченное количество портов. В идеале не должны быть вообще доступны непривилегированные порты.
-/tmp должна быть отдельной системой, смонтированной как nodev, nosuid, noexec – т.е. даже если “плохие парни” выполнят код, скачают в темп какой-нить эксплойт, то запустить его им не удастся.
Наверняка найдется еще куча советов, но сейчас я очень хочу спать и вряд ли их вспомню 🙂