0:01 Hi I am Maxim from Versa and in this video we will learn about network obfuscation. 0:07 First let's define what is a network obfuscation. 0:10 So, network obfuscation is a technique that involves intentionally obscuring or hiding the structure and behavior of end users and applications. 0:20 Let's take a look at this example. 0:22 We have a user who is connected to a Versas IC gateway with Versas IC client application. 0:28 This user trying to access internal resource in a private data center. 0:34 As a basic technique that can be used to confuse intruder who can capture user traffic over the Internet is to change Ipsec VPN pattern of it. 0:44 In this example user is assigned with a fake IP address that is not routed in enterprise DC. 0:50 The request to an application is also done with IP address that is randomly assigned by a verse assessing gateway. 0:58 Once the traffic reach versus AC gateway, those parameters are changed. 1:03 As a result, VPN pattern also changed for outgoing connection to a private workload. 1:09 And it is just a basic part of it. 1:12 Every day, even user accesses the same application, those VPN parameters will still be different. 1:20 So in a simple words, network obfuscation will enhance the overall security posture by strengthening confidentiality, integrity and resilience of the network infrastructure. 1:32 This technique will help in mitigating recognizance attacks. 1:36 It will reduce attack surface and deter automated attacks. 1:41 So let's go ahead and take a closer look at it. 1:45 So technically, network obfuscation is a combination of multiple security features such as CGNET and DNS proxy which are available in Versal as security stack. 1:56 Leveraging those features, we can create configuration that will eliminate similar VPN traffic patterns And as a result, it will significantly complicate and desired actions planned by intruder. 2:08 Is it sound cool? 2:09 Let's take a practical look at it. 2:13 So here is my concerto view and I have a user connected which is myself connected to a London Gateway. 2:20 And also as per diagram I have an IP SEC tunnel with my private data center. 2:25 Over IP SEC tunnel I have also BGP connection and over BGP connection I'm getting one 92168 dot 10.0 slash 24 subnet. 2:35 This is where my test server with this private application is located. 2:42 I am going here to my laptop which has this SASE client connected with the London Gateway and now my tunnel IP address is 190 two 168.105 dot two. 2:55 Let me verify connectivity my with my application now. 2:59 And Please note that at this moment I don't have any network obfuscation enabled, so I do pingmyapp.acme.com and as we can see I cannot resolve name. 3:15 So I'm verifying my DNS and I can see that based on my SAS gateway policy I'm using Public Cloud Flare DNS 1.1.1.1. 3:27 And this Public Cloud Flare DNS of course does not have any idea about my private app. 3:33 So therefore there is a reason why I cannot reach to my private app. 3:39 Let me log into my server, it's one 92168 dot 10.5. 3:48 Let me make it bigger and I will run TCP dump on my server to verify reachability. 4:02 ICMP. 4:03 I'll use ICMP at this moment and I will run a PINQ from my laptop. 4:17 OK, so I'm running my PINQ and I can see that request is coming from one 92168 dot 105.2 which is my tunnel IP address. 4:31 Let me go ahead and enable private application obfuscation. 4:38 So for that I go into configuration, real time protection and network obfuscation and 1st I will enable application obfuscation. 4:48 For that I will tick this checkbox and I need to add my private application. 4:53 At this point I don't have any application so I'll click add to create a new. 4:58 I say this private application and host pattern will be my app.acme.com and protocol for connectivity. 5:08 It can be TCP destination port 5001. 5:13 It might will be my business application and application service. 5:19 I can set a productivity and risk for that and precedence by default. 5:25 It can be one as my application precedence. 5:28 Here I click next and I give it a name my private app and click save so I can add this my private. 5:42 I have this FQDN as a host pattern and now I can also add a resolver so which DNS server I need to use in order to access my private app. 5:52 So my DNS server is one 92168 dot 10.5 and I click add this configuration on under concerto and click save configuration saved and now we can go ahead and publish it. 6:15 Once configuration is published we can go ahead and verify it. 6:20 So I will connect to my server first and run TCP dump. 6:40 So I start TCP down for capturing DNS request and 1st what I will do I will do a next look up to myapp.acme.com. 6:52 I can see that I again getting response from cloud flare what is syncing my laptop and I'm getting KP which is 176 to 24.3. 7:02 But when I go here I can see that my server actually getting DNS request and this is for myapp.acme.com and I am providing him a response with my actual IP address where my actual IP address is 192.168 dot 10.5 for this application. 7:24 OK so let me start another TCP dump for ICMP and I will do pink pinkmyapp.acme.com. 7:37 As you can see I am trying to reach IP address 100.76.24.3 and my server is getting response from from my laptop which is 192.168 dot 105.5 and I'm giving him an ICMP response. 7:56 So if I check my tunnel IP at this moment, I have it As for London Gateway 192.168 dot 105.5. 8:10 Next let us go ahead and enable remote user obfuscation. 8:15 I go to real type protection, network obfuscation and remote user obfuscation. 8:20 I hit the check box and click save. 8:24 Now we can publish it and go ahead and verify. 8:37 So let me first check IP config and as we can see now my IP address is 100.72 dot 0.0. 8:51 Let me try to resolve my app and at this moment my app is resolving again to a different IP address which is 100.74.24.0. 9:06 So once I start ping after enabling TCP dump on my server I can see that I'm getting response from 100.74.24.0 while on the server I am getting request from 192.168 dot 105.3 which is a different IP address than my tunnel IP address as well as I am get giving my response from my versa DC. 9:52 So my Versa DC is this interface which is 192.168 dot 10.5 and this is what we can resolve in DNS. 10:06 So here is my DNS configuration. 10:09 Any request that is coming to this DNS server, the result will be resolved to this IP address. 10:15 While on the client it is different and Please note that my source IP address is changed, my destination IP address is changed while DNS request itself is coming to Cloudflare DNS for DNS, we can also validate this DNS proxy in Concerto logs. 10:38 I can go to analytics and I click Logs DNS and DNS proxy and for example I can analyze this entry where I'm doing a request to myapp.acmi.com and the source address is 190 two 168105.1 with the destination address which is my private DNS and also it was proxy and this source IP address is my real client IP and destination is Cloudflare. 11:15 So in reality I am getting the DNS resolution from my private server and IP address of this private server is hidden and request is also coming from a different IP address. 11:29 So this is address that is routed inside my data center network. 11:34 But this is my IP address that is assigned by to my Saasy client. 11:41 With this I would like to conclude on network obfuscation technique. 11:47 I hope it was informative for you. 11:49 Thank you for watching.