RDP beskyttelse mot brute force: hvordan blokkere angrep og holde fjernadgang i drift

Hvordan en RDP brute-force angrep ser ut i praksis

Du pleier å legge merke til RDP brute force den samme måten: gjentatte mislykkede pålogginger mot en Windows-server som er tilgjengelig fra internett, ofte etterfulgt av kontolåsing, støyende sikkerhetslogger og bekymrede brukere som ikke kan koble til. Mange av disse angrepene er ikke "rettet" i menneskelig forstand. Internett-eksponert RDP skannes kontinuerlig, og automatiserte verktøy vil fortsette å prøve brukernavn og passord til de finner en svak legitimasjon eller skaper forstyrrelse.

I MITRE ATT&CK, dette kartlegges til Teknikk T1110 (Brute Force) , som inkluderer relaterte mønstre som passordgjetting og passordspraying. I praktiske operasjonsbetingelser er RDP brute force-angrep gjentatte eksterne påloggingsforsøk (ofte automatiserte) som prøver mange passord eller mange kontoer mot en eksponert RDP-tjeneste inntil legitimasjonene er funnet eller kontoene blir forstyrret.

Typiske symptomer inkluderer:

• En plutselig økning av mislykkede pålogginger i Windows sikkerhetslogger
• Mange forsøk mot vanlige kontonavn (Administrator, admin, test, tjenestestilnavn)
• Feil som kommer fra mange eksterne IP-adresser, noen ganger roterende ofte
• Brukerklager om kontolåsing eller treg pålogging ytelse
• Høyere CPU- eller autentiseringsbelastning under topper (LSASS- og RDP-relaterte tjenester kan bli påvirket)

Det hjelper å navngi det du ser. "Brute force" betyr vanligvis mange passord mot én konto. "Password spraying" betyr noen få vanlige passord mot mange kontoer for å unngå låsegrense. "Credential stuffing" betyr å teste brukernavn og passordpar stjålet andre steder. Alle tre viser seg som gjentatte mislykkede pålogginger eksternt og fortjener den samme første responsen: reduser eksponeringen og senk forsøkene.

Rask diagnose: bekreft at det er RDP brute force (og ikke en feilkonfigurasjon)

Før du endrer retningslinjer og risikerer å låse ute legitime brukere, bekreft hva som feiler, fra hvor, og i hvilken mengde. Microsofts egne feilsøkingsveiledning for Azure VM-er under brute-force angrep bruker det samme utgangspunktet selv utenfor Azure: se etter høye volumer av mislykkede pålogginger og korreler dem med eksterne kilde-IP-er.

• Sjekk Windows-sikkerhetslogger for en bølge av mislykkede pålogginger i løpet av den tiden brukerne rapporterte problemer. Hendelses-ID 4625 er en vanlig indikator å gjennomgå.
• Se etter mønstre: gjentatte kontonavn, mange forskjellige kontoer, eller den samme kilde-IP-en som treffer flere brukere.
• Korreler mislykkede pålogginger med vellykkede pålogginger kort tid etter. Vellykkede pålogginger blir ofte registrert som Hendelses-ID 4624, avhengig av din revisjonspolicy.
• Bekreft eksponering: er TCP 3389 (eller din tilpassede RDP-port) tilgjengelig fra internett gjennom en brannmurregel, NAT, portvideresending eller skytjenestegruppe?
• Bekreft at du ikke ser "falske alarmer" fra legitime kilder (en RDS-gateway, en VPN-konsentrator, et verktøy for ekstern administrasjon eller en intern skanner) som fremstår som gjentatte feil på grunn av et lagret feil passord.

Hvis du ser hendelses-ID 4625 i stort volum, fra mange eksterne IP-adresser over korte perioder, er det sannsynlig at du har med aktiv gjetting eller spraying å gjøre i stedet for en enkelt bruker som skriver feil passord.

Stopp blødningen på 15 til 30 minutter (tiltak for inneslutning som fungerer)

Når brute-force trafikk er aktiv, er prioriteten å gjenopprette kontroll og holde en sikker administrasjonsvei tilgjengelig. Den raskeste måten å redusere RDP brute-force risiko er å stoppe eksponeringen av RDP direkte mot internett og begrense innkommende tilgang til et kjent sett med pålitelige IP-adresser eller en sikret tilgangsvei (gateway, VPN eller bastion). Microsoft Learn’s veiledning for Azure-hendelser forsterker denne samme inneslutningsmetoden: begrens innkommende tilgang først, deretter forbedre tilgangsveien.

1. Etabler en sikker måte å komme tilbake på før du endrer noe. Hvis du allerede er låst ute, bruk din ut-av-bånd tilgang (hypervisor-konsoll, iLO/iDRAC, sky-serialkonsoll, bastion eller VPN) slik at du fortsatt kan administrere verten etter brannmurendringer.
2. Fjern direkte internett-eksponering av RDP. Deaktiver den offentlige portviderekoblingen eller stram inn innkommende regler slik at RDP ikke er åpen for "hvilken som helst kilde." Hvis du ikke kan fjerne det umiddelbart, begrens innkommende tilgang til en kort hviteliste (dine kontor-IP-er, ditt administrasjonsnettverk, dine faste utgående IP-er fra MSP).
3. På Azure eller lignende skyer, stram inn perimeteren umiddelbart. Begrens innkommende regelen i din NSG eller tilsvarende. Hvis du har muligheten, gå over til Microsoft-godkjente mønstre som Azure Bastion, VPN Gateway, eller just-in-time tilgangskonsepter for å redusere eksponeringsvinduer.
4. Bekreft Nettverksnivåautentisering (NLA) er aktivert. NLA krever autentisering før en full ekstern skrivebordsøkt etableres, noe som reduserer eksponeringen for noen forhåndsautentiseringsrisikoer og reduserer unødvendig ressursbruk under gjetting.
5. Gjennomgå hvem som kan logge på via RDP. Valider medlemskap av lokale administratorer og brukere av Remote Desktop, og fjern eventuelle brede grupper som ikke trenger interaktiv pålogging eksternt.
6. Beskytt privilegerte kontoer med en gang. Hvis du mistenker at et passord kan være svakt eller lekket, roter legitimasjonen for privilegerte kontoer på en kontrollert måte, og sjekk for uventede nye lokale administratorer eller nylig aktiverte kontoer.
7. Stabiliser tilgang for ekte brukere. Hvis brukere blir låst ute, er løsningen vanligvis reduksjon av eksponering og bedre throttling, ikke lavere sikkerhet. Unngå å haste endringer i låsing som kan skape en bredere nedetid.

Når du har fått kontroll over trafikken, kan du trygt gjøre langsiktige endringer. Hvis du ønsker en verktøyassistert tilnærming etter at du har gjenvunnet kontrollen, TSplus Advanced Security kan hjelpe med å operasjonalisere blokkering av brute-force og tilgangsbegrensninger på Windows-servere, men inneslutning begynner fortsatt med å redusere eksponeringen.

Reduser angrepsflaten: tilgangsarkitekturene som reduserer risikoen for brute-force.

Hvis du bare skal ta én lærdom fra gjentatte RDP-angrep, la det være dette: arkitektur slår tweaking. Å sette et kontrollert inngangspunkt foran sesjonsverter endrer hva angripere kan nå og hva du kan håndheve. Microsofts sikkerhetsblogg veiledning for adopsjon av ekstern skrivebord fremhever å redusere direkte eksponering, og Microsoft Learn-dokumenter for RD Gateway som en måte å gi sikker tilgang over TLS med riktig sertifikatkonfigurasjon.

Den mest pålitelige måten å redusere RDP brute-force forsøk på er å unngå direkte RDP eksponering og i stedet kreve tilgang gjennom et kontrollert inngangspunkt som RD Gateway , VPN, eller en bastion, ideelt sett med sterk autentisering.

Tilgangsmønster	Eksponering og risiko for brute-force	Operasjonell kompleksitet	Når det passer	Notater
Direkte RDP fra internett	Høyeste risiko og høyest støy. Konstant skanning og gjetting.	Lav for å sette opp, høy for å forsvare.	Kun for kortvarig nødsituasjonstilgang med strenge begrensninger.	Å endre porten kan redusere opportunistisk skanning, men det gir ikke sterk beskyttelse i seg selv.
Direkte RDP med IP-whitelisting	Lavere eksponering hvis tillatelseslisten er liten og stabil.	Medium. Krever vedlikehold av tillatelser og håndtering av reise/ISP-endringer.	Små administrasjonsteam med faste kontor-IP-er eller faste MSP-utganger.	Fungerer best når den kombineres med sterke autentiseringskontroller og overvåking.
RD Gateway foran RDS/RDP	Reduserer direkte eksponering av sesjonsverter og tunneler over TLS.	Medium til høy. Sertifikater, tilgjengelighet og policyutforming er viktig.	Windows-sentriske miljøer som allerede bruker RDS-mønstre.	Microsoft Learn’s RDS planleggingsveiledning dekker gateway-krav. Microsoft-lisensiering forblir ditt ansvar og bør valideres med Microsoft eller en kvalifisert lisenspartner.
VPN for ekstern tilgang	Fjerner RDP fra offentlig eksponering når det gjøres riktig.	Medium. Klientdistribusjon, ruting og MFA-integrasjon varierer.	Administratorer og ansatte som trenger bredere nettverkstilgang, ikke bare én app.	Begrens VPN-brukere til det de trenger, og sikre RDP inne i nettverket.
Bastion eller hoppvert	Sterk eksponeringsreduksjon. RDP er kun tilgjengelig fra bastionkonteksten.	Medium. Trenger sterk kontroll over selve bastionen.	Skybaserte servere, regulerte miljøer og tilgang kun for administratorer.	Ofte passer det godt med just-in-time tilgangsvinduer og betingede kontroller avhengig av plattform.
Publiser applikasjoner/skrivbord via en nettportal (HTTPS)	Kan redusere eller eliminere behovet for å eksponere rå RDP offentlig, avhengig av design.	Lav til middels. Fokuserer på å levere det brukerne trenger, ikke full nettverksadgang.	SMB-er som leverer et sett med Windows-apper eller eksterne skrivebord til brukere og partnere.	Hvis målet ditt er å gi brukere tilgang til Windows-applikasjoner uten å la rå RDP være eksponert for internett, er TSplus Remote Access verdt å vurdere for applikasjons- og skrivebordsutgivelse gjennom en sikret webportal.

Hvis du må holde noe RDP-tilgang tilgjengelig, behandle det som et beskyttet administrasjonsgrensesnitt, ikke et generelt inngangspunkt for fjernarbeid. Hvis du går mot app- og desktoppublisering gjennom en sikret nettportal en hurtigstartguide kan hjelpe deg med å komme i gang. Din sikkerhetsstilling forbedres betydelig når de fleste brukere aldri kobler til TCP 3389 i det hele tatt.

Herd autentisering for RDP uten å låse ute ekte brukere

God motstand mot brute-force er en balanse mellom å bremse angripere og opprettholde pålitelig tilgang for legitime brukere. Effektiv motstand mot brute-force kombinerer NLA og sterke legitimasjoner med en hastighetsbegrensning eller låsepolitikk som bremser gjentatte feil, samtidig som den er justert for å unngå tjenestenekt utløst av angripere. NIST SP 800-63B diskuterer throttling og håndtering av gjentatte mislykkede autentiseringsforsøk som en kjernekontroll, fordi det reduserer muligheten for rask gjetting.

Start med NLA og kontorenslighet

NLA er en basislinje for RDP fordi det krever autentisering før sesjonen er fullt etablert. Det vil ikke stoppe passordspraying av seg selv, men det reduserer eksponeringen og bortkastede ressurser sammenlignet med å la uautentiserte sesjoner fortsette.

Deretter adresser identitetsgrunnlagene som brute force utnytter: fjern unødvendige administratorrettigheter, håndhev minste privilegium, og rydd opp i utdaterte kontoer. Hvis du har åpenbare eller delte lokale administrator kontoer, roter dem, begrens hvor de kan logge inn, og vurder å endre navn på eller deaktivere kontoer som ikke trenger interaktiv pålogging. Hold brukere av Remote Desktop og lokale administratorer stramme, spesielt på servere som huser sensitiv data.

Låsing og throttling: hvorfor justering er viktig

Innstillinger for Windows-konto låsingspolicy brukes vanligvis for å redusere suksess med brute-force, og Microsoft Learn dokumenterer de viktigste begrepene : låsegrense, låsevarighet og nullstillingstelling. Avveiningen er tilgjengelighet. Angripere kan med vilje utløse låsinger for ekte brukere (eller ditt hjelpesenter og administratorer) hvis grensen din er for lav og eksponeringen din er bred.

Bruk disse beslutningsfaktorene når du justerer låsing og throttling:

• Hvor utsatt er tjenesten? Hvis RDP er tilgjengelig fra hele internett, er det mer sannsynlig at låsinger blir utnyttet. Reduser eksponeringen først, og juster deretter låsingen.
• Hvordan autentiserer brukerne seg? En gateway, VPN eller bastion kan redusere behovet for aggressive utestengelser på sesjonsverten fordi færre ukjente kilder kan nå den.
• Hvor kostbart er en låsing? Hvis låsing oversettes til en nedetid for et produksjonsstøtteteam, kan du foretrekke hastighetsbegrensning og IP-baserte utestengelser fremfor strenge kontolåsing.
• Hvordan oppfører delte kontoer seg? Delte legitimasjoner forsterker virkningen av låsinger. Eliminér delte kontoer der det er mulig.

Spesiell sak: innebygd lokal administrator

Mange miljøer har fortsatt en innebygd lokal Administrator-konto på servere og arbeidsstasjoner, og dens låseadferd har vært et hyppig forvirringspunkt. Microsoft Support KB5020282 gir kontekst om kontolås for innebygde lokale administratorer, inkludert hvordan lås kan gjelde for nettverksinnlogginger som RDP avhengig av konfigurasjon og versjon. Ikke anta at den innebygde administratoren vil oppføre seg på samme måte som en vanlig brukerkonto, og test på en kontrollert måte før du stoler på låseatferd som en primær kontroll.

For team som ønsker et praktisk herde-lag, inkluderer TSplus Advanced Security beskyttelse mot brute-force angrep designet for å stoppe gjentatte uautoriserte forsøk på verts-nivå. Det bør komplementere, ikke erstatte, sterke Windows autentiseringspolitikker og nøye justering av låsing.

Nettverkskontroller som hjelper (og de som folk overvurderer)

Nettverkskontroller er ofte de raskeste forbedringene du kan gjøre, men de har ulik verdi i den virkelige verden. Microsofts veiledning for RDP brute-force problemer (inkludert i Azure-scenarier) prioriterer konsekvent å begrense innkommende tilkobling fremfor kosmetiske endringer.

Høy verdi: IP tillatelse. Hvis du kan begrense RDP til kjente adresser (kontorets utgående IP-er, VPN-områder, bastion-subnett, faste IP-er fra MSP), fjerner du mesteparten av brute-force-trafikken umiddelbart. Dette gjør også overvåkingen din mer meningsfull fordi eventuelle gjenværende feil kommer fra et mindre sett med kilder.

Nyttig med forsiktighet: geografiske og omdømmebaserte kontroller. Geo-blokkering og IP-reputasjon kan redusere støy, men de kan også blokkere legitime brukere som reiser, kobler seg til fra roaming-nettverk eller kommer gjennom CGNAT. Angripere kan også bruke VPN-er og proxyer, så behandle geokontroller som en risikoreduksjon, ikke en garanti.

Overvurdert: endring av RDP-porten. IP tillatelse reduserer betydelig RDP brute-force eksponering, mens endring av RDP-porten hovedsakelig reduserer opportunistisk skanning og ikke bør stole på som primær beskyttelse. En portendring kan kjøpe tid under en hendelse, men den adresserer ikke passordspraying fra en bestemt aktør som kan oppdage porten.

I miljøer der team ønsker enklere håndheving enn å opprettholde komplekse regelsett manuelt, tilfører TSplus Advanced Security geografisk beskyttelse og IP-baserte kontroller som kan brukes konsekvent på tvers av servere.

Overvåking og deteksjon: hva som skal logges, varsles om og undersøkes

Brute force er et av de problemene som ser åpenbare ut i ettertid og kostbare når du oppdager det sent. Målet med overvåking er ikke å telle hver mislykkede pålogging for alltid. Det er å oppdage unormale mønstre tidlig og å undersøke om disse forsøkene noen gang ble til en vellykket pålogging.

Overvåk unormale topper i mislykkede pålogginger (ofte hendelses-ID 4625) og varsle om mønstre som indikerer passordspraying eller en vellykket pålogging etter gjentatte feil. Microsofts veiledning for feilsøking av brute-force fremhever den samme artefakten (4625) fordi det er et praktisk utgangspunkt når administratorer prøver å gjenvinne tilgang og forstå omfanget.

For daglige operasjoner, fokuser på tre undersøkelsesspørsmål:

Er trafikken ekstern eller intern? Eksterne IP-er som treffer et offentlig grensesnitt peker på eksponeringsproblemer. Interne IP-er kan indikere et kompromittert sluttpunkt eller en feilkonfigurert tjenestekonto.

Er det én konto eller mange? Én konto antyder brute force. Mange kontoer med lave forsøk hver antyder passord spraying.

Lyktes noen kontoer etter utbruddet? En vellykket pålogging kort tid etter gjentatte feil er en høyprioritert korrelasjon å undersøke, spesielt for privilegerte kontoer.

Hvis du ikke allerede sentraliserer Windows-loggene, vurder Windows Event Forwarding eller ditt eksisterende SIEM slik at du kan varsle på tvers av flere servere konsekvent. For team som trenger enkle varsler og historisk synlighet under angrepsspisser , TSplus Server Monitoring kan hjelpe deg med å spore serverhelse og tilgjengelighet sammen med sikkerhetsloggingen din.

Automatiserte blokkeringstilnærminger (og hvordan unngå falske positiver)

Manuell respons skalerer ikke når vertene dine er tilgjengelige på internett. Automatisering er der mange team gjenvinner kontroll, så lenge det er designet for å være reversibelt og for å beskytte legitim tilgang. Den sikreste automatiseringen blokkerer gjentatte mislykkede pålogginger med tidsbegrensede utestengelser og klare tillatelser, og den må ta hensyn til delte IP-adresser for å unngå å blokkere legitime brukere.

Hvordan automatisering ser ut i praksis

Vanlige tilnærminger inkluderer vert brannmurmoduler som oppdager gjentatte feil og midlertidig forbyr en IP, EDR-funksjoner som oppdager atferd for passordgjetting, og skript som analyserer sikkerhetslogger og anvender dynamiske brannmurregler. Gateway-sentriske kontroller (RD Gateway, VPN, bastion) reduserer ofte behovet for aggressiv blokkering på verts nivå fordi færre ukjente kilder når serveren.

Hvor team får brent seg

Delt NAT og CGNAT. Hvis mange legitime brukere kommer fra én offentlig IP (et filialkontor, et hotellnettverk, noen ISP-er), kan blokkering av den IP-en kutte av gode brukere sammen med angripere. Tidsbegrensede forbud og kjente gode hvitelister reduserer blast-radiusen.

Blokkerer din egen ledelsesvei. Alltid hviteliste VPN-områdene dine, bastion-subnettet og MSP-administrasjonsutgående IP-er før du aktiverer aggressiv blokkering. Dokumenter en nødvei som ikke er avhengig av den samme nettverksruten.

Låseutløste avbrudd. Hvis din eneste kontroll er kontolås, kan angripere gjøre det om til tjenestenekt. Kombiner låsepolitikker med eksponeringsreduksjon og IP-basert throttling slik at verten ikke blir flaskehalsen.

TSplus Advanced Security legger til praktisk beskyttelse mot brute-force angrep , IP og geografiske kontroller, samt ransomware-fokusert herding for Windows-servere, som kan hjelpe deg med å redusere gjentatte RDP-påloggingsforsøk uten å implementere en tungvint sikkerhetsløsning.

En praktisk basislinje for SMB- og MSP-miljøer

SMB-er og MSP-er trenger en standard som er repeterbar, testbar og lite sannsynlig å bryte daglige operasjoner. Microsofts sikkerhetsveiledning for eksterne skrivebord støtter det samme generelle prinsippet: reduser direkte eksponering, deretter styrk tilgangen og overvåk aktivt.

• Fjern direkte internett-eksponering av RDP der det er mulig, og rute tilgang gjennom VPN, gateway eller bastion-mønstre.
• Hvis RDP må forbli tilgjengelig, begrens innkommende tilgang til en liten IP-hvitliste og gjennomgå den regelmessig.
• Aktiver nettverksnivåautentisering (NLA) og krev sterke, unike legitimasjoner for alle interaktive brukere.
• Stram inn privilegert tilgang: minimer lokal administratormedlemskap og gjennomgå medlemskap for Remote Desktop Users.
• Sett kontolåsepolicy med vilje (terskel, varighet, tilbakestillings teller) og test den for å unngå nedetid drevet av låsing.
• Overvåk mislykkede pålogginger (for eksempel, hendelses-ID 4625) og undersøk mønstre av suksess etter feil raskt.
• Hold Windows, RDP-relaterte komponenter og internettvendte tjenester oppdatert etter en definert tidsplan.
• Dokument brudd-glass tilgang, inkludert hvordan du vil gjenvinne konsolltilgang hvis nettverksregler blokkerer ekstern tilgang.

Hvis du ønsker en strukturert vurdering, bruk vår RDP-sikkerhetsrevisjon: En 20-punkts sjekkliste for 2026 .

For MSP-er, standardiser det du kan (GPO-maler, brannmurstandarder, tillatte administrasjons-IP-er) og hold kundespesifikke tillatelser og unntak tydelig dokumentert. Hvis du trenger et praktisk herdinglag på tvers av mange kundeservere, kan TSplus Advanced Security implementeres som en del av en standard sikkerhetspakke for fjernadgang, og TSplus Remote Access kan støtte en "ikke eksponer rå RDP direkte" holdning for publiserte applikasjoner og skrivebord.

FAQ

Stopper endring av standard RDP-port brute-force angrep?

Nei. Å endre RDP-porten kan redusere opportunistisk skanningstøy, og Microsofts egne retningslinjer for hendelser nevner det som en midlertidig avbøtning i noen scenarier, men det stopper ikke målrettet gjetting. Behandle det som en sekundær taktikk og fokuser først på reduksjon av eksponering (tillatelser, gateway, VPN, bastion) og styrking av autentisering.

Hvilke Windows-policyinnstillinger er viktigst for RDP bruteforce-beskyttelse?

Start med å aktivere NLA for RDP, stramme inn hvem som har rett til å logge på via Remote Desktop, og konfigurere retningslinjer for konto-låsning (terskel, varighet, tilbakestillings teller) som dokumentert av Microsoft Learn. Strenge passordpolicyer og minst privilegerte administratorrettigheter reduserer også sjansen for at gjetting fører til et meningsfylt kompromiss.

Kan innstillingene for konto-lås gjøre RDP-avbrudd verre under et angrep?

Ja. Hvis RDP er bredt eksponert, kan angripere med vilje utløse låsinger for ekte brukere, noe som blir et problem med tjenestenekt. Derfor er den anbefalte rekkefølgen å redusere eksponeringen først, deretter justere låsing og throttling på en måte som balanserer sikkerhet med tilgjengelighet.

Er nettverksnivåautentisering (NLA) tilstrekkelig for å sikre RDP?

NLA er en viktig basislinje, men det forhindrer ikke passordspraying eller legitimasjonsstapping alene. Du trenger fortsatt eksponeringsreduksjon, sterk legitimasjonspraksis, fornuftig throttling eller låseadferd, og overvåking av uvanlige påloggingsmønstre.

Hva bør jeg overvåke for å oppdage RDP brute-force forsøk tidlig?

Se etter unormale topper i mislykkede pålogginger, vanligvis synlige som Hendelses-ID 4625, spesielt når de kommer fra mange eksterne IP-er eller retter seg mot mange brukernavn på kort tid. Undersøk også enhver vellykket pålogging som skjer kort tid etter gjentatte feil, fordi det kan indikere et gjettet eller gjenbrukt passord.

Konklusjon: prioriter reduksjon av eksponering, deretter styrk og automatiser

RDP beskyttelse mot brute force er ikke én innstilling. Det er en lagdelt tilnærming som fungerer best i denne rekkefølgen: reduser eller fjern direkte eksponering, styrk autentisering (NLA, sterke legitimasjoner, minst privilegium, fornuftig låsing eller throttling), anvend nettverkskontroller som faktisk begrenser tilgjengelighet, overvåk for meningsfulle mønstre, og automatiser blokkering nøye for å unngå falske positiver.

Dokumenter endringene dine, test dem utenom arbeidstid når det er mulig, og bekreft at din nødprosedyr fortsatt fungerer etter justeringer av brannmur og låsing. Hvis du ønsker å operasjonalisere disse beskyttelsene med mindre manuelt arbeid, kan TSplus Advanced Security hjelpe med beskyttelse mot brute-force og tilgangsbegrensninger, og TSplus Remote Access kan gi en sikrere leveringsmodell for publiserte Windows-applikasjoner og skrivebord gjennom en webportal. For å evaluere kan du nedlasting en prøve og vurdering priser .