Åpne opp Remote Desktop utenfor hjemmenettverket?

[NoTrace]

12 års erfaring innen dette emnet. Jeg hadde nok satt opp en RDP GW med MFA foran i det minste.

Endret 12. mai 2020 av NoTrace

[tigerdyr]

1 hour ago, Miri said:

Jeg har jobbet med dette profesjonelt. For et par-tre år siden fikk jeg en henvendelse fra en ny kunde. Da de kom på jobb og slo på skjermene, var alle maskiner og servere infisert med løsepengevirus. Hackere hadde fått tilgang via en sårbarhet i RDP-protokollen. Selv om alt tilsynelatende var sikkert og riktig satt opp av leverandøren, så hjelper ikke det når selve programvaren har sikkerhetshull. Kun én maskin i hele nettverket var uberørt, den hadde RDP deaktivert. Alle andre hadde fått alle disker kryptert, inkluderte servere og NAS-disker. Uten min bistand hadde selskapet gått konkurs. Det ble dyrt.

Betyr ingenting vettu.  Trådstarter har blitt ekspert av å ha sett tutorials på Udemy.  Hva skulle vi kunne bidra med da?

[sedsberg]

Rart det der. Ekspert på IT, nettverk og sikkerhet, men sliter med å sette opp port forwarding på en hjemmerouter.

[frohmage]

Miri skrev (19 timer siden):

Uten min bistand hadde selskapet gått konkurs.

Hva var din bistand? Hadde du ekstra backup?

[Gjest Slettet+9817234]

frohmage skrev (På 12.5.2020 den 18.14):

Hva var din bistand? Hadde du ekstra backup?

Windows-diskene var kryptert, backup på NAS var slettet, og ekstern backup var ubrukelig. Maks uflaks. De betalte også hackerne for opplåsingsnøkkel, men sentrale filer og SQL-data var ødelagt. Jeg gjenopprettet filer fra NAS med et kommersielt Linux-verktøy, og brukte dette til å bygge opp serverne manuelt.

[sk0yern]

nomore skrev (På 11.5.2020 den 15.40):

Hørt om nulldags sårbarheter? Også kjent som zero day vulnerability.

Å holde spesielt operativsystemet oppdatert, men også annen installert programvare, er et veldig godt steg på veien. Men man er altså fortsatt sårbar for nye og hittil ukjente sårbarheter. Så jeg mener motsatt, at spesielt på private PC'er er dette ekstra risikabelt ettersom arbeidet blir ofte manuelt og lagt opp til tilfeldigheter.

Det er nulldags sårbarheter i Chrome også, så da må man vurdere om man skal slutte å bruke Chrome, eller leve med risikoen.
På de aller fleste private windows pc'er i dag, går patchene automatisk igjennom ganske kort tid etter at de er sluppet.

Det er ikke slik at ting automatisk blir mye tryggere dersom man plasserer ting bak en vpn-gateway. Denne kan også få kritiske patcher, som neppe patches like automatisk som windows update.

 

[Uderzo]

Det handler om å redusere risiko, å eksponere RDP rett ut på nettet uten noen form for ekstra sikkerhetslag, er det motsatte av det.

[superfastjellyfish]

Å ikke bry seg om sikkerhet eller å ikke prioritere sikkerhet er to veldig forskjellige valg. Argumenter om at det ikke er nødvendig å gjøre ekstra tiltak fordi det alltid vil finnes andre sårbarheter er nesten like dumt som å ikke låse bildøren fordi tyven like gjerne kan knuse bilruten.

Dersom trådstarter ikke ønsker å implementere ekstra lag med sikkerhet pga kostnad- og/eller tidsbesparelser så er det gyldige argumenter, selv om det alltid vil være noen som er uenig i de prioriteringene. Å argumente for at økt sikkerhet er unødvendig derimot, er det de fleste reagerer på her.

[sk0yern]

Min påstand er at man overvurderer risikoen ved å eksponere rdp mot internett.
Dersom man har et sterkt passord og maskinen patches automatisk, er risikoen for å bli tatt veldig liten.

 

[Gjest Sletttet+98134]

sk0yern skrev (1 minutt siden):

Min påstand er at man overvurderer risikoen ved å eksponere rdp mot internett.
Dersom man har et sterkt passord og maskinen patches automatisk, er risikoen for å bli tatt veldig liten.

 

Så du ville ikke hatt noen problemer med å forsvare åpen RDP ut på internett til ledelsen i et eventuelt firma du jobbet for?

[sk0yern]

Fleskefjeset skrev (46 minutter siden):

Så du ville ikke hatt noen problemer med å forsvare åpen RDP ut på internett til ledelsen i et eventuelt firma du jobbet for?

Der jeg jobber så eksponeres ikke rdp mot internett. Grunnene til dette er flere, hovedgrunnen er at det rett og slett ikke er nødvendig, og at vi har vpn eller lignende foran.

Vi eksponerer dog en rekke ssh servere mot internett.

Nå er vel uansett topic her "Åpne opp Remote Desktop utenfor hjemmenettverket".
Jeg har eksponert rdp mot internett hjemme i mange år, og har ingen større bekymringer med det.
Samme med ssh.

[Gjest Sletttet+98134]

sk0yern skrev (1 time siden):

Der jeg jobber så eksponeres ikke rdp mot internett. Grunnene til dette er flere, hovedgrunnen er at det rett og slett ikke er nødvendig, og at vi har vpn eller lignende foran.

Vi eksponerer dog en rekke ssh servere mot internett.

Nå er vel uansett topic her "Åpne opp Remote Desktop utenfor hjemmenettverket".
Jeg har eksponert rdp mot internett hjemme i mange år, og har ingen større bekymringer med det.
Samme med ssh.

Du svarte ikke på spørsmålet mitt.

[sk0yern]

Fleskefjeset skrev (13 minutter siden):

Du svarte ikke på spørsmålet mitt.

Det er fordi "det kommer an på".
Dersom firmaet prosesser kredittkortbetalinger eller utvikler våpen, så nei, jeg ville aldri forsvart det for ledelsen.
Hvis det var et lite elektrikerfirma, der sjefen vil nå maskinen sin hjemmefra via rdp, så hadde jeg ikke hatt noen problemer med dette (igjen, gitt at man har et bra passord, og maskinen følger standard windows update patching).

[tommyb]

On 5/10/2020 at 3:32 PM, KGMK said:

Ja, men jeg skjønner jo ikke hva dere mener. Så dere mener at millioner av Windows Servere som har RDP åpen på default på 3389 er risky og unsafe? 

Ja.

 

Med ett ord: nulldagssårbarheter. Og da snakker jeg ikke om konseptet, men listen over historiske sårbarheter på akkurat RDP. Opp gjennom tiden har det vært 80 CVE-innslag (Common vulnerabilities and exposures) registrert relatert til RDP. Kilde: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RDP

Et eksempel er CVE2020-0610 fra januar. Her er Microsofts beskrivelse fra når de lagde en oppdatering til den: 
A remote code execution vulnerability exists in Windows Remote Desktop Gateway (RD Gateway) when an unauthenticated attacker connects to the target system using RDP and sends specially crafted requests. This vulnerability is pre-authentication and requires no user interaction. An attacker who successfully exploited this vulnerability could execute arbitrary code on the target system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

To exploit this vulnerability, an attacker would need to send a specially crafted request to the target systems RD Gateway via RDP.

The update addresses the vulnerability by correcting how RD Gateway handles connection requests.

For å beskrive dette eksemplet så betyr det at en angriper kunne kjøre kode på din maskin uten å måtte autentisere seg. Brukernavn og passord er derfor irrelevant. Men eksemplet i seg selv er ikke det du trenger bruke som beslutningsgrunnlag. Det du trenger bruke som beslutningsgrunnlag er at RDP er et spesielt interessant angrepspunkt, siden det er mye utbredt, gir brede tilganger og er på dårlige beskyttede maskiner. Videre at det - målbart og bevist - ofte og med jevnlige mellomrom ikke bare oppdages men faktisk utnyttes sikkerhetshull i RDP.

På toppen av dette kommer Microsofts tilbakelente patching syklus, med Patch Tuesday. Og selv når oppdateringen blir sluppet, blir den ikke lukket hos deg før du har installert patchen på din RDP-server. Det nevnte eksemplet ble registrert i november 2019 og oppdateringene kom midt i januar 2019. Det på en patch Microsoft klassifiserer som critical. 

Du trekker inn Linux. Men det er en vesentlig forskjell i _når_ nulldagerssårbarheter blir lappet på Linux og Windows. Det er en grunn til at vi alltid setter Windows-servere bak en brannmur. Du har en sikkerhetsmekanisme foran Windows-maskinen selv også (NAT, og det har i utgangspunktet kun en sikkerhetseffekt for IPv4), men den slår du hull i når du port-forwarder. Da tillater du trafikk fra hele verden til din RDP-port. 

Det du ønsker å gjøre kan sikres, men da må du sørge for at den trafikken som når Windows-maskinen faktisk er fra deg. Det kan du ikke gjøre i det grensesnittet du viste oss, og derfor er det anbefalt at du setter opp et VPN på ditt nettverk. Eier du en trådløsruter mellom modemruteren fra din ISP og ditt lokalnettverk, er det med høy sannsynlighet mulig å sette opp VPN der. Det er vanskeligere enn port forwarding, men mye tryggere.  

 

 

[tommyb]

2 hours ago, sk0yern said:

Jeg har eksponert rdp mot internett hjemme i mange år, og har ingen større bekymringer med det.
 

I eksemplet ovenfra fra 2019-11 til 2020-01-14 + din patchetid et kjent, kritisk, åpent sikkerhetshull som tillot eksterne brukere å kjøre kode på ditt nettverk, dersom du har et av operativsystemene berørt og altså ikke har satt opp VPN eller tilsvarende foran. At du hadde potensielt utnyttede sikkerhetshull betyr naturligvis ikke at du hadde noen bekymringer. Vil likevel ikke anbefale noen å sette Windows-maskiner rett på nett for der blir de angrepet.  

Passordstyrken er komplett irrelevant, problemet er at det tar opp mot to måneder før maskinen blir patcha fra sårbarheten blir oppdaget. 

Endret 15. mai 2020 av tommyb

[sk0yern]

tommyb skrev (31 minutter siden):

I eksemplet ovenfra fra 2019-11 til 2020-01-14 + din patchetid et kjent, kritisk, åpent sikkerhetshull som tillot eksterne brukere å kjøre kode på ditt nettverk, dersom du har et av operativsystemene berørt og altså ikke har satt opp VPN eller tilsvarende foran. At du hadde potensielt utnyttede sikkerhetshull betyr naturligvis ikke at du hadde noen bekymringer. Vil likevel ikke anbefale noen å sette Windows-maskiner rett på nett for der blir de angrepet.  

Passordstyrken er komplett irrelevant, problemet er at det tar opp mot to måneder før maskinen blir patcha fra sårbarheten blir oppdaget. 

Det ligger jo litt i CVE'en der, men den ble altså publisert i januar 2020, ikke november 2019.
Faktisk ble den publisert 14 januar 2020.
Jeg kikker i update history på maskinen min nå, og ser patchen ble installert ... 14 januar 2020.

 

[Gjest Sletttet+98134]

sk0yern skrev (58 minutter siden):

Det er fordi "det kommer an på".
Dersom firmaet prosesser kredittkortbetalinger eller utvikler våpen, så nei, jeg ville aldri forsvart det for ledelsen.
Hvis det var et lite elektrikerfirma, der sjefen vil nå maskinen sin hjemmefra via rdp, så hadde jeg ikke hatt noen problemer med dette (igjen, gitt at man har et bra passord, og maskinen følger standard windows update patching).

OK, så det er kun betalings- eller forsvarshemmeligheter det er verdt "bryet" å beskytte ved å ikke åpne for RDP for hele verden. Hvordan ville du startet forklaringen til elektrikerfirmaet at pga. åpen 3389 så har noen tatt over dataene deres? Noe sier meg at "Dere er bare et lite elektrikerfirma, dere driver ikke med betalingsløsninger eller våpen" ikke nødvendigvis blir så godt mottatt.

[sk0yern]

Fleskefjeset skrev (15 minutter siden):

OK, så det er kun betalings- eller forsvarshemmeligheter det er verdt "bryet" å beskytte ved å ikke åpne for RDP for hele verden. Hvordan ville du startet forklaringen til elektrikerfirmaet at pga. åpen 3389 så har noen tatt over dataene deres? Noe sier meg at "Dere er bare et lite elektrikerfirma, dere driver ikke med betalingsløsninger eller våpen" ikke nødvendigvis blir så godt mottatt.

Stikkordet er "trusselmodell"

James Mickens beskriver det godt:

Sitat

My point is that security people need to get their priorities straight. The "threat model" section of a security paper resembles the script for a telenovela that was written by a paranoid schizophrenic: there are elaborate narratives and grand conspiracy theories, and there are heroes and villains with fantastic (yet oddly constrained) powers that necessitate a grinding battle of emotional and technical attrition.

In the real world, threat models are much simpler (see Figure 1). Basically, you're either dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then you'll probably be fine if you pick a good password and don't respond to emails from [email protected].

If your adversary is the Mossad, YOU'RE GONNA DIE AND THERE'S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://. If the Mossad wants your data, they're going to use a drone to replace your cellphone with a piece of uranium that's shaped like a cellphone, and when you die of tumors filled with tumors, they're going to hold a press conference and say "It wasn't us" as they wear t-shirts that say "IT WAS DEFINITELY US," and then they're going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them.

In summary, https:// and two dollars will get you a bus ticket to nowhere. Also, SANTA CLAUS ISN'T REAL. When it rains, it pours.

Den største trusselen for rdp-tilgangen for elektrikerfirmat er typisk script kiddies som scanner etter rdp-servere som ikke er patchet, eller har enkle passord.
Dersom man har et godt passord, og gode patcherutiner, så er denne risikoen trolig såpass lav at de kan leve godt med det.

Endret 15. mai 2020 av sk0yern
formatering

[tommyb]

4 hours ago, sk0yern said:

Det ligger jo litt i CVE'en der, men den ble altså publisert i januar 2020, ikke november 2019.
Faktisk ble den publisert 14 januar 2020.
Jeg kikker i update history på maskinen min nå, og ser patchen ble installert ... 14 januar 2020.

 

Det er fordi den ble publisert når og fordi patchen var ferdig. CVEen for hullet ble opprettet 04. november.

Date Entry Created
20191104

Disclaimer: The entry creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

 

[sk0yern]

tommyb skrev (2 timer siden):

Det er fordi den ble publisert når og fordi patchen var ferdig. CVEen for hullet ble opprettet 04. november.

Date Entry Created
20191104

Disclaimer: The entry creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

 

Ikke sant.
Hvor mange exploits var det i sirkulasjon før den 14. januar, som utnyttet denne sårbarheten?