I think I can pinpoint the issue a bit.
My server hostname is not reachable from my Mac, so I ended up using the public IP address. I guess I’ll have to use the public domain in order for the client to be able to reach it…
all these
[2022-09-29T14:19:12.085Z] ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
are troubling. it's as though the client machine cannot attach to the edge router. ...
My server hostname is not reachable from my Mac
i was just typing that
THIS might be your next issue fwiw. When you run the quickstart, if it didn't use the external IP when enrolling, your cert will not be valid. So if you run into a problem now - it might be due to that.
Haha okay. Thanks and absolutely makes sense.
I’ll start over once again, but I think I’m getting there slowly
I’d ask you to run this command to see if you’ll have a problem.
host_and_port=ec2-18-188-201-183.us-east-2.compute.amazonaws.com:8442
openssl s_client -connect $host_and_port 2>/dev/null | openssl x509 -text 2>/dev/null | grep -a1 "Subject Alternative Name"
X509v3 Subject Alternative Name:
DNS:ip-172-31-42-64, DNS:localhost, DNS:ec2-18-188-201-183.us-east-2.compute.amazonaws.com, IP Address:127.0.0.1, IP Address:18.188.201.183
see how my EXTERNAL IP Address: 18.188.201.183 is included in there? that’s really important
It’s a very easy fix too - you can just remove the router, modify the config file, and reenroll the router. If you want to try that - I can walk you through…
The easiest thing (imo) is to use AWS where you’ll get an External DNS entry - and then you can just copy/paste the ‘host it anywhere’ quickstart…
and
might also be of interest to watch
Thanks for the help! I even have an external DNS entry!!
I’ll start over again with the external DNS set.
The Oracle OCI video should cover that. It doesn’t come with an external DNS name out of the gate so if you don’t have one - that won’t stop you. Just make sure the externa IP is in the SANS of your edge router and controller and it’ll work fine that way.
The quickstart should show you how to do that but if you run into any bumps, we’ll help you out asap. Cheers!
1 Like
Ha! Works! Thanks for the help
1 Like
Awesome, great to hear! Thanks for sticking with it. If you have any feedback to ‘make things better/easier’, drop an issue into GitHub - openziti/ziti-doc: Documentation describing the usage of the Ziti platform. or GitHub - openziti/ziti: The parent project for OpenZiti. Here you will find the executables for a fully zero trust, application embedded, programmable network. Whatever is easier.
Cheers!
1 Like
Absolutely, will do, and again, love the project and will definitely implement with my customers.
What might attract customers as well could be some kind of an example enterprise network, showing a traditional network segmentation VPN way and how it would look like with OpenZiti
Thanks for that feedback. What sort of ‘traditional network segmentation’ do you have in mind? Are you thinking something like a site to site VPN? Robert has a great video that shows you how to use OpenZiti as a LAN Gateway. Something like that or something else did you have in mind?
I like the video.
But what I meant is more something like showing how the following network, which is common practice for most companies, can look like with zero trust:
We have a few diagrams along those lines which we can share. We’ll share whatever is most helpful to you. Is remote worker the scenario you want us to drill down into? If so:
-
Generic - e.g. remote worker needs to access some mix of apps (internal, saas, web app, other apps, web browsing, etc) in some mix of places (private dc, public cloud, etc) with some latency sensitive, some more sensitive from security/compliance perspective, some high bandwidth, etc? Remote admin too (e.g. ssh, rdp, etc)?
-
Specific - there are specific use cases or apps you want to understand at a lower level?
-
Or something else entirely ; )
Yeah, the generic example sounds exactly like what I was thinking about! 
A few slides showing the generics. We also used your diagram for a quick compare at the end. Pls let us know if you want to dive into any specifics. This mainly discusses zero trust networking from the remote worker perspective but other use cases are linked on the last slide, and some of those docs get deeper on key concepts.
1 Like
Thanks so much! Do you by any chance have any diagrams or docs on preventing ransomware attacks by using a zero trust / OpenZiti approach?
Unfortunately we can’t 100% prevent, but we can minimize along 2 important vectors:
Minimize attack surface. With all inbound firewall ports closed, it makes it much more difficult for attackers to ‘talk to’ the ransomware, and sometimes more difficult to insert the malware in the first place. The main Ziti superpowers here are the fabric brokering sessions, coupled with the ability of the Ziti endpoints to go anywhere and serve every use case - this pair of superpowers enabling the closing of all the inbound firewall ports and link listeners.
Minimize blast radius. It is usually a thin version or loader app of the ransomware which is initially planted - like a seed. This seed then contacts a server to expand its capabilities. OpenZiti blocks or makes that communication much more difficult via least privileged access, attribute-based authorization and app level microsegmentation. Similarly, if the ransomware seed can bloom, the microsegmentation can make it more difficult to spread across the WAN to find valuable data to encrypt.
As an example, you may not prevent all ransomware from being embedded in the first place. However, if it can’t easily be exploited from the networks, and it can’t use the networks as roads to do its damage, then you may have much more time to remove it.
There is a 3 part series here which gets deeper, written from the NetFoundry perspective (hosted Ziti as NaaS):
2 Likes
Thanks, but that would require firewall rules to block outbound traffic except on the ports that OpenZiti uses, right? Talking about the communication to C2C servers here…
I’ll have a look at the slides!
Yes, ideally (if you were 100% least privileged access) your firewalls would be default deny on both sides, with the outbound side only speaking to your private Fabric, and the inbound side being completely closed. However, OpenZiti does help reduce the risk, even if the OB side of your FWs is less restrictive. To be more specific, let’s look at two categories of threats:
Category one: the vulnerability is exploited from the networks
This is almost always the category which your ransomware question falls into. The deny-all on the IB FW side, enabled by and combined with the other OpenZiti superpowers, is a very strong and proactive defense for this category. It basically means you can have vulnerabilities inside (e.g. Log4j libraries or not yet identified zero-days), but most are like bombs that can’t be detonated from the networks because attackers can’t easily reach them from the networks (the primary attack vector). So you may have some time to remove the bombs (but do remove them quickly : )), because you have moved to a proactive OpenZiti security paradigm. Without OpenZiti, you would instead be reactive - scrambling to find the signatures and add them to all your WAFs, and/or add a bunch of IP restrictions to your network firewalls, and usually after some bombs have already been detonated…and then scramble again to react as the attacks morph or for the next zero-day.
Category two: the vulnerability is fully exploited from the inside
However, to your point, there is another category of threats in which the bombs can be detonated from the inside, and/or don’t need a detonation (your ransomware question almost always falls in the other category, but I don’t want to ignore this category). This category is more rare, but restrictive OB FW rules helps with this category, as can other security layers such as endpoint security. Your OpenZiti endpoints and OpenZiti LPA policies can also help with this category. For example, if you are running OpenZiti on a server which has a zero-day, and now the zero-day already running on the server tries to ‘phone home’ to talk to an app outside of its LPA policies (these policies are kept on the OpenZiti side; not the firewalls), then OpenZiti will deny it. This requires your OpenZiti policies for that server to ‘intercept’ all traffic so you make it very difficult for the malware to find a different network connection to ‘phone home’ (there are still soft spots, e.g. if the ‘phone home’ looks like a request to a service on some server which you do include as permitted in your LPA rules). Similarly, your OpenZiti LPA policies will likely make it much more difficult for the malware to spread across your WAN, which can limit damage and make remediation simpler.
1 Like