There are times when I must travel or even where I stay at my partner’s/friend’s place, but to be honest, I don’t sleep that much, so I like playing my videogames during night hours.
However, I don’t always take my gaming computer with me (TBH looks fancy as it is, ignore my poor cable management abilities).
My Rig
I remember the first security conference I participated in as a speaker. It was back in 2008.
A friend of mine asked me to help him fill up a space with a topic I was doing at that time, “Port Knocking”.
For those who are not that familiar with the term, Port Knocking is a stealth method to open ports that, by default, the firewall has closed. It works by having a daemon listening for connection attempts to certain closed firewall ports. When the correct sequence is received, the firewall opens the port for the specific IP address and a specific port to allow the connection. Obviously, Port Knocking must be used as a part of a security strategy and not as the only protection.
As a security enthusiast and a geek, I try to combine my passions. So, for a very long time I continued using Port Knocking (PK) for accessing my public servers. Some of those I have as honeypots for gathering Threat Intelligence; one was used to have a VPN service that allowed me to access those assets.
It was good… but a real pain in the rear; why? Well, first, the VPN management. I’m not that big, but from time to time, adding extra profiles, defining access, changing time to time the PK sequence… I had to create a python script that allowed me to dial the correct PK sequence before trying to open the VPN port and get a VPN connection to my internal endpoints. As you can read and see so far… many steps are involved to gather access. More importantly, it wasn’t secure enough because, in my current country, you’re always behind a NAT (even sometimes a NAT behind a NAT), so when my PK sequence opens the port… it’s open for many others.
Standard ISP (Basic Diagram)
Then I found OpenZiti. And I immediately fell in love with it, no more custom scripts, no more providing full access or inbound ports. And the best part, I do have the ability to design as I need it.
I am going to skip the installation and initial setup. So, it is assumed that you have the basic Ziti network setup and have ZAC in place to add access to systems, or at least you have the ziti CLI in place. If not, you can follow the QuickStart.
Ingredients:
- A fully deployed Ziti Network, with the CLI configured or ZAC in place to add access and create configurations. You can follow the QuickStart, if you don’t have it yet.
- Ziti Client installed on your Windows Gaming Machine.
- Ziti Client installed on your working computer (like in my case).
Let’s see how simple and secure this is:
1. Create the identity for the Hosting workstation. You can assign as many attributes as you want. Openziti works with an “attribute-enabled role-based access control (ARBAC) model. So, if you have used hashtags, you’re probably familiarized with it.
Creating the Identity
As you can see in the image above, we’re defining two attributes for this identity “GameDevice” and “WorkstationDevice”, those are definitions of what this device does for me. We will refer to one of these later.
2. Create or add the additional tags to the devices that will eventually have access to the game device.
Adding extra tags
Again, the attributes defined on this eventually will allow me to use service policies according to my needs. Noteably, we’re focusing on the one called “gameClient”. So that’s my way of defining this workstation works as my game client device.
3.With the identities in place, we need to create the service that will define the “how” we’re going to connect to our resources. That means creating a service with 2 configuration definitions:
a.) A ziti-tunneler-client configuration to intercept the traffic in the client and redirect it to the proper gaming workstation.
Creating a Service
There’re a few things to notice in the previous screenshot:
- We’re assigning to our service the name “DragonRDP”
- We’re assigning the attribute “gameRDP” to this service.
- Finally, this configuration will intercept all calls made to the host “dragon.natashell.ziti” via the TCP port “3389”. As you can see, this highlight one of the features I most love, private DNS, and this may be different for each client who needs it.
b.)A ziti-tunneler-server configuration, as we have installed a ziti client on our gaming device. Here we define how that client will connect to the IP /port we want to access.
Creating the Server Configuration
Again, let’s dissect what we have just done. We just created a server configuration saying the tunneler installed in the workstation/server will redirect the traffic internally to port 3389.
4. Now we need to authorize the services. The first identity we want to authorize is the ‘host’. We do this by defining a ‘Bind’ policy. A ‘bind’ policy allows us to define what identities can provide access to other identities on the OpenZiti overlay network.
Creating a Bind Policy
Looking at this closer, this policy authorizes the “Dragon” identity to provide any services which have the “gameRDP” attribute defined. Remember, OpenZiti is using ARBAC. If the value assigned here begins with a `#`, it will match attributes for the given type. If it starts with a `@`, it matches identities directly.
5. Finally, we need to authorize clients. A ‘dial’ policy allows us to define the identities permitted to access the matching services.
Creating a Dial Policy
If we take a closer look into this policy, we’re authorizing all devices/identities that have the attribute named “gameClient” to communicate with the services with the attribute “gameRDP”.
6.You can always review your current settings and see if everything is in place. You can go to the identity you’ll use to connect to the service and click on the service you want to test (for our purposes the “gameRDP” service).
Testing Using Ziti Control (ZAC)
You can also use OpenZiti CLI to review the policy created:
Testing Using the CLI
And we’re all set, we have successfully configured the connection to our game station and now we can RDP into it and enjoy some videogame entertainment.
Gaming on the Go
And there you go, in less than 5 minutes, OpenZiti allows us to connect to any service, any computer, any “edge” in an easy and incredibly secure way.
APPENDIX.
While this blog entry was to show you how easily you can solve a “geek” challenge, OpenZiti allows you to access anything anywhere in a secure way.Take a look at some of my personal examples:
1. I can manage my internal infrastructure deployed on my server using OpenStack, wherever I may be.
OpenStack access via ZITI
2. Access my Jupyter instance to start looking for any threats or start any investigation/remediation process.
Jupyter Access via ZITI
3. Access to my Sharing Information Platform to keep updated with the latest threats.
MISP Access via ZITI
And all that was done using a single OpenZiti service, which allows my own devices to have access to those assets.
Internal Service Access Configuration
Perfect SelfHosted Darkness!
