что такое домен безопасности

Домен безопасности

Домен безопасности (security domain): часть автоматизированной системы, которая реализует одни и те же политики безопасности

Источник: » ГОСТ Р ИСО/МЭК ТО 19791-2008. Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Оценка безопасности автоматизированных систем»

(утв. и введен в действие Приказом Ростехрегулирования от 18.12.2008 № 525-ст)

Домен безопасности (security domain): совокупность активов и ресурсов, подчиненных единой политике безопасности

Источник: » ГОСТ Р ИСО/МЭК 18028-1-2008. Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Сетевая безопасность информационных технологий. Часть 1. Менеджмент сетевой безопасности»

(утв. и введен в действие Приказом Ростехрегулирования от 18.12.2008 № 523-ст)

Ссылки на определение понятия «Домен безопасности»

Уважаемые пользователи сайта. На данной странице вы найдете определение понятия «Домен безопасности». Полученная информация поможет вам понять, что такое Домен безопасности. Если по вашему мнению определение термина «Домен безопасности» ошибочно или не обладает достаточной полнотой, то рекомендуем вам предложить свою редакцию этого слова.

Источник

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Полное руководство по Active Directory, от установки и настройки до аудита безопасности. Ч. 1: Введение в Active Directory (понятия, применение, отличие от Workgroup)

Оглавление

8. Групповые политики

9. Управление пользователями и компьютерами Active Directory. Группы. Организационные единицы

10. Настройка траста и сайта доменов

11. Другие службы и роли Active Directory

12. Настройка Samba (Active Directory для Linux)

13. Инструменты для аудита безопасности Active Directory

Что такое Active Directory

Active Directory — это технология Microsoft, которая представляет собой распределенную базу данных, в которой хранятся объекты в иерархическом, структурированном и безопасном формате. Объекты AD обычно представляют пользователей, компьютеры, периферийные устройства и сетевые службы. Каждый объект уникально идентифицируется своим именем и атрибутами. Домен, лес и дерево представляют собой логические подразделения инфраструктуры AD.

Домены Windows обычно используются в больших сетях — корпоративных сетях, школьных сетях и государственных сетях. Они не то, с чем вы столкнётесь дома, если у вас нет ноутбука, предоставленного вашим работодателем или учебным заведением.

Типичный домашний компьютер — обособленный объект. Вы управляете настройками и учётными записями пользователей на компьютере. Компьютер, присоединённый к домену, отличается — этими настройками управляет контроллер домена.

Что такое домен?

Домены Windows предоставляют сетевым администраторам возможность управлять большим количеством компьютеров и контролировать их из одного места. Один или несколько серверов, известных как контроллеры домена, контролируют домен и компьютеры на нём.

Домены обычно состоят из компьютеров в одной локальной сети. Однако компьютеры, присоединённые к домену, могут продолжать обмениваться данными со своим контроллером домена через VPN или подключение к Интернету. Это позволяет предприятиям и учебным заведениям удалённо управлять ноутбуками, которые они предоставляют своим сотрудникам и учащимся.

Когда компьютер присоединён к домену, он не использует свои собственные локальные учётные записи пользователей. Учётные записи пользователей и пароли устанавливаются на контроллере домена. Когда вы входите в систему в этом домене, компьютер аутентифицирует имя вашей учётной записи и пароль с помощью контроллера домена. Это означает, что вы можете войти в систему с одним и тем же именем пользователя и паролем на любом компьютере, присоединённом к домену.

Сетевые администраторы могут изменять параметры групповой политики на контроллере домена. Каждый компьютер в домене получит эти настройки от контроллера домена, и они переопределят любые локальные настройки, указанные пользователями на своих компьютерах. Все настройки контролируются из одного места. Это также «блокирует» компьютеры. Вероятно, вам не будет разрешено изменять многие системные настройки на компьютере, присоединённом к домену.

Другими словами, когда компьютер является частью домена, организация, предоставляющая этот компьютер, управляет и настраивает его удалённо. Они контролируют ПК, а не тот, кто им пользуется.

Поскольку домены не предназначены для домашних пользователей, к домену можно присоединить только компьютер с версией Windows Professional или Enterprise. Устройства под управлением Windows RT также не могут присоединяться к доменам.

Для чего нужна Active Directory

Если в вашем офисе используется Active Directory, все машины будут подключены к домену, что означает, что вся информация хранится в централизованном месте, а не локально на жёстких дисках отдельных компьютеров. Домен управляется глобальным каталогом, который отслеживает все устройства, зарегистрированные в сети. В глобальном каталоге хранятся IP-адреса, имена компьютеров и пользователей, поэтому глобальный администратор может контролировать всё, что происходит в домене. Чтобы управлять компьютерами, администратору просто понадобится имя этого компьютера, потому что всё уже связано с серверной частью.

Когда вы используете Active Directory, все разрешения устанавливаются контроллером домена. Это означает, что сетевой администратор уже сообщил контроллеру домена, какие разрешения назначить каждому пользователю. Это делает всю цифровую коммуникацию более эффективной.

Что может администратор сети через Active Directory?

Не всем в вашей организации обязательно нужен доступ ко всем файлам/документам, имеющим отношение к вашей компании. С помощью Active Directory вы можете предоставить отдельным пользователям разрешение на доступ к любым файлам/дискам, подключённым к сети, чтобы все участвующие стороны могли использовать ресурсы по мере необходимости. Кроме того, вы можете указать ещё более точные разрешения. Чтобы проиллюстрировать это, давайте рассмотрим пример: предположим, у вашей компании есть каталог в сети для всех документов, относящихся к кадрам. Сюда могут входить любые формы, которые нужны сотрудникам для подачи в отдел кадров (официальные запросы, официальные жалобы и так далее). Предположим также, что в каталоге есть таблица, в которой указано, когда сотрудники будут в отпуске и отсутствовать в офисе. Ваш сетевой администратор может предоставить всем пользователям доступ к этому каталогу только для чтения, что означает, что они могут просматривать документы и даже распечатывать их, но они не могут вносить какие-либо изменения или удалять документы. Затем администратор может предоставить расширенные права вашему менеджеру/директору по персоналу или любому другому сотруднику отдела кадров, которому потребуется редактировать файлы, хранящиеся в каталоге.

Ещё одним огромным плюсом для сетевых администраторов, использующих Active Directory, является то, что они могут выполнять обновления в масштабе всей сети одновременно. Когда все ваши машины автономны и действуют независимо друг от друга, вашим сетевым администраторам придётся переходить от машины к машине каждый раз, когда необходимо выполнить обновления. Без Active Directory им пришлось бы надеяться, что все сотрудники обновят свои машины самостоятельно.

AD позволяет централизовать управление пользователями и компьютерами, а также централизовать доступ к ресурсам и их использование.

Вы также получаете возможность использовать групповую политику, когда у вас настроена AD. Групповая политика — это набор объектов, связанных с подразделениями, которые определяют параметры для пользователей и/или компьютеров в этих подразделениях. Например, если вы хотите сделать так, чтобы в меню «Пуск» не было опции «Завершение работы» для 500 лабораторных ПК, вы можете сделать это с помощью одного параметра в групповой политике. Вместо того, чтобы тратить часы или дни на настройку правильных записей реестра вручную, вы создаёте объект групповой политики один раз, связываете его с правильным OU (organizational units, организационные единицы) или несколькими OU, и вам больше никогда не придётся об этом думать. Существуют сотни объектов групповой политики, которые можно настроить, и гибкость групповой политики является одной из основных причин доминирования Microsoft на корпоративном рынке.

Что нужно для Active Directory

Active Directory можно включить на компьютерах с Windows Server. На не серверных компьютерах (например, с Windows 10), можно установить и включить Active Directory Lightweight Directory Services, то есть средства удалённого администрирования сервера: средства доменных служб Active Directory и служб облегчённого доступа к каталогам. Они предоставляют сервер LDAP (Lightweight Directory Access Protocol, облегчённый протокол доступа к каталогам). Он работает как служба Windows и предоставляет каталог для аутентификации пользователей в сети. Это лёгкая альтернатива полноценному серверу Active Directory, которая будет полезна только в определённых бизнес-сетях.

Active Directory Domain Services

Когда люди говорят «Active Directory», они обычно имеют в виду «доменные службы Active Directory» (Active Directory Domain Services, AD DS). Важно отметить, что существуют другие роли/продукты Active Directory, такие как службы сертификации, службы федерации, службы облегчённого доступа к каталогам, службы управления правами и так далее.

Доменные службы Active Directory — это сервер каталогов Microsoft. Он предоставляет механизмы аутентификации и авторизации, а также структуру, в которой могут быть развёрнуты другие связанные службы (службы сертификации AD, федеративные службы AD и так далее). Это совместимая с LDAP база данных, содержащая объекты. Наиболее часто используемые объекты — это пользователи, компьютеры и группы. Эти объекты могут быть организованы в организационные единицы (OU) по любому количеству логических или бизнес-потребностей. Затем объекты групповой политики (GPO) можно связать с подразделениями, чтобы централизовать настройки для различных пользователей или компьютеров в организации.

Контроллер домена

Сервер, который хостит AD DS — это Контроллер домена (Domain Controller (DC)).

Диспетчер серверов и Windows Admin Center

Управлять всем этим можно через различные программы. Более старым вариантом является Диспетчер серверов (Server Manager). Он позволяет установить Active Directory Domain Services (AD DS) и назначить компьютеру роль Domain Controller (DC).

Новым ПО для управления компьютерами является Windows Admin Center. Данное программное обеспечение является облегчённым с технической точки зрения (работает в веб браузерах), но при этом более функциональное с точки зрения возможностей. Microsoft активно продвигает Windows Admin Center как приложение которое включает в себя функциональность Диспетчера серверов (Server Manager), а также превосходит её, предлагая множество дополнительных функций и удобные интерфейсы для управления и мониторинга компьютерами.

На самом деле, Windows Admin Center не является полноценной заменой ни для Server Manager, ни для другой оснастки. Это программное обеспечение сильно облегчает выполнение многих популярных действий по администрированию компьютеров и серверов, но для некоторых узкоспециализированных настроек требуется другое ПО.

Мы рассмотрим работу с Active Directory в каждом из этих приложений. Также мы рассмотрим развёртывание и управление Active Directory в PowerShell.

Диспетчер серверов уже предустановлен на Windows Server 2022 и автоматически открывается при включении компьютера. Для установки Windows Admin Center перейдите по ссылке https://aka.ms/WindowsAdminCenter. Более подробные инструкции по установке и использованию Windows Admin Center будут даны в третьей части данного цикла статей.

Чем рабочие группы отличаются от доменов

Рабочая группа — это термин Microsoft для компьютеров Windows, подключённых через одноранговую сеть. Рабочие группы — это ещё одна организационная единица для компьютеров Windows в сети. Рабочие группы позволяют этим машинам обмениваться файлами, доступом в Интернет, принтерами и другими ресурсами по сети. Одноранговая сеть устраняет необходимость в сервере для аутентификации.

Каждый компьютер Windows, не присоединённый к домену, является частью рабочей группы. Рабочая группа — это группа компьютеров в одной локальной сети. В отличие от домена, ни один компьютер в рабочей группе не контролирует другие компьютеры — все они объединены на равных. Для рабочей группы пароль также не требуется.

Рабочие группы использовались для общего доступа к домашним файлам и принтерам в предыдущих версиях Windows. Теперь вы можете использовать домашнюю группу чтобы легко обмениваться файлами и принтерами между домашними ПК. Рабочие группы теперь переведены в фоновый режим, поэтому вам не нужно о них беспокоиться — просто оставьте имя рабочей группы по умолчанию WORKGROUP и настройте общий доступ к файлам домашней группы.

Есть несколько различий между доменами и рабочими группами:

Является ли мой компьютер частью домена?

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

Вы можете быстро проверить, является ли ваш компьютер частью домена. Откройте приложение «Параметры» (Win+x).

Нажмите «Система».

Перейдите на вкладку «О программе» и найдите пункт «Переименовать этот ПК (для опытных пользователей)»:

Если вы видите «Домен»: за которым следует имя домена, ваш компьютер присоединён к домену.

Если вы видите «Рабочая группа»: за которым следует имя рабочей группы, ваш компьютер присоединён к рабочей группе, а не к домену.

В англоязычной версии это соответственно «Settings» → «System» → «About» → «Rename this PC (advanced)».

Используя командную строку (PowerShell) вы также можете узнать, прикреплён ли компьютер к домену или входит в рабочую группу.

Для этого выполните команду (можно за один раз всё скопировать-вставить в окно терминала):

Источник

домен безопасности

3.38 домен безопасности (security domain): Совокупность активов и ресурсов, подчиненных единой политике безопасности.

3.35 домен безопасности (security domain): Совокупность активов и ресурсов, подчиняющихся единой политике безопасности.

Полезное

Смотреть что такое «домен безопасности» в других словарях:

Домен безопасности — (security domain): часть автоматизированной системы, которая реализует одни и те же политики безопасности. Источник: ГОСТ Р ИСО/МЭК ТО 19791 2008. Национальный стандарт Российской Федерации. Информационная технология. Методы и средства… … Официальная терминология

Домен безопасности — совокупность объектов и участников информационного процесса, подчиняющихся единой политике безопасности и единой администрации безопасности. См. также: Политика информационной безопасности Финансовый словарь Финам … Финансовый словарь

домен безопасности — 1. Совокупность пользователей и систем, подчиняющихся общей стратегии обеспечения безопасности. 2. Набор ресурсов, подчиняющихся одной стратегии обеспечения безопасности. Рекомендация МСЭ Т X.841, X.411.… … Справочник технического переводчика

домен безопасность — Условия или контекст, который определяется моделями безопасности и архитектурой безопасности, включая комплекс ресурсов и множество элементов системы, которым разрешен доступ к ресурсам. В одном административном домене может располагаться один… … Справочник технического переводчика

домен — 3.23 домен (domain): Конструкция моделирования предприятия, которая представляет часть моделируемого предприятия, обеспечивая идентификацию релевантной информации. Источник: ГОСТ Р 54136 2010: Системы … Словарь-справочник терминов нормативно-технической документации

Домен — (фр. domaine) область; единица структуры: В Викисловаре есть статья «домен» … Википедия

Домен Windows NT — У этого термина существуют и другие значения, см. Домен. Домен Windows NT собрание участников безопасности (все объекты Active Directory), имеющих единый центр (который называется контроллером домена), использующий единую базу, известную… … Википедия

ГОСТ Р ИСО/МЭК 18028-1-2008: Информационная технология. Методы и средства обеспечения безопасности. Сетевая безопасность информационных технологий. Часть 1. Менеджмент сетевой безопасности — Терминология ГОСТ Р ИСО/МЭК 18028 1 2008: Информационная технология. Методы и средства обеспечения безопасности. Сетевая безопасность информационных технологий. Часть 1. Менеджмент сетевой безопасности оригинал документа: 3.3 аудит (audit):… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р ИСО/МЭК 27033-1-2011: Информационная технология. Методы и средства обеспечения безопасности. Безопасность сетей. Часть 1. Обзор и концепции — Терминология ГОСТ Р ИСО/МЭК 27033 1 2011: Информационная технология. Методы и средства обеспечения безопасности. Безопасность сетей. Часть 1. Обзор и концепции оригинал документа: 3.2 архитектура (architecture): Базовая организация системы,… … Словарь-справочник терминов нормативно-технической документации

область (домен) политики безопасности — Область, в переделах которой определена и приведена в исполнение администратором политика безопасности. Область политики безопасности имеет следующие характеристики: обладает набором пользователей (или principals); использует хорошо определенный… … Справочник технического переводчика

Источник

Защитные механизмы операционных систем

Авторизация. Разграничение доступа к объектам ОС

Операции зависят от объектов. Hапример, процессор может только выполнять команды, сегменты памяти могут быть записаны и прочитаны, считыватель магнитных карт может только читать, а файлы данных могут быть записаны, прочитаны, переименованы и т. д.

Желательно добиться того, чтобы процесс осуществлял авторизованный доступ только к тем ресурсам, которые ему нужны для выполнения его задачи. Это требование минимума привилегий, уже упомянутое в предыдущей лекции, полезно с точки зрения ограничения количества повреждений, которые процесс может нанести системе. Hапример, когда процесс P вызывает процедуру А, ей должен быть разрешен доступ только к переменным и формальным параметрам, переданным ей, она не должна иметь возможность влиять на другие переменные процесса. Аналогично компилятор не должен оказывать влияния на произвольные файлы, а только на их хорошо определенное подмножество (исходные файлы, листинги и др.), имеющее отношение к компиляции. С другой стороны, компилятор может иметь личные файлы, используемые для оптимизационных целей, к которым процесс Р не имеет доступа.

Различают дискреционный (избирательный) способ управления доступом и полномочный ( мандатный ).

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

Некоторые авторы утверждают [Таненбаум, 2002], что последнее требование называют *-свойством, потому что в оригинальном докладе не смогли придумать для него подходящего названия. В итоге во все последующие документы и монографии оно вошло как *-свойство.

Отметим, что данная модель разработана для хранения секретов, но не гарантирует целостности данных. Например, здесь лейтенант имеет право писать в файлы генерала. Более подробно о реализации подобных формальных моделей рассказано в [Столлингс, 2002], [Таненбаум, 2002].

Домены безопасности

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

Рассмотрим стандартную двухрежимную модель выполнения ОС. Когда процесс выполняется в режиме системы ( kernel mode ), он может выполнять привилегированные инструкции и иметь полный контроль над компьютерной системой. С другой стороны, если процесс выполняется в пользовательском режиме, он может вызывать только непривилегированные инструкции. Следовательно, он может выполняться только внутри предопределенного пространства памяти. Наличие этих двух режимов позволяет защитить ОС (kernel domain) от пользовательских процессов (выполняющихся в user domain). В мультипрограммных системах двух доменов недостаточно, так как появляется необходимость защиты пользователей друг от друга. Поэтому требуется более тщательно разработанная схема.

В ОС Unix домен связан с пользователем. Каждый пользователь обычно работает со своим набором объектов.

Источник

Еще раз о том, как не сделать из своей сети «решето»

Здравствуйте! Я почти 10 лет работаю в сфере ИТ и ИБ, всегда интересовался практической безопасностью, в настоящее время работаю пентестером. За все время работы я постоянно сталкивался с типовыми ошибками в настройках и дизайне инфраструктуры. Ошибки эти чаще всего досадные, легко устранимые, однако быстро превращают сеть в полигон для взлома. Порой кажется, что где-то специально учат так настраивать, насколько часто они встречались. Это и побудило меня написать данную статью, собрав все самое основное, что может улучшить защищенность.

В этой статье я не буду рассказывать про использование сложных паролей, максимального ограничения прав доступа, смене учетных записей по умолчанию, обновлению ПО, и других «типовых» рекомендациях. Цель статьи – рассказать о самых частых ошибках в настройках, заставить администраторов и специалистов ИБ задуматься над вопросом – «а все ли в моей сети хорошо?», а также показать, как можно оперативно прикрыть те или иные типовые уязвимости, используя встроенные или бесплатные средства, не прибегая к дополнительным закупкам.

Инструкций-рецептов намеренно не прикладываю, так как многое ищется очень легко по ключевым словам.

1. Усильте безопасность инфраструктуры Windows

Не создавайте локальные учетные записи доменными политиками

Это сильный повтор, но тут нужно повторять и повторять, так как эта ошибка очень частая – не создавайте доменной групповой политикой локальные учетные записи на хостах в домене. Опасность этого действия крайне высокая. Про это много где написано, но написано обычно на ресурсах, сугубо связанных с практической безопасностью, а не ИТ.

Причина высокой опасности – сведения об этой учетной записи, в том числе ее пароль, хранятся в открытом виде в файле groups.xml, в ресурсе sysvol контроллера домена, который по умолчанию доступен ВСЕМ участникам домена на чтение. Пароль зашифрован, но шифрование симметричное, а ключ один для всех копий Windows, и написан в открытом виде в MSDN. Отсюда следует: любой пользователь может скачать этот файл, и путем простых манипуляций узнать пароль от распространяемой учетной записи. Обычно так распространяется учетная запись с правами администратора, и часто она создается без разбора везде…

Решение – групповыми политиками добавляйте только доменные учетные записи в локальные группы на хостах. Пример расшифровки такого пароля вручную в ходе пентеста, обратите внимание на количество манипуляций до получения пароля:

Противодействие угону доменных учетных записей через mimikatz/wce

Администраторы, не связанные с пентестами и практической ИБ, редко знают про такие утилиты, как mimikatz и wce. Кратко об их работе – обладая правами локального администратора, можно извлечь из оперативной памяти билет доступа Kerberos, хеш пароля и даже сам пароль в открытом виде от учетных записей, которые недавно производили вход на этот хост. А так как администраторы совершают вход часто и много где, это приводит к высокому риску компрометации их полномочий.

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

Против этих утилит есть меры разной степени эффективности, например, такие, но часто они не применимы по разным причинам: старая схема AD, «зоопарк» в сети, который дошел до стадии метастаз, слишком большая инфраструктура, где есть слабо контролируемые участки.

Дополнительно надо отметить, что для атаки в отдельных случаях даже необязательно устанавливать данные утилиты на хост. Пользователь с администраторскими правами может легко снять дамп нужного участка оперативной памяти, и производить все манипуляции вне рабочей сети. Это многократно увеличивает риски компрометации учетных записей более привилегированного пользователя.

Решение без дополнительных затрат: заводить для управления инфраструктурой даже не 2-3 учетные записи, как принято (надеюсь, у вас так?):

— для локальной работы;
— для администрирования серверов и ПК;
— для контроллеров домена,
а как минимум 4 учетные записи (а то и больше), в соответствии с условными «зонами доверия» в домене, и не применять их вне своей зоны. То есть, держать отдельные учетные записи:
— для работы со своей личной машиной;
— для входа на контроллеры домена и управлением ими.
— для серверов;
— для рабочих станций;
— для удаленных филиалов, если там оказался ваш домен, но при этом вы не уверены, что там происходит в конкретный момент времени;
— для зоны DMZ, если вдруг доменные хосты оказались в DMZ;
— если вы частый посетитель клуба анонимных параноиков – разбить эти зоны еще на меньшие группы, либо менять свои пароли очень часто.

Запрет на ввод «тестовых» хостов в домен

По схожей причине (см. пункт выше) по возможности лучше не заводить общественные «тестовые» хосты в домен. Такие хосты наиболее часто встречаются в компаниях с подразделениями по разработке софта, «для ускорения» и экономии лицензии они часто не снабжаются антивирусами (которые, кстати, «ловят» нешифрованные mimikatz и wce), а все причастные разработчики и тестировщики имеют на них права администратора, с целью осуществления разных сомнительных действий. Используя свои администраторские права, они могут легко похитить доменные учетные записи других администраторов.

Детализация прав сервисных учетных записей

Учетные записи в Windows имеют набор различных прав входа в систему. Это локальный вход, вход в качестве пакетного задания, в качестве службы, и др. В крупном домене всегда есть служебные учетные записи, которые необходимы для массовой работы различного ПО, служб, запуска заданий, и так далее. Обязательно нужно не полениться и минимизировать права данных учетных записей под свою область применения, и явно запретить ненужные полномочия. Это снизит риски быстрого распространения угроз в случае утечки контроля над такой записью.

Обращение к SMB по именам и запрет использования NTLM

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

Касательно протокола NTLM (который без «v2») – он должен быть запрещен. Помимо атак по перебору паролей, можно использовать атаку типа «Pass-the-hash». Эта атака по сути разрешает переотправку хеша NTLM без изменения и попыток подобрать пароль на произвольный хост, где разрешен NTLM. Сам хеш может быть украден из другой сессии в ходе атаки. Если у вас разрешены оба протокола NTLM, возможна ситуация, когда атакующий может понизить предпочтение с NTLMv2 до NTLM, и хост-жертва выберет самую слабую аутентфикацию.

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

Блокировка механизма WPAD

Есть два механизма, которые включены по умолчанию, и в совокупности позволяют проводить атаку «человек посередине», причем практически не обнаруживая атакующего. Это механизм автоматического обнаружения прокси через специальное сетевое имя (WPAD), и механизм широковещательного разрешения имен LLMNR.

Через WPAD некоторое ПО (в домене это чаще всего служба обновлений WSUS и некоторые браузеры) выполняет поиск HTTP прокси, и готово при необходимости прозрачно авторизоваться на нем при помощи NTLM(v2). Таким образом, оно добровольно «выдает» хеш учетной записи, которая инициировала подключение. Его можно в последствии перебирать по словарю, и восстановить пароль. Либо применять атаку «Pass-the-hash», описанную выше, если не отключен NTLM (про это см. пункт выше).

Устройства выполняют поиск сервера WPAD через DNS, и, если это не сработает, задействуют широковещательный запрос LLMNR или NetBIOS. И тут атакующему уже значительно проще ответить на вопрос хоста, где же находится «правильный» сервер конфигурации прокси. Дополнительный негативный эффект — такой поиск прямо замедляет скорость подключения, так как тратится время на поиск прокси.

Решение – в групповых политиках запретить и автообнаружение прокси для ПО, и протокол LLMNR. На DNS адрес WPAD (wpad.domain.name) в DNS поставить заглушку. LLMNR это фактически имитация DNS на сегменте сети L2 путем широковещательных запросов. В доменной сети при нормально работающем DNS он не нужен. С NetBIOS все сложнее, он до сих пор используется во многих случаях, и его выключение может обрушить работу, так что здесь все же остается лазейка для навязывания WPAD.

Включение UAC на максимум

Не выключайте User Account Control (UAC), а лучше наоборот, установите его на максимум. UAC, конечно, реализован не очень удобно и не информативно, но вы не представляете, как обидно пентестеру получить формальную возможность удаленного выполнения команд от имени пользователя с администраторскими правами, но без фактической возможности выполнения именно привилегированных действий, которые как раз при «обычной» работе надоедают запросами о подтверждении. Обойти UAC или повысить права конечно, возможно, но это лишние препятствия.

Отключение скрытых файловых ресурсов

Сетевые диски как ярлыки

Спорное решение, и явно не всем подходит, но был случай, когда это спасло от эпидемии шифровальщиков. По возможности, предоставлять пользователям удаленные общие файловые ресурсы не как сетевые диски, а как ярлыки на рабочем столе. Причина простая – malware иногда перебирает буквы дисков, и при этом не всегда в состоянии найти ресурсы, не подключенные в виде дисков.

2. Почтовая система. SPF

Ревизия содержимого SPF

Проверьте SPF-запись вашего почтового домена. А потом проверьте ее еще раз.

Многие недооценивают значимость этой записи, и при этом не понимают работу протокола SMTP. SPF запись показывает, какие ресурсы могут легитимно отправить почту от имени вашего домена. Для частного случая отправки писем на ваш домен от вашего домена (то есть, для внутренней переписки внутри вашего же домена) эта запись показывает, кто (т.е. конкретные хосты) может отправлять письма без авторизации, от имени любого пользователя. Чаще всего здесь делают две незначительные на вид ошибки, приводящие к огромным проблемам.

all» в конце SPF записи почтового домена. Не знаю почему, но большинство публичных мануалов рекомендуют оставить такую настройку. Такая настройка дает письму статус «не прошло проверку, но помечено как опасное и все равно доставлено» при отправке почты от ресурсов, прямо не указанных в SPF домена. Это говорит получателю, что решение о легитимности отправляемой почты перекладывается на жесткость настроек его спам-фильтра и других механизмов фильтрации. Далее, есть вероятность, что ваш собственный спам-фильтр настроен мягко (особенно часто это бывает с «публичными» пользователями компании, которые боятся «прозевать» письма), и это приводит к тому, что любой хост Интернета отправит вам же письмо от вашего же домена, и с некоторой вероятностью оно пройдет во входящие, а не в спам. Очень забавно видеть пользователей и даже ИТ-администраторов, беспрекословно выполняющих срочные указания от «важного начальства» из подобных поддельных писем при пентестах с социальной составляющей. Конечно же, не исключена ситуация со слабыми спам-фильтрами и у ваших контрагентов, и тогда уже вы будете делать им заманчивые предложения без своего ведома.

SPF для подавляющего большинства компаний должна содержать только –all в конце, разумеется, после тщательной сверки своего содержимого.

2) Бывает, что по ошибке в SPF корпоративного домена оказываются внешние адреса, через которые пользователи компании выходят в интернет. Последствия понятны – возможность нелегитимной отправки писем от кого угодно из корпоративного домена, куда угодно. Обычно администраторы в таких ситуациях говорят – «но у нас же есть авторизация на почте», напрочь забывая про сам механизм протокола SMTP.

Один раз видел ситуацию, когда в SPF оказался выход гостевого WiFi. Это сразу дает возможность злоумышленнику слать легитимную почту от целевого домена, даже без получения привилегированного доступа во внутреннюю сеть компании-жертвы.

Для борьбы с такими атаками дополнительно поможет система подписей DKIM, показывающая, кто есть на самом деле отправитель, но ее внедрение процесс не моментальный, поэтому начать стоит именно с настроек SPF – ужесточить ее и сделать полную ревизию по разрешенным адресам.

3. Дизайн локальной сети

Организуйте DMZ

Организуйте DMZ, и навсегда перестаньте «пробрасывать» порты из Интернет в основную сеть. Правильная DMZ эта та, ресурсы в которой с двух сторон закрыты файерволами (как от внутренней сети, так и от Интернет), а трафик разрешен крайне выборочно, и только минимально необходимый. На мой взгляд, настоящий специалист по ИБ должен думать, что его хост из DMZ по уже взломан, и оценивать риски исходя из этого. На такие мысли наводит тот факт, что в DMZ очень часто оказываются нестандартные приложения, которые несут специфичную бизнес-логику, ставятся подрядчиками на потоке, как вариант – делаются на заказ и очень плохо проверяются, например, на банальные для WEB уязвимости. Штатный специалист по ИБ чаще всего в состоянии создать DMZ, но не в состоянии проверить приложения на уязвимости. Исходя из этого и нужно действовать.

Типичный вариант правильно организованной DMZ и общий принцип движения трафика. Стрелки – направления инициации трафика из/в DMZ.

Бюджетный дизайн DMZ для параноиков, в которой каждый ресурс находится в отдельной изолированной сети, и ресурсы не «кушают» много трафика:

Что касается «проброса» портов, то помимо риска «взлома» сервиса, существует неявный риск сбора информации о внутренней сети. Например, в ходе пентестов зачастую видно порты RDP, которые были «скрыты» путем смены со стандартного 3389 на какой-нибудь 12345. Разумеется, они легко обнаруживаются сканерами, легко идентифицируются именно как RDP, но помимо простого обнаружения, они могут, например, предоставить информацию об имени компьютера и домена (путем просмотра сертификата службы RDP), или информацию о логинах пользователей.

Полностью изолированный гостевой WiFi

Гостевой WiFi должен быть максимально изолирован от основной сети (отдельный VLAN, отдельный провод от маршрутизатора интернет до точки доступа, и т.д.). Дополнительно, по возможности, выключайте гостевой WiFi в нерабочее время по расписанию на оборудовании.

Здесь есть один нюанс. Многие правильно выделяют гостевой WiFi в отдельный изолированный VLAN, но при этом зачем-то выдают клиентам адреса DNS серверов Active Directory. Наиболее рациональное оправдание – «чтобы работали ресурсы из DMZ по внутренним адресам». Однако, это является уязвимостью, и это хорошо помогает злоумышленнику при несанкционированном анализе внутреннего устройства сети, ведь запросы к DNS (PTR по внутренним диапазонам IP) обычно никак не ограничиваются.

Решение – создать легкий внутренний DNS сервер специально для WiFi, либо использовать публичные DNS в Интернет.

Не создавайте «корпоративный» WiFi на едином Preshared-ключе

Это очень частая проблема. Один ключ от WiFi часто живет годами, ведь «нельзя же беспокоить пользователей лишний раз». Это неизбежно снижает безопасность такой конфигурации до нуля с течением времени. Основные причины – текучка сотрудников в организации, кражи устройств, работа malware, возможность перебора пароля сети.

Решение: авторизация на WiFi только через WPA2-Enterprise, для того, чтобы каждый пользователь имел свои персональные, легко блокируемые учетные данные, которые контролируются централизованно. Если внутренняя сеть на самом деле не нужна для WiFi устройств, а нужен только Интернет, нужно сделать WiFi по типу гостевого. Сам дизайн аутентификации WPA2-Enterprise это предмет отдельной статьи.

Правильная сегментация сети

Максимально сегментируйте сеть на VLAN, максимально ограничьте широковещательный трафик. Об этом пишут все мануалы по дизайну сети, почему-то это редко кем соблюдается, особенно в малом и среднем сегменте компаний, но это крайне полезно как с точки зрения удобства администрирования, так и с точки зрения безопасности.

В любом случае обязательно нужно держать ПК пользователей отдельно от серверов, иметь отдельный VLAN для management-интерфейсов устройств (сетевых устройств, интерфейсов iLO/IMPI/IP KVM, и т.д.). Все это снизит возможности подделки адресов, упростит настройку сетевого доступа, снизит вероятность атак за счет широковещательных запросов, а значит повысит и стабильность работы.

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

Для малых сетей ситуация сильно отличается – зачастую сегментировать нечего, сеть слишком мала. Однако, во всех организациях, где появляется минимальных набор серверов, обычно вместе с серверами закупаются управляемые коммутаторы, иногда с функциями L3. Почему-то они используются как просто коммутаторы, зачастую даже без минимальной настройки, хотя настройка L3 для простой маршрутизации между 2-3 сетями очень проста.

Защита от ARP spoofing и поддельных DHCP серверов

Два механизма, на языке технологий Cisco: DHCP snooping и ARP Inspection, помогут расстроить разных шутников-пользователей и реальных злоумышленников. После их внедрения вы получите предотвращение появлений ложных DHCP серверов в сети (которые могут появиться как по ошибке — кто-то перепутал настольный «домашний» маршрутизатор форм-фактора «мыльница советская» с такого же типа коммутатором, так и в результате атаки), и атак типа «человек посередине» через ARP протокол. В сочетании с малыми размерами VLAN (предыдущий пункт) это отлично снизит возможный ущерб.

Если такие функции невозможно настроить, как минимум стоит указать жесткую привязку MAC адреса шлюза сети с физическим портом коммутатора.

Port security

Если кабельная сеть и оборудование позволяют, настройте на коммутаторах доступа port security. Это хорошо защищает, хоть и не полностью, от подключения «левых» и «лишних» устройств, несанкционированного перемещения компьютеров в пространстве.

Противодействие «левым» устройствам

Даже с описанными выше защитными мерами (port security, dhcp snooping, arp inpection), возможно появление «левых устройств», причем, как показывает практика, наиболее вероятное устройство в этом случае – «домашний» роутер с функцией «клонировать MAC-адрес компьютера на внешний интерфейс». Поэтому, есть следующий шаг развития сетевой тирании – 802.1x. Однако, это уже серьезное решение, требующее хорошего планирования, поэтому возможен более простой способ выявления самовольных роутеров (именно выявления, а не пресечения). Здесь хорошо поможет анализ трафика на промежуточном звене сети на предмет параметра протокола IP — TTL. Можно сделать span порт на коммутаторе, зеркалирующий трафик в сервер со снифером, и анализировать этот трафик на наличие пакетов с аномальным TTL. В этом поможет банальный tcpdump/Wireshark. Трафик с таких роутеров будет иметь TTL меньше на 1, чем легальный трафик.

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

Удаленный доступ

При организации удаленного подключения к сети забудьте про протокол PPTP. Он, конечно, настраивается быстро и легко, но помимо наличия уязвимостей в самом протоколе и его составляющих, он плох тем, что очень хорошо виден сканерами сети (из-за работы на TCP на одном и том же порте), зачастую плохо проходит через NAT за счет транспорта на GRE, от чего на него жалуются пользователи, и по своему дизайну не содержит второго фактора аутентификации.

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

Решение-минимум: использовать протоколы на UDP (либо свободно инкапсулирующиеся в UDP), которые не так видны при сканировании, с предварительной аутентификацией по PSK, либо по сертификату (L2TP/IPSec, OpenVPN, разные вендорские реализации IPSec). Обязательно нужно настроить перечень адресов и портов внутри сети, куда можно получить доступ, используя VPN.

Запретите прямой произвольный доступ в интернет для «пользовательской» сети

Прямой выход в интернет для пользователей – это зло, хотя с удешевлением каналов Интернет его становится все больше и больше, особенно в малых и средних компаниях. Многие администраторы ограничивают исходящие порты для пользователей на минимальный набор, вроде 80, 443, пытаясь экономить полосу. С точки зрения Malware и злоумышленников, это ничем не отличается от свободного доступа в Интернет.

На мой взгляд, всегда нужен прокси-сервер, пусть без кеширования и авторизации, даже в самых маленьких сетях, и запрет на прямой выход в интернет для пользователей. Основная причина — множество всяческой malware обращается на свои центры управления именно по HTTP(S), либо по чистому TCP c популярными портами (80/443/25/110…), но при этом она зачастую не в состоянии обнаружить настройки прокси в системе.

Возьмите под контроль IPv6

Если вы не интересовались использованием IPv6, повторите все действия по фильтрации трафика применительно к IPv6, либо запретите его. Ваша инфраструктура может неявно использовать его, но вы можете и не знать об этом. Это опасно проблемами несанкционированного получения доступа в сети.

Трафик в межфилиальных сетях

Если у вас под контролем крупная сеть с удаленными филиалами, и в ней настроен Site-to-Site VPN, не поленитесь максимально ограничить трафик, который идет к вам в центр, причем именно на центральном оборудовании, а не в филиалах. Не воспринимайте каналы с удаленными филиалами как «свою родную» сеть. Обычно в компаниях филиалы защищены меньше центра, и большинство атак начинаются именно с филиалов, как с «доверенных» для центра сетей.

Ограничение icmp ping

Ограничьте список адресов, которые могут «пинговать» важные сервисы. Это снизит обнаружение ваших хостов, хоть и ненамного. При этом не забудьте, что ping – это не весь протокол icmp, а только один вид сообщений в icmp, и не нужно его (icmp) запрещать целиком. По крайней мере, вам точно будут нужны для корректного взаимодействия со всеми сетями некоторые сообщения видов Destination Unreachable. Не создавайте полным запретом ICMP на своих маршрутизаторах так называемую MTU Discovery Black Hole.

4. Шифрование трафика

Сертификаты SSL для всего и везде

Не ленитесь защищать шифрованием все сервисы, куда можно пристроить SSL/TLS. Для хостов из домена Active Directory можно настроить AD Certificate Services, либо распространять сертификаты служб через групповые политики. Если нет денег для защиты публичных ресурсов, воспользуйтесь бесплатными сертификатами, например, от startssl.

Для себя, т.е. администраторов, всегда можно пользоваться легким самодельным удостоверяющим центром, например, easy-rsa, либо самоподписанными сертификатами. Вы же заметите, что на вашем внутреннем администраторском ресурсе внезапно возникла ошибка доверия к ранее одобренному сертификату?

Если вам кажется, что вашему сайту-визитке ничего не угрожает, то надо учесть, что шифрование спасет вас не только от кражи учетных данных, но и от подмены трафика. Все наверно видели на сайтах с доступом по открытому HTTP заботливо встроенную операторами связи рекламу? А если вам встроят не рекламу, а «правильный» скрипт?

Wildcard SSL сертификат

Если вы стали счастливым обладателем wildcard-сертификата (для доменов «*.ваш-домен»), не торопитесь его распространять по всем публичным серверам. Сделайте себе отдельный сервер (или кластер), к примеру, на Nginx, который будет «разгружать» от шифрования входящий трафик. Так вы сильно снизите количество каналов утечки закрытого ключа вашего сертификата, и в случае его компрометации, не будете менять его сразу на множестве сервисов.

5. Пару слов про веб-серверах на основе Linux

Linux-хосты чаще всего видно в роли веб-серверов, классической связки LAMP (Linux + Apache + Mysql + PHP, или любой другой скриптовый язык), которую чаще всего и ломают за счет дыр в веб-приложении, поэтому опишу самый минимум для данной связки, который относительно легко внедряется, и не требует большого опыта настройки и отладки (вроде мер типа SELinux/AppArmor).

Доступ к серверу

Не поленитесь запретить вход по ssh для root, настроить авторизацию только по сертификатам и сместить порт ssh куда-нибудь далеко со стандартного 22.

Если на сервере не один администратор, активируйте для каждого механизм sudo, а для root используйте пароль, который никто не знает, кроме бумаги, которая все время лежит в конверте и в сейфе. В этом случае вход через ssh по паролям категорически нельзя разрешать.
Если же наоборот, администратор один, то деактивируйте sudo (особенно в том случае, если у вас по каким-то причинам сохранился вход через ssh по паролю), и для администраторских задач используйте аккаунт root.

Ну и конечно, классика — не работайте под рутом.

Iptables

Не поленитесь настроить iptables, даже если вам кажется, что iptables ничего не решит, например, если на сервере из сетевых приложений работают только Web и ssh, которые и так должны быть разрешены. В случае получения минимальных полномочий злоумышленником на сервере, iptables поможет предотвратить дальнейшее распространение атаки.

Правильно настроенный iptables, как и любой другой файервол, разрешает только минимально необходимое (включая исходящие соединения через цепочку правил output). На случай минимальной конфигурации Web-сервера в iptables будет не более 10 строк. По сложности, это значительно проще настройки firewall для доменного хоста Windows, где можно нечаянно запретить динамические RPC порты, доменные службы и другие важные для работы коммуникации, так как не всегда очевидна даже последовательность коммуникации. Поэтому, для настройки iptables под web-сервер не нужны особые знания по сетям, и можно настроить файервол значительно легче.

Противодействие повышению прав в случае взлома

Отправьте Apache работать в chroot. Как вариант, сделайте отдельные разделы в файловой системе для /var/ и /tmp, смонтируйте их с флагами noexec,nosuid. Так вы защитите сервер от исполнения локальных эксплоитов в бинарном виде, которые могут повысить права атакующего. Запретите исполнение интерпретаторов скриптовых языков типа Perl, Python для «других пользователей» (chmod o-x), куда относится веб-сервер, если это не требуется веб-серверу и другим службам. Чем меньше в системе «других служб», а соответственно, пользователей под них, тем проще это сделать.

Пара слов о настройке web-сервера на примере Apache

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

Проверить свою настройку SSL можно, например, через https://www.ssllabs.com/ssltest/

Настройте аудит системы

Включите и настройте auditd по показательным событиям (создание пользователя, изменение прав, изменение конфигурации) с отправкой уведомлений на удаленный сервер. Все взломы не производятся одномоментно, поэтому периодически осматривая логи, пусть даже и вручную, можно обнаружить подозрительную активность. Дополнительно это поможет при «разборе полетов» в случае инцидентов.

Ставьте только минимально необходимое в системе

ОС на основе Linux хороши тем, что можно гибко выключать/удалять ненужные компоненты. С точки зрения безопасности, в первую очередь, это относится к сетевым и локальным демонам. Если вы видите, что на вашем только что установленном сервере работают демоны, которые явно или косвенно не относятся к задаче данного сервера, задумайтесь – действительно ли они нужны. Для большинства случаев это всего лишь стандартная установка, и они легко и без последствий выключаются и/или удаляются. Например, не всем нужен RPC, который включен по умолчанию в Debian. Не ждите, пока под такие сервисы найдут уязвимости и сделают эксплойт, а вы забудете обновиться.

6. Самоконтроль

Даже не обладая навыками специалиста по тестированию на проникновение, можно дополнительно включить в самоконтроль минимальные «пентестерские» действия. Вам помогут:

Сканеры безопасности

Проверьте действительную видимость открытых портов при помощи nmap/zenmap. Иногда это дает результаты, которых вы не ожидаете, например, в случае ошибочной настройки правил фильтрации трафика, или в случае, когда сеть большая и сегментация персонала по зонам ответственности также очень значительна.

Проверьте хосты в сети на типовые уязвимости при помощи сканера OpenVAS. Результаты также бывают неожиданными, особенно в крупных сетях, где обычно существует хаос разной степени. Главное при использовании сканеров безопасности – отличать ложные срабатывания от настоящих уязвимостей.

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

Брутфорс учетных записей

Проверяйте учетные записи сотрудников на предмет слабых паролей. В минимальной комплектации в этом поможет файловый ресурс, доступный любому доменному пользователю после авторизации, и утилита THC Hydra. Сформируйте словари из паролей, которые подходили бы под вашу парольную политику, но при этом были бы простые, вроде «123QAZxsw». Количество слов в каждом – не более числа допустимых попыток авторизации в домене, минус 2-3 для запаса. И пропустите через брутфорс все учетные записи домена, уверен, найдете много интересного.
Разумеется, на эти проверки заранее нужно получить официальное (желательно, «бумажное») разрешение от руководства, иначе это будет походить на попытку неавторизованного доступа к информации.

Минутка юмора

Напоследок, пентестерская байка касательно паролей. Осенью 2015 года мы делали социальный пентест с применением фишинга – выманивали доменные пароли. У двух попавшихся пользователей пароль был «Jctym2015» («Осень2015»). Посмеялись, забыли. В ноябре 2015 года делаем подобный пентест в другой организации, никак не связанной с первой, опять те же пароли, и опять сразу у нескольких пользователей. Начали что-то подозревать, нашли в одной оранжевой социальной сети такое вот руководство к действию:

Надеюсь, кому-нибудь эти простые советы помогут существенно защитить свою инфраструктуру. Конечно, есть еще масса различных технических и организационных тонкостей, касающихся вопросов «как надо делать», и «как делать не надо», но все они могут быть раскрыты только в рамках конкретной инфраструктуры.

Источник