включать домен входа в windows что это

Что такое домен Windows и каковы его преимущества?

Если вы используете компьютер на работе или в школе, он почти наверняка является частью домена Windows. Но что это на самом деле означает? Что делает домен, и каковы преимущества присоединения компьютера к нему?

Давайте посмотрим, что такое домен Windows, как они работают и почему компании используют их.

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

Домен Windows — это, по сути, сеть управляемых компьютеров, используемых в бизнес-среде. По крайней мере, один сервер, называемый контроллер домена, отвечает за другие устройства. Это позволяет сетевым администраторам (обычно ИТ-персоналу) управлять компьютерами в домене с помощью пользователей, настроек и многого другого.

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

могу присоединиться к одному. Вам также потребуется копия Windows Server для контроллера домена, поскольку она включает в себя необходимое программное обеспечение, такое как Active Directory (подробнее об этом позже).

Как вы знаете, если ваш компьютер находится в домене?

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

Чтобы проверить, является ли ваш компьютер частью домена, откройте Панель управления и нажмите система запись. Заглянуть под Имя компьютера раздел. Если вы видите Workgroup вход с РАБОЧАЯ (по умолчанию) или другое имя в списке, ваш компьютер не находится в домене. Точно так же, если вы видите Домен здесь, то ваш компьютер находится в домене.

Эти шаги также позволяют вам найти ваше доменное имя на вашем компьютере.

Домены против рабочих групп

Прежде чем мы обсудим больше о доменах, мы должны кратко упомянуть, как они сравниваются с рабочими группами. Если компьютер не принадлежит домену, он входит в рабочую группу

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

В современных версиях Windows рабочие группы на самом деле являются формальностью, особенно когда Microsoft отказывается от функции HomeGroup.

, Windows никогда не просит вас настроить один, и они используются только для обмена файлами между устройствами в вашей сети

, Microsoft хочет, чтобы вы использовали OneDrive для этого

в настоящее время, поэтому, если вы не хотите настраивать свою собственную рабочую группу, вам не нужно беспокоиться об этом.

Что такое учетная запись пользователя домена?

В отличие от персонального компьютера, подключенный к домену ПК не использует локальные учетные записи

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

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

Экран входа в Windows выглядит немного иначе, когда вы используете компьютер, подключенный к домену. Вместо локального имени пользователя вам необходимо убедиться, что вы входите в домен под своим именем пользователя. Таким образом, ваш логин будет выглядеть примерно так MyDomain \ StegnerB01.

Контроль домена и групповая политика в Windows

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

Наряду с управлением пользователями Active Directory присоединение компьютеров к домену позволяет использовать групповую политику. Мы обсудили, как групповая политика полезна на вашем ПК

, но он действительно предназначен для корпоративного использования.

Используя контроллер домена, администраторы могут настраивать все виды безопасности и использовать политики для всех компьютеров. Например, групповая политика упрощает применение всех следующих методов:

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

Присоединиться или оставить домен в Windows

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

Возвращайтесь к Панель управления> Система снова. На Имя компьютера, домен и параметры рабочей группы страницу, нажмите Изменить настройки. Вы увидите Свойства системы окно. Нажмите на + Изменить кнопка рядом с Чтобы переименовать этот компьютер или изменить его домен коробка.

Здесь вы увидите окно, позволяющее изменить имя вашего компьютера (это не единственное место, где это можно сделать в Windows 10). Что еще более важно, вы увидите Член поле ниже. Проверить Домен Bubble и введите имя домена, чтобы присоединиться к нему. Windows подтвердит это, поэтому вам нужно иметь домен, чтобы присоединиться к нему.

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

Домен Мастера

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

С новыми сотрудниками и компьютерами, постоянно заменяющими отдельных сотрудников и старые машины, хорошо отлаженная система является ключом для бесперебойной работы бизнес-компьютеров. Чтобы обеспечить бесперебойную работу вашего ПК, ознакомьтесь с нашим руководством для начинающих по установке Windows 10.

Кредит изображения: kovaleff / Depositphotos

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Создание доменного пользователя и ввод компьютера в домен

В прошлой статье мы создали и настроили контроллер домена (DC), настало время наполнить наш домен пользователями и рабочими станциями.

Конфигурация

Открываем Server Manager и выбираем опцию Roles.

Отметим также, что вы можете создать свою группу и добавлять пользователей туда.

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

Далее, нас просят ввести пароль для новой учетной записи и выбрать дополнительные опции:

После того, как все данные будут заполнены, нас попросят подтвердить создание нового объекта.

Отлично, новый пользователь домена создан. Теперь нам нужно зайти на компьютер пользователя и ввести его в домен. Для этого логинимся на компьютер пользователя с локальными учетными данными и открываем Свойства компьютера. Как видите, наш компьютер пока еще не стал частью домена, он ещё является частью рабочей группы WORKGROUP/. Убедитесь, что компьютер пользователя имеет версию Windows не ниже Professional. Чтобы ввести его в домен выбираем Change Settings

Важно! Поддержка доменной инфраструктуры начинается только с версии Windows Professional. На версиях Starter, Home Basic, Home Premium подключиться к домену не получится!

Далее напротив опции «To rename this computer or change its domain or workgroup, click Change» нажимаем собственно Change

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

Далее в открывшемся окне в опции «Member of» вместо Workgroup выбираем Domain и вводим имя нашего домена (в нашем случае – merionet.loc)

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

После чего, нас попросят перезагрузить компьютер для применения изменений.

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

Теперь, если мы откроем свойства компьютера, то увидим, что наш компьютер принадлежит домену (в нашем случае – merionet.loc)

Онлайн курс по Linux

Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps

Источник

Включать домен входа в windows что это

Доброго времени суток! Уважаемые подписчики и гости, крупного IT блога Pyatilistnik.org. В прошлый раз мы с вами разобрали в десятке, новую версию утилиты Robocopy, которая помогает переносить данные в раз быстрее, чем через обычный проводник. В сегодняшней статье, я вам хочу показать, как ввести в домен Active Directory Windows 10. Так как многие с новым интерфейсом и его видоизменением от версии к версии, не могут это сделать. Ну что поехали.

Постановка задачи

У меня есть домен Active Directory, если вы не в курсе что это такое, то переходите по ссылке слева, там очень подробно описано, но если в двух словах, то это база данных всех устройств и пользователей в организации, которой централизованно управляет системный администратор.Устанавливая тестовую виртуальную машину с Windows 10 1803 (Если вы не знаете, где взять дистрибутив, то вот вам легальный метод, как скачать ISO образ Windows 10), я захотел ее ввести в домен, но не классическим методом, а новым, модным, через интерфейс аля метро 2.0. Какого же было мое удивление, что я минут 10 не мог его найти, я даже ради эксперимента спросил своих коллег со второй линии из технической поддержки, знают ли они, но они мне кроме классического метода не смогли ничего показать. Гугление так же оставляло больше вопросов, чем ответов, так как той кнопки, про которую все говорили уже не было в моем случае, но я все же ее нашел и решил написать небольшую заметку, мало ли кому-то пригодится.

Методы присоединения в домен Windows 10

Для того, чтобы присоединить Windows 10 к домену Active Directory, лично я знаю 4 метода, о которых мы подробно с вами поговорим:

Практика подключения Windows 10 к домену

Ввод через новый интерфейс

Данный метод можно разделить на два, объясню почему. Текущая политика компании Microsoft, заключается в том, что она хочет привести внешний вид операционной системы Windows 10 к общему виду на всех устройствах, чтобы все действия, где бы их пользователь не совершал, выполнялись одинаково. С одной стороны это хорошо и наверное правильно, но с другой стороны, это влечет к постоянному и глобальному изменению интерфейса с каждым новым релизом и выпиливание классических оснасток, в виде панели управления.

Подключаем к домену Windows 10 до 1511

Для десятки с релизом Threshold 1 и 2 (1507 и 1511) процедура добавления компьютера в Active Directory имеет такой алгоритм. Вы нажимаете сочетание клавиш Win и I одновременно (Это одна из многих горячих комбинаций в Windows), в результате у вас откроется меню «Параметры». В параметрах вы находите пункт

Далее вы находите раздел «О системе», тут вы увидите сводную информацию, видно, что в моем примере у меня Windows 10 1511, и обратите внимание, что есть две удобные кнопки:

для подключения к домену вам необходимо указать его полное имя, в моем случае это root.pyatilistnik.org и нажимаем далее.

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

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

и последним этапом нужно выполнить перезагрузку рабочей станции, после этого ввод в домен Windows 10, можно считать успешным.

Подключаем к домену Windows 10 выше 1607

С версией 1511 мы разобрались, на мой взгляд там были удобно расположены кнопки, не знаю что не понравилось разработчикам. Теперь я вам приведу пример присоединения в Active Directory Windows 10 1607 и выше, в моем примере, это будет версия 1803. Вы также открываете «Параметры Windows». Если вы зайдете в систему и «О системе», то не обнаружите там нужных кнопок для подключения к AD предприятия, туше. Как я и писал выше функционал перенесли.

В параметрах Windows найдите и перейдите в пункт «Учетные записи»

Находите пункт «Доступ к учетной записи места работы иди учебного заведения» и нажимаем кнопку «Подключиться»

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

Про присоединение к Azure AD можно почитать вот это https://docs.microsoft.com/ru-ru/previous-versions//mt629472(v=vs.85)

У вас откроется окно «Настройка рабочей или учебной записи». В самом низу нас будет интересовать два пункта:

У вас откроется окно с вводом FQDN имени вашего домена Active Directory.

Далее вас попросят указать учетные данные для присоединения рабочей станции к AD.

Пропускаем шаг с добавлением учетной записи.

Когда все готово, то делаем обязательную перезагрузку, и ваша Windows 10, теперь является членом Active Directory.

После перезагрузки мы видим префикс домена.

Классический метод ввода в домен Windows 10

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

Откройте окно выполнить и введите команду:

У вас откроется окно «Свойства системы», в него можно так же попасть если щелкнуть по значку «Этот компьютер» и перейти в его свойства, далее выбрать «Изменить параметры»

На вкладке имя компьютера, нажмите кнопку «Изменить». В открывшемся окне «Изменение имени компьютера или домена», поставьте переключатель на поле «Является членом домена» и введите его имя, у меня это root.pyatilistnik.org. Нажмите ок.

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

Если проблем не возникло, то вы увидите окно «Добро пожаловать в домен root.pyatilistnik.org».

Далее вас уведомят, что необходимо произвести перезагрузку, «Чтобы изменения вступили в силу, нужно перезагрузить компьютер»

На выходе получаем присоединенную рабочую станцию с Windows 10 Pro к Active Directory.

Как подключить Windows 10 к домену с помощью PowerShell

Данный метод ввода в домен Active Directory, будет быстр и полезен, особенно для начинающих системных администраторов. Открываете оболочку PowerShell от имени администратора и пишите вот такую команду:

У вас появится окно авторизации, где вы должны указать учетные данные пользователя, у которого есть права на ввод в рабочей станции Windows 10 в домен.

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

Если открыть оснастку ADUC на контроллере домена, то в контейнере Computers, вы обнаружите вашу рабочую станцию.

Источник

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

Здравствуйте! Я почти 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 года делаем подобный пентест в другой организации, никак не связанной с первой, опять те же пароли, и опять сразу у нескольких пользователей. Начали что-то подозревать, нашли в одной оранжевой социальной сети такое вот руководство к действию:

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

Источник