Заметки о Windows

Настойка буфера обмена в RDP-сессии

Kirill — Sat, 21 Mar 2026 20:19:54 +0000

При работе с удаленным рабочим столом по протоколу RDP у пользователя есть возможность пробрасывать локальные ресурсы (диски, принтера, буфер обмена и т.п.) в удаленный сеанс. Это очень удобно, поскольку позволяет пользоваться локальными ресурсами на удаленном сервере — копировать файлы, распечатывать документы и многое другое. Но с точки зрения безопасности это не всегда допустимо, поэтому часто доступ к локальным ресурсам запрещается или ограничивается. И сегодня мы поговорим о том, каким образом можно контролировать доступ к буферу обмена.

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

Ограничить доступ к буферу обмена можно несколькими различными способами

Ограничение на клиенте с помощью реестра

Для того, чтобы запретить обмен информацией в удаленной сессии через буфер обмена необходимо на клиентской ОС в ветке реестра HKLM\Software\Microsoft\Terminal Server Client создать параметр типа DWORD с именем DisableClipboardRedirection и значением 1. Для отмены запрета можно присвоить параметру значение 0 либо просто удалить его.

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

Ограничение на сервере с помощью реестра

Чаще доступ к буферу запрещают на стороне сервера. Если сервер один, это можно сделать также с помощью реестра, установив в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp для параметра DWORD с именем fDisableClip значение 1. Для отключения запрета параметру можно задать значение 0 или удалить его.

Примечание. Для того, чтобы настройки применились, требуется перезагрузка. Как вариант, можно перезапустить сам буфер обмена (rdpclip.exe).

Ограничение с помощью групповых политик

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

За доступ к буферу обмена отвечает политика Do not allow Clipboard redirection находящаяся в разделе Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection

Действует эта политика крайне просто — при включении (enabled) запрещает использование буфера обмена в RDP-сессии в обе стороны. Т.е. скопировать что либо на сервер или с сервера невозможно.

При применении этой политики создается уже знакомый нам параметр реестра fDisableClip имеющий значение 1, но находящийся в ветке реестра HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.

Отключение проброса локальных дисков

А теперь один маленький, но важный нюанс. На работу буфера обмена в терминальной сессии влияет доступность локальных дисков. За проброс локальных дисков в сессию отвечает политика Do not allow drive redirection находящаяся в том же разделе.

При включении эта политика создает параметр реестра fDisableCdm со значением 1 в ветке реестра HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.

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

Об этом явно сказано в описании политики.

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

Новые объекты групповых политик

Но это еще не все. Начиная с Windows Server 2022\Windows 11 появились новые объекты групповых политик, отвечающие за доступ к буферу обмена. Находятся они в том же разделе и называются Restrict clipboard transfer from client to server и Restrict clipboard transfer from server to client.

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

Если посмотреть в реестр, то каждая политика создает в ветке HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services параметр DWORD с одним и тем же именем CSClip.level и значением от 0 до 4. Т.е. если включить обе политики, то в реестре создаются 2 абсолютно одинаковых параметра. Различить их можно только в том случае, если задать им разные значения.

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

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

На этом, пожалуй, все.

Из crt в pfx и обратно или конвертирование сертификатов с помощью OpenSSL

Kirill — Mon, 11 Aug 2025 15:42:50 +0000

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

Все SSL-сертификаты соответствуют стандарту X.509 . Этот стандарт определяет формат данных и процедуры распространения открытых ключей с помощью соответствующих сертификатов с цифровыми подписями. Эти сертификаты предоставляются удостоверяющими центрами (Certificate Authority). Кроме того, X.509 определяет формат списка отозванных сертификатов (Certificate Revocation List), формат полей сертификата и алгоритм проверки подлинности с помощью пути сертификации. В основе X.509 лежит наличие иерархической системы удостоверяющих центров для выдачи сертификатов.

На данный момент актуальна версия X.509 v3, которая описана в RFC 5280.

Форматы сертификатов

Для X.509 существует 4 формата сертификатов:

PEM (Privacy-Enhanced Mail)

Дословно переводится как формат почты с повышенной конфиденциальностью. Является наиболее распространенным форматом для SSL-сертификатов. Файл PEM представляет из себя обычный текстовый файл, содержащий один или несколько элементов в кодировке Base64 ASCII. Данные в файле располагаются между верхним и нижним колонтитулами, например вот так:

-----BEGIN CERTIFICATE-----
[данные в кодировке base64]
-----END CERTIFICATE-----

Один файл PEM может содержать сертификат конечного объекта, закрытый ключ или несколько сертификатов, образующих полную цепочку доверия. Большинство файлов, получаемых от коммерческих центров сертификации, будут в формате PEM. Файл PEM может иметь расширение .crt, .pem, .cer и .key (для закрытых ключей).

В основном сертификаты в формате PEM используются в операционных системах Linux/Unix.

PKCS #7 (Public-Key Cryptography Standards #7)

Также известен как Cryptographic Message Syntax (CMS). Стандарт определяет общий формат для хранения и передачи подписанных и зашифрованных сообщений, а также цепочек доверия. В основном используется для реализации электронной цифровой подписи (ЭЦП), а также для шифрования данных и проверки сертификатов. Файлы PKCS # 7 не используются для хранения закрытых ключей.

Содержимое файла, так же как и для PEM, хранится в виде текста, в кодировке ASCII. Расширение файла .p7b, .p7c. Чаще всего встречается в Windows и Java.

DER (Distinguished Encoding Rules)

Это двоичная кодировка сертификатов и закрытых ключей X.509. В отличие от файлов PEM файлы DER не содержат удобочитаемых простых текстовых операторов.

Файл DER имеют расширение der, .cer. В основном используются в контексте Java, но встречаются и в Windows.

PKCS#12

Он же PFX (Personal Information Exchange). PFX представляет собой зашифрованный контейнер, содержащий сертификат сервера, промежуточные сертификаты и закрытый ключ. Содержимое файла хранится в двоичном формате. Файлы PFX используются для экспорта и импорта сертификатов и связанных с ними закрытых ключей.

Файл PFX обычно имеет расширение .pfx или .p12. PFX является основным форматом SSL-сертификатов в Windows.

Цепочка сертификатов

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

Путь доверия — это последовательность (цепочка) сертификатов, которая начинается с корневого (Root) сертификата с высоким уровнем доверия, проходит через промежуточные (Intermediate) сертификаты и заканчивается конечным сертификатом.

Для примера возьмем сертификат моего сайта, откроем его свойства и перейдем на вкладку ‘Путь сертификации’. Вот так выглядит путь сертификации в моем случае:

GlobalSign Root CA -> GlobalSign GCC R6 AlphaSSL -> windowsnotes.ru

Работает это очень просто — мы доверяем корневому CA, он доверяет промежуточному, а промежуточный доверяет сайту windowsnotes.ru, значит мы тоже доверяем сайту.

А почему мы должны доверять корневому CA? А потому, что его сертификат находится на нашем компьютере, в хранилище сертификатов. Удостовериться в этом просто, достаточно открыть оснастку управления сертификатами и зайти в раздел Доверенные корневые центры сертификации (Trusted Root Certification Authority).

Здесь вы можете увидеть все выпускающие CA, которым доверяет Microsoft. Этот список входит в состав операционной системы изначально, а также обновляется во время обновления операционной системы. При необходимости его можно загрузить и вручную, например отсюда https://learn.microsoft.com/en-us/security/trusted-root/participants-list.

Теперь переходим к тому, как сконвертировать сертификат нужного формата. По своему опыту могу сказать, что в 99% случаев встречаются всего 2 сценария конвертации.

Конвертация из PEM в PFX

Один из наиболее распространенных сценариев — мы получили коммерческий SSL-сертификат и нам надо установить его на Windows сервера. Как правило, коммерческие CA предоставляют сертификаты в формате PEM, а нам требуется PFX. Вот, к примеру, что я получил от GlobalSign.

Здесь crt и key- собственно сам сертификат и закрытый ключ к нему в формате PEM, ca_bundle — цепочка доверия, тоже в формате PEM, и csr -файл запроса (Certificate Signing Request). И из этого нам надо получить файл PFX, содержащий сертификат и ключ. Конвертацию будем производить с помощью утилиты OpenSSL.

Первым делом запускаем командную строку и переходим в папку с сертификатом. Для того, чтобы сконвертировать сертификат и ключ из PEM в PFX выполняем команду:

openssl pkcs12 -export -in windowsnotes.ru.pem -inkey windowsnotes.ru.key -out windowsnotes_ru.pfx

вводим пароль для экспорта закрытого ключа, подтверждение, и на выходе получаем сертификат в формате PFX, который можем устанавливать на Windows-сервера.

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

openssl pkcs12 -export -in windowsnotes.ru.pem -inkey windowsnotes.ru.key -out windowsnotes.ru.pfx -certfile windowsnotes.ru.ca_bundle

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

Конвертация из PFX в PEM

Второй по распространенности сценарий — у нас есть корпоративный CA на базе Windows, на котором мы выпускаем сертификаты для сервисов на Linux. Соответственно на входе имеем файл PFX, на выходе должны получить сертификат и ключ в формате PEM. При экспорте сертификата в Windows необходимо указать пароль. Постарайтесь не забыть его, поскольку этот пароль требуется ввести при конвертации из PFX в PEM.

Первым делом получаем открытую часть сертификата командой:

openssl pkcs12 -in windowsnotes_ru.pfx -clcerts -nokeys -out windowsnotes_ru.crt

Затем получаем закрытый ключ:

openssl pkcs12 -in windowsnotes_ru.pfx -nocerts -out windowsnotes_ru.key

По умолчанию закрытый ключ шифруется парольной фразой (PEM pass phrase), которую необходимо указать при его экспорте или конвертировании.

В итоге получаем закрытый ключ в зашифрованном виде.

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

С помощью ключа -nodes можно сразу выгрузить ключ без пароля, в расшифрованном виде:

openssl pkcs12 -in windowsnotes_ru.pfx -nocerts -nodes -out windowsnotes_ru_unenc.key

Ну и как вариант, можно расшифровать сам ключ. Для этого надо выполнить команду:

openssl rsa -in windowsnotes_ru.key -out windowsnotes_ru_unenc.key

Еще из PFX , с помощью ключа -cacerts можно отдельно выгрузить цепочку сертификатов:

openssl pkcs12 -in windowsnotes_ru.pfx -cacerts -nodes -nokeys -out cacerts.crt

Результат работы команды зависит от того, как был создан файл PFX, добавлялись ли сертификаты CA по отдельности или вместе, а также от порядка добавления сертификатов CA в файл PFX. В нашем случае мы получим содержимое ca_bundle, которое было добавлено при конвертации в PFX.

Все остальные варианты конвертации встречаются крайне редко. Но для общего развития рассмотрим и их.

Конвертация из PEM в DER

Сконвертировать сертификат в формате PEM в формат DER можно командой:

openssl x509 -outform der -in windowsnotes_ru.crt -out windowsnotes_ru.der

В обратную сторону команда конвертации будет такая:

openssl x509 -inform der -in windowsnotes_ru.der -out windowsnotes_ru.crt

Конвертация из PEM в PKCS #7

Такой командой сконфертируем сертификат из PEM в PKCS#7:

openssl crl2pkcs7 -nocrl -certfile windowsnotes_ru.crt -out windowsnotes_ru.p7b

и в обратную сторону:

openssl pkcs7 -print_certs -in windowsnotes_ru.p7b -out windowsnotes_ru.crt

Ну вот вроде и все. Как видите, ничего сложного 🙂

Простой способ подключения по ssh в VirtualBox

Kirill — Mon, 12 May 2025 10:24:57 +0000

Как в VirtualBox подключиться к виртуальной машине по ssh? Можно пойти традиционным путем — подключить машину к внешней сети, выдать ей IP-адрес и подключаться как к обычному компьютеру. Но есть способ проще…

Если вы не хотите выставлять машину наружу, то можно воспользоваться пробросом портов. Для этого надо открыть свойства машины, перейти на вкладку Network и выбрать тип сетевого адаптера NAT. Затем нажать на кнопку Port Forwarding

и в открывшемся окне создать новое правило проброса портов со следующими параметрами:

Name: ssh
Protocol: TCP
Host Port: 2022
Guest Port: 22

Имя можно указать любое, более менее понятное, Host Port можно выбрать любой свободный. Остальные поля оставляем пустыми и сохраняем правило.

Теперь открываем консоль и подключаемся к машине, указав выбранный порт:

ssh -p 2022 127.0.0.1

Способ немного корявый, но зато максимально простой и быстрый.

Управление суффиксами UPN в Active Directory

Kirill — Fri, 28 Mar 2025 08:35:51 +0000

Имя участника-пользователя (User Principal Name, UPN) — одно из имен пользователя в Active Directory, основанное на стандарте RFC 822 . Его еще называют именем пользователя в стиле интернета, поскольку по формату оно схоже с именем электронной почты.

Состоит UPN из двух частей — префикса (имя участника-пользователя) и суффикса (имя субъекта-пользователя). Префикс объединяется с суффиксом с помощью символа «@». Суффикс UPN по умолчанию определяет домен, в котором размещается учетная запись пользователя. Например, для пользователя vasily_p, находящегося в домене test.local, UPN по умолчанию будет vasily_p@test.local.

Добавление суффикса UPN

По умолчанию в Active Directory суффиксом UPN является DNS-имя первого домена в лесу доменов. Но иногда требуется добавить дополнительные (альтернативные) UPN суффиксы. Например, вы хотите, чтобы имя пользователя совпадало с именем его почтового ящика, но внутреннее имя домена AD не соответствует внешнему почтовому домену. Или требуется разделить пользователей по какому либо признаку — например принадлежности к определенной организации или физическому местоположению. Также при использовании в AD немаршрутизируемого имени (напр. test.local) невозможно добавить домен в Microsoft Azure и настроить синхронизацию.

Суффикс UPN имеет следующие ограничения:

• Он должен быть DNS именем домена, но не обязательно того, в котором находится пользователь;
• Это может быть имя домена в текущем лесу, или любое альтернативное имя.

Дополнительные суффиксы UPN хранятся в разделе Partitions конфигурации AD, в атрибуте upnSuffixes. Добавить их можно различными способами, например с помощью ADSIEdit. Для этого надо подключиться к конфигурации, перейти к разделу Partitions, выделить его правой клавишей мыши и выбрать раздел свойств (Properties).

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

Добавлять суффиксы можно также с помощью оснастки Active Directory Domains and Trusts. Для этого надо открыть оснастку, кликнуть в корне правой клавишей мыши и в открывшемся контекстном меню выбрать пункт Properties.

Затем во вкладке UPN suffixes добавить нужный суффикс и нажать Add.

Ну и конечно же управлять UPN-суффиксами можно с помощью PowerShell. Посмотреть имеющиеся суффиксы можно командой:

Get-ADForest | fl name,upn*

Поскольку атрибут upnSuffixes, в котором хранятся суффиксы, представляет из себя массив, то для добавления нового элемента массива воспользуемся методом Add:

Ser-ADForest -Identity test.local -UPNSuffixes @{add="office.moscow"}

Изменение суффикса UPN пользователя

После добавления суффиксов UPN при создании нового пользователя появляется возможность выбрать для него нужный суффикс. В консоли ADUC суффикс выбирается из выпадающего списка

а при использовании PowerShell потребуется явно указать UPN с нужным суффиксом:

NewADUser -Name "sidorov petr" -SamAccountName "sidorov_p" -UserPrincipalName "sidorov_p@test.ru"

Для изменения суффикса UPN уже имеющихся пользователей можно зайти в свойства учетной записи и выбрать из списка нужный суффикс,

либо воспользоваться PowerShell:

Set-ADUser vasily_p -UserPrincipalName vasily_p@test.ru

Изменить UPN-суффикс у группы пользователей пользователей можно с помощью ADUC. Для этого надо выделить нужных пользователей и открыть пункт Properties

а затем поставить галку UPN suffix и выбрать нужный суффикс.

Вариант с ADUC простой, но не очень гибкий. Если требуется поменять пользователям UPN-суффикспо какому то произвольному алгоритму, например по расположению в OU, принадлежности к департаменту или просто по списку, то тут лучше подойдет PowerShell. Вариантов много, для примера поменяем суффикс пользователям, расположенным в OU Employees:

$users = Get-ADUser -Filter * -SearchBase "OU=Employees, DC=test, DC=local";
foreach ($user in $users) {Set-ADUser -UserPrincipalName ($user.UserPrincipalName.replace("test.local","office.moscow"))}

Удаление суффикса UPN

Если требуется удалить лишние суффиксы UPN, сделать это можно с помощью PowerShell. Команда практически такая же, как и при добавлении, только теперь мы используем метод remove:

Ser-ADForest -Identity test.local -UPNSuffixes @{remove="office.moscow"}

Также для удаления можно воспользоваться графической оснасткой. Для этого надо выбрать суффикс и нажать кнопку Remove.

В заключение несколько интересных моментов касательно UPN, о которых нужно помнить.

Не смотря на то, что имя участника-пользователя состоит из двух независимых друг от друга частей, хранится оно как единое целое, в атрибуте пользователя UserPrincipalName.

Из этого следует, что хотя UPN пользователя должно быть уникальным среди всех объектов в пределах леса, однако префикс (имя пользователя) можно повторно использовать с другим суффиксом. Т.е. технически можно создать в одном домене двух одинаковых пользователей, назначив им разные суффиксы UPN.

Также стоит помнить, что UPN не является обязательным атрибутом пользователя, поэтому технически можно создать пользователя без UPN. Графическая оснастка ADUC сделать такое не позволит, а вот PowerShell вполне. К примеру вот такая команда успешно отработает и пользователь будет создан:

NewADUser -Name "sidorov petr" -SamAccountName "sidorov_p"

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

На этом, пожалуй, все.

Настройка SSH аутентификации по ключам

Kirill — Wed, 22 Jan 2025 13:57:26 +0000

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

Использование ключей основано на асимметричном шифровании. Асимметричное шифрование — это метод шифрования данных, предполагающий использование пары ключей — открытого и закрытого. Открытый (публичный) ключ применяется для шифрования информации и может передаваться по незащищенным каналам. Закрытый (приватный) ключ применяется для расшифровки данных, зашифрованных открытым ключом. Открытый и закрытый ключи представляют из себя наборы символов, связанные друг с другом определенной функцией, но так, что, зная один, крайне сложно вычислить второй.

Теоретически приватный ключ от асимметричного шифра можно вычислить, зная публичный ключ и механизм, лежащий в основе алгоритма шифрования. Поэтому надежными считаются ключи, для которых это нецелесообразно с практической точки зрения. Так на данный момент удалось взломать ключ RSA длиной 768 бит, на что потребовалось 4000 вычислительных лет (core years).

Примечание. Один вычислительный год эквивалентен непрерывному использованию одного процессорного ядра в течение года. Использование 12 ядер в месяц или 365 ядер в течение одного дня эквивалентно 1 вычислительному году.

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

Принцип действия асимметричного шифрования

Схема передачи данных между двумя субъектами (А и B) с использованием открытого ключа выглядит следующим образом:

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

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

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

Для генерации ключей используются несколько алгоритмов шифрования:

RSA (Rivest–Shamir–Adleman) — самый старый и распространённый алгоритм шифрования с открытым ключом. Основывается на вычислительной сложности задачи факторизации больших полупростых чисел. По сравнению с DSA, RSA быстрее проверяет подпись, но медленнее ее генерирует. Стойкость основана на факторизации целых чисел, поэтому безопасный генератор случайных чисел (RNG, Random Number Generator) не требуется. Рекомендуемая минимальная длина ключа — 2048 бит;

DSA (Digital Signature Algorithm) — криптографический алгоритм для создания цифровой подписи (не для шифрования, в отличии от RSA) с использованием пары ключей. Алгоритм DSA основывается на вычислительных задачах, связанных с дискретным логарифмированием. DSA по сравнению с RSA быстрее генерирует подпись, но медленнее ее проверяет. Стойкость ключа зависит от качества RNG. На данный момент считается небезопасным, не поддерживается OpenSSH с версии 7 и не рекомендуется к использованию;

ECDSA (Elliptic Curve D — асимметричный алгоритм шифрования с открытым ключом для создания цифровой подписи, использующий математические свойства эллиптических кривых для генерации ключей и выполнения операций над ними. Способен обеспечить относительно тот же уровень безопасности, что и RSA, но с меньшей длиной ключа. Рекомендуемый минимальный размер ключа для ECDSA — 256 бит. Поскольку ECDSA является развитием DSA, то он имеет тот же недостаток — чувствительность к качеству RNG;

EdDSA (Edwards-curve Digital Signature Algorithm) — алгоритм цифровой подписи на основе кривой Эдвардса. Это схема цифровой подписи, использующая вариант подписи Шнорра, основанный на искривленных кривых Эдвардса. Создание подписи в EdDSA является детерминированным, его безопасность основана на трудноразрешимости определенных задач дискретного логарифма, поэтому он безопаснее, чем DSA и ECDSA, которые требуют высококачественной случайности для каждой подписи;

Ed25519 — вариант EdDSA, использующий SHA-512/256 и эллиптическую кривую, связанную с Curve25519. Обеспечивает лучшую безопасность, чем DSA, ECDSA и EdDSA, а также имеет лучшую производительность. На данный момент наиболее рекомендуемый алгоритм шифрования.

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

Настройка аутентификации по ключу в Linux

Итак, переходим от теории к практике. Для опытов у нас есть два сервера на Ubuntu 24.04 LTS. В качестве клиента выступает SRV1, а сервер, к которому мы будем подключаться, зовут SRV2.

Для начала необходимо на сервере SRV1 сгенерировать пару ключей. Сделать это можно с помощью специальной утилиты ssh-keygen, которая входит в пакет OpenSSH. Запустим ее командой:

ssh-keygen

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

По умолчанию ключи создаются в домашней директории пользователя, в каталоге ~/.ssh. Имена для ключей генерируются, исходя из используемого алгоритма, так для RSA это будет id_rsa для приватного и id_rsa.pub для публичного ключа, а для Ed25519 — id_ed25519 и id_ed25519.pub соответственно.

При необходимости можно изменить параметры генерируемых ключей, например указать желаемый алгоритм и размер ключа. Для примера сгенерируем ключ RSA длиной 2048 бит с именем srv2key:

ssh-keygen -t RSA -b 2018 -f ~/.ssh/srv2key

И раз уж мы создали два разных типа ключей, давайте их сравним. Посмотрите, какая разница в длине между ED25519 и RSA при сопоставимой безопасности. И это только 2048 бит, а сейчас уже рекомендуется использовать 4096-битные RSA-ключи.

Ключи у нас есть, теперь надо публичный ключ перенести на SRV2, к которому мы планируем подключаться, для чего его необходимо добавить в файл ~/.ssh/authorized_keys. Проще всего сделать это с помощью утилиты ssh-copy-id, также входящей в набор утилит OpenSSH. Для копирования ключа надо перейти в директорию с ключами и запустить утилиту, указав файл ключа, имя пользователя и удаленный сервер. В нашем случае сервер SRV2, пользователь administrator, соответственно команда будет выглядеть так:

ssh-copy-id -i ~/.ssh/id_ed25519.pub administrator@srv2

Имя ключа в принципе можно не указывать. Если их несколько, то будет выбран ключ с дефолтным именем, в нашем случае это id_ed25519.pub. Если же есть несколько ключей с именем по умолчанию, но разных типов, например rsa и ed25519, то скопируется ключ RSA.

Для тех, кто не ищет легких путей, есть второй вариант копирования ключа. В этом случае сначала на удаленном сервере проверяем наличие в домашнем каталоге пользователя директории ~/.ssh, и если она отсутствует, то создаем ее:

mkdir ~/.ssh

назначаем на директорию права:

chmod 0700 ~/.ssh

создаем файл ~/.ssh/authorized_keys:

touch ~/.ssh/authorized_keys

и назначаем права на файл:

chmod 0644 ~/.ssh/authorized_keys

Теперь копируем ключ в файл командой:

cat ~/.ssh/id_ed25519.pub | ssh administrator@srv2 "cat >> ~/.ssh/authorized_keys"

Каким бы способом вы не воспользовались, в итоге ключ будет добавлен на SRV2, в домашнюю директорию пользователя administrator, в файл /.ssh/authorized_keys.

Теперь остается только набрать:

ssh administrator@srv2

и вот мы уже на SRV2, без запроса пароля и прочих глупостей)

Файл known_hosts

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

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

″The authenticity of host ‘srv2 (192.168.147.170)’ can’t be established.
RSA key fingerprint is SHA256:kd9mRkEGLo+RBBNpxKp7mInocF3/Yl/0fXRsGJ2JfYg.
Are you sure you want to continue connecting (yes/no)?″

Соответственно нам предстоит решить, уверены ли мы в том, куда именно подключаемся. Если согласиться, то в файл ~/.ssh/known_hosts добавится строка, в которой через пробел записаны: хэш от имени сервера, название используемого алгоритма и публичный ключ сервера. И при каждом последующем подключении SSH-клиент будет проверять, совпадает ли публичный ключ для этого сервера с тем, который был прошлый раз.

Защита приватного ключа паролем

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

Пароль можно задать как при создании ключа, так и позже, с помощью все той же утилиты ssh-keygen. Для этого выполним команду:

ssh-keygen -p -f ~/.ssh/id_ed25519

введем парольную фразу и подтверждение.

Теперь ключ в безопасности. Но есть один минус — при аутентификации с ключом придется вводить пароль.

Избежать постоянного ввода пароля можно с помощью агента ssh-agent, который является частью OpenSSH. Агент SSH — это менеджер ключей для SSH. Он загружает ключи в оперативную память и хранит их там, незашифрованные и готовые к использованию. Это избавляет от необходимости вводить пароль при каждом подключении к серверу.

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

Агент работает в фоновом режиме, отдельно от ssh. По умолчанию он неактивен, запустить его можно командой:

eval `ssh-agent -s`

Затем в него надо загрузить ключи командой:

ssh-add

Если не указывать конкретные ключи, то ssh-add проверяет домашний каталог пользователя на наличие стандартных ключей (id_rsa, id_ed25519 и т.п.) и загружает их в память. При загрузке ключа потребуется однократно ввести его пароль, зато после добавления ключей они будут автоматически использоваться ssh в течение всего сеанса пользователя, без необходимости ввода пароля.

Вывести список ключей, загруженных в агент, можно командой:

ssh-add -l

А можно ли сделать так, чтобы ssh-agent запускался автоматически, при логине, и сам подгружал все необходимые ключи? Можно, например с помощью утилиты keychain (связка ключей). Это менеджер ключей, работающий в паре с агентом. Он проверяет наличие работающего ssh-agent и запускает его, если он не запущен, а также сохраняет переменные среды ssh-agent в файл ~/.keychain/${HOSTNAME}-sh, что позволяет командным оболочкам при логине получать этот файл и устанавливать соединение ssh без ввода пароля.

Установить keychain можно командой:

sudo apt install keychain

Для того, чтобы наш ключ подгружался автоматически, при логине, откроем в текстовом редакторе файл ~/.bashrc и добавим в него строчки:

/usr/bin/keychain $HOME/.ssh/id_ed25519
source $HOME/.keychain/$HOSTNAME-sh

Теперь при первом входе в систему агент SSH будет автоматически запущен, и в него, также автоматически, будет загружен наш ключ. Но пароль все равно придется ввести, хотя и всего один раз.

Запрет аутентификации по паролю

Добавив на сервер ключи, можно запретить аутентификацию по паролю. Это еще больше повысит безопасность сервера, поскольку зайти на него по SSH, не имея ключа, станет невозможно. Для этого надо открыть файл /etc/ssh/sshd_config, в строке PasswordAuthentication поставить значение no, и рестартовать SSH командой:

sudo systemctl restart ssh

Настройка клиента SSH в Windows

В самой Windows протокол SSH для удаленного управления используется редко. Однако зачастую машины с Windows используются как рабочие станции для удаленного администрирования Linux систем. Поэтому добавляем в нашу тестовую среду третий сервер SRV3 на Windows Server 2022.

Начиная с Windows 10\Windows Server 2019 ssh-клиент входит в состав операционной системы в виде отдельного компонента. Активировать его можно из PowerShell, командой:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Процесс генерации ключей такой же, как и на Linux. Единственное отличие в том, что по умолчанию создается 2048 битный RSA ключ, поэтому для генерации ключа ED25519 необходимо явно указать тип ключа. Размер указывать не нужно, он у ED25519 фиксированный (256 бит):

ssh-keygen -t ED25519

Ключи будут созданы в профиле текущего пользователя, в директории ./ssh (%USERPROFILE%\.ssh).

Утилита ssh-copy-id в Windows отсутствует, поэтому для копирования публичного ключа воспользуемся командой type:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh administrator@srv2 "cat >> .ssh/authorized_keys"

Ключ добавлен, можно подключаться:

ssh administrator@srv2

Вот так теперь выглядит содержимое файла authorized_keys на SRV2.

Защитим приватный ключ паролем:

ssh-keygen -p -f $env:USERPROFILE\.ssh\id_ed25519

Чтобы не вводить ключ каждый раз, проверим службу агента SSH:

Get-Service ssh-agent

По умолчанию она остановлена. Выставим для нее автоматический режим запуска при старте системы:

Set-Service ssh-agent -StartupType Automatic

и запустим ее:

Start-Service ssh-agent

Остается только загрузить ключи в агента командой:

ssh-add

Настройка подключения с помощью Putty

Хотя для подключения по SSH в Windows имеются все необходимые средства, все же большинство пользователей предпочитает использовать сторонние SSH-клиенты. Для примера возьмем Putty, как наиболее распространенный вариант.

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

Получившийся публичный ключ будет показан в окошке сверху. Не закрывайте его, пока не добавите ключ на удаленный сервер.

Сохранять ключи можно в любом удобном месте. Обратите внимание, что формат ключей у Putty свой, отличающийся от стандартного OpenSSH. Если публичный ключ можно достать из файла довольно просто, то приватный надо будет конвертировать.

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

Подключившись к SRV2 переходим в директорию ~/.ssh, открываем на редактирование файл authorized_keys и добавляем в него отдельной строчкой публичный ключ, который копируем из окошка Puttygen.

В настройках Putty идем в раздел Connection — SSH — Credentials и указываем расположение приватного ключа.

Теперь остается создать новое подключение, указать имя сервера, нажать Open

и подключиться.

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

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

Как изменить имя хоста в Ubuntu

Kirill — Thu, 19 Dec 2024 12:21:43 +0000

Имя компьютера, или, по-другому, имя хоста, задается в процессе установки системы. Оно используется для идентификации компьютера в сети, например, передается службой NetBIOS как имя сервера Samba, а также вы можете видеть его в терминале перед приглашением ввода команды.

Изменить имя хоста в Linux можно различными способами, некоторые из которых мы сегодня рассмотрим. Начнем с самого простого.

Hostname

Hostname — утилита командной строки, которая используется для отображения и изменения имени хоста. Посмотреть имя хоста можно с помощью команды:

hostname

Этой же командой можно изменить текущее имя, достаточно в качестве аргумента указать новое имя:

hostname newname

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

Имя хоста хранится в файле /etc/hostname, однако программы не используют его напрямую. Файл /etc/hostname читается только один раз, во время загрузки, для инициализации имени хоста ядра. Активное имя хоста фактически хранится в ядре. Команда hostname устанавливает параметр sysctl kernel.hostname путем записи в /proc/sys/kernel/hostname, и именно там все программы будут искать текущее имя хоста. При этом в /etc/hostname имя хоста останется без изменений, и при перезагрузке оно вернется обратно.

Примечание. Файлы, расположенные в каталогах /proc/ и /sys/ образуют так называемую виртуальную файловую систему. Их задача состоит в том, чтобы считывать информацию от ядра, помещенную в виртуальные файлы, и записывать информацию в виртуальные файлы — для передачи ядру. В частности /sys/ предназначен для обеспечения доступа к внутренним объектам ядра, особенно к тем, которые представляют различные устройства в системе. Таким образом, ядро может обмениваться различной информацией — состояние каждого устройства (например, находится ли оно в режиме энергосбережения), его тип (напр. является ли оно съемным устройством) и т. д. Каталог /proc/ описывает текущее состояние ядра — файлы в нем содержат информацию о процессах, запущенных в системе, и ее оборудовании.

Hostnamectl

systemd-hostnamed.service — служба, которая отвечает за ряд параметров системы, в том числе и за имя хоста. Для управления этой службой используется утилита командной строки hostnamectl, с помощью которой можно посмотреть и изменить имя хоста и связанные с ним настройки.

Hostnamectl различает три разных имени хоста:

• Статическое (Static) — то самое имя, которое задается при установке системы и которое хранится в /etc/hostname;
• Красивое (Pretty) — имя хоста в свободной форме. Может использоваться для описания системы, хранится в /etc/machine-info;
• Временное (Transient) — динамическое имя, устанавливается ядром системы при конфигурации (напр. по DHCP или mDNS). Если задано статическое имя хоста, отличное от localhost, то временное имя использоваться не будет.

Узнать имя хоста можно командой:

hostnamectl

или

hostnamectl --status

Кроме имени хоста команда информацию о системе, такую как версия ОС, архитектуру процессора и т.п. Если надо вывести только статическое имя хоста, то команда будет такой:

hostnamectl --static

Задать новое имя хоста можно командой:

hostnamectl set-hostname newname

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

Статическое и временное имена имеют довольно жесткие ограничения. Они могут иметь длину максимум 64 символа и включать в себя только буквенно-цифровые символы (A–Z, a–z, 0–9) и дефисы (-). В отличии от них красивые имена имеют минимальные ограничения — они могут включать в себя любой символ UTF8 и практически не ограничены по длине. Например можно задать вот такое имя:

hostnamectl set-hostname "Very pretty name!"

Как я уже говорил, красивое имя в хранится в /etc/machine-info, в формате переменной.

Что интересно, если при изменении имени хоста указать некорректное имя, то ошибку мы не получим. Вместо этого статическое имя будет скорректировано, а некорректное имя станет красивым. Для примера выполним команду:

hostnamectl set-hostname ubuntu-server_new

Как видите, указанное имя содержит недопустимый для статического имени символ (нижнее подчеркивание). Однако команда отработала без ошибок. А если теперь проверить имена командой:

hostnamectl

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

Ну и третий тип имени — временное. В принципе его можно попробовать задать вручную, например командой:

hostnamectl set-hostname transname --transient

Команда даже отработает без ошибок, но поскольку у нас уже есть статическое имя, не приведет ни к какому результату.

Network manager

Network Manager — пакет для управления сетевыми подключениями. С его помощью тоже можно сменить имя хоста. Устанавливается пакет командой:

apt install network-manager

Дальше есть два варианта. Можно воспользоваться утилитой командной строки nmcli. Для изменения имени хоста надо выполнить команду:
nmcli g hostname newname

Затем для того, чтобы изменения применились, надо рестартовать службу systemd-hostnamed:
systemctl restart systemd-hostnamed

Ну и проверить изменения можно командой:
nmcli g hostname

Также можно воспользоваться графическим интерфейсом NetworkManager TUI. Для его открытия надо выполнить команду:

nmtui

Затем в открывшемся окне выбрать пункт меню ″Set system hostname″

ввести новое имя

и подтвердить изменения.

После этого закрыть NetworkManager TUI и рестартовать службу systemd-hostnamed.

Редактирование /etc/hostname

Имя хоста хранится в файле/etc/hostname, из которого оно берется системой при загрузке. И ничто не мешает взять этот файл, открыть его в любом текстовом редакторе, например в nano:

nano /etc/hostname

и отредактировать имя хоста.

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

Заключение

И в заключение еще пара нюансов, о которых нужно помнить.

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

Если система была сконфигурирована с помощью пакета cloud-init, то необходимо в файле /etc/cloud/cloud.cfg для строки preserve_hostname поставить значение true. В противном случае любые изменения имени хоста после перезагрузки не сохранятся.

Вот как то так 🙂

Проверяем доступность порта UDP с помощью утилиты PortQry

Kirill — Mon, 02 Dec 2024 09:51:37 +0000

В операционных системах Windows есть множество инструментов для диагностики сетевых проблем, но иногда этих инструментов бывает недостаточно. Поэтому сегодня рассмотрим утилиту PortQry, предназначенную для устранения неполадок с сетевыми подключениями. Рассматривать будем на конкретном примере, взятом из практики.

Итак, есть подозрения на проблему с DNS, и нам надо ее решить. Симптомы — не разрешаются внешние DNS-имена. В качестве основного DNS указан сервер Google (8.8.8.8) и нам надо проверить его доступность.

Для диагностики работоспособности DNS-сервера отправляем на него запрос с помощью утилиты nslookup и видим, что он не отвечает, соответственно адреса внешних ресурсов не резолвятся.

Проверяем доступность сервера. Пинг проходим успешно.

Для проверки портов я обычно использую telnet, но сейчас для наглядности возьму PowerShell командлет Test-NetConnection. Проверяем доступность сервера по 53 порту и видим, что он открыт.

Пока все идет по плану 🙂

Но Test-NetConnection, как и горячо любимый мной telnet-клиент, умеет проверять только протокол TCP, а DNS-сервера для запросов используют UDP.

Примечание. Поскольку UDP-пакеты имеют небольшой размер, и не могут превышать 512 байт, для передачи данных, превышающих 512 байт, требуется протокол TCP. Поэтому DNS использует TCP для передачи зон, а для обычного разрешения имен используется UDP.

И вот тут на сцену выходит PortQry. Это утилита командной строки, предназначенная для диагностики проблем с сетевой доступностью. Она умеет проверять состояние портов TCP и UDP как на локальном, так и на удаленном компьютере.

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

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

и распаковать утилиту в любое удобное место.

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

Утилита может работать в нескольких режимах. Начнем с простого режима командной строки. В этом режиме формат команды проверки доступности портов на удаленном сервере следующий:

PortQry-n <name> [options]

где основные опции команды:

-n <name> – имя или IP-адрес компьютера для запроса. Это единственный обязательный параметр для режима командной строки. Это значение не может содержать пробелы;
-e <port_number> — порт для запроса. Может иметь значение от 1 до 65535, по умолчанию используется 80;
-p <protocol> — протокол запроса. Это иметь значение TCP, UDP или BOTH, по умолчанию используется TCP.

Для проверки доступности DNS-сервера 8.8.8.8 по 53 порту UDP выполним следующую команду:

PortQry-n 8.8.8.8 -e 53 -p UDP

По результату запроса для указанного порта PortQry возвращает одно из трех состояний:

• Listening – указанный порт доступен и принимает входящие подключения, ответ от него получен;
• Not Listening – по указанному адресу нет процесса (службы и т.п.), который принимает подключения на заданном порту. При проверке доступности ресурса по ICMP утилита PortQry получила ответ Destination Unreachable с кодом Port Unreachable;
• Filtered – утилита PortQry не получила ответа от указанного порта, либо ответ был отфильтрован. Т.е. на целевой системе указанный порт никто не слушает, либо доступ к нему ограничен, например файерволом. По умолчанию PortQry запрашивает TCP-порт три раза, а UDP-порт один раз, прежде чем возвращает ответ Filtered.

В нашем случае ответ Filtered, т.е. удаленный ресурс доступен, но по указанному порту не отвечает. Что собственно и подтверждает наши подозрения 🙂

Добавив ключ -i можно запустить утилиту в интерактивном режиме:

PortQry-i -n 8.8.8.8 -e 53 -p UDP

и выполнить запрос командой

q

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

node 77.88.8.8

протокол:

set protocol=both

и еще раз отправим запрос:

q

Как видите, этот DNS-сервер доступен по всем портам.

Ну и для выхода из интерактивного режима надо набрать:

exit

В итоге диагностика успешно проведена, проблемы выявлена и устранена. А я еще немного расскажу об утилите.

При работе в интерактивном режиме можно использовать готовые профили служб. Для примера проверим наш многострадальный DNS-сервер. Запустим утилиту в интерактивном режиме:

PortQry-i

укажем адрес сервера:

node 8.8.8.8

и запустим проверку с помощью предустановленного профиля DNS:

q dns

Эта команда проверяет указанный сервер по 53 порту TCP и UDP и эквивалентна команде:

PortQry -n 8.8.8.8 -p both -e 53

Профили есть для следующих служб.

Профиль	Порты для запроса
dns	TCP-порт 53, UDP-порт 53
ftp	TCP-порт 21
imap	TCP-порт 143
ipsec	UDP-порт 500
isa	TCP-порт 1745, UDP-порт 1745
ldap	TCP-порт 389, UDP-порт 389
l2tp	UDP-порт 1701
mail	TCP-порты 25, 110 и 143
pop3	TCP-порт 110
rpc	TCP-порт 135, UDP-порт 135
smtp	TCP-порт 25
snmp	UDP-порт 161
sql	TCP-порт 1433, UDP-порт 1434
tftp	UDP-порт 69

Также PortQry умеет не просто стучаться по указанным портам, но и производить расширенную диагностику для некоторых сетевых служб. Например при отправке запроса на SMTP-сервер она не только покажет состояние порта, но и выведет приветственный баннер:

PortQry-n smtp.yandex.ru -e 25

А при обращении к контроллеру домена по 389 порту отправит LDAP-запрос:

PortQry -n srv01.test.local -e 389 -p udp

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

PortQry -local

Примечание. В документации заявлено, что с помощью параметра -wport можно выполнить проверку состояния указанного порта, а параметр -wpid выводит состояние всех портов, связанных с указанным процессом на локальном хосте. Но тут есть нюанс — ни на одной системе у меня эти параметры не сработали, при попытке выполнить команду я стабильно получал сообщение ″Port to process mapping is not supported on this system″.

Ну и для тех, кто не любит набирать команды вручную, есть PortQryUI — вариант PortQry с графической оболочкой. Устанавливается так же, как и консольный вариант утилиты, при запуске открывается окошко, в котором надо указать имя или IP адрес удаленного сервера, порт и протокол для проверки. Также можно выбрать из списка предустановленны профиль службы.

В графическом режиме утилита возвращает следующие коды состояния:

0 (0x00000000) – соединении успешно установлено, порт доступен. Аналогично состоянию Listening;
1 (0x00000001) – порт недоступен. Нет процесса, который принимает подключения на заданном порту, либо хост недоступен. Аналогично состоянию Not Listening;
2 (0x00000002 – не получен ответ от указанного порта, либо ответ был отфильтрован. Аналогично состоянию Filtered.

Как видите, утилита PortQry одна может заменить кучу инструментов для диагностики сетевых проблем, а в случае с UDP она вообще незаменима. На сайте Microsoft можно найти подробную документацию и примеры использования утилиты. Так что крайне рекомендую.

Структура и базовые принципы работы DNS

Kirill — Mon, 21 Oct 2024 09:42:40 +0000

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

Начнем издалека.

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

Идея использования имени хоста вместо его сетевого адреса появилась еще во времена ARPAnet. Правда тогда для этой цели использовался обычный текстовый файл HOSTS.TXT, который сопоставлял имена узлов с числовыми адресами компьютеров в ARPAnet. За поддержку файла отвечал Сетевой информационный центр (NIC, Network Information Center) Стэнфордского исследовательского института (SRI, Stanford Research Insitute).

Единственным источником, распространявшим этот файл, являлся узел SRI-NIC. Администраторы ARPAnet просто посылали изменения электронной почтой в NIC и периодически синхронизировали свои файлы HOSTS.TXT с копией на узле SRI-NIC с помощью протокола FTP. Присылаемые изменения добавлялись в файл HOSTS.TXT один или два раза в неделю.

Однако по мере роста сети эта схема становилась все менее работоспособной. Размер файла увеличивался пропорционально количеству узлов в сети. Кроме того, рос информационный поток, связанный с необходимостью обновления файла на узлах, поскольку появление каждого нового узла требовало синхронизации данных на всех узлах сети с данными SRI-NIC.

И вот в 1984 году на замену HOSTS.TXT пришла система доменных имен (Domain Name Services, DNS). Что примечательно, от файла hosts не отказались полностью, он до сих пор присутствует во всех операционных системах Windows и Linux. Правда теперь он является необязательным и скорее дополнительным инструментом при работе с сетью.

Что же из себя представляет DNS?

Структура DNS

Система доменных имен (DNS) — это распределенная база данных, представляющая собой пространство имен, содержащее все сведения, необходимые для поиска любого имени клиента. Поэтому DNS имеет иерархическую структуру, выглядящую следующим образом:

• Корневая (Root) зона DNS – исходная точка для всего DNS. Технически представляет собой файл, содержащий перечень имен и IP-адресов всех доменов верхнего уровня в системе DNS;
• Доменные зоны верхнего или первого уровня (top-level domain, TLD) — национальные и международные доменные зоны, такие как .ru, .com, или .org. Они включают в себя все доменные имена, входящие в эту зону. В любую доменную зону может входить неограниченное количество доменов;
• Доменные зоны второго уровня – то, что обычно и называют доменом, например google.com или yandex.ru;
• Доменные зоны третьего уровня и ниже – по простому поддомены, например api.google.com или mail.yandex.ru. Могут быть доменные зоны 4, 5 уровней и так далее. Теоретически число уровней может достигать 127.

За каждую ступень иерархии отвечают разные сервера:

• Корневые (Root) сервера — обеспечивают работу корневой зоны. Они находятся на вершине иерархии и являются начальной точкой для всех DNS-запросов. Существует всего 13 идентификаторов корневых серверов, исторически обозначаемых от a.root-servers.net до m.root-servers.net, которыми управляют 12 независимых организаций, именуемых операторами корневых серверов (RSO). Каждый корневой сервер DNS (за исключением B.root) состоит из множества хостов-реплик, размещаемых в различных локациях сети Интернет и имеющих один IP-адрес. Корневые серверы содержат информацию о доменах верхнего уровня (TLD) и направляют запросы к соответствующим серверам;
• Сервера верхнего уровня — стоят следующими в иерархии после корневых серверов. Сервера верхнего уровня обеспечивают организацию и управление доменными зонами верхнего уровня и перенаправляют запросы к авторитетным серверам, которые содержат детальную информацию о доменах второго уровня;
• Авторитетные (Authoritative) сервера — на следующем уровне находятся авторитетные DNS-сервера. Это сервера, на которых собственно и хранятся DNS-записи для конкретной зоны. Например, авторитетный сервер для contoso.com содержит записи, которые указывают на IP-адреса, связанные с этим доменом. Таким образом, именно авторитетные сервера предоставляют окончательную информацию, необходимую для завершения DNS-запроса.

Делегирование

Чтобы DNS-сервер отвечал на запросы о любом имени, он должен иметь прямой или косвенный путь к каждой зоне в пространстве имен. Эти пути создаются с помощью делегирования. Делегирование — это запись в родительской зоне, которая содержит список серверов имен, заслуживающих доверия для зоны на следующем уровне иерархии. Делегирование позволяют серверам в одной зоне ссылаться на серверы в других зонах.

Технически делегирование выражается в выделении части дерева в отдельную зону, и размещении этой зоны на DNS-сервере, управляемом отдельным лицом или организацией. При этом в родительскую зону включаются склеивающие (glue) ресурсные записи (NS и А), содержащие указатели на DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах этой зоны.

Для примера возьмем домен contoso.com. Обратите внимание на точку в конце доменного имени. Это не опечатка, точкой обозначается домен верхнего уровня (корневой домен).

Корневая зона содержит делегирование в зону com. Делегирование в корневой зоне сообщает корневому серверу, что для поиска зоны com он должен связаться с сервером первого уровня, отвечающим за эту зону. Аналогичным образом, делегирование в зоне com сообщает серверу этой зоны, что для поиска зоны contoso.com он должен связаться с авторитетным сервером Contoso.

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

Корневые подсказки

Классический путь DNS-запроса выглядит следующим образом — клиент обращается к DNS-серверу, прописанному у него в сетевых настройках. DNS-сервер проверяет, не делегирован ли запрашиваемый домен ему, и если делегирован — то сам отвечает на запрос. Если же нет, то обращается к корневым серверам и запрашивает у них адреса серверов первого уровня для данной зоны. Получив запрошенные адреса, он так же обращается к серверам первого уровня и запрашивает у них авторитетные для нужной зоны сервера. И уже после этого делает запрос непосредственно на авторитетный сервер, обслуживающий нужный домен, а полученный ответ возвращает клиенту.

Для того, чтобы DNS-сервер смог найти корневые сервера, как раз и нужны корневые подсказки (Root Hints). Они представляют из себя список IP-адресов серверов, считающихся авторитетными на корневом уровне иерархии DNS. Корневые подсказки заранее предустановлены в операционной системе, например в Windows они хранятся в файле CACHE.DNS который находится в папке \Windows\System32\Dns, а в Linux их можно найти в /usr/share/dns/root.hints, хотя тут могу и ошибаться.

Технически файл с подсказками представляет из себя обычный текстовый файл, в котором прописано сопоставление имя сервера — его IP-адрес.

Рекурсивные и итеративные запросы

В DNS используятся следующие типы запросов:

Итеративный (прямой) запрос

DNS-клиент посылает DNS-серверу доменное имя и просит вернуть либо IP-адрес для этого имени, либо адрес DNS-сервера, авторитетного для этого домена. При этом запрашиваемый сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые сервера и сервера верхнего уровня.

Итеративный запрос позволяет DNS-серверу вернуть лучший ответ, который он может дать, на основе данных своего кэша или зоны. Если запрашиваемый DNS-сервер не имеет точного соответствия запрашиваемому имени, наилучшая возможная информация, которую он может вернуть, — это ссылка (то есть указатель на DNS-сервер, авторитетный для более низкого уровня пространства имен). Затем DNS-клиент может запросить DNS-сервер, для которого он получил ссылку. Он продолжает этот процесс до тех пор, пока не найдет DNS-сервер, ответственный за запрошенное имя, или пока не произойдет ошибка или условие тайм-аута. Этот процесс иногда называют «обходом по дереву», и этот тип запроса обычно инициируется DNS-сервером, который пытается разрешить рекурсивный запрос имени для DNS-клиента.

Рекурсивный запрос

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

На следующем рисунке показан пример итеративных и рекурсивных запросов.

В примере происходят следующие события:

— Клиент обращается к DNS-серверу с рекурсивным запросом имени name.contoso.com. Сервер должен вернуть либо ответ, либо сообщение об ошибке.
— DNS-сервер проверяет свой кэш и зоны на наличие ответа, но не находит его, поэтому обращается к авторитетному (корневому) серверу с итеративным запросом name.contoso.com.
— Корневой сервер не знает ответа, поэтому отвечает ссылкой на сервер, авторитетный для зоны .com.
— DNS-сервер обращается к серверу, ответственному за зону .com, с итеративным запросом name.contoso.com.
— Авторитетный для зоны .com сервер также не знает точного ответа, поэтому он отвечает ссылкой на сервер, авторитетный для зоны contoso.com.
— DNS-сервер обращается к серверу, ответственному за contoso.com., с итеративным запросом name.contoso.com.
— Авторитетный сервер сервер contoso.com. знает точный ответ, поэтому он отвечает запрошенным IP-адресом.
— DNS-сервер отвечает на запрос клиента IP-адресом name.contoso.com.

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

Кэширование и время жизни

Когда сервер обрабатывает рекурсивный запрос, ему может потребоваться отправить несколько запросов, чтобы найти окончательный ответ. Полученную в процессе информацию сервер сохраняет в кэш, где она хранится в течении определенного времени, полученного в результате запроса. Это время называется временем жизни (Time to Leave, TTL) и указывается в секундах. TTL — это время, в течении которого данные в кэше DNS-сервера остаются актуальными и их можно использовать, не обращаясь с повторным запросом к авторитетному DNS-серверу.

Примерно вот так выглядит содержимое кэша DNS-сервера на базе Windows.

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

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

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

Отрицательное кэширование описано в RFC 1034 и RFC 2308. RFC 1034 описывает, как кэшировать отрицательные ответы, и делает отрицательное кэширование необязательным. А вот RFC 2308 требует, чтобы DNS-сервера кэшировали отрицательные ответы, если они кэшируют какие-либо ответы, а также описывает способ, с помощью которого серверы имен пересылают кэшированные отрицательные ответы. Как и при обычном кэшировании, им также необходимо начать уменьшать TTL.

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

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

Пересылка

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

Пересылка (Forwarding) позволяет обойти эти ограничения и маршрутизировать разрешение имен через определенные DNS-сервера (сервера пересылки) вместо использования корневых подсказок. Сервер пересылки (Forwarder) — это DNS-сервер в сети, используемый для пересылки запросов для разрешения внешних имен на DNS-серверы за пределами этой сети.

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

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

— Клиент запрашивает у своего DNS-сервера адрес для имени name.contoso.com.
— DNS-сервер получает запрос от клиента и пытается разрешить его, используя основную и дополнительную зоны, которые он размещает, а также свой кэш;
— Если запрос не может быть решен с использованием этих локальных данных, DNS-сервер перенаправляет запрос на другой DNS-сервер, назначенный в качестве сервера пересылки, отправляя ему рекурсивный запрос. Это отличается от итеративного запроса, который DNS-сервер отправляет другому DNS-серверу во время стандартного разрешения имен, без использования пересылки;
— Сервер пересылки не является доверенным для contoso.com. и не имеет ответа в своем кэше, поэтому он использует корневые подсказки для поиска IP-адреса корневого сервера DNS;
— Сервер пересылки отправляет итеративный запрос корневому DNS-серверу для разрешения имени name.contoso.com. Корневой сервер DNS возвращает ссылку на сервер Com, на котором размещена зона com.
— Сервер пересылки отправляет итеративный запрос на сервер Com для разрешения имени name.contoso.com. Сервер Сom возвращает ссылку на сервер Contoso, на котором размещается зона contoso.com.
— Сервер пересылки отправляет на сервер Contoso итеративный запрос для разрешения имени name.contoso.com. Сервер Contoso находит ответ в файлах зоны и возвращает ответ на сервер пересылки.
— Получив искомую информацию, сервер пересылки возвращает результат исходному DNS-серверу.
— Исходный DNS-сервер возвращает результат клиенту.

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

Условная пересылка

Хотя условная пересылка (conditional forwarding) и является частным случаем пересылки, тем не менее о ней стоит упомянуть отдельно.

Условная пересылка — это пересылка запросов в соответствии с DNS-именем в запросе. Например, DNS-сервер можно настроить на пересылку всех получаемых им запросов на разрешение имен в домене contoso.com на IP-адреса авторитетных для этого домена DNS-серверов. При этом процесс разрешения имен будет выглядеть следующим образом:

— Клиент запрашивает у своего DNS-сервера адрес для имени name.contoso.com.
— DNS-сервер получает запрос от клиента и пытается разрешить его собственными силами, проверяя свои зоны и кэш;
— Если запрос не может быть решен с использованием локальных данных, DNS-сервер перенаправляет запрос на сервер Contoso, указанный как сервер условной пересылки для contoso.com;
— Сервер Contoso является доверенным для contoso.com., поэтому он находит у себя нужную информацию и возвращает результат исходному DNS-серверу;
— Исходный DNS-сервер возвращает результат клиенту.

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

Как перенести раздел восстановления Windows

Kirill — Fri, 11 Oct 2024 13:01:06 +0000

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

Сразу за разделом с операционной системой стоит так называемый раздел восстановления (Recovery Partition).

Что такое раздел восстановления и для чего он нужен?

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

Раздел восстановления содержит в себе среду восстановления Windows (Windows RE), в которую входит набор инструментов для восстановления системы. В том случае если операционная система, по какой либо причине, не может загрузиться, вы можете загрузить компьютер в режиме восстановления и попытаться с помощью этих инструментов ее починить.

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

Поэтому Microsoft рекомендует размещать раздел восстановления на системном диске, сразу после раздела с Windows. Это позволяет операционной системе изменять раздел, если для будущих обновлений потребуется больший по размеру образ для восстановления. А начиная с Windows версии 2004 при установке операционной системы раздел восстановления по умолчанию создается в конце системного диска, после раздела с операционной системой.

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

Для примера возьмем виртуальную машину с Windows Server 2022. Увеличим размер диска на 10ГБ, зайдем в оснастку управления дисками и попробуем расширить системный раздел. Как видите, это невозможно, поскольку между системным разделом и свободным местом находится раздел восстановления.

К счастью эту ситуацию можно исправить. Для начала откроем командную консоль и отключим восстановление командой:

reagentc /disable

При этом образ восстановления будет выгружен в файл Winre.wim и сохранен на диск, в папку C:\Windows\System32\Recovery.

Затем запускаем утилиту diskpart:

diskpart

выводим список дисков:

list disk

и выбираем системный диск, на котором должен находиться раздел восстановления:

sel disk 0

Затем выводим список разделов на выбранном диске:

list part

В полученном списке находим раздел восстановления и выбираем его:

sel part 4

Ну и наконец удаляем выбранный раздел:

del part override

и еще раз проверяем список разделов. Как видите, раздела восстановления больше нет.

Теперь заходим в оснастку управления дисками и видим, что свободное место доступно

и можно беспрепятственно расширить системный диск.

В принципе можно просто удалить раздел восстановления и занять все свободное дисковое пространство. На работу ОС это никак не повлияет, а при необходимости всегда можно загрузить режим восстановления с любого загрузочного диска или образа с дистрибутивом Windows.

А можно оставить немного свободного места (примерно 700-900МБ) и вернуть раздел на место, что мы и сделаем. Для этого на оставшемся месте создадим новый раздел

без буквы диска

с настройками по умолчанию. Обзовем его Recovery.

Теперь перейдем в свойства диска

и уточним тип таблицы размещения файлов — GPT или MBR.

Возвращаемся обратно в diskpart и выводим список разделов:

list part

Находим свежесозданный раздел и переходим на него:

sel part 4

теперь для диска GPT изменяем ID раздела, чтобы Windows опознала его как раздел восстановления:

set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac

Дополнительно требуется скрыть диск и пометить его как обязательный раздел, для этого нам нужно установить атрибут GPT:

gpt attributes=0x8000000000000001

Если же диск MBR, то назначить раздел восстановления можно командой:

set id=27

Теперь подключаем обратно образ восстановления:

reagentc /enable

И проверяем его состояние:

reagentc /info

В итоге мы и системный диск расширили, и раздел восстановления сохранили.

Вот как то так 🙂

Генерация пароля заданной длины и сложности с помощью PowerShell

Kirill — Sun, 18 Aug 2024 19:04:19 +0000

Если необходимо сбросить пароли или создать большое количество новых пользователей, это легко можно сделать с помощью Powershell. Cегодня мы рассмотрим 3 способа создания паролей в PowerShell.

— Простой генератор паролей, выдающий произвольный пароль заданной длины;
— Генератор паролей с предопределенным набором символов;
— Генератор паролей, позволяющий задать количество прописных, строчных, числовых и специальных символов.

Простой генератор паролей

Самый простой вариант, с использованием встроенного генератора паролей. В этом варианте используем метод GeneratePassword класса System.Web.Security.Membership:

function Get-Password { param ( [Parameter(Mandatory)] [int] $length, #password length [int] $special = 1 #special ) Add-Type -AssemblyName 'System.Web'; $password = [System.Web.Security.Membership]::GeneratePassword($length, $special); return $password; }

В итоге получаем произвольный пароль заданной длины. Но методу GeneratePassword можно передать только 2 аргумента — длину и минимальное количество нестандартных символов. В ситуации, когда есть жесткие требования к сложности пароля (например парольная политика AD) этот способ может не подойти.

Генератор паролей с предопределенным набором символов

Здесь мы используем класс RandomNumberGenerator, который реализует криптографический генератор случайных чисел. Пароль будем создавать с помощью метода Create:

function Get-Password { param ( [Parameter(Mandatory)] [int] $length #password length )

#password charset $charSet = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789{]+-[*=@:)}$^%;(_!&#?>/|.'.ToCharArray();

#generate password $rng = [System.Security.Cryptography.RandomNumberGenerator]::Create(); $bytes = New-Object byte[]($length); $rng.GetBytes($bytes); $result = New-Object char[]($length);

for ($i = 0 ; $i -lt $length ; $i++) { $result[$i] = $charSet[$bytes[$i]%$charSet.Length]; } return (-join $result); }

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

Генератор паролей с контролируемыми параметрами

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

function Get-Password { param ( [Parameter(Mandatory)] [ValidateRange(4,[int]::MaxValue)] [int] $length, #length [int] $upper = 1, #number of uppercase [int] $lower = 1, #number of lowercase [int] $numeric = 1, #number of numeric [int] $special = 1 #number of special ) if($upper + $lower + $numeric + $special -gt $length) { throw "number of upper/lower/numeric/special char must be lower or equal to length"; } # password charset $uCharSet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; #uppercase $lCharSet = "abcdefghijklmnopqrstuvwxyz"; #lowercase $nCharSet = "0123456789"; #numeric $sCharSet = "/*-+,!?=()@;:._"; #special $charSet = ""; if($upper -gt 0) { $charSet += $uCharSet } if($lower -gt 0) { $charSet += $lCharSet } if($numeric -gt 0) { $charSet += $nCharSet } if($special -gt 0) { $charSet += $sCharSet }

#pasword generate $charSet = $charSet.ToCharArray(); $rng = [System.Security.Cryptography.RandomNumberGenerator]::Create(); $bytes = New-Object byte[]($length); $rng.GetBytes($bytes);

$result = New-Object char[]($length); for ($i = 0 ; $i -lt $length ; $i++) { $result[$i] = $charSet[$bytes[$i] % $charSet.Length] } $password = (-join $result);

# pasword validation $valid = $true; if($upper -gt ($password.ToCharArray() | Where-Object {$_ -cin $uCharSet.ToCharArray() }).Count) { $valid = $false } if($lower -gt ($password.ToCharArray() | Where-Object {$_ -cin $lCharSet.ToCharArray() }).Count) { $valid = $false } if($numeric -gt ($password.ToCharArray() | Where-Object {$_ -cin $nCharSet.ToCharArray() }).Count) { $valid = $false } if($special -gt ($password.ToCharArray() | Where-Object {$_ -cin $sCharSet.ToCharArray() }).Count) { $valid = $false }

if(!$valid) { $password = Get-Password $length $upper $lower $numeric $special; } return $password; }

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