3 ms·

My problem with this guide is that by using a VPN/Firewall combination there is a lot of inherent trust in the underlay network through the use of listening por

by PLG88 2y ago

My problem with this guide is that by using a VPN/Firewall combination there is a lot of inherent trust in the underlay network through the use of listening ports with inbound connections allowed. This means external actors can scan these ports, and attempt external network attacks - e.g., DDoS, CVE exploit, credential stuffing etc. This is why, when I wrote a blog a few years ago comparing zero trust networking using Harry Potter analogies, my daughter and I designated these setups as 'non-magical' as silly muggles can find our environment. Table stakes is making yourself invisible, and you do not need a "cloud based phenom that will eat your budget" in order to achieve this - https://netfoundry.io/demystifying-the-magic-of-zero-trust-with-my-daughter-and-opensource/ https://netfoundry.io/demystifying-the-magic-of-zero-trust-w....

transpute 2y ago
Fun article :) > software-defined perimeter (SDP) ... can use various techniques, including single packet authentication (or port knocking) or authentication and authorization-before-connectivity using strong identity and least-privileged access... when you embed an open-source OpenZiti SDK into your application... it’s magically transported to the destination through the OpenZiti fabric.. configured using identities, services, and policies. It ensures there is no other way to reach your app as we have zero trust in the wide-area, local network and even OS network. Embedding zero trust into your apps makes them immune to network-based side-channel attacks Does this use an OpenZiti IDP proxy or rendezvous server on WAN/cloud?
- PLG88 2y ago
  Thanks! And good question, lets unpack a few things: - OpenZiti is opinionated on trust and thinks PKI is the best way to ensure every element in the private overlay network uses secure identity-based authentication and authorization. Thus OpenZiti has a built-in CA/PKI, with third-party CA support (RFC 7030). In any scenario, all identities verify the JWT, verify the controller, request CSR and enroll via CSR if all validated. Nothing can access the private network without secure identity-based authentication and authorization. - Due to every element having an identity, across the overlay we route according to the identity. This effectively provides you with a private DNS which does not need to comply to top-level domains. - When we define a service to connect from endpoint (ingress) to endpoint (egress), it gets stitched together across the OpenZiti fabric, specifically the edge routers, which act as a smart routing data plane. The endpoints at source/destination are making outbound connections to the routers which is providing the 'turn server' functionality. These can be hosted anywhere, whether in your private network or across the WAN (or internet). So, the answer is closer to your second suggestion but with some nuances. Net result, no need for VPNs, complex FW rules or inbound FW ports, public DNS, bastions, NAC, L4 load balancers, and more.

by PLG88 2y ago

transpute 2y ago

Fun article :) > software-defined perimeter (SDP) ... can use various techniques, including single packet authentication (or port knocking) or authentication and authorization-before-connectivity using strong identity and least-privileged access... when you embed an open-source OpenZiti SDK into your application... it’s magically transported to the destination through the OpenZiti fabric.. configured using identities, services, and policies. It ensures there is no other way to reach your app as we have zero trust in the wide-area, local network and even OS network. Embedding zero trust into your apps makes them immune to network-based side-channel attacks Does this use an OpenZiti IDP proxy or rendezvous server on WAN/cloud?

PLG88 2y ago
Thanks! And good question, lets unpack a few things: - OpenZiti is opinionated on trust and thinks PKI is the best way to ensure every element in the private overlay network uses secure identity-based authentication and authorization. Thus OpenZiti has a built-in CA/PKI, with third-party CA support (RFC 7030). In any scenario, all identities verify the JWT, verify the controller, request CSR and enroll via CSR if all validated. Nothing can access the private network without secure identity-based authentication and authorization. - Due to every element having an identity, across the overlay we route according to the identity. This effectively provides you with a private DNS which does not need to comply to top-level domains. - When we define a service to connect from endpoint (ingress) to endpoint (egress), it gets stitched together across the OpenZiti fabric, specifically the edge routers, which act as a smart routing data plane. The endpoints at source/destination are making outbound connections to the routers which is providing the 'turn server' functionality. These can be hosted anywhere, whether in your private network or across the WAN (or internet). So, the answer is closer to your second suggestion but with some nuances. Net result, no need for VPNs, complex FW rules or inbound FW ports, public DNS, bastions, NAC, L4 load balancers, and more.