Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
Радует, адекватность взгляда. Еще хотел бы добавит о вреде таких вещей, как политика частой смены паролей для пользователей вкупе с требованием к их повышенной сложности. Вместо ожидаемого роста безопасности получаем пароли записанные на бумажках под клавиатура ми.
Тут уже вступает в силу еще один момент — квалификация и значимость службы безопасности предприятия.
По моему опыту работы (а его ой как много), могу заметить тот факт, что служба безопасности на предприятии зачастую представляет собой доброго дядьку, который натаскавшись в 90х разруливать базары теперь сидит и получает бабки…
Но что касаемо некоторых компаний, служба безопасности проявляла должную активность и за пароли на бумажках и прочее — штрафовало от 1/10 до 1/2 оклада. За 1-2 месяца люди развивали какие-то астральные возможности своего мозга и спокойно восьмизначный пароль запоминали и меня его ежемесячно (хотя бы ежемесячно).
Что было также замечено, это в первую очередь повальное большинство фрилансеров (далеких от понятий безопасности и вообще работы АД), развернув контроллер не отключали учетные записи «Администратор». При этом пароль на них обычно был вида «123456» — ну так, чтобы не париться. Тут же летели выставления галочек на СОБСТВЕННЫЕ пользовательские учетные записи вида «Администратор домена», «Администратор чего угодно»… Что по моему мнению не является корректным. Если ты пользователь — то ты пользователь. Если ты выполняешь работу с контроллером — будь добр зайти в систему с логином администратора. В руттиной работе админа — всегда есть вероятность подцепить что-либо при серфинге. Тем самым раздать доступ к контроллеру кому-угодно.
По моему опыту работы (а его ой как много), могу заметить тот факт, что служба безопасности на предприятии зачастую представляет собой доброго дядьку, который натаскавшись в 90х разруливать базары теперь сидит и получает бабки…
Но что касаемо некоторых компаний, служба безопасности проявляла должную активность и за пароли на бумажках и прочее — штрафовало от 1/10 до 1/2 оклада. За 1-2 месяца люди развивали какие-то астральные возможности своего мозга и спокойно восьмизначный пароль запоминали и меня его ежемесячно (хотя бы ежемесячно).
Что было также замечено, это в первую очередь повальное большинство фрилансеров (далеких от понятий безопасности и вообще работы АД), развернув контроллер не отключали учетные записи «Администратор». При этом пароль на них обычно был вида «123456» — ну так, чтобы не париться. Тут же летели выставления галочек на СОБСТВЕННЫЕ пользовательские учетные записи вида «Администратор домена», «Администратор чего угодно»… Что по моему мнению не является корректным. Если ты пользователь — то ты пользователь. Если ты выполняешь работу с контроллером — будь добр зайти в систему с логином администратора. В руттиной работе админа — всегда есть вероятность подцепить что-либо при серфинге. Тем самым раздать доступ к контроллеру кому-угодно.
Подпишусь под каждым словом.
В наших реалиях — СБ — отставные дядьки при погонах в 80-90% случаев, которые и ворд то часто открыть не могут, не то чтобы разбираться в ИТ безопасности — у нас этой культуры практически нет…
а про фрилансеров — так это вообще чуть ли не стандартная практика «чтобы к клиенту не ездить»
В наших реалиях — СБ — отставные дядьки при погонах в 80-90% случаев, которые и ворд то часто открыть не могут, не то чтобы разбираться в ИТ безопасности — у нас этой культуры практически нет…
а про фрилансеров — так это вообще чуть ли не стандартная практика «чтобы к клиенту не ездить»
Да, блокировка учетных записей после трех попыток ввода пароля — это прекрасная возможность для DOS-атаки на аккаунты. Особенно это актуально для онлайн-сервисов. Если кто-то знает ваш логин — то он сможет заблокировать вам доступ к сервису путем «подбора» пароля. Беспроигрышная игра. Или пароль подберешь, или учетку заблокируешь.
Я не догоняю, чем и досить собрались? у Вас авторизация AD смотрит прямиком в интернет?
В 2014 году люди, случается, авторизуются в корпоративных сетях через Интернет. :) Всякие там почты, мессенджеры, VPN…
И даже если этого нет, в общем случае защита на периметре — не повод оставлять дырки внутри.
И даже если этого нет, в общем случае защита на периметре — не повод оставлять дырки внутри.
Угу, только учетки блочатся на соответствующих сервисах, а не на контроллере домена.
типа RADIUS?
Я не очень понимаю суть ваших комментариев. Вы считаете, что онлайн-сервисы по какой-то причине должны обязательно каждый иметь отдельную базу данных пользователей для аутентификации, причем этой базой не должна являться AD?
AD LDS на TMG, разве не спасает от такого? Это именно отдельная база.
Авторизация из ad, но при подборе пароля блочится доступ на конкретный сервис, а не на вход в домен. Взять, например, exchange, защита от перебора паролей — блокировка учетки. Но счетчик попыток в данном случае ведет сам почтовый сервак и забанит вас он.
А атаки из серии, я запущу программу изнутри и она будет подбирать пароли маловероятна. Я подозреваю, что при включенном брандмауэре она ответ от dc даже не получит (соответственно схему мы не выгрузим).
Можно еще с пеной у рта кричать о software restriction policy и app controller, но лично мое мнение: в среднестатистической конторе нереально внедрять. (если кто внедрял, поделитесь опытом!!!)
По вашей статье предлагаю расширить область, рассмотрите как работает AD CS и какие проблемы позволяет решить.
А атаки из серии, я запущу программу изнутри и она будет подбирать пароли маловероятна. Я подозреваю, что при включенном брандмауэре она ответ от dc даже не получит (соответственно схему мы не выгрузим).
Можно еще с пеной у рта кричать о software restriction policy и app controller, но лично мое мнение: в среднестатистической конторе нереально внедрять. (если кто внедрял, поделитесь опытом!!!)
По вашей статье предлагаю расширить область, рассмотрите как работает AD CS и какие проблемы позволяет решить.
А атаки из серии, я запущу программу изнутри и она будет подбирать пароли маловероятна
В свое время, в одной из контор вот этот зверь, занимался перебором паролей учетных записей в локальной сети. Быстро выявили благодаря тому что учетки блокировались после 10 неверных паролей.
А что Вас удивляет? Есть куча сервисов, доступ к которым пользователи получают через интернет по доменным учеткам. Начиная от корпоративных порталов и заканчивая корпоративными чатами. Почта, например, тоже часто авторизуется по AD.
радиус для железа хорош. Сейчас активно говорят о «притащи свое устройство», для этого есть workplace join, direct access. Они позволяют бурить тоннели через все подряд. И авторизироваться сертификатами. Формально ты за пределы сетевого периметра не выходишь.
Приятно, что моя статья О защите служебных учетных записей оказалась столь близкой темой для ildarz и помогла ему написать свою первую статью.
Возможно, автор найдет время для того, чтобы систематизировать свой богатый опыт и оформить его не в форме критичной заметки, а систематизированных рекомендаций с примерами и описанием реализации? Такой материал был бы многим полезен.
Возможно, автор найдет время для того, чтобы систематизировать свой богатый опыт и оформить его не в форме критичной заметки, а систематизированных рекомендаций с примерами и описанием реализации? Такой материал был бы многим полезен.
В виде отдельной статьи я в данном случае писал исключительно потому, что единственным доступным мне вариантом был пост в песочницу. Иначе я бы ответил развернутым комментарием. Что до систематизированных рекомендаций… Во-первых, я сам не безопасник, во-вторых, рекомендации могут сильно отличаться в зависимости от конкретных требований бизнеса и/или государства. Увидеть явные косяки в предлагаемых решениях я, как правило, могу. Дать конкретные советы в конкретной ситуации — когда как. Писать общие систематизированные рекомендации «как надо» — для меня пока слишком. Но я подумаю. :)
Попутно отвечая на нижний комментарии о требованиях государственных и ведомственных нормативных актов — если мы откроем методический документ ФСТЭК, который указан в ваших ссылках, то прочитаем там на стр. 10 буквально следующее:
«При невозможности реализации в информационной системе в рамках ее
системы защиты информации отдельных выбранных мер защиты информации
на этапах адаптации базового набора мер защиты информации или уточнения
адаптированного базового набора мер защиты информации могут
разрабатываться иные (компенсирующие) меры защиты информации,
обеспечивающие адекватное блокирование (нейтрализацию) угроз
безопасности информации.»
Иными словами, будь я системным администратором, ответственным за функционирование IT-инфраструктуры в госструктуре, то для меня было бы два варианта действий:
1. Мне пофиг. Беру под козырек и тупо следую инструкции.
2. Мне не пофиг. Пишу служебку (или инициирую совещание, в зависимости от ранга), где подробно описываю возможные последствия (в том числе можно сослаться на положения тех же нормативных актов в части, где они регламентируют доступность информационной системы, ибо тут будет очевидное противоречие), и предлагаю компенсирующие меры.
Конкретика, ясное дело, будет зависеть от местных условий.
Попутно отвечая на нижний комментарии о требованиях государственных и ведомственных нормативных актов — если мы откроем методический документ ФСТЭК, который указан в ваших ссылках, то прочитаем там на стр. 10 буквально следующее:
«При невозможности реализации в информационной системе в рамках ее
системы защиты информации отдельных выбранных мер защиты информации
на этапах адаптации базового набора мер защиты информации или уточнения
адаптированного базового набора мер защиты информации могут
разрабатываться иные (компенсирующие) меры защиты информации,
обеспечивающие адекватное блокирование (нейтрализацию) угроз
безопасности информации.»
Иными словами, будь я системным администратором, ответственным за функционирование IT-инфраструктуры в госструктуре, то для меня было бы два варианта действий:
1. Мне пофиг. Беру под козырек и тупо следую инструкции.
2. Мне не пофиг. Пишу служебку (или инициирую совещание, в зависимости от ранга), где подробно описываю возможные последствия (в том числе можно сослаться на положения тех же нормативных актов в части, где они регламентируют доступность информационной системы, ибо тут будет очевидное противоречие), и предлагаю компенсирующие меры.
Конкретика, ясное дело, будет зависеть от местных условий.
По теме блокировки:
Согласен автором в том, что блокировка может привести к негативным последствиям для сети. Даже если исключить целенаправленные действия нарушителя, веерная блокировка может быть вызвана вирусной активностью (тот же Kido, о котором писал).
Но при этом прошу обратить внимание, что блокировка учетных записей — это базовое требование для ГИС (государственных информационных систем) и ИСПДн — ИАФ.4, УПД.1, УПД.6.
И если ваша система предполагается к аттестации на соответствие 17 или 21 приказам ФСТЭК, надо будет постараться, чтобы обосновать отсутствие автоматической блокировки.
Согласен автором в том, что блокировка может привести к негативным последствиям для сети. Даже если исключить целенаправленные действия нарушителя, веерная блокировка может быть вызвана вирусной активностью (тот же Kido, о котором писал).
Но при этом прошу обратить внимание, что блокировка учетных записей — это базовое требование для ГИС (государственных информационных систем) и ИСПДн — ИАФ.4, УПД.1, УПД.6.
И если ваша система предполагается к аттестации на соответствие 17 или 21 приказам ФСТЭК, надо будет постараться, чтобы обосновать отсутствие автоматической блокировки.
Удивительное дело: полностью согласен с выводами, к которым пришел автор статьи, но абсолютно не согласен с тем путем, которым он к ним пришел, опровергая необходимость казалась бы фундаментальной best practices о блокировке учетных записей.
Оповещения о событиях неудачного логина и блокировки, как и сама блокировка после n-го количества неудачных входов — обязательное требование многих стандартов ИБ, как наших, так и зарубежных. Интересно, как вы сможете пройти аудит по одному из этих стандартов, если побоялись веерной блокировки учеток и включили эту политику.
Есть множество способов обнаружения таких атак, каждый из которых по сути сводится к мониторингу, в той или иной степени автоматизированному. Но все это в дополнение к политике блокировки учетки после 6 (чаще всего встречал это значение) неудачных попыток входа.
Оповещения о событиях неудачного логина и блокировки, как и сама блокировка после n-го количества неудачных входов — обязательное требование многих стандартов ИБ, как наших, так и зарубежных. Интересно, как вы сможете пройти аудит по одному из этих стандартов, если побоялись веерной блокировки учеток и включили эту политику.
Есть множество способов обнаружения таких атак, каждый из которых по сути сводится к мониторингу, в той или иной степени автоматизированному. Но все это в дополнение к политике блокировки учетки после 6 (чаще всего встречал это значение) неудачных попыток входа.
* выключили эту политику. Опечатался немного )
Я не столько что-то опровергаю, сколько предлагаю людям задуматься над тем, что они делают и что советуют. В частности, описываю последствия бездумного применения того, что многими считается «простым» и «общепринятым». По сути, люди сами дают в руки злоумышленнику дополнительный инструмент для создания проблем. Не очень хорошо так делать, и вдвойне нехорошо советовать, не описывая возможные последствия. Лично мое мнение — блокировку надо применять в исключтельных случаях, и как минимум предприняв какие-то меры против потенциальной полной блокировки AD.
Про стандарты и сертификацию по ним отчасти ответил выше — меры по ИБ, в том числе описанные в разных стандартах, включают в себя не только защиту учеток, но и обеспечение доступности информационной системы. И в ситуации, когда реально стоит выбор между борьбой с перебором паролей и доступностью, этот выбор должен делаться осознанно, а не просто потому, что в какой-то бумажке так написано.
Про стандарты и сертификацию по ним отчасти ответил выше — меры по ИБ, в том числе описанные в разных стандартах, включают в себя не только защиту учеток, но и обеспечение доступности информационной системы. И в ситуации, когда реально стоит выбор между борьбой с перебором паролей и доступностью, этот выбор должен делаться осознанно, а не просто потому, что в какой-то бумажке так написано.
Все зависит от параноидальности. Все попытки нетрадиционной активности фиксируются в секюрити логе при грамотно настроенном аудите. На активность можно повесить какой-либо внешний триггер, который будет, например, блочить гада на сетевом оборудовании. Ну а дальше насколько хватит бюджета. Можно накрутить VPNы для каждого пользователя, навтыкать соболей и девайс локов. В общем, поставить пользователя в такие рамки, что он будет счастлив, что его клавиатура током еще не бьет.
Куда интереснее с точки зрения ИТ-безопасности следить за активностью админа. Т.е. построить такой аудит, который будет фиксировать деятельность обслуживающего персонала, но сам этот персонал не будет иметь доступа к этой системе. И это тоже решаемо. Если необходимо.
И как краткое резюме: блокировка учетной записи по количеству неправильных вводов имени-пароля — это очень правильный инструмент, но как любой инструмент, он работает в руках дилетанта и мастера несколько иначе.
Куда интереснее с точки зрения ИТ-безопасности следить за активностью админа. Т.е. построить такой аудит, который будет фиксировать деятельность обслуживающего персонала, но сам этот персонал не будет иметь доступа к этой системе. И это тоже решаемо. Если необходимо.
И как краткое резюме: блокировка учетной записи по количеству неправильных вводов имени-пароля — это очень правильный инструмент, но как любой инструмент, он работает в руках дилетанта и мастера несколько иначе.
Так и не понял в чем опасность блокировки. Если к учетке подбирают пароль — блокировка не даст перебрать серьезное число вариантов. Сама по себе не опасна, разблокировать запись легко и очень быстро, можно оптом. Разумеется учетку админа блокировать нельзя, впрочем автоматом так и настроено.
Если некий критичный сервис работает от имени доменной учетки, то при блокировке записи сервис упадет.
Сервис упадет — директор расстроится. Потом расстроится начальник IT службы, последним расстроится админ.
Сервис упадет — директор расстроится. Потом расстроится начальник IT службы, последним расстроится админ.
вы когда проект писали, учитывали момент что будет, если учетная запись «сломается»? Нет? Но тогда это проблема проектирования АС вообще, а не частный случай функционала защиты в AD.
Прокурору расскажете (с)
Вы когда проект принимали, вносили замечания «о неучтении момента»?
Вы когда проект принимали, вносили замечания «о неучтении момента»?
давайте держаться конструктивного диалога. Если со стороны исполнителя и заказчика выступили дилетанты, то эта проблема лежит в несколько иной плоскости, нежели обсуждаемый функционал. Ведь никто не считает, например, что применение паролей плохая идея лишь на том основании, что их иной раз записывают на бумажке?
Я не против. Напомните, а в чем был конструктив, которого мы договорились держаться?
функционал блокирования учетной записи. Мы не можем рассматривать учетную запись вне общего контекста безопасности. Более того, учетная запись является его неотъемлемой частью. И значит атака на эту часть есть атака на все. И отсюда следует, что формирование политик безопасности никак нельзя рассматривать по отдельности для тех или иных функциональных модулей в отрыве от общей политики защищаемой АС (АСУ).
Короче, нельзя сказать хорошо или плохо блокировать учетные записи. Это лишь инструмент. Помните про микроскоп и гвозди? Вот и тут так же. Блокировка учеток осмысленна лишь в рамках контекста применения данной политики.
Короче, нельзя сказать хорошо или плохо блокировать учетные записи. Это лишь инструмент. Помните про микроскоп и гвозди? Вот и тут так же. Блокировка учеток осмысленна лишь в рамках контекста применения данной политики.
Классика. Фейерверк терминов при полном отсутствии смысла. Вы, наверное, безопасник?
А теперь к конструктиву. Коллега Savvy задал конкретный вопрос и получил на него конкретный ответ. Все что написано ниже, и мной, и Вами, никакого отношения к конструктиву не имеет.
А теперь к конструктиву. Коллега Savvy задал конкретный вопрос и получил на него конкретный ответ. Все что написано ниже, и мной, и Вами, никакого отношения к конструктиву не имеет.
Сценарий 1. В компании за ИБ отвечает системный администратор. Обычно это означает, что ИБ для компании не критична. Намного важнее, скажем, доступность вконтакта 24/7 или чистота мышек в офисе. Рекомендации, приведенные в статье, в такой компании всем до одного места.
Сценарий 2. Компания посерьезнее, со штатом IT и, о чудо, с собственным безопасником. Как уже упоминалось в комментах — часто это подполковник в отставке, который строит уборщиц и избегает разговоров об IT. Такой компании ИБ также не критична, так что см. Сценарий 1.
Сценарий 3. Компания может позволить себе скилованного специалиста по ИБ. Это автоматически означает, что в компании есть скилованный специалист по AD, который давным давно знает все описанное в статье.
Вот сижу и думаю. А для кого эта статья?
Сценарий 2. Компания посерьезнее, со штатом IT и, о чудо, с собственным безопасником. Как уже упоминалось в комментах — часто это подполковник в отставке, который строит уборщиц и избегает разговоров об IT. Такой компании ИБ также не критична, так что см. Сценарий 1.
Сценарий 3. Компания может позволить себе скилованного специалиста по ИБ. Это автоматически означает, что в компании есть скилованный специалист по AD, который давным давно знает все описанное в статье.
Вот сижу и думаю. А для кого эта статья?
Таким образом, админы делятся на тех, кому пофиг (сценарии 1 и 2), и тех, кто уже и так всё знает (сценарий 3). Последние, вероятно, черпают знания прямым подключением в ноосферу. Отсюда делаем вывод, что писать что-либо бессмысленно в принципе. :)
А если серьезно, жизнь немного сложнее. Хотя бы в том же SMB секторе обычно специалистов по ИБ, да ещё и скилованных, не густо, а работать надо. И, думается мне, собственную работу лучше стараться выполнять добросовестно. Тем более, что «всем до одного места» ровно до тех пор, пока таки не случается факап и админ не огребает по полной программе. Да и в крупных структурах очень разные по уровню подготовки люди работают.
А если серьезно, жизнь немного сложнее. Хотя бы в том же SMB секторе обычно специалистов по ИБ, да ещё и скилованных, не густо, а работать надо. И, думается мне, собственную работу лучше стараться выполнять добросовестно. Тем более, что «всем до одного места» ровно до тех пор, пока таки не случается факап и админ не огребает по полной программе. Да и в крупных структурах очень разные по уровню подготовки люди работают.
Я понял для кого эта статья и в чем мне чудится диссонанс. Статья не для админов, статья для безопасников.
Начинающий администратор (читаем эникейщик) занимается всем, от заправки картриджей до веб-верстки. У него нет достаточной компетенции, чтобы внедрять рекомендации из статьи. Скажем честно, у него нет и понимания половин терминов из статьи.
Как только администратор поднял свой скилл в АД настолько, что у него все заработало и дошли руки до безопасности, оказывается, что за безопасность в его новой компании получают деньги совсем другие люди )) Так что информация из статьи представляет для него лишь праздный интерес.
Вот для кого статья. Для ИБшников. Так что не надо упоминать в статье «среднего администратора», он не виноват.
Начинающий администратор (читаем эникейщик) занимается всем, от заправки картриджей до веб-верстки. У него нет достаточной компетенции, чтобы внедрять рекомендации из статьи. Скажем честно, у него нет и понимания половин терминов из статьи.
Как только администратор поднял свой скилл в АД настолько, что у него все заработало и дошли руки до безопасности, оказывается, что за безопасность в его новой компании получают деньги совсем другие люди )) Так что информация из статьи представляет для него лишь праздный интерес.
Вот для кого статья. Для ИБшников. Так что не надо упоминать в статье «среднего администратора», он не виноват.
помню, потребовалось мне вывезти системный блок с территории предприятия, где я тогда работал. Предприятие старое, персонал ему под стать. И для того, чтобы охрана на выходе не возбудилась на коробку, надо было дать им волшебную бумажку с печатью и подписью одного из волшебников. Заполнив в форме чего выносим — системный блок — я пошел к волшебнику за печатью и подписью. Посмотрел он на мою бумажку и говорит
Он -а что вы, собственно говоря, хотите вынести?
Я — в смысле?
Он — ну системный блок это понятно, а что это? (тут он решил блеснуть что в теме и свой) у вас там «четверка», «пятерка» или что иное?
Я — а вы по виду коробки-корпуса это способны определить?
Он- а что, я по вашему, дурак, что ли?
Я (в сторону) — это провокационный вопрос
В общем, подписали мне бумагу на вынос коробки. Понятно, что в эту коробку я мог запихать что угодно, от любимого сервера компании до пачек купюр различных валют в произвольных номиналах. Зато безопасность была соблюдена. По всей форме.
Он -а что вы, собственно говоря, хотите вынести?
Я — в смысле?
Он — ну системный блок это понятно, а что это? (тут он решил блеснуть что в теме и свой) у вас там «четверка», «пятерка» или что иное?
Я — а вы по виду коробки-корпуса это способны определить?
Он- а что, я по вашему, дурак, что ли?
Я (в сторону) — это провокационный вопрос
В общем, подписали мне бумагу на вынос коробки. Понятно, что в эту коробку я мог запихать что угодно, от любимого сервера компании до пачек купюр различных валют в произвольных номиналах. Зато безопасность была соблюдена. По всей форме.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного о том, как не надо защищать учетные записи в Active Directory