How do you currently secure RDP admin access to servers?
Posted by squishmike@reddit | sysadmin | View on Reddit | 74 comments
I'm currently trying to revamp our administrative / privileged access at my company. We're a hybrid Windows shop with half on-prem half cloud. For server access, there seems to be many different ways to skin the cat on this one so I'm looking to see what other folks are doing with regards to this. Mabye there's a new and better way that I'm not aware of.
This is all of course assuming the separation of a standard regular account, where admins are logging into servers etc. using a different privileged account.
Things I've seen / tried in the past:
- Use a tool like Crowdstrike Identity or similar to throw MFA in front of RDP sessions. Admins can RDP from anywhere given that they are identified via MFA/conditional access. Additional identification can be attached to the network traffic as well (identification based firewall rules).
- Use a broker system like Beyond Trust, Delinea or similar where RDP sessions are administrered and accessed through a cloud service and then the RDP traffic funnelled through specific broker servers. RDP traffic is restricted to only being from the few broker boxes. This is likely quite secure (as far as you can trust the provider) but proven to be very cumbersome for administrators. At least in implementations I've seen/been a part of.
- Use secured jump servers. You can only RDP to other servers from these central jump server hosts (either running RDS or similar VDI) which are behind conditional access / identity & MFA. RDP to all other servers is restricted at the network layer.
- Yubikeys or some other hardware based token instead of app-based MFA. I've personally tried this in the past and it was both cumbersome and non-universal. The login would sometimes work with Yubikeys, either with the cert loaded on the key or using the 'tap to enter your password' functionality. But for other odd things / admin portals, it would not support Yubikey/certificates. I like the idea but it's not universally compatible yet.
- Other forms of 'passwordless'...?
Personally I'm a fan of Crowdstrike's MFA Identity implementation because you can also use that for MFA'ing to a myriad of other important things on the internal network, granting east-west protection (e.g. VMWare console, or any web-based admin console that is AD auth based).
But I'm very aware there could be other options I'm simply not aware of that might be better, or offer more balance in terms of security vs. convenience.
SpotlessCheetah@reddit
MFA in front of RDP only solves RDP. Does not solve back end controls.
Tech88Tron@reddit
Soooooooo.....how to solve back end controls?
menace323@reddit
Get a MFA solution that protects all types of logins, including Powershell remoting.
null_frame@reddit
What is an example of this solution? We implemented Duo but I quickly realized that it doesn’t protect every type of login.
menace323@reddit
Authlite for cheaper, Silverfort if you have a bigger budget.
Both can trigger for any kind of authentication.
trail-g62Bim@reddit
I honestly did not know there was mfa available for psremoting.
menace323@reddit
Both Authlite and Silverfort have agents (Silverfort call it and adapter - but it’s an agent) that run on the domain controller, as well as the endpoints.
For psremoting, Silverfort actually intercepts any outbound Active Directory approved auth. If you can’t complete the Silverfort MFA, it never releases that auth and your sign in /psremoting just times out.
What that also means is that it can work for any AD auth of any kind, from anywhere and for any legacy app.
Do note for what I described only supports tap to approve. TOTP is supported, but controls for endpoints with the agent and can’t protect psremoting.
trail-g62Bim@reddit
Thanks for the info!
null_frame@reddit
This is why I love Reddit. Thank you!
Shedding@reddit
Group policies and shut down things like right clicking, copying, file Explorer view and command prompt.
jlipschitz@reddit
Set the firewall to only allow specific ports for required services. Disable all unused services. Disable remote registry.
CombJelliesAreCool@reddit
Shut down the server. Intersection of security and availability, ya know? Focus solely on security. Its in the job title, it's Cyber Security, not Cyber Accessibility.
squishmike@reddit (OP)
Can you elaborate on what you mean by back end controls?
chubz736@reddit
This post is wild. Pretty much saying you can obtain credential by rdp into servers.
squishmike@reddit (OP)
Hmm, how did you come to that conclusion exactly..?
chubz736@reddit
Eh i over think
narcissisadmin@reddit
Start the problem where it starts: how often is admin RDP access actually necessary?
squishmike@reddit (OP)
Fairly often for accessing the servers but unlikely actual admin is required is very often, indeed.
_BoNgRiPPeR_420@reddit
PAWs. You should use them for remote access to everything on its own management VLAN - servers, storage appliances, firewall management interfaces, switches, you name it.
By not exposing management interfaces to all end user devices on the network, you drastically lower your attack surface. Use GPO to update the allowed IPs for RDP/WinRM/etc.
miyo360@reddit
How do servers on a management vlan work if they are user-facing, eg file server? Would you configure two vNIC’s per user-facing server, each connected to a different vlan? Thanks.
_BoNgRiPPeR_420@reddit
I've seen both ways in production. Multiple NICs with only 1 having a default gateway is one way. I also commonly see just one NIC, but everything is firewalled off except the necessary service ports to employees (in this case tcp/445). Then the PAW has a firewall exception for 3389 and everything else.
ErikTheEngineer@reddit
Didn't Microsoft kill all the guidance for PAW/AD hardening? I know they used to have it but they're trying to get everyone off AD and onto Azure.
_BoNgRiPPeR_420@reddit
They still seem to recommend it a lot, but you're right, it is buried in a bit of Azure/Entra marketing these days:
https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-deployment
TechOfTheHill@reddit
We're still figuring out how to implement PAWs, so I apologize if I'm still a little confused on how they work. If I'm remote, I don't have access to the PAW as it is segmented off from the rest of the network and is the only device that can make network configuration changes. So the only way I can make changes, updates, or configuration fixes is to be onsite in front of the PAW?
_BoNgRiPPeR_420@reddit
There are a couple ways to implement them but they do not need to be air gapped, some places will just do a VM with one leg in multiple subnets (this is how we do it). The PAW VMs only have the RDP port open in the firewall and the only allowed IPs for RDP are the IT team. In the office, IT has its own VLAN, and on VPN we are handed static addresses as well.
jstuart-tech@reddit
This is the only correct answer in this thread. Normal RDP is still vulnerable to PtH attacks. RestrictedAdmin and RCG both have their own limitations
https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard?tabs=intune#compare-remote-credential-guard-with-other-connection-options
h00ty@reddit
From inside the buildings MFA with Duo to log into a server. Out side the buildings Duo to log into vpn then Duo again to log into the server.
nostradamefrus@reddit
disclosure5@reddit
As usual, I'll point out that "RDP access to servers" is just one of many ways to access a server and these various "MFA on RDP" solutions ignore what the majority of threat actors actually utilise.
BlackV@reddit
Explain more please I'm interested
disclosure5@reddit
I have worked security in more than my share of businesses where I obtain a credential or even just an NTLM hash, and the default is any of these things:
And someone smugly points out the credential obtained was useless, because they have a sold a DUO connector on the RDP service.
chubz736@reddit
What you do to secure endpoint when doing these task
evil-winrm Enter-PSSession \server\c$ impacket-secretsdump.py Using gpmc.msc on my own machine and deploying policies
Im really interested whats best practice since this is rarely mention
lurkerfox@reddit
disabling powershell remoting, not sharing C drives, dont have domain admin logging into every random workstation, basic common sense stuff.
trail-g62Bim@reddit
Is disabling powershell remoting common? What do people do to replace it? Logon to each server individually?
BlackV@reddit
ah right so you're saying hackers are nut using RDP to make the connections to computers (or its one off type scenarios)
RichardJimmy48@reddit
Hackers never use RDP. They don't need it and it's too high visibility.
_DoogieLion@reddit
Definitely wouldn’t say never, have seen multiple real world attacks where the threat actor used RDP
disclosure5@reddit
That's generally correct yes. Of course they might choose to, but it's not usually the path of least resistance. It's worth reading the write ups on thedfirreport.com, I barely ever see RDP used.
I'll also note that if you obtain a password NTLM hash, and not a password (which is quite common in many situations), you can use it with basically everything but RDP, so it's the one option ruled out by default.
feldrim@reddit
I don't get it. Would you please clarify?
BlackV@reddit
Appreciate the info
lurkerfox@reddit
I just wanna second in here that youre completely correct.
RDP is so incredibly low on the priority list for malicious remote access(not withstanding consumer tech support scams, but thats a completely different topic) that it will be the last option taken unless it was for some reason literally the only way to reach their target.
Pretty much the only thing that changes the math here is if its being exposed to public internet for some godsforsaken reason. And thats just because an easy win is never frowned upon.
SmiteHorn@reddit
Yes please elaborate, currently our RDP is open besides a domain admin password. I would like to lock it down with Okta MFA but if there is something better and not overly cumbersome I would like to know!
RichardJimmy48@reddit
Please tell me you're not RDP'ing into anything other than a domain controller with a domain admin.
SmiteHorn@reddit
Just DCs and a file server
vane1978@reddit
You may want to setup RDP over IPSec to secure your Domain Admin credentials when connecting to your servers - via RDP. This can mitigate BlueKeep. Even though BlueKeep is an old vulnerability back in 2019, setting up RDP over IPSec mitigate potential similar vulnerabilities.
SmiteHorn@reddit
Thank you for this insight! Digging into it now
vane1978@reddit
You want to protect your critical credentials when connecting to your servers such as Domain Admin. Lookup ‘RDP over IPSec.
jstuart-tech@reddit
That's not really doing anything as RDP is already encrypted, It's good for locking down which computers can specifically access it, but it's a bit of a pain in the ass and there are better ways (e.g. PAW)
vane1978@reddit
You got this all wrong. RDP over IPSec is just not limiting access to predefined endpoints, it also encrypting the transport layer.
RDP encrypts the application payload only: User Inputs Display Clipboard
RDP over IPSec encrypts the entire IP payload:
TCP/UDP headers Source and destination ports (e.g., TCP port 3389 ) Sequence numbers and other transport-layer metadata.
My understanding this is achieved using ESP, which encrypts everything in the IP packet except the outer IP header that is necessary for routers forward packets to the destination.
This IPSec method is not restricted to RDP protocols. This can also be used for other protocols such as
WinRM WMI SMB etc
BatemansChainsaw@reddit
To solve that issue we don't do rdp. Administrative logins are through rsat/mmc, windows admin center, and designated roles for each task.
RichardJimmy48@reddit
We have a dedicated RDP account for each server in Delinea, and require a secret be 'checked out', and require the RDP session be proxied through Delinea's server, and when you're done the password gets rotated automatically. We try to avoid at all costs accounts that have local admin on more than one endpoint. We also have a lot of ACLs restricting where RDP connections are allowed to come from.
I don't like those MFA tools, since they're usually only good for RDP. That's a nice checkbox for the auditors, but in reality it does nothing for your security posture. All it takes is an attacker getting access to one server and filling up the disk, an admin RDP's in to investigate, they pull the password from LSASS, and now they have local admin on every endpoint and can do as they see fit with PSRP.
arn0789@reddit
This is interesting. I'm assuming the "checkout" is the audit trail for the shared rdp account?
RichardJimmy48@reddit
Yes. There's always an audit trail of who has viewed the password, but the checkout adds an additional layer of audit by ensuring that only one person can be using that RDP account at a time, and then rotates the password before someone else can use it again. So if the account is used during the checkout window, you can be very confident that the person who 'checked it out' is the one who performed the action.
We also require an approval before allowing checkout for our most important assets, but that's more of a change-control/process thing than a security thing. It should also go without saying that we require MFA in order to log into Delinea.
BigBobFro@reddit
Crowdstrike has a number “secret sauce” things they do and based on their disaster earlier this year where they killed fundamental access to systems, no thanks bro.
roiki11@reddit
I've been recently trialing teleport for that. But I don't really use rdp.
RatsOnCocaine69@reddit
You also used to be able to secure connections with TLS certs, don't know if you still can. Moving off the default port (3389) can also help.
MDL1983@reddit
MFA for RDP sessions is less than half the battle. Check out AuthLite for MFA, it's cheaper than a service like Duo, even offers a perpetual license, and does so much more to secure your Domain.
SilverFort is the big product, expensive, but then they do take their staff to on holiday abroad for a week so they have that to pay for.
aprimeproblem@reddit
IPSec the management ports towards your PAWs
g-nice4liief@reddit
https://www.paloaltonetworks.com/blog/2021/07/diagnosing-the-ransomware-deployment-protocol/
https://bullwall.com/how-has-rdp-become-a-ransomware-gateway/
Just my 2 cents.
YourMumsITGuy@reddit
I'm utilizing Beyond Trust PRA with clustered jump points to allow for updates to be scheduled regularly.
jlipschitz@reddit
Crowdstrike require MFA for RDP connections
Affectionate-Cat-975@reddit
Have duo in place for local login access based on the account
Geocacher62@reddit
You didn't say where your cloud servers are located but here is my setup. RDP access to my AWS servers is through CloudConnexa VPN with Entra SSO auth, Yubikey security key is the only MFA option, and the only IP address allowed RDP access through the security groups is the IP for CloudConnexa. Seems pretty secure to me. If you don't have an enrolled Yubikey you don't get into my AWS instances.
TxJprs@reddit
Why not put admins in protected users group?
hihcadore@reddit
Limit RDP access. You don’t really need to RDP for many admin tasks anyway. We use a protected admin workstation and either psremote or use the RSAT tools to make changes.
For other servers where we may need or want to RDP we use a server admin account that only has access to those servers.
artekau@reddit
Cyberark
myrianthi@reddit
Use an RMM to access the servers. Duo and remote desktop gateway or azure proxy for end users.
anonpf@reddit
Role based vlan access
stacksmasher@reddit
Yes.
BlackV@reddit
We're very low brow
Have a managment VM, logging in with "admin" account, AD groups grant RDP access and grant Admin access where needed
optimuspryma@reddit
Same here. Admin access via AD based “role” groups
Guilty_Spray_6035@reddit
We have Citrix terminal servers where we expose RDP client as a published application. Only Citrix servers can connect to RDP port on the others, otherwise RDP is firewalled off. Each person who needs non-privileged access has their own account. Smart card and password are used for authentication - such accounts can typically trigger a few minor things but not change anything requiring UAC privilege escalation. Privileged user access is done through CyberArk, you can retrieve the credential after you've opened a change or an incident in the ITSM tool, and it was approved by another human or auto-approved depending on system classification. After change is done, CyberArk automatically changes privileged user password.
SnooDucks5078@reddit
Small operation, I use DUO
WestDrop3537@reddit
Mfa with yubikey