Credentials Protection and Management
This topic for the IT professional discusses features and methods introduced in Windows Server 2012 R2 and Windows 8.1 for credential protection and domain authentication controls to reduce credential theft.
Restricted Admin mode for Remote Desktop Connection
Restricted Admin mode provides a method of interactively logging on to a remote host server without transmitting your credentials to the server. This prevents your credentials from being harvested during the initial connection process if the server has been compromised.
Using this mode with administrator credentials, the remote desktop client attempts to interactively logon to a host that also supports this mode without sending credentials. When the host verifies that the user account connecting to it has administrator rights and supports Restricted Admin mode, the connection succeeds. Otherwise, the connection attempt fails. Restricted Admin mode does not at any point send plain text or other re-usable forms of credentials to remote computers.
LSA protection
The Local Security Authority (LSA), which resides within the Local Security Authority Security Service (LSASS) process, validates users for local and remote sign-ins and enforces local security policies. The Windows 8.1 operating system provides additional protection for the LSA to prevent code injection by non-protected processes. This provides added security for the credentials that the LSA stores and manages. This protected process setting for LSA can be configured in Windows 8.1 but is on by default in Windows RT 8.1 and cannot be changed.
For information about configuring LSA protection, see Configuring Additional LSA Protection.
Protected Users security group
This new domain global group triggers new non-configurable protection on devices and host computers running Windows Server 2012 R2 and Windows 8.1. The Protected Users group enables additional protections for domain controllers and domains in Windows Server 2012 R2 domains. This greatly reduces the types of credentials available when users are signed in to computers on the network from a non-compromised computer.
Members of the Protected Users group are limited further by the following methods of authentication:
- A member of the Protected Users group can only sign on using the Kerberos protocol. The account cannot authenticate using NTLM, Digest Authentication, or CredSSP. On a device running Windows 8.1, passwords are not cached, so the device that uses any one of these Security Support Providers (SSPs) will fail to authenticate to a domain when the account is a member of the Protected User group.
- The Kerberos protocol will not use the weaker DES or RC4 encryption types in the preauthentication process. This means that the domain must be configured to support at least the AES cypher suite.
- The user’s account cannot be delegated with Kerberos constrained or unconstrained delegation. This means that former connections to other systems may fail if the user is a member of the Protected Users group.
- The default Kerberos Ticket Granting Tickets (TGTs) lifetime setting of four hours is configurable using Authentication Policies and Silos accessed through the Active Directory Administrative Center (ADAC). This means that when four hours has passed, the user must authenticate again.
Accounts for services and computers should not be members of the Protected Users group. This group provides no local protection because the password or certificate is always available on the host. Authentication will fail with the error “the user name or password is incorrect” for any service or computer that is added to the Protected Users group.
For more information about this group, see Protected Users Security Group.
Authentication Policy and Authentication Policy Silos
Forest-based Active Directory policies are introduced, and they can be applied to accounts in a domain with a Windows Server 2012 R2 domain functional level. These authentication policies can control which hosts a user can use to sign in. They work in conjunction with the Protect Users security group, and admins can apply access control conditions for authentication to the accounts. These authentication policies isolate related accounts to constrain the scope of a network.
The new Active Directory object class, Authentication Policy, allows you to apply authentication configuration to account classes in domains with a Windows Server 2012 R2 domain functional level. Authentication policies are enforced during the Kerberos AS or the TGS exchange. Active Directory account classes are:
- User
- Computer
- Managed Service Account
- Group Managed Service Account
For more information how to configure protected accounts, see How to Configure Protected Accounts.
See also
For more information about the LSA and the LSASS, see the Windows Logon and Authentication Technical Overview.
For more information about how Windows manages credentials, see Cached and Stored Credentials Technical Overview.
4624(S): учетная запись успешно выполнена.
—>
Описание события:
Это событие возникает при создании сеанса входа (на целевом компьютере). Он создает на компьютере, к которому был доступ, где был создан сеанс.
Рекомендации см. в статье Рекомендации по мониторингу безопасности для этого события.
XML события:
"/> 4624 2 0 12544 0 0x8020000000000000 211 "/> Security WIN-GG82ULGC9GO S-1-5-18 WIN-GG82ULGC9GO$ WORKGROUP 0x3e7 S-1-5-21-1377283216-344919071-3415362939-500 Administrator WIN-GG82ULGC9GO 0x8dcdc 2 User32 Negotiate WIN-GG82ULGC9GO - - 0 0x44c C:\\Windows\\System32\\svchost.exe 127.0.0.1 0 %%1833 - - - %%1843 0x0 %%1842 Необходимые роли сервера: нет.
Минимальная версия ОС: Windows Server 2008, Windows Vista.
Версии события:
- 0 — Windows Server 2008, Windows Vista.
- 1 — Windows Server 2012, Windows 8.
- Добавлено поле «Уровень олицетворения».
- Добавлен раздел «Сведения о входе:».
- Тип входа перемещен в раздел «Сведения о входе:».
- Добавлено поле «Ограниченный режим Администратор».
- Добавлено поле «Виртуальная учетная запись».
- Добавлено поле «Токен повышенных привилегий».
- Добавлено поле «Связанный идентификатор входа».
- Добавлено поле «Имя учетной записи сети».
- Добавлено поле «Домен учетной записи сети».
Описания полей:
Тема:
-
Идентификатор безопасности [Type = SID]: идентификатор безопасности учетной записи, которая сообщает сведения об успешном входе или вызывает его. Средство просмотра событий автоматически пытается разрешить идентификатор безопасности SID и отобразить имя учетной записи. Если идентификатор безопасности разрешить не удается, в событии будут отображены исходные данные.
Примечание Идентификатор безопасности (SID) — это уникальное значение переменной длины, используемое для идентификации доверенного лица (субъекта безопасности). Каждая учетная запись имеет уникальный идентификатор безопасности, выданный центром сертификации, таким как контроллер домена Active Directory, который хранится в базе данных безопасности. Каждый раз, когда пользователь входит в систему, система получает идентификатор безопасности этого пользователя из базы данных и помещает ее в маркер доступа этого пользователя. Система использует идентификатор безопасности в маркере доступа для идентификации пользователя во всех последующих операциях с Безопасностью Windows. Если идентификатор SID использовался как уникальный идентификатор для пользователя или группы, он не может использоваться повторно для идентификации другого пользователя или группы. Дополнительные сведения о SID см. в разделе Идентификаторы безопасности.
- Пример имени домена NETBIOS: CONTOSO
- Полное имя домена в нижнем регистре: contoso.local
- Полное имя домена в верхнем регистре: CONTOSO.LOCAL
- Для некоторых известных субъектов безопасности, таких как LOCAL SERVICE или ANONYMOUS LOGON, значение этого поля равно «NT AUTHORITY».
- Для учетных записей локальных пользователей это поле будет содержать имя компьютера или устройства, к которым принадлежит эта учетная запись, например: «Win81».
Сведения о входе [версия 2]:
- Тип входа [Версия 0, 1, 2] [Тип = UInt32]: тип выполненного входа. В приведенной ниже таблице содержится список возможных значений для этого поля.
Типы и описания входа
Тип входа в систему Название типа входа Описание 0 System Используется только системной учетной записью, например при запуске системы. 2 Interactive Пользователь успешно вошел в систему на данном компьютере. 3 Network Пользователь или компьютер вошли в систему на данном компьютере через сеть. 4 Batch Пакетный тип входа используется пакетными серверами, исполнение процессов на которых производится по поручению пользователя, но без его прямого вмешательства. 5 Service Служба была запущена диспетчером служб. 7 Unlock Эта рабочая станция была разблокирована. 8 NetworkCleartext Пользователь вошел в систему на данном компьютере через сеть. Пароль пользователя передан в пакет проверки подлинности в нехешированной форме. Встроенная проверка подлинности упаковывает все хешированные учетные записи перед их отправкой через сеть. Учетные данные не передаются через сеть открытым текстом. 9 NewCredentials Инициатор вызова клонировал свой текущий маркер и указал новые учетные данные для исходящих соединений. Новый сеанс входа в систему имеет то же самое локальное удостоверение, но использует другие учетные данные для других сетевых соединений. 10 RemoteInteractive Пользователь выполнил вход в систему на этом компьютере через службы терминалов или удаленного рабочего стола. 11 CachedInteractive Пользователь выполнил вход в систему на этом компьютере с сетевыми учетными данными, которые хранились локально на компьютере. Контроллер домена не использовался для проверки учетных данных. 12 CachedRemoteInteractive То же, что и RemoteInteractive. Используется для внутреннего аудита. 13 CachedUnlock Вход на рабочую станцию. - Режим ограниченного Администратор [версия 2] [Тип = ЮникодString]: заполнен только для сеансов типа входа RemoteInteractive. Это флаг «Да/Нет», указывающий, были ли предоставленные учетные данные переданы в режиме ограниченного Администратор. Режим ограниченного Администратор добавлен в Win8.1/2012R2, но этот флаг был добавлен в событие в Win10. Ссылка: https://blogs.technet.com/b/kfalde/archive/2013/08/14/restricted-admin-mode-for-rdp-in-windows-8-1-2012-r2.aspx. Если вход в RemoteInteractive не задан, это будет строка «-«.
- Виртуальная учетная запись [версия 2] [Type = UnicodeString]: флаг «Да» или «Нет», который указывает, является ли учетная запись виртуальной учетной записью (например, «Управляемая учетная запись службы»), которая была введена в Windows 7 и Windows Server 2008 R2 для предоставления возможности идентификации учетной записи, используемой данной службой, а не просто «NetworkService».
- Токен с повышенными привилегиями [версия 2] [Type = UnicodeString]: флаг «Да» или «Нет». Если «Да», сеанс, который представляет это событие, имеет повышенные права администратора.
Уровень олицетворения [версия 1, 2] [Type = UnicodeString]: может иметь одно из следующих четырех значений:
- SecurityAnonymous (отображается как пустая строка): серверный процесс не может получить сведения об идентификации клиента и не может олицетворить клиента. Он определяется без заданного значения и, следовательно, правилами ANSI C по умолчанию имеет значение, равное нулю.
- SecurityIdentification (отображается как «Идентификация«): серверный процесс может получать сведения о клиенте, такие как идентификаторы безопасности и привилегии, но он не может олицетворять клиента. Это полезно для серверов, которые экспортируют собственные объекты, например продукты базы данных, которые экспортируют таблицы и представления. Используя полученные сведения о безопасности клиента, сервер может принимать решения о проверке доступа, не имея возможности использовать другие службы, использующие контекст безопасности клиента.
- SecurityImpersonation (отображается как «Олицетворение«): серверный процесс может олицетворение контекста безопасности клиента в локальной системе. Сервер не может олицетворять клиент в удаленных системах. Это наиболее распространенный тип.
- SecurityDelegation (отображается как «Делегирование«): серверный процесс может олицетворять контекст безопасности клиента в удаленных системах.
Новый вход:
-
Идентификатор безопасности [Type = SID]: идентификатор безопасности учетной записи, для которой выполнен вход. Средство просмотра событий автоматически пытается разрешить идентификатор безопасности SID и отобразить имя учетной записи. Если идентификатор безопасности разрешить не удается, в событии будут отображены исходные данные.
Примечание Идентификатор безопасности (SID) — это уникальное значение переменной длины, используемое для идентификации доверенного лица (субъекта безопасности). Каждая учетная запись имеет уникальный идентификатор безопасности, выданный центром сертификации, таким как контроллер домена Active Directory, который хранится в базе данных безопасности. Каждый раз, когда пользователь входит в систему, система получает идентификатор безопасности этого пользователя из базы данных и помещает ее в маркер доступа этого пользователя. Система использует идентификатор безопасности в маркере доступа для идентификации пользователя во всех последующих операциях с Безопасностью Windows. Если идентификатор SID использовался как уникальный идентификатор для пользователя или группы, он не может использоваться повторно для идентификации другого пользователя или группы. Дополнительные сведения о SID см. в разделе Идентификаторы безопасности.
- Пример имени домена NETBIOS: CONTOSO
- Полное имя домена в нижнем регистре: contoso.local
- Полное имя домена в верхнем регистре: CONTOSO.LOCAL
- Для некоторых известных субъектов безопасности, таких как LOCAL SERVICE или ANONYMOUS LOGON, значение этого поля равно «NT AUTHORITY».
- Для учетных записей локальных пользователей это поле будет содержать имя компьютера или устройства, к которым принадлежит эта учетная запись, например: «Win81».
Примечание GUID — это аббревиатура от «Глобальный уникальный идентификатор». Это 128-разрядное целое число, используемое для идентификации ресурсов, действий или экземпляров.
Сведения о процессе:
- Идентификатор процесса [Type = Указатель]: шестнадцатеричный идентификатор процесса, который попытался выполнить вход. ИД процесса (PID) — это число, которое операционная система использует для идентификации активного процесса уникальным образом. Узнать значение PID для определенного процесса можно, например, в диспетчере задач (вкладка «Подробности», столбец «ИД процесса»): Если преобразовать шестнадцатеричное значение в десятичное, можно сравнить его со значениями в диспетчере задач. Кроме того, можно сопоставить этот ИД процесса с ИД процесса в других событиях, например в событии «4688: создан процесс» Информация о процессе \ ИД нового процесса.
- Имя процесса [Type = UnicodeString]: полный путь и имя исполняемого файла для процесса.
Сведения о сети:
- Имя рабочей станции [Type = UnicodeString]: имя компьютера, с которого была выполнена попытка входа.
- Исходный сетевой адрес [Type = UnicodeString]: IP-адрес компьютера, с которого была выполнена попытка входа.
- IPv6-адрес или ::ffff:IPv4-адрес клиента.
- ::1 или 127.0.0.1 означает localhost.
- 0 для интерактивных входов.
Подробные сведения о проверке подлинности:
- Процесс входа [Type = UnicodeString]: имя доверенного процесса входа, который использовался для входа. Дополнительные сведения см. в описании события «4611: процесс доверенного входа зарегистрирован в локальном органе безопасности».
- Пакет проверки подлинности [Type = UnicodeString]: имя пакета проверки подлинности, который использовался для процесса проверки подлинности входа. Пакеты по умолчанию, загруженные при запуске LSA, находятся в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig. Другие пакеты можно загрузить во время выполнения. При загрузке нового пакета регистрируется событие «4610: пакет проверки подлинности загружен локальным центром безопасности» (обычно для NTLM) или «4622: пакет безопасности загружен локальным центром безопасности» (как правило, для Kerberos) и указывает на то, что новый пакет загружен вместе с именем пакета. Наиболее распространенные пакеты проверки подлинности:
- NTLM — проверка подлинности семейства NTLM
- Kerberos — проверка подлинности Kerberos.
- Согласование — пакет безопасности Negotiate выбирает между протоколами Kerberos и NTLM. Согласование выбирает Kerberos, если он не может быть использован одной из систем, участвующих в проверке подлинности, или вызывающее приложение не предоставило достаточных сведений для использования Kerberos.
- «NTLM V1»
- «NTLM V2»
- «LM» Заполняется только в том случае, если «Пакет проверки подлинности» = «NTLM».
Рекомендации по контролю безопасности
Для 4624(S): учетная запись успешно выполнена.
Тип требуемого мониторинга Рекомендации Учетные записи большой ценности: у вас может быть домен или локальные учетные записи большой ценности, для которых необходимо отслеживать каждое действие.
Примеры учетных записей большой ценности: учетные записи администраторов баз данных, встроенная учетная запись локального администратора, учетные записи администраторов домена, учетные записи служб, учетные записи контроллеров домена и т. д.Отслеживайте это событие с помощью «New Logon\Security ID» , который соответствует высокоценной учетной записи или учетным записям. Аномалии и вредоносные действия: у вас могут быть особые требования касательно обнаружения аномалий или отслеживания потенциально вредоносных действий. Например, вам может потребоваться отслеживать использование учетной записи во внерабочее время. При отслеживании аномалий или вредоносных действий используйте «New Logon\Security ID» (с другими сведениями), чтобы отслеживать, как и когда используется определенная учетная запись. Неактивные учетные записи: у вас, возможно, есть неактивные, отключенные или гостевые учетные записи, а также другие учетные записи, которые не должны использоваться. Отслеживайте это событие с помощью «New Logon\Security ID» , который соответствует учетным записям, которые никогда не следует использовать. Список разрешенных учетных записей: возможно, у вас есть список разрешенных учетных записей, которым разрешено выполнять действия, соответствующие определенным событиям. Если это событие соответствует действию allowlist-only, проверьте «Новый идентификатор входа\Безопасность» для учетных записей, которые находятся за пределами списка разрешений. Учетные записи различных типов: вам может потребоваться, чтобы определенные действия выполнялись только учетными записями определенных типов, например локальными учетными записями или учетными записями домена, учетными записями компьютеров или пользователей, учетными записями поставщиков или сотрудников и т. д. Если это событие соответствует действию, которое вы хотите отслеживать для определенных типов учетных записей, просмотрите раздел «Новый идентификатор входа\Безопасность» , чтобы узнать, соответствует ли тип учетной записи ожидаемым. Внешние учетные записи: вам может потребоваться отслеживать учетные записи из другого домена или «внешние» учетные записи, которым не разрешено выполнять определенные действия (представленные определенными событиями). Отслеживайте это событие для «Subject\Account Domain» , соответствующего учетным записям из другого домена или «внешних» учетных записей. Ограничение использования компьютеров или устройств: у вас могут быть определенные компьютеры или устройства, на которых определенные люди (учетные записи) обычно не должны выполнять никаких действий. Отслеживайте целевой компьютер (или другое целевое устройство) на наличие действий, выполняемых «New Logon\Security ID» , о которых вас беспокоит. Соглашения об именовании учетных записей: в вашей организации могут быть определенные соглашения об именовании учетных записей. Отслеживайте «Subject\Account Name» для имен, которые не соответствуют соглашениям об именовании. - Так как это событие обычно активируется учетной записью SYSTEM, рекомендуется сообщать о нем всякий раз, когда «Subject\Security ID» не является SYSTEM.
- Если для входа определенными учетными записями должен использоваться режим «Ограниченный Администратор«, используйте это событие для отслеживания входов с помощью «New Logon\Security ID» относительно «Тип входа«=10 и «Ограниченный режим Администратор«=»Да». Если «Ограниченный режим Администратор» =»Нет» для этих учетных записей, активируйте оповещение.
- Если вам нужно отслеживать все события входа для учетных записей с правами администратора, отслеживайте это событие с помощью «Повышенный токен«=»Да».
- Если необходимо отслеживать все события входа для управляемых учетных записей служб и группировать управляемые учетные записи служб, отслеживайте события с помощью «Виртуальная учетная запись«=»Да».
- Чтобы отслеживать несоответствие между типом входа и учетной записью, которая его использует (например, если тип входа 4-Batch или 5-Service используется членом административной группы домена), отслеживайте тип входа в этом событии.
- Если ваша организация ограничивает вход в систему следующими способами, это событие можно использовать для соответствующего мониторинга:
- Если учетная запись пользователя «New Logon\Security ID» никогда не должна использоваться для входа с определенного компьютера:
- Если учетные данные New Logon\Security ID не должны использоваться из имени рабочей станции или исходного сетевого адреса.
- Если определенная учетная запись, например учетная запись службы, должна использоваться только из внутреннего списка IP-адресов (или другого списка IP-адресов). В этом случае можно отслеживать сведения о сети\Исходный сетевой адрес и сравнивать сетевой адрес со списком IP-адресов.
- Если определенная версия NTLM всегда используется в вашей организации. В этом случае это событие можно использовать для отслеживания имени пакета (только NTLM), например для поиска событий, в которых имя пакета (только NTLM) не равно NTLM V2.
- Если NTLM не используется в вашей организации или не должен использоваться определенной учетной записью (новый вход\Идентификатор безопасности). В этом случае отслеживайте все события, в которых пакет проверки подлинности имеет значение NTLM.
- Если пакет проверки подлинности — NTLM. В этом случае для монитора длина ключа не равна 128, так как все операционные системы Windows, начиная с Windows 2000, поддерживают 128-разрядную длину ключа.
Обратная связь
Отправить и просмотреть отзыв по
RDS-Knight
Расматривая тему уязвимостей Windows систем мы продолжим расказ о атаках направленных на корпоративные сети затронутой ранее. Удивительное дело, но теперь техника Pass-the-Hash работает и для RDP-подключений. То есть мы можем аутентифицироваться с помощью NTLM-хеша пользователя при подключении по RDP!
С другой стороны, я недавно узнал, что, оказывается, не все люди в курсе, что это такое — PtH. А потому кратенько расскажу про это дело.
Итак, начнем с того, что в ОС Windows многопользовательская система и потому ей надо хранить пароли пользователей. Но хранить их в открытом тексте не секьюрно, а потому их хранят захешироваными. Хеширование — это однонаправленная функция, по результату которой нельзя узнать входное значение (то есть нельзя «расшифровать»). NT-хеш — это тот формат, в котором винда хранит пароли. Причем подчеркну, что даже если это отдельный хост или домен — формат хранения один.
Второй важный момент — это глубокая поддержка Single Sign-on («единая» автоматическая аутентификация) виндой на базе NTLM-аутентификации. В ней не передается в открытом виде ни пароль, ни сам NT-хеш. Алгоритм такой: сначала клиент посылает запрос на подключение, потом сервер возвращает ему случайно сгенеренную последовательность (challenge). После этого клиент берет хеш-пользователя, соединяет c challeng’eм, хеширует и отправляет на сервер. Тот, в свою очередь, делает то же самое. И если хеши совпадают, то пользователь верный.
Выводом здесь будет то, что NT-хеш является полным эквивалентом пароля пользователя. Ведь почти все сервисы, которые есть в экосистеме Windows, поддерживают NTLM-аутентификацию. Например, HTTP, SMB (через который мы можем подключаться и управлять хостом удаленно), SMTP, FTP, подключения к SQL-серверу и так далее.
[ad name=»Responbl»]
Таким образом, захакав какой-то хост в домене, мы можем получить хеши пользователей из памяти и дальше ходить по сети, аутентифицируясь везде с ними. Это техника и называется Pass-the-Hash. В итоге защита домена складывается, как карточный домик.
Исключением всегда был протокол RDP. Раньше можно было подключиться, только введя пароль. И это составляло проблему, так как очень часто бывают закрытые сегменты (DMZ, например) в корпоративной сети, где на файрволе разрешен доступ только RDP (чтобы админы могли админить).
Несколько подключений к Win 2012 с использованием хеш-пароля администратора
Так вот, в Windows 8.1 и 2012 R2 по умолчанию теперь есть поддержка аутентификации с хешем. Но изначально у микрософта эта функция называется Restricted Admin Mode, и о «поддержке» PtH они, конечно, не говорят.
А потому давайте скажем спасибо ресерчерам сlabs.portcullis.co.uk за то, что они поведали миру всю правду (подробности, видеосмотри там же). Теперь коротко о практике. Все, что нам нужно для подключения, — результат трудов FreeRPD Project, то бишь опенсорсный RDP-клиент (по умолчанию входит в Kali). После публикации исследования они внедрили поддержку PtH прямо в него. А потому для подключения нам требуется следующая строка в консоли:
xfreerdp / d : domain_name / u : Administrator / pth : 8846F7EAEE8FB117AD06BDD830B7586C / v : 192.168.0.1
где после /d: — имя домена,
после /u: — имя пользователя,
после /pth: —хеш,
после /v: — IP сервера.Все просто.
И еще одна тонкость. Данная функция (Restricted Admin) работает только для администраторов. То есть залогиниться под юзерами из группы RDP Users не получится. Но невелика потеря!Restricted admin mode что это
Есть, на их основе в AD реализовано делегирование. Однако это вещь довольно опасная даже по сравнению с интерактивным логином — было бы достаточно чтобы любой пользователь
хотя бы по SMB ткнулся в сломанный терминальный сервер (даже если он вообще прав не имеет на этом RDSH), чтобы от его имени авторизоваться в любом сервисе, к которому разрешено делегирование (а их будет много, это ж терминальный сервер).Поэтому, наверное SSO через CredSSP Default Credentials Delegation посчитали оптимальным в свое время. Ну, а теперь вот Remote Credential Guard.
Комментарий пока не оценивали 0
Посмотреть Добавить в закладки
Всего голосов 1: ↑1 и ↓0 +1
Посмотреть Добавить в закладкиЕсли речь про SSO, то Kerberos не позволит уйти дальше сеанса на сервере, так как ограничивает авторизацию одной конечной точкой, и, в общем-то, в этом почти весь его смысл и есть. То есть, сервер проверил что вы это вы, а вот ваш сеанс на этом сервере уже не сможет на еще одном сервере прозрачно авторизоваться. Прощайте все сетевые ресурсы. Такой режим кстати есть начиная с 2012, называется Restricted Admin Mode.
А так вообще Kerberos вполне себе используется, но только для проверки подлинности сервера вместо сертификатов (если проходит Kerberos, кривой сертификат игнорится).
Еще начиная с 2016 есть режим Remote Credential Guard, но и клиент и сервер должны быть поддерживаемой версии, и это по сути дополнительная обертка над Kerberos.
Комментарий пока не оценивали 0
Посмотреть Добавить в закладкиС нашей «цифровизацией» ключи ЭЦП прибывают сейчас на предприятия лавинообразно, поэтому и захотелось свой кейс описать.
Что касается лицензий — постепенно ПО переходит на облачную проверку лицензирования, пусть не всё сразу — но это в том числе те отличия, которые могут быть одним из аргументов при выборе нового / планировании апгрейдов. Вендоры всегда балансируют между защитой от пиратов и отказоустойчивостью, но, как правило, именно у «облачных» лицензий есть достаточно лояльный grace period, зачастую измеряющийся в неделях.
А USB ключи, наоборот, чаще проверяются многократно прямо во время работы защищаемого ПО.Так что, зачастую, совсем уйти нельзя, но постепенно минимизировать риски возможно.
Комментарий пока не оценивали 0
Посмотреть Добавить в закладкиА что если навернется это счастье, а то и ключи с собой заберет?
Мне гораздо больше нравится идея вытащить ключи ЭЦП с токенов и загружать в профили нужных пользователей на терминальниках. Сразу становится гораздо лучше с отказоустойчивостью. Безопасность при этом вполне обеспечивается разделением пространства терминальных сессий, для параноиков можно VDI. Уж точно не хуже сильно нестандартной железки, которая у вас, как я понял, вообще в интернет напрямую смотрит (!).
От лицензионных же ключей просто по мере возможности нужно уходить — отказы ключей 1С «на 300» случались, и такое по-быстрому не решается. При этом, программные лицензии при всей своей небесспорности, по-крайней мере, дают 2 попытки моментального восстановления. Кстати, их можно сейчас на аппаратный ключ завязать, скрестив ежа с ужом и обеспечив как возможность легкой замены железа, так и использование резервных PIN в случае отказа ключа.
Комментарий пока не оценивали 0
Посмотреть Добавить в закладкиА ко мне какой-то вялый DDoS летит с их адресов. TCP SYN пакеты на все открытые tcp порты, по всем адресам. Заметил только по переполнению таблицы NAT, там большое время жизни записей, а так никакой заметной нагрузки.
До этого пару дней назад что-то похожее было с подсетей какого-то турецкого банка, который судя по турецким новостям в тот день тоже лежал…Интересно, что это? Может, издержки маршрутизации? Для намеренной атаки совсем слабо.
Комментарий пока не оценивали 0
Посмотреть Добавить в закладкиНе, я не из идеального мира, но из мира людей, применяющих политики назначения прав пользователей, чтобы доменные админы не заходили случайно куда не следует.
Первую часть не понял. Петя собирает все что есть в lsass, а дальше если у вас из этого списка кто-то вхож на другие рабочие станции как админ, то Петя приезжает и на них тоже.
Комментарий пока не оценивали 0
Посмотреть Добавить в закладкиNotPetya помимо эксплойта EternalBlue использовал mimikatz чтобы вытащить из памяти lsass lm-хэши локальных администраторов, и дальше пробовал с ними ходить по сети. Например, вот здесь есть об этом.
А чем плох встроенный администратор? Тривиально ведь найти на машине всех остальных. Разве что UAC у него выключен по умолчанию. Так ведь включить можно, да и вообще согласно Microsoft «UAC is not a security feature».
Всего голосов 1: ↑1 и ↓0 +1
Посмотреть Добавить в закладкиОпасные вы вещи говорите — все ведь ровно наоборот.
Именно потому что привилегии локального админа сравнительно легко достижимы, они должны быть изолированы в пределах одной рабочей станции. Иначе повысившись на одной станции можно по всей сети расползтись — что наглядно всем желающим и продемонстрировал NotPetya еще полтора года назад.Всего голосов 2: ↑2 и ↓0 +2
Посмотреть Добавить в закладкиТолько не забудьте защитить атрибут объекта, в котором пароль будете хранить, а то обычные поля компьютерных объектов по умолчанию весь домен может читать. А после этого сделать какой-то тул для просмотра этого атрибута, потому что в ADUC его видно не будет.
А еще что-то придумать для клиентов, которые не постоянно онлайн, чтобы не пропускали время запуска скрипта.
А также не забудьте открыть везде порты, чтобы COM-RPC работал с сервера, на котором скрипт запускается, к клиентам — а то по умолчанию, например, клиенты общаются с контроллером домена только в режиме pull.
Ну и как следует защитить учетную запись, от которой запускается скрипт — прав у нее в сети будет немало.Или можно вместо всей этой головной боли использовать LAPS, официальное и поддерживаемое (бесплатное) решение от Microsoft.
Всего голосов 3: ↑3 и ↓0 +3
Посмотреть Добавить в закладкиА кэширование учетных данных на рабочих станциях при этом включено или выключено? Если выключено, то у вас нет аварийного входа в случае, если нет связи с доменом. Если включено, то креативный пользователь mimikatz может натворить больших дел у вас в сети — см NotPetya.
Всего голосов 1: ↑1 и ↓0 +1
Посмотреть Добавить в закладкиПри добавлении RADIUS клиента в NPS поддерживается CIDR-синтаксис в поле «адрес». Можно сразу всю подсеть с точками добавить как одного клиента.
NAT, конечно, оригинально, но…Всего голосов 1: ↑1 и ↓0 +1
Посмотреть Добавить в закладкиСпасибо, подробно и доходчиво. А расскажите, пожалуйста, что-нибудь про производительность в режиме расшифровки SSL? Как показала практика, у некоторых вендоров с этим большая-большая беда — включая, скажем, отнюдь недешевые Checkpoint и Palo Alto.
Причем конкретные цифры никто не публикует, в отличие, например, от производительности IPS. А между тем, без расшифровки SSL DPI-фичи на 443 порту толком работать просто не будут, и весь NGFW превращается в тыкву.
Всего голосов 2: ↑2 и ↓0 +2
Посмотреть Добавить в закладкиЕсть еще хороший вариант для SfB — Jabra Dial 550. Отличный звук, неплохой спикерфон, все кнопки работают с SfB. Но стоит далеко не 3 бакса, ~5-6000Р.
Комментарий пока не оценивали 0
Посмотреть Добавить в закладкиCXы на прошивке от Microsoft — Lync Phone Edition, её развитие прекращено и через пару лет она будет снята с поддержки окончательно. Даже прошивку с заменой названия Lync на Skype for business для них не выпустили. Сам софт специфический, очень много функций зарыты в меню, мало физических кнопок.
Snom есть один (800й) тоже на LPE, с теми же ограничениями, а все остальные (700е) на собственной UC firmware, которую они перестали развивать осенью прошлого года, и из партнерской программы с MS вышли.
Так что из современных остались только VVXы, да Аудиокодес. По опыту ценник на них обоих заметно выше. VVX600 стоит около 30 000Р, а T48 — условно, 15. VVX310 — около 13 000, а T42 — 8 000. При этом свои грабли и тараканы в Поликомах тоже есть.
Комментарий пока не оценивали 0
Посмотреть Добавить в закладкиСофт не требуется, а просто предлагается как опция. То есть, можно и без него. Просто какие-то действия удобнее в софте делать, поэтому логично объединить софтфон с телефоном.
А отличие от гарнитуры есть — лучше качество звука, громкий спикерфон, можно звонить без компьютера, физические кнопки под рукой, ну и далее в том же духе. Насколько это необходимо, каждый решает для себя сам. У нас, например, большая часть абонентов обходятся без аппаратов, но какое-то их количество все равно нужно.
Комментарий пока не оценивали 0
Посмотреть Добавить в закладкиХорошие аппараты для SfB, в целом. Есть опыт с двумя старшими моделями.
Есть один неприятный минус — нельзя нормально сохранить контакт с городским телефонным номером. Либо отображается один номер без имени, либо email-адрес и имя, но номера телефона вообще не будет. Можно, конечно, сохранить в локальные контакты, но это, во-первых, идеологически неверно, а во-вторых, при сохранении локального контакта почему-то не работает шикарная экранная клавиатура на 48ом. То есть имя-фамилию нужно набирать на цифровой клавиатуре.
Ноги этой проблемы растут, судя по всему, из полного отсутствия интеграции с контактами в Exchange, поэтому, видимо, и решить никак не могут.
В остальном довольно убедительные аппараты — интерфейс 48ого субъективно нагляднее, логичнее, и удобнее, чем у VVX600, и это при стоимости ниже, чем VVX410, который вообще сравнения в таком разрезе не выдерживает, ибо по меню замучаешься прыгать.
Особых глюков не замечено, основные функции все есть, качество спикерфона на уровне VVXов (!). Техподдержка на yealink.com отвечает, работает, и финскит потихоньку найденные легкие баги.
Snom от развития поддержки SfB отказались, так что из конкурентов остались недешевые Поликомы с отпиленным начисто в РФ SRTP, да Аудиокодес. Причем последние совсем не впечатлили, от интерфейса до качества звука.