RDP-sessies overnemen; Riskant?

[Ulysses]

Voor ik dit onderwerp tikte heb ik gezocht op "rdp sessie" en "rdp sessie overnemen" in dit subforum, zonder resultaat. Verder heb ik even door technet gebladerd, maar ook daar kon ik niet snel het exacte antwoord vinden.

Op mijn werk is er een omgeving van ThinClients welke via RDP verbinden met een Terminal Server. Dit is in Win2k8 R2 omgeving en op zich werkt het allemaal prima.
Laatst echter kwam ik tot de ontdekking dat het mogelijk is om iemand anders uit zijn sessie te duwen. (N.B. mits je het wachtwoord van de andere account hebt)
Ik heb hiervoor toen een intern ticket aangemaakt met de opmerking dat mij dat een ongewenste feature lijkt. Van de externe partij die het netwerkbeheer verzorgt, kreeg ik het antwoord dat het een gecompliceerd issue was om op te lossen en wel om de volgende reden:

• Een fors aantal gebruikers laat zijn sessie open en zet alleen de Thin-Client uit (Hiervoor is dan wel bedacht dat sessies na 2 uur vervallen)
• Er zijn mensen die van locatie binnen of buiten wisselen, en wanneer die mensen hun sessie niet goed afsluiten en vervolgens proberen in te loggen, zou dat niet mogelijk zijn wanneer het door mij gesignaleerde feature van RDP dichtgetimmerd wordt.
• Mensen die niet in hun account kunnen omdat de sessie nog open hangt zijn aangewezen op de externe netwerkbeheerders om hun sessie te laten beëindigen. De beheerders hebben echter wel wat beters te doen dan halve dagen te spenderen met het afschieten van verlaten sessies.

Nu is het op dit moment nog zo dat er maar een paar accounts zijn die een algemeen bekend wachtwoord hebben. Ook gaat het niet om een heel grote organisatie. Dus ik zag zelf ook al wel in dat het "potentiële aanval oppervlak" zeer gering is.

Mijn argumentering om er toch een ticket voor aan te maken was, dat het mogelijk is voor de mensen die met een niet persoonlijke account inloggen maar met een algemeen account, om elkaar van het netwerk te duwen, de sessie over te nemen en zo verder te gaan waar de vorige fysieke persoon die het account gebruikte gebleven was. Als hier dus (privé) webmail o.i.d. open staat, of noem maar een toepassing waarvoor persoonlijke gegevens gebruikt worden, kan deze informatie door iemand anders gezien/gewijzigd/etc. worden. Echter, als we het breder trekken, en iemand van buitenaf weet een login te bemachtigen, dan is er al een meer zorgelijke situatie. Vooral als het een login betreft van iemand die wel bij alle netwerk-bronnen kan. Op een aantal netwerk-bronnen staat wel degelijk bedrijf kritische informatie.

Toch geboeid door deze constructie van hoe RDP blijkbaar werkt, heb ik de volgende vragen:

• Hoe groot is het risico dat er misbruik van gemaakt kan en gaat worden?
• Is het mogelijk om op andere wijze RDP dicht te timmeren voor meerdere sessies van andere locaties zonder dat het lock-out probleem optreedt voor de medewerkers die wel legitiem ergens anders hun sessie weer oppikken?

Het lijkt inderdaad een niet te voorkomen bijkomstigheid van hoe het netwerk is ingericht, waarbij de voordelen in bruikbaarheid zwaarder wegen dan de potentie dat iemand er misbruik van maakt.

Het enige dat ik zelf tot nu toe heb kunnen bedenken is dat er actief geïnvesteerd kan worden in kennis over te brengen naar alle medewerkers over hoe correct hun sessies af te sluiten e.d. Rest alleen nog de enkele sessie die gewoon vast loopt waarna er een lock-out op treedt als de policy dan alsnog wordt om multiple login niet mogelijk te maken.

Terwijl ik dit typ herinner ik me een mogelijke oplossing welke ik al eerder eens heb voorgedragen, en dat is dat mensen met tokens gaan werken om aan te melden. Dit plan heeft het echter niet gehaald, aangezien ik niet voor De Nederlandsche Bank o.i.d. werk. Eigenlijk is de hele bedrijfscultuur zeer open en transparant, en alleen ik verzin dit soort (tegen het paranoïde aan) potentiële dreigingen/maatregelen. Overigens is het wel zo dat we o.a. persoonsgegevens verwerken, dus dat het niet een compleet onzinnig vraagstuk is.

[LauPro]

De oplossing lijkt mij gewoon om die algemene accounts te sluiten en een streng wachtwoordbeleid in te voeren. Dan heb je geen gedeelde wachtwoorden etc meer.

[MAX3400]

Tokens & algemeen account -> zelfde situatie.

Men moet intern gewoon de algemene accounts afzinken. En zeker het uitwisselen van credentials van named accounts. Ben je van het hele gedoe af. Niet in de laatste plaats als er in een week 16x met dat account wordt ingelogd door 5 afwisselende medewerkers en volgende komt men erachter dat dat account is gebruikt om bedrijfsgeheimen te lekken/kopieren, wie moet je dan op het matje roepen?

Verder vraag ik me af of het wenselijk is dat thin clients maar worden uitgezet en de sessie open blijft staan. Er is veel voor te zeggen om het wel te doen maar in sommige gevallen (afhankelijk van de controle op de sessie), kan je nooit meer thuis inloggen omdat de "open sessie" op clientnaam is geregistreerd en dan bouw je thuis dus een nieuwe sessie op.

[leuk_he]

Je geeft zelf al aan dat hier een goede wachtwoord policy gewoon belangrijk is.

Deel van de probelemn kan gewoon geapkt worden door te monitoren. Delen mensen welrkelijk een account? kan daar niet beter gewoon een account voor worden bijgemaakt. Laten mensen hun account idlen? hebben curusus afloggen nodig blijkbaar of defecte hardware?

Enige opvallende vind ik "(privé) webmail oid", draaien internet sessies dan niet in een aparte sessie?


jouw vragen
1. Risico: 80% (wat dacht je nou zelf, ...)
2. Remote met token werken(via vpn..), lokaal met password?

[ Voor 8% gewijzigd door leuk_he op 03-05-2011 13:11 ]

[Tsurany]

Gewoon prive accounts invoeren, ben je direct overal vanaf en verhoog je de veiligheid aanzienlijk.

[ralpje]

Als je op een algemeen account met privé-zaken bezig bent doe je sowieso al iets niet goed, natuurlijk.
Met de rest hierboven, dus.

[swbr]

Eens met wat er al gezegd is. Zolang er gedeelde accounts zijn kun je allerlei technische hindernissen opwerpen, maar veiliger wordt het daar niet van.

Mag ik vragen wat jouw functie is binnen het bedrijf? Ben je van IT, of ben je een bezorgde werknemer?

[Ulysses]

Bedankt voor de reacties dusver.

De algemene accounts zijn er omdat we deels een pay-per-user model hebben, elke extra account loopt dus fors in de papieren. Voor een vrijwilliger die 1x per week een paar uurtjes met de IT-faciliteiten moet werken, loont het dus niet om een eigen account aan te maken.

Dat het technisch gezien niet het meest handige is, was mij inderdaad ook wel duidelijk. Helaas is ICT een faciliteit en niet het product van de organisatie, anders zouden de aanbestedingen ook anders gedaan worden natuurlijk.

Ik ben stagiair/vrijwilliger voor deze organisatie in het kader van een opleiding tot Microsoft Certified IT Professional Enterprise Administrator.

Dat mensen privé dingen doen op het bedrijfsnetwerk is niet iets wat je kan of wil verbieden. Zolang dit niet de voornaamste bezigheid is van iemand binnen de organisatie, is dit ook geen probleem.

[ Voor 12% gewijzigd door Ulysses op 04-05-2011 10:49 ]

[MAX3400]

Hint: als je aan het opleiden bent tot MCITP, zijn er mogelijk andere/belangrijker issues in het faciliteitsgedeelte van de ICT-omgeving waar je beter je licht op kan laten schijnen.

Ik snap dat pay-per-user een vaakgebruikt model is voor kleinere organisaties om kosten te drukken maar je bekijkt het nu, terecht, vanuit een technische hoek. Heb je dit topic al laten lezen aan de financieel directeur of het algemeen opperhoofd? Die zullen vast een andere kijk hebben op de materie (kosten, risico, handigheid etc) en mogelijk geven zij je een idee om je kennis en ervaring aan te wenden voor een goede opdracht om een structurele wijziging te gaan opstellen?