Что делать если на WEB сервере скомпрометирован root доступ?

Question

[3ton]

Так уж волей случая получилось что начальство дало root пароль стороннему человеку.
С компанией у него нет никаких юридических обязательств.
На сервере есть приватная инфа третьих лиц.
Нет никаких намеков на не добропорядочность данного лица, но если отталкиваться от важности сохранения конфиденциальности данных - какие действия можно предпринять чтоб обезопасить себя от последствий данного посещения сервера???

На сервере есть виртуальные машины, есть много веб сервисов которые содержат десятки тысяч файлов на разных языках программирования, поэтому советом просто переустановить систему ничего не решится. Кроме того виртуалки имеют и свой прямой доступ извне.

Answer 1

[Сергей]

Все зависит от того для чего были выданы права, на какой срок и какие работы проводились.
Смените пароль для начала.
Можно предположить что сторонний человек мог что-то установить, сделать, логи вам подскажут что делалось в системе, если конечно их не потерли)))
Если начальство будет спрашивать, просто укажите на то что: 1.не вы передавали пароль 2.не было задачи протоколировать действия
Ну и избегайте подобного в дальнейшем.

Comments

[3ton]

Выдано было для консультации, о выдаче мы узнали несколько дней спустя, что делалось - не в курсе.

[3ton]

кстати логи показали наличие таких строк(это не наши)

vi /root/.bash_history
exit

[Сергей]

3ton: проведите инвентаризацию ПО сервера, просмотрите логи от того периода и до настоящего времени, просмотрите работающие сервисы на предмет выявления новых или не регламентированных, сделайте актуальные резервные копии, смените рут пароль, кстати о птичках он должен быть запрещен, только через sudo.
Если не найдете ничего подозрительного, помониторьте сервер еще недельку и успокойтесь.

[Сергей]

3ton: затер свои действия)))) молодец, там хранится 1000 последних команд

[Владимир Куц]

Сергей: Он в принципе мог и вводить команды с пробелом в начале, чтобы они не попадали в историю

Answer 2

[Валентин]

Вряд ли туда вкорячили какой-то руткит, для вас повод задуматься о расширенном логировании действий в cli, а также мониторинга всех попыток входа в систему.

Answer 3

[pfg21]

На будущее настроить бекап, хотя бы системных файлов, настроек и т.д. чтобы было с чем сравнивать. что изменилось, что нового внеслось.
бекап **пу прикрывает во многих случаях.

в твоем случае попробовать посмтореть какие файлы во всей системе менялись за последние **цать дней, прошедших с момента компрометирования рута. решениение не полноценное (все файлы системы я так понял валидировать вручную нереально), работа будет дебильней некуда, но хотя бы попытка.

Зато теперь есть всеуниверсальная отмазка.

Answer 4

[CityCat4]

Первым делом обязательно сменить пароль.
Потом изучить логи - если они есть :)
Потом оценить изменения в файлах за интервал времени между утечкой пароля и его сменой.
Если у виртуалок свои руты, то они скорее всего не скомпроментированы - надо очень здорово извернуться, чтобы изменить что-то в образе диска машины из хостовой машины.
А вот хостовую машину все равно придется переставлять. Хотя утечка, если она была - она уже произошла и далее человеческий фактор - что это был за человек, что были за данные, насколько ему было интересно их тырить и что он мог утянуть в первую очередь.

Comments

[3ton]

У виртуалок свои руты, но LXC позволяет с хостовой сразу попасть в рут виртуалки без знания пароля виртуалки