Архив рубрики: Security

>Секреты %SystemRoot%system32: cipher

>

Следующая команда в списке редко вспоминается, пока не влетает пользователь с воплем “я сменил пароль и где теперь все мои зашифрованные данные!”. Знакомая ситуация? Мне не очень, но я слышал предостаточно ужастиков на эту тему. Резервное копирование ключей – ключ к спасению в данной ситуации (ну или агент восстановления). И с этим вполне может помочь наша команда. А еще с обновлением ключа шифрования на файлах. И с созданием ключа восстановления.

Про все это полно статей, однако, когда я решил взглянуть на утилиту поближе, я вдруг обнаружил для себя очередную новую функцию: добавив аргумент /W и имя какой-нибудь папки, мы уничтожим все данные, все еще содержащиеся в “пустом” месте на диске, содержащем эту папку (если папка это линк на другой диск, то будет зачищен этот самый “другой” диск). Что при этом происходит:

1) Создается папка EFSTMPWP:

2) В ней создается временный файли (или несколько)

image

3) Место в них заполняется нулями, потом единицами, а потом все это отполировывается случайными числами:

image

Каждый из этих шагов делается пока не заполнится все место на диске, потом все повторяется:

image

image

image

Разумеется, это достаточно длительная операция, особенно для больших дисков. Тем не менее, если бы я проектировал эту процедуру, то я бы сделал просто и со вкусом: в три прохода шифровал бы каждый свобоный кластер на диске с помощью случайного ключа. Впрочем, оно и к лучшему, что это был не я, процедура и так не короткая ;)

Да, кроме всего прочего, команда просит Вас закрыть все приложения, очевидно, чтобы затереть место и под временными файлами.

Что еще почитать:

cipher /?

http://technet.microsoft.com/en-us/library/cc771346(WS.10).aspx

http://support.microsoft.com/kb/295680

http://support.microsoft.com/kb/814599

Реклама

>Делегирование полномочий на создание GPO в другом домене

>

imageТакая задача неизбежно встает во весь  рост, как только  Вы начинаете пользоваться концепцией ролевого администрирования. Если честно, то пребывая в эйфории от возможностей AGPM, я что оно яйца выеденного не стоит: включили учетную запись в некоторые группы, включая “Group Policy Creator Owners” и вуаля – вот оно. Ага, черта с два!=) Эта чертова группа – глобальная и поэтому не может содержать объекты из других доменов. Более того, мы даже не можем изменить этот факт: такие возможности недоступны:

image

По крайней мере, я пока не знаю, как это сделать (но пометил себе разобраться с этим вопросом в будущем). Таким образом, уделать “по-быстрому” у нас не получится. отступим ли мы? Конечно же нет! Если мы не можем добавить объект в группу, то нужно создать новую группу, выдать ей такие же полномочия и включить объект в нее. Какие разрешения есть у группы “Group Policy Creator Owners”? Насколько я знаю, чтобы создать любой GPO нам нужно иметь права на контейнере Policies в AD и на папке Policies в sysvol. Так что давайте делегируем такие права нашей свежесозданной группе “Role GP Creator Owners”:

1) На контейнер Domain/System/Policies в AD:

image

image

image

image

Причем я полагаю, что “Create All Child Objects” это немного слишком, и можно сделать более тонкую настройку (но я не проверял – просто предположение)однако группа “Group Policy Creator Owners” имеет именно такие полномочия, так что хуже мы точно не сделаем.

2) И на папке Policies:

image

image

Вот теперь все должно работать. У меня, вроде, работает, хотя я еще буду спрашивать об этом ребят из MS, да и Вам рекомендую все тщательно проверить на тестовых стендах. Если выяснятся новые детали, то статью я поправлю, разумеется.

>Недостатки wildcard-сертификатов

>

imageПо такому запросу некоторые пользователи заходят ко мне на блог. Что ж, недостатки определенно есть, так что почему бы и не написать об этом? Но сначала: что же из себя представляют эти загадочные сертификаты диких карт или, как иногда это тоже переводят, подстановочные сертификаты.

Чтобы защитить коммуникации с веб-страницами или веб-сервисами (это к примеру, список больше, разумеется) мы используем SSL-сертификаты. Должен сказать, что на самом деле это не означает, что увидев префикс https и валидный сертификат мы можем быть уверены в том, что это настоящий сайт, настоящий сертификат и что общение с сайтом действительно защищены, но это тема отдельной дискуссии. В любом случае, прекрасны сертификаты или ужасны, это наша реальность, с которой нужно жить. Поэтому, как только Вы оказываетесь владельцем хоть сколько-нибудь большой инфраструктуры с множеством веб-сайтов, сервисов и тому подобного, и каждый из таких сервисов должен защищаться своим собственным сертификатом. Почему? Думаю, не раскрою никакого секрета, напомнив, что сертификат выписывается в таких случаях на определенное доменное имя, то есть microsoft.com, www.microsoft.com и technet.microsoft.com должны иметь разные сертификаты. Так что в вышеописанной ситуации Вы оказываетесь погребены под десятками и сотнями сертификатов, которые истекают, их нужно обновлять, наблюдать за их состоянием и так далее. Чертова прорва работы, иной раз, однако “безопасность должна быть безопасной” и все такое.

Впрочем, мир остался бы в каменном веке без ленивых людей, знаете ли. Так что эти лентяи изобрели wildcard-сертификаты. Они выпускаются на имена типа *.microsoft.com и могут таким образом быть использованы с любым поддоменом домена microsoft.com. Это как бы решает все описанные выше проьлемы. Правда ведь? На самом деле это действительно так, но ничто не бывает бесплатным и данный случай вовсе не исключение. Если Вы используете один такой сертификат в своей организации, то его секретный ключ лежит везде, где используется сертификат (существуют сервисы, которые могут выдавать разные сертификаты с одним именем, но тогда зачем вообще заморачиваться?). Статистически это означает, что риск скомпрометировать этот конкретный сертификат возрастает многократно. А сменить его после компрометации придется на всех узлах. Некоторые думают, что это вовсе и не проблема, но тогда зачем использовать сертификаты? =) Предположим, что мы считаем это все-таки проблемой, но не слишком большой, тогда, как я уже говорил выше, добавьте к этой проблеме стоимость аудита всех скомпрометированных систем (а мы ведь можем считать во многих случаях, что все, что работало на этом сертификате — скомпрометировано). Поверьте мне, аудит нескольких систем – вовсе не дешевое занятие. И не дающее стопроцентного результата, зачастую.

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

Подытожим: я однозначно не фанат такого решения. По крайней мере в своем нынешнем положении и на своей работе. Про себя же Вы можете решить сами Winking smile

>Секреты %SystemRoot%System32: AzMan

>

Если быть честным, то я очень долго думал, что это какая-то никому не нужная консоль непонятного назначения. Но не так давно я взглянул на нее поближе и понял, что я был абсолютно не прав. Это на самом деле очень мощный инструмент управления разрешениями для приложений, которые его поддерживают. Настолько много возможностей можно открыть с его помощью, что эта статья только затравка: в будущем я планирую сделать еще одну или несколько с описанием конкретных применений. пока же просто представьте, что Ввам нужно предоставить кому-то полный контроль над виртуальной машиной Hyper-V, включая возможность удалить ее, но при этом отобрать возможность создавать снапшоты (вечная головная боль, знаете ли). Можно ли создать такой набор полномочий с помощью AzMan? Легко! Вам нужно создать прямо противоположныю политику? Добро пожаловать. Вы желаете чтобы пользователь был проверен не только на членство в группах, но, скажем, на нахождение Сатурна в созавездии Девы? Создайте для таких нужд скрипт и создайте на его базе правило с помощью AzMan. Еще один факт, который чрезвычайно мне импонирует: этот инструмент очень ориентирован на ролевой доступ. Мышление в терминах ролей просто навязывается им.

image2

Хорошо, скажете Вы мне, в чем ловушка? К сожалению, она есть и не одна. Первое: Ваше приложение должно быть спроектировано и написано с учетом возможностей Authorization Manager. Для многих приложений от MS это так, например, для Hyper-V. Однако, если Вы используете SC VMM, то пользоваться AzMan почти невозможно и VMM дает Вам меньше возможностей по сравнению с AzMan. В DPM возможности этой консоли еще не сломаны никаким “управляющим” ПО, однако возможности настройки чрезвычайно скудны. =(

И все же, если Вам это не мешает, или Вы используете какое-нибудь другое приложение, которое совместимо с AzMan, то я искренне Вам рекомендую посмотреть на него.

>Дело о застрявших разрешениях

>

imageОднажды я получил запрос от одного из наших администраторов, которому были делегированы определенные права на AD в его сфере ответственности. Он жаловался мне, что он не имеет необходимых прав на одну из учетных записей. Что ж, нет проблем: небольшое исследование и – бинго! – я выяснил, что по непонятным причинам на этой учетной записи было отключено наследование прав. Починка не отняла у меня много времени: одна галка, кнопка “Ок” – не великая потеря времени. На следующий день я получил повторный запрос по тому же поводу и по той же самой учетной записи. Наследование опять было отключено. Ладно, я не такой уж новичек, я даже знаю кое-что о таких тайнах бытия, как adminCount, adminSDHolder и SDProp. Так что я пошел и удостоверился, что проблемный пользователь не является членом ни одной из защищенных групп – так оно и было. Так что я попробовал еще пару трюков навроде переноса учетки в другое OU и обратно. Безрезультатно. И в этот самый момент я получил еще одни запрос, от другого администратора про другую учетную запись, но с тем же самым эффектом. И эта другая учетная запись тоже когда-то была членом группы Domain Admins. 
Что ж, теперь было очевидно, что именно SDProp перезаписывает разрешения на объектах. Проверка атрбута adminCount показала, что наконец-то я был прав: он был установлен в 1.Как только я установил его в 0 и восстановил наследование, все пришло в норму. А еще немного поковырявшись, я выяснил, что когда объект покидает защищенную группу, adminCount не возвращается в значение 0. И это сделано специально, by design. Чуть больше деталей можно найти здесь и здесь. А я в следующий раз буду чуть менее ленивым и буду больше доверять своиему внутреннему Админу – глядишь, время сэкономлю Winking smile

>Секреты %SystemRoot%System32: Auditpol

>

CLIА вот эта команда очень даже полезна в случае, если Вам нужно тонко настроить аудит. Например, Вы не сможете только с помощью GUI установить “Audit directory service changes” не установив “Audit directory service replication” и еще парочку, потому что “Средства с интерфейсом Windows, позволяющего просматривать или задавать подкатегории политики аудита, в Windows Server 2008 нет”. Так что Вы крайне нуждаетесь в этой утилите, если есть нужда в настройке подкатегорий аудита. Так же она Вам нужна для создания скриптов, изменяющих или анализирующих SACL. А еще она пригодится для резервного копирования и восстановления политик аудита (скажем, Вам нужно на время поиска решения проблемы включить расширенный аудит, а потом выключитьт его). А еще она может полностью или частично сбросить политики аудита.

Обалдеть! Пишу вот это и преисполняюсь благоговения. Мне следовало лучше использовать этот инструмемнт Winking smileСинтаксис весьма обширен, так что читайте сами, а я приведу здесь лишь самый простой пример использования утилиты:

image

Have fun! =)

>Зловреды: как нас заражают

>

Уже не в первый раз имел я некие споры с разными людьми, знакомыми, не очень и даже коллегами, которые до сих пор думают, что основной метод для заражения для зловредов это использование уязвимостей, не требующее от пользователя быть идиотом помощником в этом нелегком деле. Я же полагаю (и имею братьев по оружию, которые меня поддерживают), что главной угрозой является как раз упомянутый выше… Эээ… Ну давайте переформулируем так: недостаток образования и халатность. О чем я говорю? Что ж, некоторые источники рассказали мне на ушко, что самые успешные, с точки зрения инсталляционной базы, зловреды устанавливают себя через USB флешки, открытые в общий доступ диски и прочие, требующие вовлечения пользователя, технологии.  Например, в отчете SIR №9 от Microsoft (первая половина 2010) мы легко увидим следующую таблицу:

1

Win32/Taterf

2

Win32/Frethog

3

Win32/Renos

4

Win32/Rimecud

5

Win32/Conficker

6

Win32/Autorun

7

Win32/Hotbar

8

Win32/FakeSpypro

9

Win32/Alureon

10

Win32/Zwangi

 

Это top10 семейств зловредов, обнаруженных на компьютерах. Первый – наиболее часто встречающийся, последний – наименее (из top10, конечно же) часто. Теперь я просто повторю ту же таблицу, но с добавлением механизмов заражения:

1

Win32/Taterf

Win32/Taterf это семейство червей, которые распространяются через открытые в общий доступ диски.

2

Win32/Frethog

Распространяется через…

Mapped Drives

3

Win32/Renos

Скачивание “видеокодеков” и других “вкусняшек” со злонамемренных сайтов. 
4

Win32/Rimecud

Win32/Rimecud это семество червей, распространяющихся через съемные носители и IM. 
5

Win32/Conficker

Не могу спорить: этот распространяется через уязвимость. А еще через съемные носители и слабые пароли.
6

Win32/Autorun

Ну и здесь не поспоришь: авторан. Съемные и прочие носители.
7

Win32/Hotbar

Набор “установи это сам”. Правда.
8

Win32/FakeSpypro

Rogue:Win32/FakeSpypro может быть установлен пользователем с сайта программы или тем же пользователем, но с применением социальной инженерии.
9

Win32/Alureon

Ручные скачки (кейгены, ПО в нагрузку, etc…)
10

Win32/Zwangi

Ручные скачки.

 

Знаете что? Пока писал это, даже расхотелось дискутировать. Прочитайте еще один отчет. И хватит на этом: нет нужды хакать Ваш компьютер, если можно хакнуть Вашу голову.

Будьте осторожны хотя бы уж в этом году и в последующие. Заставьте хакеров быть более изобретательными Winking smile