- Enable AppLocker on Windows 10 Pro and Windows 11 Pro with PowerShell - Thu, Jun 30 2022
- Restore BitLocker-encrypted drives from image backup - Thu, May 19 2022
- When the trust relationship between a workstation and the primary AD domain fails - Wed, May 18 2022
For decades, software developers have assumed that client machines are online at all times. Users are online at home and at work—being able to look up and exchange information, 24/7, is taken for granted. The fact that any Internet connection bears some risks is usually accepted, since there seems to be no alternative in the modern world.
I work for a company that has always required keeping computers disconnected from the Internet for security reasons. As you can imagine, at least web browsing must be made possible.
The solution is to work with a Windows Server with Remote Desktop Services that is allowed online. Users may connect to it and browse from there, so they only see the graphical output of the browser as part of a remote session, leaving their own machine disconnected from the public Internet.
This concept is simple, yet not widely known. It is called a remote-controlled browser system (ReCoBS). Google the term ReCoBS, and you'll find that it originated possibly in Germany, as described by a federal agency for information safety (BSI) in 2006. Our company has been using it for about 20 years, starting back in the day with a Linux machine as a browser system. Over the years, we have switched to a Windows Server and use a seamless browser window, AKA browsing via RemoteApp.
The concept I describe will not be suitable for just anyone, so I will start by determining who should consider it.
ReCoBS shortcomings
First, imagine simply cutting the Internet at your users' endpoint machines. Email would continue to come in and go out as long as you are using an on-premises mail server that still has the Internet. The same applies to all Internet services that are relayed through an on-premises server.
But what about applications that need Internet access to access remote services in the cloud? This includes Internet cloud storage and connections to software license servers. Apps would need to be patched and updated using a LAN-based patch server from now on, since these apps would not be able to retrieve updates from the Internet anymore. In addition, remote control solutions like Team Viewer that you might be using to get product help from manufacturer support teams could not be used anymore at your endpoints, at least not directly.
Working with ReCoBS is only a solution for your corporate network if your environment's productivity is not negatively affected by these limitations.
Setting up safe browsing with ReCoBS
To build a safe browsing experience using a ReCoBS environment, you need a Windows Server with remote Remote Desktop Session Host (RD Session Host). I recommend working with Windows Server 2022. Of course, you will also need Remote Desktop CALs.
The Remote Desktop Server role can be installed in two different ways: session-based or VM-based. The latter is more secure, but requires Windows enterprise licensing (software assurance). If you lack enterprise licenses, this will have to be session-based. In this article, I will take a closer look at the session-based option.
The server can be physical or virtual and would need to be considerably strong, since browsing consumes significant resources. To give you an idea, our solution (session-based) is sometimes used by 40 users at the same time, so we need 12 CPU cores and 32 GBs of RAM. This might not suffice for power users who keep many tabs open and need to watch video tutorials online regularly. However, for the standard user, let us roughly assume that we need to provide 1 GB of RAM per user and at least one CPU core for every three users.
Your server can be Active Directory domain-joined, so you can use GPOs to manage your server centrally. However, if you're using RDP, single sign-on using domain accounts poses a serious security risk. If you have a session-based machine, then all users share the same system. If this system is compromised, all accounts are at risk of being targeted by Mimikatz and the like. Thus, for maximum security, I recommend not working with domain accounts and instead using local server accounts.
There is one drawback if you set it up that way: RDS CAL licensing. Microsoft allows the use of RDS user CALs only for domain users. Taking local users means you have to buy device CALs, which, if your environment holds more devices than users, could mean that your costs will increase a little.
The rest of the deployment is simple: install your favorite browser on the server (for this article, I will simply assume you will be using the built-in Microsoft Edge 64 bit) and deploy it as a RemoteApp.
RemoteApp and Desktop Connection as seen from the Edge browser
Now, when users visit the site https://yourTS.yourdom/rdweb with the (local) Edge browser and click the published (remote) Edge browser icon, they will be served an RDP file, which they may save to their desktop. They connect to a remote session and save the credentials of their personal local user, and the remote browser opens. It works and looks just like a local browser, but it needs no local online connection at the endpoint. The performance is good; you may even watch HD videos without any lags and without having to invest in special graphic adapters on the server.
Improved security of ReCoBS
Not only did you just make your endpoint machines safer by giving up local Internet access, but you also improved the security of web browsing itself.
Having a dedicated server for browsing allows the server admin to reduce the functionality of that server to "browsing only." That simply means the admin will be able to use application whitelist (AppLocker) rules with no trouble at all. You only allow the execution of the browser, and the rest remains forbidden. This defensive measure is also already built in, by the way.
Application whitelisting is superior to security provided by antivirus products by far, as it requires no definitions or behavior analysis. All drive-by infections will at some point try to start a malicious process, which will not be allowed to run.
In addition, imagine how easily this server could be isolated with a firewall. Inbound, it just needs to be accessible by RDP, and outbound, the server only needs access to your proxy server or router. Thus, you can isolate the server from all valuable company data.
Because RemoteApp by default allows you to redirect local drives to the server, this will, of course, need to be disabled. This is shown in the session collection options in the following screenshot:
QuickSessionCollection Properties Disable the redirection of drives
Even if attackers got past AppLocker, they would have nothing to attack. There is no work data saved locally, and they see only local accounts. Hence, not even domain credentials could be harvested.
But, alas, this perfect world scenario is based on the assumption that you only need a browser for browsing—not for downloads. As soon as you want to transfer your downloads from the server to your personal system, you will have to build some sort of bridge. Fortunately, this is easily achieved by allowing SMB traffic and sharing the server's download folder in read-only mode. This means that clients can read the downloads but cannot write to that folder, not even accidentally; this implies that data leakage is effectively prevented.
Subscribe to 4sysops newsletter!
Conclusion
As I have shown, ReCoBS is an effective way to deploy safe browsing and minimize the endpoint attack surface at little cost and effort. Completing a test setup took me less than one hour, and it does not require any licenses. If your endpoints need the Internet for browsing only, you should give it a try.
Neat concept. I’ve thought of implementing something like this before, but didn’t know this was a ‘known’ thing to do. Now, I’m even less hesitant to try it.
I don’t understand your conclusion:
+++
As I have shown, ReCoBS is an effective way to deploy safe browsing and minimize the endpoint attack surface at little cost and effort. Completing a test setup took me less than one hour, and it does not require any licenses.
+++
There are costs for RDP-licenses on the server as you wrote earlier:
+++
There is one drawback if you set it up that way: RDS CAL licensing.
+++
Richard, you quote me writing “at little cost” and later “there are costs” – and seem to feel those are contradictory statements. The costs for those licenses are small, compared to their benefit, if you ask me.
I don’t express “there are no costs”. Maybe you misunderstand when I encourage readers to try this out by writing that setting up a lab requires less than one hour and costs nothing (since the server trial setup allows for several months of free usage, local and RDP.).