Как да решите проблема с грешките на криптиране crentssp

Как да решите проблема с грешките на криптиране crentssp

През пролетта на 2018 г. потребителите на Windows започнаха да се сблъскват с грешка, която не се е срещала преди това.

Скоро стана ясно, че съобщението "Encryption Oracle Remediations" възникна при опит да се свърже клиентски компютър с отдалечена машина и това се случи при следните обстоятелства:

  • Свързването с отдалечена машина се извършва от компютър, на който наскоро е инсталиран сравнително стар Windows (Server 2012, „Ten” Assembly 1803 и по -долу, Server 2016), тъй като няма актуализации за безопасност, които са пуснати по -късно;
  • Връзката се осъществява към сървъра, където липсват горепосочените актуализации;
  • Когато се свързва, вградените фондове за протокол на RDP са заключени с отдалечен компютър поради липсата на необходимия пластир на клиентската машина.

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

Защо CREDSSP е грешка

И така, ние вече знаем, че в много версии на Windows (Server Options 2016/2012/2008, с изключение на 2013 г., както и клиенти, започвайки със 7) без инсталирани кумулативни пластири, ако се опитвате да се свържете с отдалечения компютър от RDS/RDP може да възникне проблемът с дистанционното свързване на работния плот.

С други думи, с отдалечена връзка с компютъра по време на процедурата за удостоверяване на криптиране е възникнала грешка в CREDSSP, причината за която може да бъде неконсултация на протоколите за криптиране. Това е така, защото един от автомобилите (клиент или отдалечен) не е инсталирал съответните актуализации, които са пуснати след март 2018 г.

Именно тогава Microsoft започна да разпространява актуализация, насочена към защита на идентифицираната уязвимост на протокола CREDSSP, заплашвайки вероятността от отдалечено изпълнение на код от нападателите. Техническите подробности за проблема са дадени достатъчно подробности в Bulletin CVE2018-0886. Два месеца по -късно беше пусната друга актуализация, която въведе по подразбиране забрана за възможността на клиентската машина на Windows да се свърже с отдалечен сървър, ако има версия на протокола CREDSSSP, не е разпространена от актуализацията на март.

Тоест, ако имате клиентски прозорци с времето, актуализациите през май, инсталирани навреме, и се опитвате да се свържете с отдалечени сървъри, на които, започвайки през пролетта на 2018. В същото време клиентската машина ще получи съобщение за невъзможността за извършване на отдалечена връзка на типа на Credssp.

Така че, причината за грешката може да бъде корекцията от разработчиците на протокола за криптиране на CREDSSP, който се появи в резултат на пускането на следните актуализации:

  • за версията на сървъра на 2008 R2 и "Seven" - KB4103718;
  • За WS 2016 - KB4103723;
  • За WS 2012 R2 и Windows 8.1 - KB4103725;
  • за "десетки" Асамблея 1803 - KB4103721;
  • за Windows 10 Assembly 1609 - KB4103723;
  • За "десетки" монтаж 1703 - KB4103731;
  • За W10 Build 1709 - KB4103727.

Посоченият списък показва номера на актуализациите, публикувани през май 2018 г., понастоящем е необходимо да се инсталират още свежи пакети от акумулативни (те също се наричат ​​кумулативни) актуализации. Тази операция може да се извърши по няколко начина. Например, визирайки услугата за актуализиране на Windows, въз основа на сървърите за разработчици или използване на локалния WSUS сървър. И накрая, можете ръчно да изтеглите необходимите модели на сигурност чрез каталога за актуализиране на Microsoft (това е каталога за актуализиране на Vindodes).

По -специално, за да търсите актуализации за вашия компютър, на който е инсталиран „дузина“ монтаж 1803 г., през май 2020 г. заявката за търсене трябва да има следния изглед: Windows 10 1803 5/*/2020.

Начини за решаване на проблема

Има два начина от тази ситуация. Тъй като е лесно да се предположи, един от тях е премахването на актуализациите на безопасността на клиентския компютър, инсталиран след март 2018 г. Разбира се, такава стъпка се счита за много рисковано и силно не се препоръчва, тъй като има и други решения на проблема. Но той е най -лесният за изпълнение и може да се използва за опит за едно време за достъп до отдалечената машина.

Сега нека разгледаме алтернативните „правилни“ опции за коригиране на грешката, която възниква при проверка на автентичността на Credssp.

Едно от тях е да деактивирате (за еднократна употреба) процедурата за проверка на версията на Credssp на отдалечен компютър по време на опит за свързване от RDP. В този случай вие оставате защитени, лепенките остават установени, има риск само по време на комуникационна сесия.

Алгоритъмът на действията:

  • Ние стартираме в конзолата „Изпълнение“ на GPEDIT.MSC (изграден -в редактор на Local GPO);
  • Отиваме в раздела за конфигуриране на компютър, избираме елемента на администрираните шаблони, след което преминете в раздела System, след това - към делегацията на идентификационните данни. В Russified Windows пълният път ще изглежда по следния начин: раздела „Конфигурация на компютъра“/раздела „Административни шаблони“/Меню за менюта Класове на класове на менюта
  • В списъка на политика търсим линията за отстраняване на Oracle Oracle, щракнете върху нея и включим селектора на политика в активираната/„приобщаваща“ позиция, избирайки уязвимата линия (оставете уязвимост) в списъка, който се появява);
  • Ние стартираме през конзолата, за да „изпълним“ командата GPUPDATE /FORCE (принудително актуализиране на политика), завършвайки процедурата за изключване на известия за редактиране на политика на местна група;
  • Опитайте се да се свържете с отдалечена машина.

Изключването на политиката за криптиране.

Внимание. Спомнете си, че този метод за елиминиране на грешките за криптиране на Credssp в Windows не се препоръчва за постоянна употреба. По -добре е да информирате администратора на отдалечената машина за проблема с несъответствието на протоколите за криптиране, за да инсталирате подходящите актуализации.

Помислете как работи политиката на EOR. Той има три нива на защита срещу уязвимостите на протокола CREDSSP при липса на пластири:

  1. Форс за актуализирани Clents - Основното ниво на защита, пълна забрана за свързване от отдалечената машина за свързване на клиентски компютри без инсталирани актуализации. По правило тази политика се активира след пълна актуализация в цялата мрежова инфраструктура, тоест след инсталиране на свежи актуализации на всички мрежови станции, свързани с мрежата, включително сървъри, към които се извършва отдалечена връзка.
  2. Смекчени - Това ниво на защита блокира всички опити за свързване със сървъри, на които протоколът CREDSSP не е правилен. В същото време всички останали услуги на Credssp не са засегнати.
  3. Уязвимо - Минималното ниво е пришито, което премахва забраната за отдалечен достъп до RDP машината, ако има уязвима версия на CredsSSP.

Обърнете внимание, че на някои клиенти на клиенти (например домашната версия на Windows), редакторът на местния политик в Асамблеята не е включен. В този случай правенето на промени, които ви позволяват да се включите с отдалечени машини без продължителни актуализации от страна на сървъра, се извършва ръчно чрез редактиране на регистъра.

За да направите това, въведете линията на конзолата на линията:

Reg Добавяне на hkml \ софтуер \ microsoft \ windows \ currentVersion \ policies \ system \ credssp \ параметри /v relectryptionoracle /t reg_dword /d 2

Тази процедура може да се приложи за всички работни станции, използвайки домейна GPO (стартиране на конзолата - GPMC.MSC), или можете да приложите скрипта на PowerShell (за да получите списък с работни станции, принадлежащи към този домейн, можете да използвате командата get-dcomputer, която е част от rsat-op-powershell), следвайки следното съдържание:

Import-module Actinedirectory
$ Pss = (get -dcomputer -filter *).Dnshostname
Foreach ($ компютър в $ pcs)
Invoke -Command -ComputerName $ computer -scriptblock
Reg Добавяне на hklm \ софтуер \ microsoft \ windows \ currentVersion \ policies \ system \ credssp \ параметри /v relecryptionoracle /t reg_dword /d 2

Но за да се избегне ненужен риск, е необходимо веднага след свързването с отдалечена машина, ако има подходящи права за задаване на текущи актуализации с помощта на услугата за актуализиране на Windows (тя трябва да бъде включена). Тази операция може да се извърши ръчно чрез изтегляне на свежи кумулативни актуализации и извършване на тяхната инсталация в съответствие с алгоритъма, посочен по -рано.

Ако искате да коригирате грешката на криптиране на CREDSSP на прозорците XP/Server 2003, които в момента не се поддържат, но поради определени обстоятелства, които сте използвани, всички тези машини трябва да пробият вградената Possfroody 2009.

Важно. След успешен опит да се свържете с сървъра, инсталиране на кумулативни пластири върху него и рестартиране на сървъра, не забравяйте да изпълните обратните трансформации в политиката на клиента, като зададете стойността в политиката на ForceUpdatedClent 2 до източника 0. По този начин, отново ще защитите компютъра си от уязвимости, присъщи на връзката с URDP, като правите корекция на криптирането на crentssp.

Не споменахме друг сценарий на погрешното съобщение „Encryption Oracle Remedion“ - когато всичко е наред с отдалечения сървър и клиентският компютър се оказва несъвместим. Тя ще възникне, ако политиката е активирана на отдалечена машина, която блокира опитите за установяване на връзка с инцизирани клиентски компютри.

В този случай не е необходимо да изтривате актуализации на сигурността на клиента. Ако имате неуспешен опит да се свържете с сървъра, трябва да проверите кога за последен път е имало инсталиране на кумулативни актуализации за сигурност на клиентската машина. Можете да извършите проверка чрез използването на модула PSWINDOWSUPDATE, както и чрез попълване на командата в конзолата:

Gwmi win32_quickfixengineering | сортиране, инсталирано на -desk

Ако датата е доста стара (по избор до март 2018 г.), инсталирайте най -новата кумулативна актуализация за вашата версия на Windows.