My TLDR version of Zero Trust Computing/Networking
Zero Trust Computing/Networking to me means that you have to assume all end points are directly exposed to the internet and all of their services/ports/exchanges say, “Hey, we are open but refer to the control plane (layered control systems) to access our data plane but you need to verify x amount of information that is dependent on multiple semi-dislike but aligned factors that put together, are hard to reproduce”. All fellow nodes or hosting infrastructures are assumed to be compromised but regardless of how ‘secure’ the zero trust system is, if humans need to interact with it, there will be ways to exploit it. Strong and reasonable cryptography (considering computing power and what information is at stake) along with mitigating low level speculative processing exploits will be of utmost importance and telemetry/diagnostics will become harder to use unless given cascading but potentially tiered/layered permissions.
( “7 principles of zero trust security model“, is a good and short read as well.)
Elliptic Curve Cryptography Overview ( F5 DevCentral )
(https://www.youtube.com/watch?v=dCvB-mhkT0w)
SSH Client as a Quick and Dirty Port Scanner
Since the ssh client is pretty ubiquitous and has been included with Windows 10 installations for the past couple years, I’ve discovered it can be a useful tcp port scanner if you use the verbose flag:
For Windows:
ssh -p 80 google.com -v 2>&1 | findstr Connect
ssh -p 80 -o ConnectTimeout=1 www.google.com -v 2>&1 | findstr Connect
debug1: Connecting to www.google.com [142.250.191.228] port 80.
debug1: Connection established.
kex_exchange_identification: Connection closed by remote host
As for your *nix systems, just use grep instead of findstr. I hope someone else finds this useful!
Domain Controller/Active directory over Meraki VPN fix
If you have a Meraki setup that has Umbrella tied into it, and you can’t communicate properly with your *.local domain controller over the Meraki VPN, I have a potential fix for you. In my scenario, VPN clients could see the domain controllers and DC IP addresses were specified as DNS servers which would properly assigned to VPN clients. VPN clients could query DCs for external DNS names without any issues but any *.local communications or gpupdate related commands would fail. I troubleshooted it to the nth degree and discovered this fix:
Go to Security & SD-WAN, then to configure, and then to threat protection. Scroll down to the Umbrella protection section and specify your local domain name (mydomain.local) as an exception from being routed to Umbrella. Save your changes and hopefully this resolves your issue.
If you continue to have issues, double check that your VPN clients and see what DNS servers are getting assigned. Some individuals had to change the metric (hint lower the number, route print to find metrics of adapters).