Windows RDP клиент. Извършваме дистанционна връзка с компютър! Как да настроите отдалечен достъп чрез RDP Защита на rdp връзка с ssl

Windows RDP клиент.  Извършваме дистанционна връзка с компютър!  Как да настроите отдалечен достъп чрез RDP Защита на rdp връзка с ssl
Windows RDP клиент. Извършваме дистанционна връзка с компютър! Как да настроите отдалечен достъп чрез RDP Защита на rdp връзка с ssl

Доста често много потребители, които използват сесии за отдалечен достъп, имат въпрос как да променят RDP порта. Сега нека разгледаме най-простите решения и също така да посочим няколко основни стъпки в процеса на конфигуриране.

За какво е RDP протоколът?

Първо, няколко думи за RDP. Ако погледнете декодирането на съкращението, можете да разберете този отдалечен достъп

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

Стандартен RDP порт: трябва ли да се промени?

Така че, независимо от модификацията на Windows, всички протоколи имат предварително зададена стойност. Това е RDP порт 3389, който се използва за осъществяване на комуникационна сесия (свързване на един терминал към отдалечени).

Каква е причината за ситуацията, когато трябва да се промени стандартната стойност? На първо място, само със сигурността на локалния компютър. В края на краищата, ако го разберете, с инсталиран стандартен порт по принцип всеки нападател може лесно да проникне в системата. Така че сега нека да видим как да промените RDP порта по подразбиране.

Промяна на настройките в системния регистър

Веднага отбелязваме, че процедурата по промяна се извършва изключително в ръчно управление, а в самия клиент за отдалечен достъп не е предвидено нулиране или инсталиране на нови параметри.

Първо извикваме стандартния редактор на системния регистър с командата regedit в менюто Run (Win + R). Тук се интересуваме от клона HKLM, в който трябва да слезем по дървото на дяловете през директорията на терминалния сървър до директорията RDP-Tcp. В прозореца вдясно намираме ключа PortNumber. Трябва да променим значението му.

Влизаме в редактирането и виждаме 00000D3D там. Мнозина веднага се озадачават какво е това. И това е само шестнадесетичното представяне на десетичното число 3389. За да посочим порта в десетична форма, използваме подходящия низ за показване за представяне на стойността и след това посочваме параметъра, от който се нуждаем.

След това рестартираме системата и при опит за свързване уточняваме нов порт RDP. Друг начин за свързване е да използвате специалната команда mstsc /v:ip_address:XXXXX, където XXXXX е новият номер на порт. Но това не е всичко.

Правила на защитната стена на Windows

Уви, вграден защитна стена на windowsможе да блокира новия порт. Така че трябва да направите промени в настройките на самата защитна стена.

Ние наричаме настройките на защитната стена с разширени опции за сигурност. Тук първо трябва да изберете входящи връзки и да кликнете върху реда за създаване на ново правило. Сега избираме елемента за създаване на правило за порта, след това въвеждаме стойността му за TCP, след това разрешаваме връзката, оставяме раздела на профила непроменен и накрая даваме име на новото правило, след което натискаме бутона за завършване на настройките . Остава да рестартирате сървъра и при свързване да посочите новия RDP порт, разделен с двоеточие в съответния ред. На теория не би трябвало да има проблеми.

RDP пренасочване на порт на рутера

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

Първо, в свойствата на системата разрешаваме и посочваме потребители, които имат право да го правят. След това отиваме в менюто с настройки на рутера през браузъра (192.168.1.1 или в края 0.1 - всичко зависи от модела на рутера). В полето (ако основният адрес е 1.1) е желателно да посочите адреса, като започнете от третия (1.3), и напишете правилото за издаване на адреса за втория (1.2).

След това в интернет връзкаизползвайте изгледа с подробности, където трябва да видите подробностите, копирайте физическия MAC адрес от там и го поставете в параметрите на рутера.

Сега, в раздела за настройки на NAT на модема, активирайте връзката към сървъра, добавете правило и посочете порта XXXXX, който трябва да бъде пренасочен към стандартния RDP порт 3389. Запазете промените и рестартирайте рутера (новият порт ще не се приема без рестартиране). Можете да проверите връзката на някой специализиран сайт като ping.eu в секцията за тестване на портове. Както можете да видите, всичко е просто.

И накрая, имайте предвид, че стойностите на портовете са разпределени както следва:

  • 0 - 1023 - портове за системни програми от ниско ниво;
  • 1024 - 49151 - пристанища, предназначени за частни цели;
  • 49152 - 65535 - динамични частни портове.

По принцип много потребители обикновено избират RDP портове от третия диапазон на списъка, за да избегнат проблеми. Въпреки това, както специалистите, така и експертите препоръчват използването на тези стойности при настройка, тъй като те са подходящи за повечето задачи.

Що се отнася до точно тази процедура, тя се използва предимно в случаите на Wi-Fi връзка. Както вече можете да видите, при обикновена кабелна връзка не е необходимо: просто променете стойностите на ключовете в системния регистър и добавете правила за порта в защитната стена.

Услуги за отдалечен работен плот (RDS) в Windows сървър 2008 R2 има повече от просто ново име; това не е остарялата терминална услуга. С нови функции (някои въведени в Windows Server 2008) като RemoteApp, RD Gateway и RD Virtualization Host, тази роля windows сървърсега ви дава гъвкавостта да инсталирате отделни приложения или цели машини с помощта на RDS или VDI решение - в много случаи без необходимост от Citrix или други добавки на трети страни.

Но какво да кажем за сигурността? Всички тези допълнителни сложности идват с допълнителни съображения за сигурност. В тази статия ще разгледаме механизмите за сигурност, вградени в RDS, как да използвате опциите за конфигурация и груповата политика за подобряване на сигурността и препоръките за сигурност при инсталиране на RDS.

Какво е новото в R2

Ако сте нов в RDS, след като сте работили с Windows Server 2008 Terminal Services, няма да видите толкова големи промени, както при мигрирането от Windows Server 2003. WS 2008 добави някои големи подобрения към Terminal Services, включително TS Web Access за свързване чрез браузър, TS Gateway за потребители, свързващи се през интернет, RemoteApp за доставяне на индивидуални приложения до потребителите чрез протокола за отдалечен работен плот (RDP) и Session Broker, който включва функция за балансиране на натоварването.

  • Виртуализация на отдалечен работен плот за VDI решение
  • RDS доставчик за PowerShell, така че администраторите да могат да променят конфигурацията и да изпълняват задачи в командния интерпретатор и чрез скриптове
  • Виртуализация на мрежови адреси (IP виртуализация на отдалечен работен плот), която ви позволява да присвоявате IP адреси на връзки за всяка отделна сесия или програма
  • Нова версия на клиента за RDP и връзка с отдалечен работен плот (RDC), версия 7.0
  • График на процесора за справедливо споделяне за динамично разпределяне на времето за обработка между сесиите въз основа на броя на активните сесии.
  • Съвместим с Windows Installerза опростяване на инсталирането на програми, които изискват персонализиране за отделни потребители.
  • Истинска поддръжка на няколко монитора (до 16), която кара програмите да работят точно както на клиентски машини.

Има и подобрения в аудио/видео и Поддръжка на Windows Aero в RD сесия (имайте предвид обаче, че Desktop Composition, който позволява на Aero да работи, не се поддържа в сесии с няколко монитора).

Аспекти и механизми на сигурността

Разбира се, потенциалните проблеми със сигурността зависят от това как сте настроили RDS. Ако имате по-сложна конфигурация, при която потребителите се свързват чрез интернет и/или браузър, ще имате повече аспекти на сигурността, които да обмислите и върху които да работите, отколкото ако имате проста конфигурация, при която потребителите се свързват изключително чрез RDC клиенти през LAN.

RDS включва редица механизми за сигурност, за да направи връзките на RD по-сигурни.

Удостоверяване на мрежово ниво

За максимална сигурност трябва да изисквате удостоверяване на мрежово ниво (NLA) за всички връзки. NLA изисква потребителите да се удостоверяват на сървъра за хост на RD сесии, преди да бъде създадена сесия. Това помага за защита отдалечени компютриот злонамерени потребители и зловреден софтуер. За да използвате NLA, клиентският компютър трябва да използва операционна системакойто поддържа протоколите Credential Security Support Provider (CredSSP), т.е. Windows XP SP3 и по-нова версия, и има RDC 6.0 клиент или по-нова версия.

NLA е конфигуриран на RD Session Host сървър в следния раздел: Административни инструменти | Услуги за отдалечен работен плот | Конфигурация на хост на сесия на отдалечен работен плот. За да настроите връзка за използване на NLA, изпълнете следните стъпки:

  1. Щракнете с десния бутон Връзка
  2. Изберете Свойства
  3. Отидете в раздела Общи
  4. Поставете отметка в квадратчето „Разрешаване на връзки само от компютри, работещи с отдалечен работен плот с проверка на мрежатаудостоверяване (разрешаване на връзки само от компютри, работещи с отдалечен работен плот с удостоверяване на мрежово ниво)", както е показано на фигура 1
  5. Натиснете OK.

Снимка 1

Протокол за сигурност на транспортния слой (TLS).

Една RDS сесия може да използва едно от трите нива на сигурност за защита на комуникациите между клиентите и хоста на RDS сесията:

  • Ниво на сигурност на RDP - Това ниво използва собствено RDP криптиране и е най-малко защитено. Сървърът на хоста на RD сесия не е удостоверен.
  • Преговаряйте „TLS 1.0 (SSL) криптиране ще се използва, ако клиентът го поддържа. Ако не, сесията ще се върне към RDP защита.
  • SSL "TLS 1.0 криптиране ще се използва за удостоверяване на сървъра и за шифроване на данни, изпратени между клиента и хост сървъра на сесията. Това е най-сигурната опция.

В допълнение към избора на ниво на защита, можете също да изберете нивото на криптиране за връзката. Ето следните опции:

  • Ниско (Low) Използва 56-битово криптиране за данни, изпратени от клиента към сървъра. Не криптира данните, изпратени от сървъра към клиента.
  • Client Compatible" е опцията по подразбиране. Тя криптира данните, обменяни между клиента и сървъра, с най-силния ключ, който клиентът поддържа.
  • High - Тази опция криптира данните в двете посоки между клиент и сървър, използвайки 128-битово криптиране.
  • FIPS Compliant - Тази опция криптира данни, предавани в двете посоки между клиента и сървъра, като използва одобрен от FIPS 140-1 алгоритъм за криптиране.

Обърнете внимание, че ако изберете опцията High или FIPS Compliant, всички клиенти, които не поддържат тези нива на криптиране, няма да могат да се свържат.

Ето как да конфигурирате настройките за удостоверяване и шифроване на сървъра:

  1. На сървъра за хост на RD сесия отворете секцията Конфигурация на хост за сесия на отдалечен работен плот и след това свойствата на връзката, както е споменато по-горе.
  2. В раздела Общи изберете подходящото ниво на сигурност и криптиране от падащия списък, както е показано на Фигура 2.
  3. Натиснете OK.

Фигура 2

Можете също да използвате групова политиказа управление на тези опции за криптиране и удостоверяване, както и други RDS настройки.

Групова политика

Има редица настройки на групови правила за RDS в Windows Server 2008 R2. Те се намират в Computer Configuration\Policies\Administrative Templates\ Компоненти на Windows(Компоненти на Windows)\ Услуги за отдалечен работен плот в конзолата за управление на групови правила на вашия домейн, както е показано на фигура 3.

Както можете да видите, има правила за лицензиране на RDC клиенти и сървъра за хост на RD сесии. Политиките за хост сървъра на RD Session, свързани със сигурността, включват:

  • Шаблон на сертификат за удостоверяване на сървъра:използвайте това правило, за да посочите име на шаблон на сертификат, което определя кой сертификат ще бъде избран автоматично за удостоверяване на сървъра на хост на RD сесия. Ако активирате това правило, само сертификати, генерирани с помощта на посочения шаблон, ще бъдат взети под внимание при избора на сертификат за удостоверяване на сървъра на RD Session Host.
  • Задайте ниво на шифроване на клиентската връзка:тази политика се използва за контрол дали е необходимо определено ниво на криптиране. Когато активирате тази политика, всички връзки трябва да използват определеното ниво на криптиране. Нивото на криптиране по подразбиране е високо.
  • Винаги подканвайте за парола при свързване:можете да използвате тази политика, за да принудите RDS винаги да изисква паролата на потребителя при влизане в RD сесия, дори ако паролата е въведена на RDC клиента. По подразбиране потребителите могат да влизат автоматично, ако в RDC клиента е въведена парола.
  • Изискване на сигурни RPC връзки (Изискване на защитена RPC комуникация):активирането на тази политика означава, че ще бъдат разрешени само криптирани и удостоверени заявки от клиенти. Връзки с ненадеждни клиенти няма да бъдат разрешени.
  • Изискване на използване на специфичен защитен слой за отдалечени (RDP) връзки: Ако активирате тази политика, всички връзки между клиентите и сървърите на хоста на сесията трябва да използват нивото на защита, което посочите тук (RDP, преговаряне или SSL/TLS)
  • Не позволявайте на локалните администратори да персонализират разрешенията:тази политика деактивира администраторските права за промяна на разрешенията за защита в инструментите за конфигуриране на хост на RD сесия, което не позволява на локалните администратори да променят потребителските групи в раздела Разрешения на инструмента за конфигуриране.
  • Изискване на потребителско удостоверяване за отдалечени връзки чрез използване на удостоверяване на мрежово ниво: С тази политика можете да изисквате NLA за всички отдалечени връзки към сървъра за хост на RD сесия. Само клиенти с активиран NLA ще могат да се свързват.

Забележка:ето как да разберете дали клиентският компютър поддържа удостоверяване на мрежово ниво: отворете RDC клиента и щракнете върху иконата в горния ляв ъгъл, след което изберете " За програмата (за)". Ако NLA се поддържа, ще видите реда "Поддържа се удостоверяване на ниво мрежа".

Други настройки на груповите правила, които си струва да се споменат, се намират в раздела Клиент за RD връзка. Те включват:

  • Не позволявайте запазването на пароли:активирането на тази настройка ще деактивира опцията за запазване на пароли в диалоговия прозорец на клиента на RDC. Ако потребителят отвори RDP файла и запише своите настройки, преди това запазените пароли ще бъдат изтрити. Това принуждава потребителя да въвежда своята парола при всяко влизане.
  • Посочете SHA1 отпечатъци на сертификати, представляващи доверени . rdp издатели):като използвате този параметър, можете да зададете списък с SHA1 отпечатъци на сертификати и ако сертификатът съвпада с отпечатъците в списъка, той ще се счита за доверен.
  • Подкана за идентификационни данни на клиентския компютър: Това правило позволява подканване за идентификационни данни на клиентски компютри, а не на сървъра за хост на RD сесия.
  • Конфигурирайте удостоверяване на сървъра за клиента: Тази опция може да се използва, за да се укаже дали клиентът може да установи връзка със сървъра за хост на RD сесия, когато не може да удостовери сървъра за хост на RD сесия. от най-много безопасна настройкаще има опция „Не се свързвай, ако удостоверяването е неуспешно).“

Можете също да използвате групови правила, за да конфигурирате съответствие с FIPS, но това правило не се намира тук с други правила за сигурност на RDS. Той се намира в следния раздел: Computer Configuration\Windows Settings\Security Settings\ Местни правила(Местни правила)\Опции за сигурност. В десния панел превъртете надолу до „Системна криптография: използвайте съвместими с FIPS алгоритми за криптиране, хеширане и подписване“. Когато тази политика е активирана, тя поддържа само алгоритъм за криптиране Triple DES (3DES) за RDS връзки.

RD уеб достъп

На компютри, които нямат инсталиран RDC клиент, потребителите могат да имат достъп до публикувани приложения, до които имат достъп от уеб браузър. Потребителят отива на URL адресЗа които се публикуват RDS ресурси. RD Web Access сървърът е отделен сървър от RD Session Host. Вие посочвате кои RD сървъри за уеб достъп могат да се свържат към кои сървъри за хост на RD сесии.

Уеб интерфейсът е конфигуриран с SSL и потребителят трябва да се удостовери със своите идентификационни данни. Проверенудостоверяване, потребителят ще може да вижда само тези RemoteApp програми, чието използване е разрешено за него сметказащото тези публикувани програми са "подрязани" със списък за контрол на достъпа (ACL).

Сървърът за уеб достъп използва сертификат X.509, за да осигури криптиране. По подразбиране е саморегистриран сертификат. За по-голяма сигурност трябва да получите сертификат от публичен CA или от PKI на вашата компания.

RD Gateway

RD Gateway (RDG) се използва, за да предостави на потребителите достъп до RD ресурси през Интернет. Сървърът на шлюза се намира на ръба и филтрира входящите RDS заявки според сървъра за мрежова политика (NPS). NPS използва две политики: политика за оторизация на връзка (CAP), която определя кои потребители имат достъп до RDG, и политика за оторизация на ресурси (RAP), която указва към кои CAP устройства потребителят може да се свърже чрез RDG.

Заключение

Услугите за отдалечен работен плот в Windows Server 2008 R2 значително подобряват функционалността на своя предшественик, терминалните услуги, но също така въвеждат някои нови съображения за сигурност, които трябва да имате предвид. Сървър, RD Gateway и клиент, както и използването на групова политика за управление на конфигурацията, можете да получите сигурна среда и да се възползвате от доставката на RDS приложения и да предоставите на потребителите си пълно изживяване на работния плот.

RDP протоколът със защита на мрежовия слой (SSL) за съжаление не се използва широко сред системни администраторикоито предпочитат да защитят терминалните връзки по различен начин. Може би това се дължи на привидната сложност на метода, но това не е така, в този материалще разгледаме как да организираме такава защита просто и без затруднения.

Какви са ползите от защитата на RDP с SSL? Първо, силно криптиране на канала, базирано на сертификат удостоверяване на сървъра и удостоверяване на потребител на ниво мрежа. Последната функция е налична от Windows Server 2008. Удостоверяването на мрежово ниво подобрява сигурността на терминалния сървър, като удостоверява потребителя преди сесията дори да започне.

Удостоверяването на мрежово ниво се извършва преди свързване с отдалечен работен плот и показване на екрана за влизане, това намалява натоварването на сървъра и значително увеличава неговата защита срещу натрапници и зловреден софтуер, а също така намалява вероятността от атаки за отказ на услуга.

За да се възползвате напълно от RDP над SSL, клиентските компютри трябва да работят Windows контрол XP SP3, Windows Vista или Windows 7 и използвайте RDP клиент версия 6.0 или по-нова.

При използвайки Windows Server 2003 SP1 и по-нови, SSL (TLS 1.0) криптиране на канала и удостоверяване на сървъра ще бъдат налични, клиентските компютри трябва да имат RDP клиент версия 5.2 или по-нова.

В нашата статия ще разгледаме настройката на терминален сървър на База на Windows Server 2008 R2, обаче, всичко по-горе ще се отнася и за Windows Server 2003 (с изключение на липсващите функции).

За да приложите успешно това решение, вашата мрежа трябва да има работещ сертифициращ орган, чиято конфигурация обсъдихме в предишната статия. За да се доверите на сертификатите, издадени от този CA на терминалния сървър, трябва да инсталирате CA сертификата (или верига от сертификати) в магазина Доверен коренови центровесертифициране.

След това трябва да поискате сертификат за удостоверяване на сървъра със следните параметри:

Изпратете заявка до CA и инсталирайте издадения сертификат. Този сертификат трябва да бъде инсталиран в локалното хранилище на компютъра, в противен случай няма да може да се използва от терминалните услуги. За да проверите това, стартирайте конзолата MMC (Старт - Изпълнение - mmc) и добавете щракване Сертификати(Файл - Добавяне или премахване на модула) за акаунта на компютъра.

В корена на конзолата изберете щракнете Изглед - Опциии задайте режим на преглед Организирайте сертификатите по предназначение. Издаденият сертификат трябва да е в групата Удостоверяване на сървъра.

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

Отворете Internet Explorer- Интернет опции - Съдържание - Сертификати, издаденият сертификат трябва да бъде инсталиран в магазина Лична.

Направете експорт. Когато експортирате, задайте следните опции:

  • Да, износ частен ключ
  • Изтрийте частния ключ след успешно експортиране
След това премахнете сертификата от това хранилище. за миг Сертификати ( локален компютър) изберете

глава Удостоверяване на сървъра, щракнете върху него Кликнете с десния бутонмишки Всички задачи - Импортиранеи импортирайте сертификата.

Сега в Администриране - услуги за отдалечен работен плототворен Конфигурация на хост на сесия на отдалечен работен плот(в Windows Server 2003 Административни инструменти - Конфигуриране на терминални услуги).

И накрая, капка катран в буре с мед. Терминал windows услугине знаят как да удостоверяват свързващите се клиенти, така че ако има такава необходимост, трябва да се използват допълнителни методи за защита, като SSH тунел или IPSec VPN.

RDP - протокол за отдалечен работен плот (отдалечен работен плот)

На първо място, тук ще говорим за самостоятелен сървър. Тоест за отделен - постоянен сървър. И не за домейн контролери и корпоративни мрежи. (просто им трябват висококвалифицирани специалисти)

Ситуация, когато дадена идея ви е хрумнала и сте решили да я реализирате. А за реализирането му е необходим Сървър, който наемате в определен център за данни.

Избрахте подходяща тарифа, платихте пари и вече имате сървър, на който е инсталиран софтуерът, от който се нуждаете. В повечето случаи Windows 2003 Server е достатъчен за тези пробни проекти. Напълно рентабилен и ефективен.

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

По подразбиране можем да кажем, че тази услуга в Windows е конфигурирана да създава на потребителя много неприятности и проблеми.

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

Започвате да виждате и тогава може би разбирате.

От една страна, разработчиците софтуерпреструвайте се, че правят системите си за обикновения човек, и започвате да вярвате.

Но от друга страна, същите тези разработчици предполагат, че само сертифициран специалист може да вземе клавиатурата. И че удостоверението било от тази година.

Такъв е парадоксът.

Нека ви кажа как наистина изглежда.

Но всъщност орди от coolhackers, след като прочетат дузина редове във форумите, изтеглят готови списъци със сървъри с отворен RDP порт. И те започват да разбиват колата ви. Кой е в ръководството, (но това е рядко), но най-вече различни програми, стартиране на речници чрез изброяване: вход - парола. И никой не ги ограничава в нищо. Дори на моменти им е тясно.

Освен това, гледам регистрационните файлове и виждам, че в по-голямата си част това са едни и същи речници.

И вашият сървър е принуден да отвърне на удара. И ти не знаеш. И не разбирате защо производителността ви е ниска, защо заявките се изпълняват дълго време.

Вие мислите мащабно. Стратегически, относно функционалността. И тук - някакви спирачки не са ясни.

Следователно ще започнете да оптимизирате паметта, да изтривате временни променливи, да дефрагментирате дискове и т.н.

И може би дори да погледнете по-отблизо раздела „Събития“ в модула за управление.

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

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

Какво ще правим:

  1. Нека ограничим броя на разрешените едновременно отворени сесии.
    (Ако управлявате своя собствена отдалечен сървър, защо имате нужда някой друг освен вас да управлява сървъра едновременно с вас?
    Въпреки че може да е необходим още един - например за техническа поддръжка. И още - защо?)
  2. И запалете светлината. Тоест, оставете системата да показва неуспешни опити за влизане в модула за събития.
    И тук ще останете изненадани.
  3. Ще забраним достъпа до сървъра от повече от 3000 IP адреса, които всъщност не правят нищо друго, освен да създават проблеми на хората. Черен списък за импортиране.

Ако нямате какво да правите и правите заявки в мрежата за настройка на RDP, ще намерите много съвети (и аз самият бях сигурен дълго време, че те са много ефективни, докато не реших да проведа експеримент)

  1. Ограничете броя на разрешените неуспешни опити за влизане.
    (Ако не сте пияни, тогава 3 пъти са достатъчни, за да разберете, че клавиатурата е на грешен език и в грешен регистър.)
  2. Ограничете времето за тези 3 опита.
    (Можете, в края на краищата, 3 пъти седмично или можете - 3 пъти в секунда и дори многонишкови. И тъй като никой от coolhackers не бърка в клавиатурата с един пръст дълго време, избирайки буква, тогава там е приличен трафик, който за 10 минути, които разработчиците са определили, ще има време да сортира няколкостотин, няколко хиляди комбинации.)
  3. Задайте блокиращо време за влизане в случай, че сте пияни, или ако - не сте вие.
    (По подразбиране - 3 минути няма да разстроят никого. Нека зададем половин час. Нека се уморят да чакат.)

Признавам, че бях много щастлив, когато намерих такива статии и веднага направих всичко както трябва. Бях сигурен, че сега можете да се съсредоточите върху самия проект и да не се притеснявате много за безопасността.

Като имаше десетки хиляди опити през деня. (И аз не седя с лице в монитора по цял ден, но веднъж на ден ходя да проверя работата на приложенията си) И така си остана.

И все още не можах да разбера как е така, така че виждам, че имам 3 опита, настроени и след това блокиране за 30 минути. И този бот играе шест часа неуморно, преминавайки през влизания от „Администратор“ до „ferapont“.
Но всичко не беше свободно време. И тогава - настроих всичко, което означава - трябва да работи!

Веднъж трябваше да прехвърля един от моите проекти от един сървър на друг поради повреда RAID масив. И стар сървър, ми беше на разположение известно време, но беше възможно безопасно да се опитам да проведа опасни и не много експерименти върху него. Затова реших да го проверя.

За да направя това, няколко минути се опитвах да вляза с грешна парола, очаквайки, че сега системата за удостоверяване ще ме блокира. Фигушки. Нищо не се е случило.

Прекарах няколко дни там подробно проучванетози проблем. Гмурнах се в ръководства и оскъдни коментари. Всички както уверяват във форумите - този метод е супер ефективен.

И това е, което ще ви кажа сега:

  • първо, този метод работи само под контролер на домейн (не знаете какво е това? Плюйте - нямате нужда от него), а за самостоятелен сървър трябва да се потопите в специални знанияи научете заклинания.
  • второ, оказва се, а явно мнозина погрешно и наивно приемат обратното (както и аз), че когато се въведе такъв механизъм, този, който се опита да влезе, ще бъде блокиран.
    Не, просто не той. И ще бъдеш блокиран!
    Да - вашият акаунт ще бъде блокиран за времето, през което сте се регистрирали там. И вие самите никога няма да можете да влезете в собствения си сървър!

Излизайки от къщата и заключвайки вратата, ще счупя ключалката. Ще си замръзна ушите - за злоба на баба.

Но мисля, че раздялата с такива илюзии си струваше няколко дни мъки.

Край с преамбюла. Да се ​​залавяме за работа.

1. Ограничете броя на разрешените едновременни отворени сесии.

Намерете и отворете модула за конфигуриране на терминални услуги:

В тази конзолна добавка изберете отваряне на раздела RDP-Tcp в „свойства“, където ограничаваме „Msximum Connections“ до 2x за всички мрежови адаптери.

Натиснете OK. Сега само още един човек може да влезе едновременно с вас. И без теб всеки желаещ ще трябва да се нареди по двама.
Следва, вие, кучи синове!

2. Включете показването на неуспешни опити за влизане в модула за събития.

Намираме и отваряме модула „Местни настройки за сигурност“ и в него - секцията: „Политика за одит“:

И променете стойностите на свойствата на всички записи "Одит" - както е показано на екранната снимка. След това ще трябва да рестартирате, за да влязат в сила промените.

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

3. Ние забраняваме достъпа до сървъра от 100% злонамерени IP адреси. Черен списък за импортиране.

Тук имате 2 опции:

  • Бързо и наведнъж.
  • Ръчно, с разбиране какво точно правиш.
Бърз начин.

След това трябва да имате нещо подобно:

Ръчен начин, с разбиране.
  1. Първо, трябва да създадете допълнителна политика. Отворете модула „Local Security Settings“.
  2. Избирате секцията „Правила за защита на IP на локалния компютър“ и щракнете с десния бутон върху: „Създаване на политика за защита на IP ...“ и стартирате съветника за конфигуриране.
  3. Измислете име за новото правило. Например: „Блокиране на IP“.
  4. След това щракнете върху всички въпроси и накрая ще имате форма за редактиране на свойствата на Политиката.
  5. Добавяне на ново правило. Кликнете върху . и ако полето Wizard е отметнато, тогава ще се стартира друг Wizard, на чиито въпроси трябва да се отговори.
  6. Крайна точка на тунела. Натиснете
  7. тип мрежа. Вече има „Всички мрежови връзки“. Натиснете
  8. Списък с IP филтри.
    Добавяне на нов филтър. Натискаме и измисляме смислено Име.

    Например: Блокирайте грубо принудително IP.
    Списъкът все още е празен. Запазваме го както е.