Архив рубрики: 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 на шестом месте… Но об этом мы уже говорили.

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