RDP byter klient: kvifor databasen ser ein annan vert

VPN-regelen din avviser databasen, og saka vert lukka som ein brannmurfeil, medan den same brukaren opnar eit publisert skrivebord og spør mot den databasen utan problem. Begge utsegnene er sanne. Skrivebordet er ein annan klient, med si eiga adresse på eit segment som reglane allereie stolar på, og med sin eigen identitet når det koplar vidare. Det som ser ut som ein motstridande regel, er som regel ein andre førespurnad som ingen la inn i gjennomgangen.

Den andre førespurnaden har si eiga klientadresse

Når eit program inne i økta opnar ei tilkopling til databasen, startar TCP-handtrykket på øktverten. Kjeldeadressa høyrer til nettet til den verten, så kvar ruter og databasen sin brannmur langs vegen vurderer segmentet til skrivebordet og ikkje tunnelbassenget den berbare datamaskina di kom frå. VPN-adressa dukkar aldri opp i den straumen. Difor kan ein avvisingsregel basert på kjelde vere både riktig og irrelevant samstundes.

Les opphavet frå inne i økta og ikkje frå den berbare datamaskina, og test deretter vegen vidare frå same stad. Dei to svara bør vere samde om kva vert som sender førespurnaden.

whoami
ipconfig /all
Test-NetConnection db01.corp.internal -Port 5432

Samanlikn det økta rapporterer med adressa databasen registrerte for same tidspunkt. Når serverloggen viser subnettet til skrivebordet i staden for tunnelbassenget, sluttar spørsmålet å vere om regelen slo til, og vert kva vert som sende førespurnaden. Det er ei anna gransking med ein annan eigar.

Identiteten endrar seg saman med adresseringa

Vidarekoplinga autentiserer seg vanlegvis som tokenet til økta, ein lagra legitimasjon eller ein tenestekonto for programmet, og ressursen registrerer det han fekk. Eit revisjonsspor som viser ein tenestekonto på databasen beviser difor ikkje at eit menneske køyrde spørjinga. Det identifiserer heller ikkje mennesket. Berre øktloggen til skrivebordet sjølv knyter dei to postane saman.

Autorisasjon skjer to gonger, og den andre avgjerda vert teken med andre inngangsverdiar. Den fyrste gjev ein namngjeven brukar pålogging til eit skrivebord, medan den andre gjev det tokenet til brukaren eller kontoen til programmet kan gjere mot ressursen. Ei helpdeskgruppe som kan opne eit skrivebord, er ikkje automatisk ei gruppe som kan lese ein kundetabell.

Sjå på tokenet og delegeringsvegen før du skriv tilgangsnotatet. Begge er synlege frå inne i økta, og det er den einaste staden der svaret ikkje er ei gissing.

whoami /groups
klist
query session

Viss programmet brukar ein tenestekonto, er det rettane til den som tel vidare. Rotasjon av den legitimasjonen høyrer i tilgangsgjennomgangen, ikkje i ein operativ ettertanke.

Kvifor den direkte vegen framleis er blokkert, og med rette

Avvisingsregelen er ikkje feil berre fordi målet kan nåast på ein annan måte. Segmentering vert vurdert per kjelde, og skrivebordet ligg på eit segment som vart tillate lenge før nokon tenkte på det som ein rute til databasen. Ingenting omgjekk policyen. Policyen skildrar ganske enkelt to ulike kjelder med to ulike utfall.

Det gjennomgangen må svare på, er kva kvar autorisert økt på den verten kan starte. Nettlesarar med lagra økter, tilkopla stasjonar, agentar som held legitimasjon og lokalt lyttande tenester utvidar alle rekkevidda til skrivebordet, og ingen av dei viser seg i saka som gav pålogginga. Den oversikta er den eigentlege løyveflata.

List dei opp frå inne i ei testøkt, ikkje frå eit rekneark. Nokre få kommandoar dekkjer det meste av flata.

Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
net use
Get-ChildItem Env: | Where-Object Name -match 'PROXY|DATABASE|API'

Vel grensa med vilje

Tre former passar til ulike oppgåver, og valet bør følgje oppgåva og ikkje verktøyet som tilfeldigvis finst. Eit publisert program viser eitt program med eigne løyve, eit fullt skrivebord viser alt brukarprofilen kan gjere, og ein avgrensa databasekonto med kjeldeavgrensing viser éin ressurs heilt utan skrivebord. Den smalaste forma som framleis fullfører arbeidet, er den som skal dokumenterast. Alt breiare treng ein grunn skriven ved sida av.

For éin rapport er eit publisert program eller ein avgrensa konto ei mindre tildeling enn eit generelt skrivebord. For vedlikehald som verkeleg treng fleire verktøy, kan skrivebordet vere riktig, men då skildrar godkjenninga heile verten og ikkje eitt program. Spør ressurseigaren kva av dei dei seier ja til.

Dataflytting er ein eigen brytar. Utklippstavle, stasjonsomdirigering og nedlastingar kan føre bedriftsdata til klienten, og det å køyre eit program eksternt held ikkje data eksternt av seg sjølv.

Kontroller begge godkjenningane og fjerningsvegen

To godkjenningar høyrer i posten: retten til å nå og opne skrivebordet, og retten til å bruke ressursar frå innsida. Namngje ein eigar for kvar av dei og hald den andre synleg for den som går gjennom ressursen. Det er den andre posten ein revisor vil spørje om, fordi han skildrar rekkevidd og ikkje inngang. Skriv begge før endringa vert godkjend, ikkje etter den fyrste hendinga.

Test deretter fjerninga, fordi ei fråkopla økt kan overleve grunnen til at ho finst. Økttabellen er den snøggaste staden å sjå kva som framleis køyrer.

query session
query user
qwinsta /server:rdsh01.corp.internal

Fråkopling av klienten lèt fjernøkta halde fram med å køyre, og nettverkstilkoplingane og dei hurtiglagra legitimasjonane kan halde fram med å vere brukande til den økta sluttar. Logg ut, eller avslutt økta eksplisitt, og stadfest at teljaren lenger nede sluttar å flytte seg etterpå. Ein fjerneringstest som berre lukkar loket på den berbare datamaskina, beviser ingenting. Køyr den same testen éin gong med deaktivert konto og éin gong med fjerna skrivebordsløyve, og noter deretter kva ressursen loggførte i kvart tilfelle.