Думается мне, данная задача выглядит как не выполнимая, тем не менее, может у кого-то есть идеи. Есть UNIX-like операционаая система (Mac OS X, если быть точнее), для которой хотелось бы получить решение позволяющее защитить приложение от удаления. Осложняет это дело тот факт, что хотелось бы защититься от удаления root-ом. В принципе, удаление файлов можно блокировать посредствам драйвера-фильтра файловой системы, но есть ли какая-то возможность защитить сам дрйвер от выгрузки?
Буду рад комментариям не только для Mac OS, но и для BSD и Linux систем
Здравствуйте, kaa.python, Вы писали:
KP>Думается мне, данная задача выглядит как не выполнимая, тем не менее, может у кого-то есть идеи. Есть UNIX-like операционаая система (Mac OS X, если быть точнее), для которой хотелось бы получить решение позволяющее защитить приложение от удаления. Осложняет это дело тот факт, что хотелось бы защититься от удаления root-ом. В принципе, удаление файлов можно блокировать посредствам драйвера-фильтра файловой системы, но есть ли какая-то возможность защитить сам дрйвер от выгрузки?
KP>Буду рад комментариям не только для Mac OS, но и для BSD и Linux систем
Можно запустить систему под гипервизором и драйвер-фильтр запускать в гипервизоре а не в гостевой системе.
Здравствуйте, RomikT, Вы писали:
RT>Можно запустить систему под гипервизором и драйвер-фильтр запускать в гипервизоре а не в гостевой системе.
Ммм.. думаю что не пойдет. Ситуация следующая: есть DLP система, которую хотелось бы защитить от удаления. Соотвествтенно ставится она сверху на уже существующую конфигурацию пользователя и запустить систему под гипервизором не выйдет.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, RomikT, Вы писали:
RT>>Можно запустить систему под гипервизором и драйвер-фильтр запускать в гипервизоре а не в гостевой системе.
KP>Ммм.. думаю что не пойдет. Ситуация следующая: есть DLP система, которую хотелось бы защитить от удаления. Соотвествтенно ставится она сверху на уже существующую конфигурацию пользователя и запустить систему под гипервизором не выйдет.
Тогда можно chattr +i сделать. От случайного удаления рутом защитит.
Здравствуйте, kaa.python, Вы писали:
KP>Думается мне, данная задача выглядит как не выполнимая, тем не менее, может у кого-то есть идеи. Есть UNIX-like операционаая система (Mac OS X, если быть точнее), для которой хотелось бы получить решение позволяющее защитить приложение от удаления. Осложняет это дело тот факт, что хотелось бы защититься от удаления root-ом. В принципе, удаление файлов можно блокировать посредствам драйвера-фильтра файловой системы, но есть ли какая-то возможность защитить сам дрйвер от выгрузки?
Если пользователю разрешается загрузиться с флопика, то в "целевой" системе он все, что угодно, сможет удалить.
Здравствуйте, Pzz, Вы писали:
Pzz>Если пользователю разрешается загрузиться с флопика, то в "целевой" системе он все, что угодно, сможет удалить.
Да, это само собой. Такой вариант не рассматривается, на данный момент есть решение на Windows с защитой при помощи драйвера, которое блокирует попытку удаления файлов администратором. И хочется получить что-то аналогичное для Mac OS X.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, RomikT, Вы писали:
RT>>Тогда можно chattr +i сделать. От случайного удаления рутом защитит.
KP>Так как речь идет именно о DLP системе, то тут стоит рассматривать преднамеренное удаление файлов пользователем.
Ну тогда я боюсь софтовым решением не отделаться.
Ядро системы с вкомпилированным фильтром на флешку, грузиться только с флешки, саму флешку в readonly, внутрь корпуса и опломбировать
Здравствуйте, kaa.python, Вы писали:
KP>Думается мне, данная задача выглядит как не выполнимая, тем не менее, может у кого-то есть идеи. Есть UNIX-like операционаая система (Mac OS X, если быть точнее), для которой хотелось бы получить решение позволяющее защитить приложение от удаления. Осложняет это дело тот факт, что хотелось бы защититься от удаления root-ом.
Если от случайного удаления (не намеренного): chflags в BSD (включая MacOS), chattr в Linux
Если от намеренного, можно поднять securelevel в BSD системах, применить TrustedBSD слой (там, AFAIR, есть готовые решения для этого), для Linux — LIDS умеет защищаться от подобных действий даже от рута
Здравствуйте, kaa.python, Вы писали:
KP>Думается мне, данная задача выглядит как не выполнимая, тем не менее, может у кого-то есть идеи.
KP>Буду рад комментариям не только для Mac OS, но и для BSD и Linux систем
Может сочетание полностью зашифрованного dm-crypt диска и правильной настройки ролей в selinux решит задачу?
Здравствуйте, kaa.python, Вы писали:
KP>Думается мне, данная задача выглядит как не выполнимая, тем не менее, может у кого-то есть идеи. Есть UNIX-like операционаая система (Mac OS X, если быть точнее), для которой хотелось бы получить решение позволяющее защитить приложение от удаления. Осложняет это дело тот факт, что хотелось бы защититься от удаления root-ом. В принципе, удаление файлов можно блокировать посредствам драйвера-фильтра файловой системы, но есть ли какая-то возможность защитить сам дрйвер от выгрузки?
KP>Буду рад комментариям не только для Mac OS, но и для BSD и Linux систем
Хочу высказать свой оффтоп.
Казалось бы, Mac OS X — до безобразия пользовательская система, не корпоративная. К чему там DLP?
Просто само наличие следящей и запрещающей системы провоцирует из спортивного интереса на зло маме отморозить себе уши нагнуть и обойти ее.
* Загрузиться с чего-нибудь, дорваться до неограниченного доступа к жесткому диску, удалить "малварь", кейлоггеры, тулзы удаленного администрирования и остальную ересь.
* На виндовых машинах у многих антивирусов есть фича указать на исполняемый файл — оно нехорошее, съешь его! 1-2 ребута и система свободна!
Даёшь пользователю свободу мысли, слова и действий!
Я бы из принципа не стал работать в компании, устанавливающей подобный софт на рабочие станции сотрудников.
Re[2]: Защита от удаления в Юниксе
От:
Аноним
Дата:
14.10.12 19:42
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Даёшь пользователю свободу мысли, слова и действий! А>Я бы из принципа не стал работать в компании, устанавливающей подобный софт на рабочие станции сотрудников.
А еще интересно, как DLP система помешает "утечь" файл, который был заархивирован, зашифрован, uuencoded, а потом небольшая программка прикидывается браузером и на несколько серверов (очень чужих, моих в общем), штук 15, лезет по http по (псевдо)рандомным портам, пихая в url (напоминающий реальный адрес популярных cms) кусочки важного файла.
Здравствуйте, Аноним, Вы писали:
А>А еще интересно, как DLP система помешает "утечь" файл, который был заархивирован, зашифрован, uuencoded, а потом небольшая программка прикидывается браузером и на несколько серверов (очень чужих, моих в общем), штук 15, лезет по http по (псевдо)рандомным портам, пихая в url (напоминающий реальный адрес популярных cms) кусочки важного файла.
DLP, помимо прочего умеет и просто подозрительную активность засекать. И тут одно из двух или много не передашь или исходящий трафик сам по себе будет достаточно большим, чтобы админ мог и в ручном режиме посмотреть что происходит.
После чего последствия будут зависеть от серьезности данных и фирмы.
Так что если вам за утечку данных не платят конкуренты, нечего и хулиганить. А если платят, они придумают и как обойти DLP
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Michael7, Вы писали:
M>>Может сочетание полностью зашифрованного dm-crypt диска и правильной настройки ролей в selinux решит задачу?
Pzz>У меня, например, этот самый selinux на всех моих линухах выключен. Потому что жить с ним совершенно невозможно.
Согласен, вернее можно, но у меня тоже терпения не хватало его вдумчиво настроить
Однако, тут возможно и просто хватило бы обычных юниксовых прав, плюс убранный root и жестко лимитированный sudo (для некоторых операций). А dm-crypt, чтобы нельзя было с внешнего носителя загрузившись что-то сделать. Но это одноразовая операция, потом даже при необходимости только переустанавливать все заново. Кстати, это тоже в принципе может быть уязвимостью. При наличии физического доступа можно же и банально все переустановить.
Здравствуйте, Аноним, Вы писали:
А>Казалось бы, Mac OS X — до безобразия пользовательская система, не корпоративная. К чему там DLP? А>Просто само наличие следящей и запрещающей системы провоцирует из спортивного интереса на зло маме отморозить себе уши нагнуть и обойти ее.
Вобщем-то совершенно без разницы на сколько она пользовательская пока есть спрос на корпоративные решения
А>Я бы из принципа не стал работать в компании, устанавливающей подобный софт на рабочие станции сотрудников.
Да ради бога, ктож заставляет?
Re[4]: Защита от удаления в Юниксе
От:
Аноним
Дата:
14.10.12 23:15
Оценка:
Здравствуйте, Michael7, Вы писали:
M>DLP, помимо прочего умеет и просто подозрительную активность засекать. и тут одно из двух или много не передашь или исходящий трафик сам по себе будет достаточно большим, чтобы админ мог и в ручном режиме посмотреть что происходит.
а насколько хорош другой сценарий:
* в конце рабочего дня отломать локальный DLP-клиент, вынуть сетевой шнур, чтобы удаленно снова не поставился — типа, сотрудник ушел и выключил рабочую станцию
* скрипт копирует файлики в подключенный по usb планшет, полный (лицензионной, так уж и быть) музыки, о чем дохлый dlp-клиент при отключенной сетке не может отчитаться на сервер. для вида музон в это время копируется на рабочий компьютер.
* сервис на планшете засовывает файлы из определенного каталога в оперативку и сразу же трет их с карты, чтобы всякий ахтунг в открытом виде не лежал
* в планшете сим-карта на человека "анонимный абонент" (такую можно получить, если чуть-чуть заплатить уличному торговцу симок, чтобы не заморачиваться с заполнением анкеты)
не, не катит. даже если не зареган номер, оператор связи все равно может показать, какой траффик был
* еще wifi роутер за окном, прячущий ssid
* скринсейвер, требующий для разблокировки длинный пароль, при неправильном вводе которого даже один раз хитрый злонамеренный сервис превращается в тыкву
из спортивного интереса
M>После чего последствия будут зависеть от серьезности данных и фирмы.
каких еще "данных"? hex в урлах? а что там? и сервера оформлены на какого-нибудь Мабуту в чудесной стране
M>Так что если вам за утечку данных не платят конкуренты, нечего и хулиганить. А если платят, они придумают и как обойти DLP
есть риск, что конкурент хочет просто получить данные любой ценой, а отсутствие последствий для согласившегося "помочь" не так уж и важно
Как немного работавший с DLP, скажу так: настоящую серьезную попытку что-то вынести эти системы могут обеспечить только для бесправных юзеров. Извините, что работаю вместо КО.
