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

Легенды и мифы ИТ #3: Как бы дать так, чтобы не дать

clip_image001Еще одна вечная загадка, встречающаяся мне очень часто: как бы так дать все, чтобы дать не все. Это именно тот вопрос, который я часто вижу на разных форумах. Этот тот самый вопрос, который мне частенько задают лично. Задаётся он в разных формах. Наиболее часто он встречается в следующих формах:

1) Как дать пользователю права локального админа так, чтобы он не мог сделать <придумайте сами, что>?

2) Как мне запретить администратору домена доступ к <очень важной информации>?

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

Для начала: предоставляя пользователю права администратора, Вы даете ему права на управление системой: в этом весь смысл. Что этот пользователь не в состоянии сделать прямо сейчас, на то он может выдать себе права. Точка.

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

Второй случай посложнее, поскольку обсуждаемые системы, как правило, распределенные. И все же, в них можно сделать не сильно больше, чем в предыдущем случае. Снова: жесткий аудит без малейших шансов у администратора поиграться с ним. Есть, конечно, варианты, типа построения изолированной от обсуждаемого администратора системы, которая, скажем, шифрует важные данные. Но это сложно и дорого: ведь система должна быть действительно изолированна: вплоть до отдельного рабочего места для людей, который с этими данными работают. А иначе какой-нибудь pass-the-hash или другой сюрприз и все: данные ушли.

Так что, на самом деле, только аудит может вам помочь против врага в лице администратора. Следовательно, просто не давайте этих прав тем, кто их не заслуживает.

Есть еще идеи?

#RuTeched: Отвечаю на вопросы. Будет ли работать Dynamic Access Control при использовании репликации?

imageКак я уже сказал, мои лабы на TechEd вполне удались, но все же я не смог ответить на ряд вопросов и пообещал сделать это позже, когда разберусь. Что ж, время пришло. Один из посетителей сказал мне, что в его опыте был случай, когда какое-то свойство файла не было отреплицировано через DFSR и поинтересовался, не поломается ли от репликации DAC. Я, разумеется мог поставить эксперимент (и сделаю это, на самом деле), но он только ответил бы на вопрос: “да” или “нет”. Ну или “возможно”. Но вряд ли бы он дал мне ответ на вопрос “почему?”. Так как я вовсе не на короткой ноге с репликацией файлов, мне пришлось просить помощи и я знал точное место, где ее можно было найти: блог AskDS.

Ответ пришел весьма быстро. Вкратце: “все будет супер”. Длинный ответ (в моем переводе) идет дальше:

“Позвольте мне уточнить некоторые аспекты вашего вопроса и ответить на каждую часть

При включении Dynamic Access Control для папок и файлов, следует рассматривать несколько аспектов.

Resource Properties

— Resource Properties определены в AD и используются в качестве шаблонов, чтобы проставить на файлы и папки дополнительные метаданные, которые могут использоваться в принятии решений об авторизации доступа. Эта информация хранится в дополнительных потоках данных (alternate data stream) папки или файла. И эта информация будет отреплицирована так же, как и дескриптор безопасности.

Security Descriptor

Как уже было сказано, они реплицируются вместе с файлом, так что все условия будут отреплицированы вместе с ними.

Все это никак не привязано к Dynamic Access Control—это просто результат репликации, к примеру, в случае репликации DFSR DAC не имеет никакого отношения к этим результатам.

Central Access Policy

Central Access Policy это способ распространить разрешения без внедрения их нпрямую в DACL дескриптора безопасности. Так что, когда Central Access Policy развернута на сервере, администратор должен прилинковать политику к папке на файловой системе. Это линкование осуществляется вставлением специального ACE в часть дескриптора безопасности, отвечающую за аудит и говорит Windows, что этот файл или папка защищены с помощью Central Access Policy.  Вследствии этого разрешения в Central Access Policy комбинируются с разрешениями Share и NTFS, чтобы получить итоговые разрешения.

Если файл или папка реплицируются на файловый сервер, который не имеет развернутой Central Access Policy, то DAC, очевидно, не применяется и разрешения так же не будут применяться.

Спасибо ребятам из этого блога: они лучшие Winking smile

Want to learn about cryptography? I know where.

image

Внимание: мой новый RSS-Feed: http://feed.feedcat.net/815939

Измените свою подписку, пожалуйста.

У Вас есть немного свободного времени и Вы желаете знать, как работает шифрование? Какой крипто-алгоритм является самым надежным? И почему λ всегда больше, чем ε… Ну… Последнее, конечно, явные враки. =)
Как бы то ни было, есть место, где можно бесплатно поучиться этому делу (при наличии знания английского языка, увы). Stanford University предоставляет бесплатно курс по криптографии. Найти его можно тут: https://www.coursera.org/#course/crypto. Я всего на второй неделе и уже подделал одно шифрованное сообщение и почти расшифровал второе (“почти” не потому, что это так сложно, а потому что весьма трудоемко, а я ленив занят).

В общем, добро пожаловать в мир знаний Winking smile

Легенды и мифы ИТ #2: PKI edition.

image

Внимание: мой новый RSS-Feed: http://feed.feedcat.net/815939

Измените свою подписку, пожалуйста.

 

Кстати, а знаете ли Вы, что на самом деле делает опция “Allow private key to be exported” или “Prompt the user during enrollment and require user input when the private key is used” в шаблоне сертификата? Делают ли они использвоание сертификата более безопасным или нет?

Я знаю как минимум пару людей, которые точно знают ответ на этот вопрос. К сожалению, я не так давно вышел из пелены невежественности, но лучше ж поздно, чем слишком поздно Winking smile В общем, короткий ответ: нет. CA не имеет ни малейшей возможности заставить клиента вести себя таким образом, как предполагает название этой настройки. В шаблоне содержатся лишь рекомендации клиентской части не экспортировать закрытый ключ.

Потому в Windows 2003 экспортировать такой сертификат через GUI было нельзя, а вот некоторые сторонние утилиты это сделать могли. Впрочем и с помощью стандартных утилит некоторые типы сертификатов были легко экспортируемы, если верить документации. А вот начиная с Windows 2008 (ну или Windows 7) сделали “улучшение” и теперь можно экспортровать неэкспортируемое.

Так что смысла в этой опции мало: только как защита от дурака.

Будьте осторожны и старайтесь задумываться над тем, что порой кажется очевидным. =)

Trustworthy computing: SDL освоили, что дальше. Часть 2: некорпоративненькая.

Trustworthy

Вы думаете, что пой предыдущий блог был о корпоративных продуктах потому что только они разрабатываются без учета безопасности применения? Ничего подобного: потребительские продукты абсолютно такие же. Назову лишь один пример: знаменитая в определенных кругах история о Windows Live Mail и SSL. До некоторых пор абсолютно нельзя было использовать с Hotmail их оба сразу. Или общайся с почтовиком без SSL или избавься от удобного клиента. Я был счастлив получить возможность их совместить. И да, мой старенький (но все еще пригодный к работе) HTC HD2 на WM6.5, кажется, так и не получил этой возможности. По крайней мере до тех пор, пока я от него не избавился.

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

Я рад, что MS уже 10 лет на твердом пути улучшения безопасности своих продуктов, нополагаю, что можно сделать и надежнее Winking smile

А Вы сталкивались со случаями, подобными описанным мной?

Trustworthy Computing. SDL освоили, что дальше?

image

Внимание: мой новый RSS-Feed: http://feed.feedcat.net/815939

Измените свою подписку, пожалуйста.

 

Наконец-то, наступила и моя очередь ругать Microsoft. Я не особый поклонник такого способа раскрутки, однако, я полагаю, что единственный путь двигаться вперед, это воспринимать, обрабатывать конструктивную критику и отвечать на нее. Так что приступим (Многа букав):

Несколько лет назад MS огласило свою широко известную инициативу Trustworthy Computing (совсем недавно они отмечали 10тилетие этой инициативы). Думаю, что мне не нужно напоминать Вам ни цели этой программы, ни средства, которые предполагалось использовать для их достижения. Интересующиеся вполне могут найти эту информацию самостоятельно. Ну и всяко, это «открытое письмо» не задумывалось, как тщательный анализ, после которого я должен был бы воскликнуть «люди, MS нам лжет!». Скорее, наоборот, просто легкая попытка показать, что, по моему скромному мнению, можно было достичь еще большего.

Я IT Pro с более, чем десятилетним стажем и этот факт, безусловно, влияет на то, как я вижу наш мир, ИТ безопасность и корпорацию Microsoft в аспектах, касающихся и того и другого. При этом моё видение Trustworthy Computing выглядит как-то так:

«SDL! SDL это! SDL то! SDL всё и повсюду!!!».

Не поймите меня неправильно, SDL это прекрасно даже с точки зрения системного администратора, который почти не умеет кодить. Нет, правда, лично у меня есть ощущение, что код от MS стал более безопасным. Большая часть актуальных уязвимостей для их реализации требует от меня либо отключения включенных по умолчанию средств защиты (DEP, UAC) или выставления совершенно незащищенного сервера в открытый интернет. Как следствие, я чувствую себя много лучше защищенным, чем, скажем, десять лет назад (впрочем, это может быть промывка мозгов, не так ли? =) ).

И все же в текущей ситуации есть приметы, которые заставляют меня полагать, что текущему SDL недостает чего-то жизненно важного. Чего же, спросите вы? Ну хотя бы тестирования продуктов в среде, соответствующей Best Practices от безопасности. То есть не только создание как можно менее уязвимого кода, но и предоставить возможность внедрить стандартные контролы для повышения безопасности решений. Хотя бы просто внедрить, если уж не без плясок с бубном. Я говорю о таких вещах, как работа с многофакторной аутентификацией, разделение ролей или делегирование полномочий. Все это должно быть включено в «Trustworthy» продукт из коробки, чтобы обеспечить сколько-нибудь безопасное окружение. Грош цена абсолютно не ломаемому (ну фантастика, ну и что) с точки зрения кода приложению, если пароли от него можно прослушать в сети банальным анализатором сетевого трафика или если любой имеет в этом приложении одинаковые полномочия. Или если для банальнейших операций с с базой данных нужно предоставить дежурному администратору права SA.

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

1) Когда мы только приступили к работе с MOSS 2007, тогда еще только RTM, мы наткнулись на невозможность индексировать порталы, доступ к которым предоставлялся с помощью CKD и HTTPS. Проблема, вроде бы решалась расширением таких порталов на HTTP, тогда индексация проходила, но поиск не выдавал результатов. Обходным маневром этой «by design» ситуации было создание сначала HTTP-приложения и расширения его с помощью HTTPS. Ерунда, казалось бы, и в последующих SP ситуация была исправлена, однако, это могло быть выявлено стандартным тестированием в соответствующем окружении.

2) Во втором случае мы никак не могли заставить работать определенные функции MOSS, связанные с WebDAV при использовании смарт-карт. Классная технология, но попробуйте безопасно опубликовать WebDAV-сайт через ISA и потребуйте аутентификации через смарт-карты… И вот она – Ваша проблема.

3) Вообще говоря, поддержка смарт-карт кажется слабым местом ребят из Рэдмонда. Я обожаю UC-продукты от MS, но попробуйте подружить со смарт-картой некоторые режимы работы Outlook или использовать их при работе с Lync/Communicator… Будет работать? Черта с два! Устанавливайте VPN-соединение или настраивайте DA, а потом используйте свои ненаглядные объединенные коммуникации.

4) Data Protection Manager. Я очень люблю этот продукт. Его чрезвычайная простота в эксплуатации в сочетании с вполне приличной мощью очень привлекательны. И все-таки первые три релиза у нас не было практически ни намека на разделение полномочий (за исключением нескольких немаловажных, но все-таки частных случаев). Все или ничего. Полный доступ или никакого доступа. Самый последний релиз наконец предоставил нам RBAC, но предыдущие пять лет без него малообъяснимы.

5) SQL сервер. Мы проверяли на 2005-2008R2. Может выстрелить в случае использования SQL Mirroring. Попробуйте с правами, меньшими, чем sysadmin выполнить операцию ALTER DATABASE на базе в режиме recovery. Мало того, что ничего не получится, так еще и дамп сгенерится по умолчанию, чем, при определенной настойчивости, можно и сервер положить =) А это, между прочим, стандартная операция для баз в зеркале.

Все, указанные выше проблемы (разрешенные и нет) вполне могли бы быть найдены при тестировании, если бы кто-то ставил перед собой задачу тестировать продукты в средах, построенных с применением основных принципов безопасности. Те возможности, которые просто отсутствовали, когда они были так нужны, так же могли бы быть предоставлены продуктами значительно раньше, если бы «там» задумывались не только о качестве самого кода.

К сожалению, мой опыт приводит к мысли, что об этом задумывался мало кто из имеющих влияние на ситуацию. Я бы мог подумать, что это лишь случайные недоразумения, однако если всего один человек встрял в такое количество ситуаций за несколько лет (а это, поверьте мне, не все), то, я скорее склонюсь к выводу, что это просто результат подхода в PG к разработке и концепции Trustworthy Computing.

MS SIR #12

like_a_sir Что ж, лучше поздно, чем слишком поздно. Я, наконец-таки добрался до недавнего Microsoft Security Intelligence Report. Хотя обычно там не сликом много сюрпризов, в этот раз я был практически шокирован первой секцией документа. Полагаю, тому есть резон, посскольку эта секция называется…

How Conflicker CONTINUES to propagate.

То есть “как закалялась сталь как продолжает распространяться Conflicker”.

Conflicker! Малварь с трехлетним стажем! ПРОДОЛЖАЕТ быть УГРОЗОЙ!

Мир сошел с ума, не правда ли? =)

60% людей, которые могли бы получить сейчас такой подарок (если бы не антивирус) имеют слабый пароль администратора на своих компьютерах. От 17 до 42% компьютеров, куда попытался пролезть этот зверь (XP Only) все еще не пропатчены от уязвимости, используемой им. Три года спустя после его выхода…

Просто-таки феерично, мне кажется, друзья. =)

Все остальное в отчете не такое волнительное, как это. Меня заинтересовали следующие места:

1) Эксплойты для HTML/JavaScript на подъеме.

2) Кажется, использование для распространения малвари уязвимостей в различных документах и их обработчиках тоже растет. Возможно, не за горами антивирусы для eBook’ов. Winking smile

3) SPAM, напротив, по статистике МС падает в объемах. Точнее, падает количество заблокированных спам-сообщений, но в случае MS я подозреваю, что эти цифры хорошо коррелируют. Что меня удивило, так это то, что основным содержанием спама является реклама лекарств без сексуального подтекста. То есть не виагры всякие, а вполне себе аспирин и около того. Впрочем, раньше я на эту секцию особого интереса не обращал, может, оно и раньше так было. Все равно приятно узнать, что здоровье людей беспокоит больше, чем какой нибудь “enlarging someone’s manhood” =) Или наоборот – такие больные, что manhood на втором плане? С этой статистикой никогда не знаешь =(

4) Ну и вовсе не стало сюрпризом то, что большая часть Top-10 малвари требует участия пользователя в своей установке на компьютер. Впрочем, Conflicker на шестом месте… Но об этом мы уже говорили.

Ждем следующего отчета.

>Секреты %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