Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
протоколирование записи на внешние носители 12.11.05 00:27
Автор: Suomi Статус: Незарегистрированный пользователь
|
|
Есть такая проблема: сотрудникам по должностным обязанностям положено писать конфиденциальную инфу на болванки, которые они после записи должны регистрировать. Но разумеется гарантии, что они зарегистрируют все диски, которые пишут, нет. Поставить резаки только в 1 месте и пускать на него "по пропускам" невозможно по многим причинам. Отсюда вопрос, как бы организовать ведениепофайловоголога всего того, что пишется на CD (имя файла с полным путем, размер, дата и т.п.). Кроме того не отказался бы от такой же возможности касательно использования LPT, COM и USB. Проверять целостность ведущегося лога- это уже ерунда:)
|
|
Опять же навеяно выставкой ЕнтерЕХ. Взял материал на стенде. Не качал, не устанавливал, только даю линк. 22.02.06 20:54
Автор: Garick <Yuriy> Статус: Elderman
|
Sanctuary Device Control
|
|
Приветствую. 15.01.06 16:48
Автор: balmaster Статус: Незарегистрированный пользователь
Отредактировано 15.01.06 16:51 Количество правок: 2
|
Приветствую.
А если отказаться от логов какие файлы писались совсем.
Тоесть при записи грограмма прожига создает образ того что пишеться, этот образ после записи (или до) копируется на сервер (это потребует конечно места и сетку будет напрягать).
Затем для файлов из образа считаються контрольные суммы чтобы определить что писалось.
Можно образ для этого распаковывать или монтировать. Монтировать думаю будет лучше.
Предполагаеться что для файлов с вашими данными контрольные суммы уже расчитаны и лежат в некоторой базе.
Так определяем что копировалось. Ну а остальное что не распознаеться уже повод для другого разбора.
Чтото похожее используеться при обработке почты на предмет пересылки конф. данных.
|
| |
Не потребует, поскольку автору совсем не надо данные... 16.01.06 11:38
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> А если отказаться от логов какие файлы писались совсем.
> Тоесть при записи грограмма прожига создает образ того что
> пишеться, этот образ после записи (или до) копируется на
> сервер (это потребует конечно места и сетку будет
> напрягать).
Не потребует, поскольку автору совсем не надо данные логировать. Вполне достаточно, чтоб "прожигалка" TOC (Table Of Contents) вновьзаписываемых(или обновляемых) файлов куда-нибудь незаметно кидала. Только где ж взять такую прогу...
|
|
В идеале, пользователь может имеет доступ ко всем и любым... 16.11.05 20:18
Автор: Anty Статус: Незарегистрированный пользователь
|
> Есть такая проблема: сотрудникам по должностным
> обязанностям положено писать конфиденциальную инфу на
> болванки, которые они после записи должны регистрировать.
В идеале, пользователь может имеет доступ ко всем и любым данным БД через запросчик в виде интерфейса пользователя. Но в виде файлов для прожига полная БД должна быть доступна ему только в зашифрованном виде. А при получении файлов с сервера - только через утилиту подписывания и/или унифицирования), чтобы, соответственно - обеспечить авторство копии и/или локализовать момент утечки. Тогда даже фокусы с подменой "запоротых" болванок на "левые" не имеют смысла.
Хотя возможен и сговор, и "подстава" чужих ключей, но это - другой аспект защиты.
> Но разумеется гарантии, что они зарегистрируют все диски,
> которые пишут, нет. Поставить резаки только в 1 месте и
> пускать на него "по пропускам" невозможно по многим
> причинам.
> Отсюда вопрос, как бы организовать ведение
>пофайловоголога всего того, что пишется на CD (имя файла
> с полным путем, размер, дата и т.п.). Кроме того не
> отказался бы от такой же возможности касательно
> использования LPT, COM и USB.
Попробуйте использовать встроенный системный аудит NT, он годится для копирования любым способом:
1. Выделить файловые области, которые должны аудироваться (не только исходные данные, но и рабочие области прожигалки, например, для создаваемых образов - это поможет понять, что и сколько раз пытались прожечь и т.п.).
2. Назначить уровни аудита для пользователей и/или групп.
3. Включить аудит процессов - станет понятно, какой ид у прожигалки, и какие события вызваны именно процессом прожига.
4. Ограничить права доступа исполнителей на чтение к файлу журнала аудита.
5. Прогнать процесс прожига и проанализировать журнал аудита. Вопрос формализации критериев поиска вполне решаем.
Для организации распределенного аудита (допустим, БД на сервере, а резаки на нескольких РС) можно использовать групповые политики. Вопросы автоматизации распределенной обработки журналов аудита тоже вполне решаемы.
> Проверять целостность
> ведущегося лога- это уже ерунда:)
Главное, чтобы не затерли. Хотя при возможности альтернативной загрузки это вполне возможно, но скрыть не удастся.
|
| |
Есть небольшая проблема: ИМХО прожиг файлов нерой на сидюк... 16.11.05 21:59
Автор: Killer{R} <Dmitry> Статус: Elderman
|
Есть небольшая проблема: ИМХО прожиг файлов нерой на сидюк не есть операция записи файлов на сидюк с точки зрения ОСи.
> Попробуйте использовать встроенный системный аудит NT, он
> годится для копирования любым способом:
> 1. Выделить файловые области, которые должны аудироваться
> (не только исходные данные, но и рабочие области
> прожигалки, например, для создаваемых образов - это поможет
> понять, что и сколько раз пытались прожечь и т.п.).
> 2. Назначить уровни аудита для пользователей и/или групп.
> 3. Включить аудит процессов - станет понятно, какой ид у
> прожигалки, и какие события вызваны именно процессом
> прожига.
> 4. Ограничить права доступа исполнителей на чтение к файлу
> журнала аудита.
> 5. Прогнать процесс прожига и проанализировать журнал
> аудита. Вопрос формализации критериев поиска вполне решаем.
>
> Для организации распределенного аудита (допустим, БД на
> сервере, а резаки на нескольких РС) можно использовать
> групповые политики. Вопросы автоматизации распределенной
> обработки журналов аудита тоже вполне решаемы.
>
> > Проверять целостность
> > ведущегося лога- это уже ерунда:)
> Главное, чтобы не затерли. Хотя при возможности
> альтернативной загрузки это вполне возможно, но скрыть не
> удастся.
|
| | |
Если "запись файла на сидюк" == "прожиг конкретной части... 17.11.05 12:05
Автор: Anty Статус: Незарегистрированный пользователь
|
Если "запись файла на сидюк" == "прожиг конкретной части подготовленного образа, которая соответствует файлу на пластинке", то для протоколирования моментов начала прожига отдельных файлов стОит начать писать свою прожигалку, поскольку запись в два шага - подготовка образа и прожиг образа - вообще такие мелочи не учитывает - обрабатываются лишь ошибки прожига.
Разве что писать мультисессионый CD, строго по одному файлу на сессию? Но кто и как это будет ограничивать? И возможно/удобно ли будет этим CD пользоваться?
IMHO, исчерпывающих технических подходов к исходному вопросу может быть ровно три -
1. написать свой процесс прожига со встроенным аудитом,
2. модифицировать существующий на предмет аудита (насколько это позволит исходная модель процесса),
3. не влезая в процессы, анализировать по косвенным признакам - какими процессами и сколько раз считаны исходные данные и файл образа.
Поскольку исходный вопрос был в конце расширен до любого типа внешних носителей, то п.3 наиболее перспективен - при реализации будут отличаться только фильтры журналов аудита, причем использовать их можно по очереди - по количеству отслеживаемых направлений утечки.
Для аудита операций с исходными файлами и подсчета количества нарезанных пластинок этого достаточно. Для централизации аудита этого тоже достаточно.
|
| | | |
Запись на сидюк есть запись на сидюк. Это работа с... 17.11.05 15:55
Автор: Killer{R} <Dmitry> Статус: Elderman
|
Запись на сидюк есть запись на сидюк. Это работа с устройством на более низком уровне нежели файловые АПИ предоставляемые ОС, и файлов там как таковых нет - мониторить нечего. Есть создание непосредственно файловой системы на диске причем сразу с данными. Вобщем если вы не программист вам возможно сложно будет это понять. А написание своей прожигалки задача весьма непростая. Лучше поискать консольные прожигалки умеющие делать это с командной строки, наваять гуи для них, работающим сервисом и разрешить юзерам юзать только этот гуи. Доступ к самой прожигалке разрешить только юзеру SYSTEM.
http://www.google.com/search?hl=ru&q=command+line+cdrom+burn+windows&lr= кстати выдает обнадеживающие линки.
|
| | | | |
Есть материал для создания образа и собственно сам файл... 10.01.06 20:22
Автор: Anty Статус: Незарегистрированный пользователь
|
> предоставляемые ОС, и файлов там как таковых нет -
> мониторить нечего.
Есть материал для создания образа и собственно сам файл образа, для прожига. Доступ к этим файлам и нужно мониторить.
Зачем (и нужно ли) - будет понятно, когда Suomi конкретизирует, что нужно сделать - посчитать ли количество записанных одним человеком болванок, запротоколировать, что, когда и кем было скопировано (и не только для записи на болванки, судя по треду). А если этот подход нужно применить к перекрывающимся группам пользователей и резаков (и/или ДРУГИХ сменных носителей!), в масштабах сети, то для протоколирования доступадостаточноиспользовать штатные средствах NT.
А вот для обработки журналов и сведения результатов потребуется программирование на уровне запросов к БД
> программист вам возможно сложно будет это понять.
Несложно. Что и как собирается в образ и как пишется, известно. Кроме того, в исходном вопросе не было ни слова про умение/необходимость программировать железо или на низком уровне, не правда ли?
(Off) А что местные авторитеты говорят по поводу оверквотинга?
|
| | | | | |
Продолжаем разговор... 10.01.06 21:21
Автор: Suomi Статус: Незарегистрированный пользователь
|
> Есть материал для создания образа и собственно сам файл
> образа, для прожига. Доступ к этим файлам и нужно
> мониторить.
Да, пожалуй. Беда только в том, что таких файлов на файл-сервере, с которого они и берутся, несколько Гиг. К тому же теоретически их могут кинуть к себе на комп и писать уже оттуда, а не сразу с сервака. Получается, за исходными файлами практически нереально следить, только за образами того, что в итоге записывалось. Видимо, при таком подходе это идеальный вариант.
> Зачем (и нужно ли) - будет понятно, когда Suomi
> конкретизирует, что нужно сделать - посчитать ли количество
> записанных одним человеком болванок, запротоколировать,
> что, когда и кем было скопировано (и не только для записи
> на болванки, судя по треду).
Нужно просто понимать, какая информация кем и когда была записана на внешние носители (идеально контролировать ВСЕ, начиная от USB и CD и заканчивая COM. Но в принципе, учитывая, что все кроме CD, можно отключить хотя бы в БИОСе, основная задача - CD).
>А если этот подход нужно
> применить к перекрывающимся группам пользователей и резаков
> (и/или ДРУГИХ сменных носителей!), в масштабах сети, то для
> протоколирования доступадостаточноиспользовать штатные
> средствах NT.
Скажем так, есть N-ное количество учетных записей в AD (не большое, с десяток), которые должны писать резаками, установленными в их рабочих станциях. За редким исключением допускается использование одного резака 2-3 взаимозаменяемыми сотрудниками.
> А вот для обработки журналов и сведения результатов
> потребуется программирование на уровне запросов к БД
>
> > программист вам возможно сложно будет это понять.
> Несложно. Что и как собирается в образ и как пишется,
> известно. Кроме того, в исходном вопросе не было ни слова
> про умение/необходимость программировать железо или на
> низком уровне, не правда ли?
Вопрос анализа логов действительно не стоит. Это уже решаемо и нас не касается. Главное - наличие некой базы логов.
На самом деле мы, видимо, придем к использованию спец. машины-резака (такая махина для массовой записи дисков). Машина позволяет многое запрограммировать, кроме того, ее можно установить в отделе, отвечающем за отслеживание записываемых данных, т.е. просто так что-то по-тихому записать без их ведома просто будет невозможно. Сдерживает пока одно: она не умеет писать на RW, только CDR диски, что несколько грустно, т.к. порой объем данных совсем ничтожен (до 10 Мб). Но все же нам кажется, что $1000 в год на CDR болванки на столь высокая цена, если проблема практически окажется решенной.
|
| | | | | | |
А не проще ли вместо такой навороченной машины для прожига... 25.02.06 11:38
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
Subj, ... просто поставить обычный PC с лялихом? ИМХО в лялихе несколько штук консольных программ для прожига, написать интерфейсную морду к ним легко. Вместе со всеми ваши требованиями и ограничениями.
|
|
Насчёт LPT, COM и USB 16.11.05 07:11
Автор: svtvl Статус: Незарегистрированный пользователь
|
|
Если у ваших сотрудников есть возможность подключать к ним различные устройства, то у нас например опечатывают порты и всё.
|
| |
Не все:-) Хотя бы ежедневно мониторить наличие плом на более 20 рм - задача не из легких. Во вторых, сорванная пломба не даст ответ на вопрос "Кто сорвал и слил инфу и какую?". 16.11.05 09:48
Автор: Garick <Yuriy> Статус: Elderman
|
|
Оторванная пломба только покажет факт ее уничтожения, но не факт подключения девайса и слива инфы.
|
| | |
И кстати насчет сети 16.11.05 12:53
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 16.11.05 12:56 Количество правок: 2
|
Берецца ноутбук с куском витой пары обжатой на кросс-овер... А дальше все тривиально ;)
Насчет лога как такогового на стороне записывателя без контроля - имхо бессмысленно. Что вы в том логе хотите увидеть? Что в пятницу вечером был записан файл TopSecret.doc? А если юзер его переименует и назовет MyHomePorno.,mpeg? Контент файлов ведь в лог по любому не пойдет как я понимаю...
|
| | | |
Идентифицировать файл можно с помощью цифровой подписи. Контент определяется не только расширением, но и заголовком. Можно создать стоп-лист по типам файлов. 16.11.05 13:54
Автор: Garick <Yuriy> Статус: Elderman
|
|
Еще как вариант: писать в терминалах. Вроде возможно вести полные логи активности терминал клиента.
|
| | | | |
Ну, значит предварительно запаковать файл с паролем и прилепить к безобидному файлу в хвост 16.11.05 14:01
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 16.11.05 14:04 Количество правок: 1
|
|
А решение с терминалами это и есть в принципе подобие решения с удаленной нерой.
|
| | | | | |
Для этого нужны инструменты (софт), которые можно запретить устанавливать. 16.11.05 14:14
Автор: Garick <Yuriy> Статус: Elderman
|
|
Цифровая подпись -обощенное название. Можно использовать парсеры файлов и создавать уникальные слепки, мало зависящие от незначительного изменения контента, с файлов.
|
| | | | | | |
Запаковка файла с шифрованием неизвестным паролем по AES - это малозначительное изменение? 16.11.05 14:21
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 16.11.05 14:23 Количество правок: 1
|
|
Если уж действительно нужна защита то по белому списку форматов файлов, причем умеющая парсить все эти форматы, не позволяя засунуть ничего лишнего. А опять же учитывая возможность многих форматов засовывать в данные абсолютно что угодно (.doc - OLE embedded, .avi - видеоданные сжатые любым кодеком, jpeg - а как программа поймет что картинка которую оно отображает дейтсивтельно картинка а не зашифрованные данные?. Вобщем импоссибл это. Нужны другие меры.
|
|
Кто ж это все придумал то!? 15.11.05 12:19
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 15.11.05 12:22 Количество правок: 2
|
> Есть такая проблема: сотрудникам по должностным
> обязанностям положено писать конфиденциальную инфу на
> болванки, которые они после записи должны регистрировать.
Кто ж это все придумал то!?
Зачем придумали регистрацию, чтоб чего лишнего не записали?
> причинам. Отсюда вопрос, как бы организовать ведение
>пофайловоголога всего того, что пишется на CD (имя файла
> с полным путем, размер, дата и т.п.). Кроме того не
> отказался бы от такой же возможности касательно
> использования LPT, COM и USB. Проверять целостность
> ведущегося лога- это уже ерунда:)
Понятно, беспокоит утечка информации, если уж о СОМ и УСБ речь пошла.
Сети нет случайно? А выхода в интернет?
Дисководы не беспокоят, потому что на них много не унести?
А ЛПТ - беспокоит скачивание или возможность распечатывания и выноса в бумажном виде?
Не боитесь, что с монитора ксерить будут или фотографировать на камерафон?
Не следует недооценивать злоумышленников - все что нужно вынести зипуется и переименовывается. Пусть читатель логов задумается - зачем человеку нужно было переписывать pagefile.sys!
Почему весь ход мысли так и остается в голове? Почему не спрашивается про то как защититься? Почему метод уже считается проработан, а недостает только маленькой програмки и вопрос ставится только про нее?
|
| |
Регистрируется, потому что положено ДСП-информацию... 15.11.05 13:11
Автор: Suomi Статус: Незарегистрированный пользователь
|
> > Есть такая проблема: сотрудникам по должностным
> > обязанностям положено писать конфиденциальную инфу на
> > болванки, которые они после записи должны
> регистрировать.
>
> Кто ж это все придумал то!?
> Зачем придумали регистрацию, чтоб чего лишнего не записали?
>
Регистрируется, потому что положено ДСП-информацию регистрировать. Пишут, потому что невозможно постоянно гонять или всех людей к одному CDRW, или специально обученного человека с соответствующими правами к разным резакам. Поэтому нет гарантии, что из 10 записанных 10 все будут зарегистрированы и, соответственно, проверены на легитимность.
> > причинам. Отсюда вопрос, как бы организовать ведение
> >пофайловоголога всего того, что пишется на CD (имя
> файла
> > с полным путем, размер, дата и т.п.). Кроме того не
> > отказался бы от такой же возможности касательно
> > использования LPT, COM и USB. Проверять целостность
> > ведущегося лога- это уже ерунда:)
>
> Понятно, беспокоит утечка информации, если уж о СОМ и УСБ
> речь пошла.
> Сети нет случайно? А выхода в интернет?
Разумеется, о возможной утечке. Сеть, безусловно, есть. Права юзеров в этой сети идентичны. Интернета нет. Так что вопрос стоит именно о протоколировании фактов записи на ВНЕШНИЕ НОСИТЕЛИ БОЛЬШОГО объема.
> Дисководы не беспокоят, потому что на них много не унести?
Так точно.
> А ЛПТ - беспокоит скачивание или возможность распечатывания
Скачивание через порт. Точнее, подключение к ЛПТ умных устройств большого объема. Но это не столь важно, т.к. можно считать, что они отключены в BIOS/сломаны.
> и выноса в бумажном виде?
> Не боитесь, что с монитора ксерить будут или
> фотографировать на камерафон?
Нет, эти угрозы в данном случае не актуальны.
> Не следует недооценивать злоумышленников - все что нужно
> вынести зипуется и переименовывается. Пусть читатель логов
> задумается - зачем человеку нужно было переписывать
> pagefile.sys!
ЧТо записывается (имя) не столь принципиально. Главное - зафиксировать факт, что в такой-то период что-то в таком-то объеме писалось. Учитывая разные факторы, установить потерю именно искомых данных можно на 95%.
> Почему весь ход мысли так и остается в голове? Почему не
> спрашивается про то как защититься? Почему метод уже
> считается проработан, а недостает только маленькой
> програмки и вопрос ставится только про нее?
Да, ход мысли не приведен, т.к. все уже проанализировано. Защититься в данном случае нельзя, кроме как вести логи. И регулярно их просматривать.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
