Windows RDP-klient. Vi utför en fjärranslutning till datorn! Hur man ställer in fjärråtkomst via RDP Säkra en rdp-anslutning med ssl

Ganska ofta har många användare som använder fjärråtkomstsessioner en fråga om hur man ändrar RDP-porten. Låt oss nu titta på de enklaste lösningarna och även ange flera huvudsteg i konfigurationsprocessen.

Vad är RDP-protokollet till för?

Först några ord om RDP. Om du tittar på avkodningen av förkortningen kan du förstå att fjärråtkomst

talande enkelt språk, är ett terminalserververktyg, eller arbetsstation. Windows-inställningar (och alla versioner av systemet) använder standardinställningar som är lämpliga för de flesta användare. Men ibland blir det nödvändigt att ändra dem.

Standard RDP-port: ska den ändras?

Så, oavsett Windows-modifiering, har alla protokoll ett förinställt värde. Detta är RDP-port 3389, som används för att utföra en kommunikationssession (ansluter en terminal till fjärranslutna).

Vad är anledningen till situationen när schablonvärdet behöver ändras? Först av allt, bara med säkerheten för den lokala datorn. När allt kommer omkring, om du räknar ut det, med en standardport installerad, kan i princip alla angripare enkelt penetrera systemet. Så låt oss nu se hur man ändrar standard RDP-porten.

Ändra inställningar i systemregistret

Vi noterar direkt att ändringsförfarandet utförs uteslutande i manuellt läge, och i själva fjärråtkomstklienten tillhandahålls ingen återställning eller installation av nya parametrar.

Först anropar vi standardregisterredigeraren med kommandot regedit i Kör-menyn (Win + R). Här är vi intresserade av HKLM-grenen, där vi måste gå ner i partitionsträdet genom terminalserverkatalogen till RDP-Tcp-katalogen. I fönstret till höger hittar vi nyckeln PortNumber. Vi måste ändra dess innebörd.

Vi går in i redigering och ser 00000D3D där. Många blir genast förbryllade över vad det är. Och detta är bara den hexadecimala representationen av decimaltalet 3389. För att ange porten i decimalform använder vi lämplig visningssträng för värderepresentationen och anger sedan den parameter vi behöver.

Efter det startar vi om systemet, och när vi försöker ansluta anger vi ny hamn RDP. Ett annat sätt att ansluta är att använda specialkommandot mstsc /v:ip_address:XXXXX, där XXXXX är det nya portnumret. Men det är inte allt.

Regler för Windows brandvägg

Ack, inbyggd Windows brandvägg kan blockera den nya porten. Så du måste göra ändringar i inställningarna för själva brandväggen.

Vi kallar brandväggsinställningarna med avancerade säkerhetsalternativ. Här ska du först välja inkommande anslutningar och klicka på raden för att skapa en ny regel. Nu väljer vi objektet för att skapa en regel för porten, anger sedan dess värde för TCP, sedan tillåter vi anslutningen, lämnar profilsektionen oförändrad och ger slutligen den nya regeln ett namn, varefter vi trycker på knappen för att slutföra inställningarna . Det återstår att starta om servern och, vid anslutning, ange den nya RDP-porten separerad av ett kolon på motsvarande rad. I teorin borde det inte vara några problem.

RDP-portvidarebefordran på routern

I vissa fall, när en trådlös anslutning används istället för en kabelanslutning, kan det vara nödvändigt att göra portvidarebefordran på routern (routern). Det är inget svårt i detta.

Först, i systemegenskaperna tillåter och specificerar vi användare som har rätt att göra det. Sedan går vi till menyn för routerinställningar via webbläsaren (192.168.1.1 eller i slutet 0.1 - allt beror på routermodellen). I fältet (om huvudadressen är 1.1) är det önskvärt att ange adressen, med början från den tredje (1.3), och skriva regeln för att utfärda adressen för den andra (1.2).

Sedan i nätverkskopplingar använd detaljvyn, där du ska se detaljerna, kopiera den fysiska MAC-adressen därifrån och klistra in den i routerns parametrar.

Nu, i avsnittet NAT-inställningar på modemet, aktivera anslutningen till servern, lägg till en regel och ange XXXXX-porten som måste vidarebefordras till standard RDP-port 3389. Spara ändringarna och starta om routern (den nya porten kommer att inte accepteras utan omstart). Du kan kontrollera anslutningen på någon specialiserad webbplats som ping.eu i avsnittet för porttestning. Som du kan se är allt enkelt.

Slutligen, notera att portvärdena är fördelade enligt följande:

• 0 - 1023 - portar för systemprogram på låg nivå;
• 1024 - 49151 - hamnar tilldelade för privata ändamål;
• 49152 - 65535 - dynamiska privata portar.

I allmänhet väljer många användare RDP-portar från det tredje området i listan för att undvika problem. Men både specialister och experter rekommenderar att du använder dessa värden vid inställning, eftersom de är lämpliga för de flesta av uppgifterna.

När det gäller exakt denna procedur används den huvudsakligen endast i fall av Wi-Fi-anslutning. Som du redan kan se, med en vanlig trådbunden anslutning, är det inte nödvändigt: ändra bara värdena för registernycklarna och lägg till regler för porten i brandväggen.

Remote Desktop Services (RDS) in Windows Server 2008 R2 har mer än bara ett nytt namn; detta är inte den föråldrade terminaltjänsten. Med nya funktioner (vissa introducerade i Windows Server 2008) som RemoteApp, RD Gateway och RD Virtualization Host, denna roll windows server ger dig nu flexibiliteten att installera enskilda applikationer eller kompletta maskiner med hjälp av en RDS- eller VDI-lösning - i många fall utan behov av Citrix eller andra tredjepartstillägg.

Men hur är det med säkerheten? Alla dessa extra komplexiteter kommer med ytterligare säkerhetsöverväganden. I den här artikeln tar vi en titt på säkerhetsmekanismerna inbyggda i RDS, hur man använder konfigurationsalternativ och grupppolicy för att förbättra säkerheten och säkerhetsrekommendationer för installation av RDS.

Vad är nytt i R2

Om du är ny på RDS efter att ha arbetat med Windows Server 2008 Terminal Services kommer du inte att se så många stora förändringar som du gjorde när du migrerade från Windows Server 2003. WS 2008 lade till några stora förbättringar av Terminal Services, inklusive TS Web Access för anslutning via en webbläsare, TS Gateway för användare som ansluter via Internet, RemoteApp för att leverera individuella applikationer till användare via protokollet Remote Desktop Protocol (RDP) och Session Broker som inkluderar en lastbalanseringsfunktion.

• Fjärrskrivbordsvirtualisering för VDI-lösning
• RDS-leverantör för PowerShell så att administratörer kan ändra konfigurationen och utföra uppgifter i kommandotolken och genom skript
• Nätverksadressvirtualisering (Remote Desktop IP Virtualization), som låter dig tilldela IP-adresser till anslutningar för varje enskild session eller program
• Ny version av RDP- och RDC-klienten (Remote Desktop Connection), version 7.0
• Fair Share CPU-schemaläggning för att dynamiskt fördela bearbetningstid mellan sessioner baserat på antalet aktiva sessioner.
• Kompatibel med Windows Installer för att förenkla installationen av program som kräver anpassning för enskilda användare.
• Äkta stöd för flera bildskärmar (upp till 16) som gör att program fungerar precis som de gör på klientdatorer.

Det finns även förbättringar inom ljud/bild och Windows-stöd Aero i en RD-session (observera dock att Desktop Composition, som gör att Aero kan fungera, inte stöds i flerskärmssessioner).

Säkerhetsaspekter och mekanismer

Naturligtvis beror potentiella säkerhetsproblem på hur du ställer in RDS. Om du har en mer komplex konfiguration där användare ansluter via Internet och/eller en webbläsare har du fler säkerhetsaspekter att ta hänsyn till och arbeta med än om du har en enkel konfiguration där användare ansluter enbart via RDC-klienter över LAN.

RDS innehåller ett antal säkerhetsmekanismer för att göra RD-anslutningar säkrare.

Autentisering på nätverksnivå

För maximal säkerhet bör du kräva Network Level Authentication (NLA) för alla anslutningar. NLA kräver att användare autentiseras till RD Session Host-servern innan en session skapas. Detta hjälper till att skydda fjärrdatorer från skadliga användare och skadlig programvara. För att använda NLA måste klientdatorn använda operativ system som stöder Credential Security Support Provider-protokollen (CredSSP), dvs. Windows XP SP3 och högre, och har en RDC 6.0-klient eller högre.

NLA konfigureras på RD Session Host-servern i följande avsnitt: Administrativa verktyg | Fjärrskrivbordstjänster | Värdkonfiguration för fjärrskrivbordssession. Följ dessa steg för att konfigurera en anslutning för att använda NLA:

1. Högerklicka på Anslutning
2. Välj Egenskaper
3. Gå till fliken Allmänt
4. Markera rutan "Tillåt endast anslutningar från datorer som kör Remote Desktop med nätverkskontroll autentisering (tillåt endast anslutningar från datorer som kör fjärrskrivbord med nätverksnivåautentisering)", som visas i figur 1
5. Klicka på OK.

Bild 1

Transport Layer Security (TLS)-protokoll

En RDS-session kan använda en av tre säkerhetsnivåer för att säkra kommunikation mellan klienter och RDS-sessionsvärden:

• RDP-säkerhetsnivå - Denna nivå använder inbyggd RDP-kryptering och är den minst säkra. RD-sessionsvärdservern är inte autentiserad.
• Förhandla "TLS 1.0 (SSL)-kryptering kommer att användas om klienten stöder det. Om inte kommer sessionen att falla tillbaka till RDP-säkerhet.
• SSL "TLS 1.0-kryptering kommer att användas för att autentisera servern och kryptera data som skickas mellan klienten och sessionsvärdservern. Detta är det säkraste alternativet.

Förutom att välja en säkerhetsnivå kan du även välja krypteringsnivå för anslutningen. Här är följande alternativ:

• Låg (låg) Använder 56-bitars kryptering för data som skickas från klienten till servern. Krypterar inte data som skickas från servern till klienten.
• Client Compatible" är standardalternativet. Det krypterar data som utbyts mellan klienten och servern med den starkaste nyckeln som klienten stöder.
• Hög - Det här alternativet krypterar data i båda riktningarna mellan klient och server med 128-bitars kryptering.
• FIPS-kompatibel - Det här alternativet krypterar data som överförs i båda riktningarna mellan klienten och servern med en FIPS 140-1-godkänd krypteringsalgoritm.

Observera att om du väljer alternativet Hög eller FIPS-kompatibel, kommer klienter som inte stöder dessa krypteringsnivåer inte att kunna ansluta.

Så här konfigurerar du serverautentisering och krypteringsinställningar:

1. På RD Session Host-servern, öppna avsnittet Remote Desktop Session Host Configuration och sedan anslutningsegenskaperna enligt ovan.
2. På fliken Allmänt väljer du lämplig säkerhets- och krypteringsnivå från rullgardinsmenyn, som visas i figur 2.
3. Klicka på OK.

figur 2

Du kan också använda gruppolicy för att hantera dessa krypterings- och autentiseringsalternativ, såväl som andra RDS-inställningar.

Gruppolicy

Det finns ett antal grupprincipinställningar för RDS i Windows Server 2008 R2. De finns under Computer Configuration\Policies\Administrative Templates\ Windows-komponenter(Windows-komponenter)\ Remote Desktop Services i din domäns Group Policy Management Console, som visas i figur 3.

Som du kan se finns det policyer för licensiering av RDC-klienter och RD Session Host-servern. Policyer för RD Session Host-servern relaterad till säkerhet inkluderar:

• Serverautentiseringscertifikatmall: använd denna policy för att ange ett certifikatmallnamn som bestämmer vilket certifikat som automatiskt väljs för RD Session Host-serverautentisering. Om du aktiverar den här policyn kommer endast certifikat som genererats med den angivna mallen att beaktas när du väljer ett certifikat för RD Session Host-serverautentisering.
• Ställ in klientanslutningskrypteringsnivå: denna policy används för att kontrollera om en viss kryptering krävs. När du aktiverar den här policyn måste alla anslutningar använda den angivna krypteringsnivån. Standardkrypteringsnivån är Hög.
• Fråga alltid efter lösenord vid anslutning: du kan använda den här policyn för att tvinga RDS att alltid fråga efter användarens lösenord när du loggar in på en RD-session, även om lösenordet anges på RDC-klienten. Som standard kan användare logga in automatiskt om ett lösenord skrivs in på RDC-klienten.
• Kräv säkra RPC-anslutningar (Kräv säker RPC-kommunikation): Aktivering av denna policy innebär att endast krypterade och autentiserade förfrågningar från klienter kommer att tillåtas. Anslutningar till opålitliga klienter kommer inte att tillåtas.
• Kräv användning av specifikt säkerhetslager för fjärranslutningar (RDP): Om du aktiverar denna policy måste alla anslutningar mellan sessionsvärdklienter och servrar använda den säkerhetsnivå du anger här (RDP, Negotiate eller SSL/TLS)
• Tillåt inte lokala administratörer att anpassa behörigheter: Denna policy inaktiverar administratörsrättigheter att ändra säkerhetsbehörigheter i RD Session Host Configuration-verktygen, vilket förhindrar lokala administratörer från att ändra användargrupper på fliken Behörigheter i konfigurationsverktyget.
• Kräv användarautentisering för fjärranslutningar genom att använda nätverksnivåautentisering: Med denna policy kan du kräva NLA för alla fjärranslutningar till RD Session Host-servern. Endast NLA-aktiverade klienter kommer att kunna ansluta.

Notera: så här tar du reda på om klientdatorn stöder autentisering på nätverksnivå: öppna RDC-klienten och klicka på ikonen i det övre vänstra hörnet, välj sedan " Om programmet (ca)". Om NLA stöds kommer du att se raden "Network Level Authentication Supported".

Andra grupprincipinställningar som är värda att nämna finns i avsnittet RD Connection Client. Dessa inkluderar:

• Tillåt inte att lösenord sparas: Om du aktiverar den här inställningen inaktiveras alternativet att spara lösenord i RDC-klientdialogrutan. Om användaren öppnar RDP-filen och sparar sina inställningar kommer de tidigare sparade lösenorden att raderas. Detta tvingar användaren att ange sitt lösenord varje gång de loggar in.
• Ange SHA1-tumavtryck för certifikat som representerar betrodda. rdp förlag): med den här parametern kan du ange en lista med SHA1-fingeravtryck av certifikat, och om certifikatet matchar fingeravtrycken i listan kommer det att anses vara betrodda.
• Fråga efter autentiseringsuppgifter på klientdatorn: Den här policyn gör det möjligt att fråga efter autentiseringsuppgifter på klientdatorer, inte på RD Session Host-servern.
• Konfigurera serverautentisering för klient: Det här alternativet kan användas för att ange om klienten kan upprätta en anslutning till RD Session Host-servern när den inte kan autentisera RD Session Host-servern. av de flesta säker inställning det kommer att finnas ett alternativ "Anslut inte om autentiseringen misslyckas)."

Du kan också använda gruppolicy för att konfigurera FIPS-efterlevnad, men denna policy finns inte här med andra RDS-säkerhetspolicyer. Den finns i följande avsnitt: Datorkonfiguration\Windows-inställningar\Säkerhetsinställningar\ Lokala policyer(Lokala riktlinjer)\Säkerhetsalternativ. I den högra rutan, scrolla ner till "Systemkryptering: använd FIPS-kompatibla algoritmer för kryptering, hashning och signering". När den här policyn är aktiverad stöder den endast Triple DES (3DES) krypteringsalgoritm för RDS-anslutningar.

RD Web Access

På datorer som inte har en RDC-klient installerad kan användare komma åt publicerade applikationer som de kommer åt från en webbläsare. Användaren går till URL-adress För vilka RDS-resurser publiceras. RD Web Access Server är en separat server från RD Session Host. Du anger vilka RD Web Access-servrar som kan ansluta till vilka RD-sessionsvärdservrar.

Webbgränssnittet är konfigurerat med SSL och användaren måste autentisera sig med sina referenser. Verifierad autentisering, kommer användaren att kunna se endast de RemoteApp-program, vars användning är tillåten för honom konto eftersom dessa publicerade program är "trimmade" med en åtkomstkontrolllista (ACL).

Web Access Server använder ett X.509-certifikat för att tillhandahålla kryptering. Standard är ett självregistrerat certifikat. För ökad säkerhet bör du skaffa ett certifikat från en offentlig CA eller från ditt företags PKI.

RD Gateway

RD Gateway (RDG) används för att ge användare åtkomst till RD-resurser över Internet. Gatewayservern är placerad vid kanten och filtrerar inkommande RDS-förfrågningar enligt Network Policy Server (NPS). NPS använder två principer: en Connection Authorization Policy (CAP), som anger vilka användare som kan komma åt RDG, och en Resource Authorization Policy (RAP), som anger vilka CAP-enheter en användare kan ansluta till via RDG.

Slutsats

Remote Desktop Services i Windows Server 2008 R2 förbättrar avsevärt funktionaliteten hos sin föregångare, Terminal Services, men den introducerar också några nya säkerhetsöverväganden att vara medveten om. Server, RD Gateway och Client, samt att använda grupppolicy för konfigurationshantering, du kan få en säker miljö och dra nytta av RDS-applikationsleverans och ge dina användare en komplett skrivbordsupplevelse.

RDP-protokollet med nätverkslagersäkerhet (SSL) används tyvärr inte i stor utsträckning bland systemadministratörer som föredrar att skydda terminalanslutningar på ett annat sätt. Kanske beror detta på den uppenbara komplexiteten i metoden, men det är inte så, i detta material vi kommer att överväga hur man organiserar ett sådant skydd enkelt och utan svårighet.

Vilka är fördelarna med att säkra RDP med SSL? För det första stark kanalkryptering, certifikatbaserad serverautentisering och användarautentisering på nätverksnivå. Den senare funktionen är tillgänglig från och med Windows Server 2008. Nätverksnivåautentisering förbättrar säkerheten för Terminal Server genom att autentisera användaren innan sessionen ens startar.

Nätverksnivåautentisering utförs innan du ansluter till Remote Desktop och visar inloggningsskärmen, detta minskar belastningen på servern och ökar dess skydd mot inkräktare och skadlig programvara, och minskar också sannolikheten för överbelastningsattacker.

För att dra full nytta av RDP över SSL måste klientdatorer vara igång Windows kontroll XP SP3, Windows Vista eller Windows 7 och använd RDP-klientversion 6.0 eller senare.

På använder Windows Server 2003 SP1 och senare, SSL (TLS 1.0) kanalkryptering och serverautentisering kommer att vara tillgängliga, klientdatorer måste ha RDP-klientversion 5.2 eller senare.

I vår artikel kommer vi att överväga att ställa in en terminalserver på Windows bas Server 2008 R2, dock kommer allt ovanstående även att gälla för Windows Server 2003 (förutom de saknade funktionerna).

För att framgångsrikt implementera denna lösning måste ditt nätverk ha en fungerande certifikatutfärdare, vars konfiguration vi diskuterade i föregående artikel. För att lita på certifikaten som utfärdats av denna CA till terminalservern måste du installera CA-certifikatet (eller kedjan av certifikat) i butiken Betrodd rotcentra certifiering.

Du bör sedan begära ett serverautentiseringscertifikat med följande parametrar:

Skicka en begäran till CA och installera det utfärdade certifikatet. Detta certifikat måste installeras i datorns lokala butik, annars kommer det inte att kunna användas av Terminal Services. För att kontrollera detta, kör konsolen MMC (Start - Kör - mmc) och lägg till snap Certifikat(Arkiv - Lägg till eller ta bort snap-in) för datorkontot.

Välj klicka i konsolroten Visa - Alternativ och ställ in visningsläge Organisera certifikat efter syfte. Det utfärdade certifikatet måste finnas i gruppen Serverautentisering.

Om du fick certifikatet med en fristående (fristående) CA (nätverket har ingen domänstruktur), installeras det som standard i användarkontoarkivet och du måste utföra ett antal ytterligare steg.

Öppen Internet Explorer- Internetalternativ - Innehåll - Certifikat, måste det utfärdade certifikatet installeras i butiken Personlig.

Gör en export. När du exporterar, ange följande alternativ:

• Ja, exportera privat nyckel
• Ta bort privat nyckel efter lyckad export

kapitel Serverautentisering, Klicka på det Högerklicka möss Alla uppgifter - Importera och importera certifikatet.

Nu inne Administration - Fjärrskrivbordstjänsteröppen Värdkonfiguration för fjärrskrivbordssession(i Windows Server 2003 Administrativa verktyg - Konfigurera terminaltjänster).

Och slutligen en droppe tjära i en tunna honung. Terminal windows tjänster vet inte hur man autentiserar anslutande klienter, så om det finns ett sådant behov bör ytterligare skyddsmetoder användas, såsom en SSH-tunnel eller IPSec VPN.

RDP - Remote Desktop Protocol (Remote Desktop)

Först av allt, här kommer vi att prata om fristående server. Det vill säga om en separat - stående server. Och inte om domänkontrollanter och företagsnätverk. (de behöver bara högkvalificerade specialister)

En situation då en viss idé dök upp och du bestämde dig för att förverkliga den. Och för dess implementering behöver du en Server, som du hyr i ett visst datacenter.

Du har valt en lämplig taxa, betalat pengar, och nu har du redan en Server där programvaran du behöver är installerad. I de flesta fall räcker Windows 2003 Server för dessa testprojekt. Helt kostnadseffektivt och effektivt.

Teknisk support ger dig en IP-adress, inloggning och lösenord för RDP-åtkomst, och du börjar din resa, full av ..., ja, i allmänhet - det kommer inte att verka tillräckligt.

Som standard kan vi säga att den här tjänsten i Windows är konfigurerad för att ge användaren mycket problem och problem.

Även om det förstås fungerar av sig självt och utför sin funktion perfekt. Men med tiden (ibland kan det vara för sent) kommer den vårdslösa ägaren av en fjärrserver att bli förskräckt över att inse vad som verkligen händer med hans system och vilken skara blodtörstiga människor som står runt väggarna i hans fästning.
Det är som att stänga av det infraröda filtret på DVR och plötsligt börja se videokällor - trafikpoliskameror med fotofixering och fjärrkontrollsignaler fjärrkontroll TV.

Du börjar se och sedan kanske förstå.

Å ena sidan utvecklare programvara låtsas att de gör sina system för den genomsnittliga personen, och du börjar tro det.

Men å andra sidan föreslår samma utvecklare att endast en certifierad specialist kan ta upp tangentbordet. Och att certifikatet var av detta år.

Sådan är paradoxen.

Låt mig berätta hur det verkligen ser ut.

Men faktiskt, horder av coolhackers, efter att ha läst ett dussin rader på forumen, laddar ner färdiga listor över servrar med en öppen RDP-port. Och de börjar bryta sig in i din bil. Vem är i manuell, (men detta är sällsynt), men mest olika program, startar ordböcker genom uppräkning: login - lösenord. Och ingen begränsar dem i någonting. De är till och med trånga där ibland.

Dessutom tittar jag på loggarna, och jag ser att det för det mesta är samma ordböcker.

Och din server tvingas slå tillbaka. Och du vet inte. Och du förstår inte varför din prestanda är låg, varför frågor körs under lång tid.

Du tänker stort. Strategiskt, om funktionalitet. Och här - någon sorts bromsar är inte tydliga.

Därför kommer du att börja optimera minnet, ta bort tillfälliga variabler, defragmentera diskar, etc.

Och kanske till och med ta en närmare titt på fliken "Händelser" i hanteringssnap-in.

Men jag försäkrar dig att du inte kommer att se anledningen där! Eftersom det inte visar försök att ange ett felaktigt användarnamn och lösenord. Kanske kommer du till och med att argumentera med andra människor att de inte knäcker dig för att de är rädda eller respekterade.
Nej. Jag försäkrar dig, det är bara det att utvecklarna är så roliga killar. Och till en början uppväger de vågen något i mörkrets riktning. De säger att om dessa händelser visades skulle belastningen på servern bli högre.
Men här bör det bara noteras att det första alla bör göra är att slå på den här skärmen. Även om det naturligtvis finns vissa tekniska system helt stängda från omvärlden, där ingen någonsin hackar något. Men där tjänar just sådana system hela team av proffs.

Så låt oss till att börja med fixa den här situationen och föra systemet till en normal fungerande form.

Vad ska vi göra:

1. Låt oss begränsa antalet tillåtna samtidigt öppna sessioner.
   (Om du sköter din egen Fjärrserver, varför behöver du någon annan än dig för att hantera servern samtidigt som du?
   Även om det kan behövas en till - till exempel för teknisk support. Och mer - varför?)
2. Och tända ljuset. Det vill säga låt systemet visa misslyckade inloggningsförsök i snapin-modulen Events.
   Och här kommer du att bli förvånad.
3. Vi kommer att förbjuda åtkomst till servern från mer än 3000 IP-adresser, som faktiskt inte gör något annat än att ge människor problem. Importera svart lista.

Om du inte har något att göra och gör förfrågningar på nätverket om att ställa in RDP, kommer du att hitta många råd (och jag var själv säker på att de var väldigt effektiva länge tills jag bestämde mig för att genomföra ett experiment)

1. Begränsa antalet tillåtna misslyckade inloggningsförsök.
   (Om du inte är full räcker det med 3 gånger för att du ska förstå att tangentbordet är på fel språk och i fel fall.)
2. Begränsa tiden för dessa 3 försök.
   (Du kan trots allt 3 gånger i veckan, eller så kan du - 3 gånger i sekunden, och till och med flertrådig. Och eftersom ingen av coolhackerna petar på tangentbordet med ett finger under lång tid när de väljer en bokstav, så finns det är hyfsad trafik, som på 10 minuter, som utvecklarna har bestämt, kommer att hinna reda ut flera hundra, ett par tusen kombinationer.)
3. Ställ in en spärrtid för inträde ifall du är full, eller om - du inte är du.
   (Standard - 3 minuter kommer inte att göra någon upprörd. Låt oss ställa in en halvtimme. Låt dem tröttna på att vänta.)

Jag erkänner att jag blev väldigt glad när jag hittade sådana artiklar och omedelbart gjorde allt rätt. Jag var säker på att nu kan du fokusera på själva projektet och inte oroa dig för mycket om säkerheten.

Eftersom det var tiotusentals försök under dagen. (Och jag sitter inte med ansiktet på monitorn hela dagen, utan en gång om dagen går jag för att kontrollera prestanda för mina applikationer) Och så förblev det.

Och jag kunde fortfarande inte förstå hur det var så, så jag ser att jag har 3 försök inställda och sedan en blockering i 30 minuter. Och den här boten har spelat i sex timmar outtröttligt och gått igenom inloggningar från "Administratör" till "ferapont".
Men allt var inte fritid. Och sedan - jag ställer in allt, vilket betyder - det borde fungera!

En gång var jag tvungen att överföra ett av mina projekt från en server till en annan, på grund av ett fel RAID-array. OCH gammal server, var tillgänglig för mig under en tid, men det var möjligt att säkert försöka genomföra farliga och inte särskilt experiment på det. Så jag bestämde mig för att kolla upp det.

För att göra detta försökte jag i flera minuter logga in med fel lösenord och förväntade mig att nu skulle autentiseringssystemet blockera mig. Figushki. Inget hände.

Jag tillbringade ett par dagar över detaljerad studie det här problemet. Jag kastade mig in i manualer och magra kommentarer. Alla som en försäkrar på forumen - den här metoden är supereffektiv.

Och det här är vad jag ska berätta för dig nu:

• För det första fungerar den här metoden bara under en domänkontrollant (vet du inte vad det är? Spotta - du behöver det inte) och för en fristående server måste du dyka in i specialkunskaper och lär dig trollformler.
• för det andra visar det sig, och tydligen antar många felaktigt och naivt något annat (som jag själv), att när en sådan mekanism implementeras kommer den som försöker komma in att blockeras.
  Nej, bara inte han. Och du kommer att blockeras!
  Ja – det är ditt konto som kommer att spärras under den tid du registrerade dig där. Och du själv kommer aldrig att kunna komma in på din egen server!

När jag lämnar huset och låser dörren kommer jag att bryta upp låset. Jag fryser om öronen - trots farmor.

Men jag tror att avsked med sådana illusioner var värt ett par dagars plåga.

Klar med ingressen. Låt oss komma till saken.

1. Begränsa antalet tillåtna samtidiga öppna sessioner.

Hitta och öppna snapin-modulen Terminal Services Configuration:

I denna snap-in, välj öppna fliken RDP-Tcp i "egenskaper", där vi begränsar "Msximum Connections" till 2x, för alla nätverkskort.

Klicka på OK. Nu kan bara ytterligare en person komma in samtidigt som du. Och utan dig måste alla som vill ställa upp i två.
Härnäst, ni jävlar!

2. Aktivera visningen av misslyckade inloggningsförsök i snapin-modulen Händelser.

Vi hittar och öppnar snapin-modulen "Lokala säkerhetsinställningar" och i den - avsnittet: "Revisionspolicy":

Och ändra egenskapsvärdena för alla "Audit" -poster - som visas på skärmdumpen. Du måste sedan starta om för att ändringarna ska träda i kraft.

Du kan vänta och efter några timmar titta på den nu verkliga bilden för att förstå vilken typ av värld vi lever i och vem som verkligen omger oss.

3. Vi förbjuder åtkomst till servern från 100 % skadliga IP-adresser. Importera svart lista.

Här har du 2 alternativ:

• Snabbt och på en gång.
• Manual, med en förståelse för exakt vad du gör.

Snabb väg.

Efter det borde du ha något sånt här:

Manuellt sätt, med förståelse.

1. Först måste du skapa en ytterligare policy. Öppna snapin-modulen "Lokala säkerhetsinställningar".
2. Du väljer avsnittet "IP-säkerhetspolicyer på lokal dator" och högerklickar: "Skapa IP-säkerhetspolicy ..." du startar konfigurationsguiden.
3. Kom på ett namn för den nya regeln. Till exempel: "Blockera IP".
   
4. Klicka sedan på alla frågorna och i slutet kommer du att ha ett formulär för att redigera egenskaperna för policyn.
   
5. Lägger till en ny regel. Klick . och om kryssrutan Wizard är markerad, startar en annan guide, vars frågor måste besvaras.
   
6. Tunnelslutpunkt. Tryck
   
7. nätverkstyp. Det finns redan "Alla nätverksanslutningar". Tryck
   
8. IP-filterlista.
   Lägger till ett nytt filter. Vi trycker på och kommer på ett meningsfullt Namn.
   
   Till exempel: Blockera brute forcering IP.
   Listan är fortfarande tom. Vi behåller det som det är.