Hello, everyone. Milan from MP Fabric here. I'm a project engineer MP Fabric, and the focus on today will be visibility and security with IP Fabric. What are we gonna do? Let's have a look at a quick introduction, and let's go through the basic, as a PowerPoint presentation.

Let's go through webinar content, and let's see what we're gonna do. So so the first, we will have a look at our simple topology, which is consisting of a couple of LAN devices, couple of routers, and we will be focusing on a basic device hardening, with our intent rules. I'm gonna go into detail into that later on. Then we will take the rules, and we apply the rules in the diagram. So we see the flexibility of IP fabric in a way that we can just simply observe the diagrams and apply our intent rules, which are related to the device hardening to really recreate that we will create.

The last part of the webinar will be focused on security and the application path testing over the security environment. We're gonna have the switches, routers, and we're gonna have a firewall cluster in our system that is supposed to verify the traffic, and we will test the application path through the firewall with the end to end path simulation in the IP fabric. So the first first part about the device hardening will be focused first, we will take our devices. There will there will be 9 devices in total in our network topology. We will create basic intent verification rules to verify that we have correct, network time protocol settings and the net and the correct, SNMP settings.

So we'll focus on NTP sources and the other parameters. For the SNMP, we will verify or see how we can, verify the SNMP summary information, the communities that we have configured, and, especially the trap host so we know where do we send the SNMP information. Then after we create our intent based rules for the device hardening, we will see how we can create a simple dashboard widget. And with the help of the widget, the rules can be easily applied to diagrams in a way that we will observe directly the diagrams. Okay.

Is this, device compliant with our NTP or SNMP rule, or is there anything wrong? We will have a look at that. And, then we have a quick very quick scenario. We will be implementing a new payment system for the hardware store. So there will be the former payment system, and we will implement a new system with the new VLAN, with a with a new subnet.

And, with the application path testing, we will be verifying if the system is working as expected, which means we wanna go all the traffic through the firewall and then through transit. We will have a look at that. So for adding the new subnets of our hardware store, it will be, 10 024183/83/0/20 4 and with the VLAN 83. So we will have a look, in the IP fabric how we can run the VLAN simulation and topology so we can verify if the VLAN is propagating correctly, if the VLAN is, having the gateway on the firewall, which we expect, and what is the traffic flow of our VLAN. In the last phase, we will be testing the application security path, towards the server, which is supposed to be working as a support for our payment service.

So it's gonna be 10 dot241255 dot 13, which is somewhere in transit, and we just need to make sure that the traffic is passing our our LAN and our routed part of the of the of the topology correctly, especially through the firewall. And, thank you for watching the presentation, and let's go to the demo, and let's go through each points individually. So I quickly close this one. So this is our IP fabric. As we see, we have, 2 baselines.

We will be working with the webinar baseline number 2. There are 9 devices discovered and, all are within one site, which will be our exact topology. So I can click on the site and see how the topology looks like. So this is the basic topology we will be working on. I have prepared a view with, the exact protocols I want to observe.

So, basically, what I did, I selected just the protocols I wanna see. I including this. I included the spanning tree. I included the OSPF, so I wanna see if all the neighbors are set up correctly over my topology. And, here is the transit, which is, the other part of network that I really don't don't want to worry about right now.

And, this is what we want to see. So in our topology, there's a routed part consisting of the routers, then we have, 2 static OSPF, neighbors, which we can observe in here. And, all the traffic from the from the switched part of network, including all the hosts, has to go through the firewall. So that's our rule. I can see that it's still a wired host, which are the server in question.

So this host, 10 dot24.183.13, is going to be our new new server for the payment system. This is the old one, and there are 2 2 other ones that we really don't worry about right now. First, we will focus on the device hardening itself. So we wanted to go through, basic verification or the internal rules for NTP and, SNMP. So we can go to technology, management, and NTP.

There's other way how we can reach, the correct table in IP Fabric. We can simply search for that. So I can search for NTP and get the details immediately. There's 2 ways. So either you can go through the menu or you can just search for anything you really want.

It's it's a very flexible tool. So what we are seeing here, we have, 9 devices in total. It seems that we have one NTP source configure. This one is verifying, if there's at least 2 NTP sources configured, which is the recommended, number of sources. It can be even more.

What we can do, let's say, we would like to see we would like to verify if we have the correct source configured. So we can create a simple NTP rule, NTP source for the lab, And we will say, okay. We wanna verify the source. We will include the rule into the widget, which we will be working later on with. I will say correct NTP source.

Just simple as that. And we say the correct NTP source is equal to this IP address. If there's anything wrong, is there anything else? Then it's wrong. So we say the the yellow color or the orange color will be as default one.

So we save the rule. And we see that everything is compliant, which is fine. Great. And let's move on to the SNMP. So this is the basic SNMP summary that we can see, and we are seeing all advices in here.

And, we see the name, location, and the contact. We can quickly check the communities. Okay. Here's the IP fabric. Here's the e read only and the prefixes allowed.

We can see all the details about the communities in this step, especially. So we can see or create a verification. Okay. All the devices needs to have the IP fabric community with the read only authorization, and we can verify that as well very easily. These intent rules for verification at the top here are basically only checking if there's nothing, like a private or public community.

Just verify that we have the IP fabric, community as a correct configured community. What we wanted to focus on is the trap host because it's quite often it happens that, on the network, there are legacy SNMP servers or syslog servers or any other servers that are used for management or monitoring or collecting the traps. What happens is that, sometimes when there's some tests being performed on network, we can temporarily set up couple of servers, to be to send to the SNMP 2, and we forget to remove those servers in the meantime. So what happens is that we have a lot of, like, a stress management work, and it happens very, very, very often. So with this rule that we created before gonna remove this widget.

We say, okay. We want to verify that all the devices are using this destination host with this destination port. It has to be v 2 because sometimes it's a v 2. Sometimes the version is named v 2 c. So we just say it has to contain v 2.

And we want to make sure that all traps are using loopback as a sort of interface of the traps. That's how it's set up on the on our Zabbix servers, so we're gonna make sure that we are complying with that. If there's anything wrong, it's gonna be, again, yellow or orange. And we are seeing that there's 2 not compliant devices, and let's see what the problem is. So this one is a special it's a wrong destination host.

This one, it seems to be correct, but the destination port is correct, version is correct, but there's no source interface. So maybe we can dive into that a little bit and see, what's going on device and see how we can refresh the data. So I'm gonna connect to the router 17. And we will check what's our configuration of the SNMP. So, eventually, we have everything correct, but we forget to set up the source interface as a as a source, for the trap host.

So we what we're gonna do, we're gonna change it. So set s n m p trap group trap group and zabbix. And what we have here is the logical system Turkish version. Mhmm. Okay.

It's gonna be different. Trap. So what are we gonna do again? We're gonna add the source address or the source interface, to the trap group, Zabbix. So we will include the source interface as our as our as our SMP source for the traps.

That is an empty trap option source address loop back 0. K. Yeah. So the configuration was updated. So now we're gonna back we're gonna go back to the IP fabric.

And what we need to do, we need to kind of reverify. So we want to refresh the data for a selected host name. So we can do that very very easily with IP fabric, and we can just go to the discovery snapshot. I will just unlock the snapshot so I can modify the snapshot. I will check this device, and I will refresh the data of this device.

And we see that IP fabric can do it very, very quickly. If we check our previous snapshot of 9 devices, it took just 1 minute or 58 seconds to create and to compile all the data. So to collect just one device, it's gonna be very, very quickly. K. We are collecting data.

Can see what's in progress. Verifying the tasks. Mhmm. Okay. The data has been collected, and we can go back to the SNMP SNMP hosts, and we see there's only one left right now, which we can gather of later on.

So we see how flexible, we how flexible we can collect the data, do the refresh, or whatever else we really want. So we see the r 17 has now the correct source IP address configured. So this is an easy way how we can, verify the data related to SNMP and the NTP. And now let's move on, and then let's see how we can take your data, take the intent verification rules, create a simple widget in the dashboard, and then apply what we created in the diagram. So we will go to the dashboard and the overview.

And, before, I created a little widget over here called management compliance. The dashboard can be edited. We can add or remove the rules that we created. We can, add those little rider charts or con charts. So we'll edit this one to see what's included.

So what what I created is the management compliance project consisting of these rules. So it's consisting of, NTP source lab, s SNMP trap host, SNMP community name, and other parts for the NTP. The way I added the rule to the to the widget was, if you remember, with the with the widget that was, that I was able to include when I was creating the rule. And because I have this kind of a management compliance widget present on the dashboard, I can easily apply that in the diagrams. So we can go to diagrams, to network.

The way we apply the rules is just through these little three dots, and here is the intent verification rule. And, we will pick up the widget that we have in the dashboard. So it's the management compliance. And we will see almost all of them are compliant, which they are kind of greenish color. When we click on that, we can get more data.

We can see, okay, it's compliant with the NTP. It's compliant with the NTP with the SNMP or other rules that we created. This one is orange. We already know why, and it's, because the NTP round trip time and everything else seems to be correct. And there was one, I think it was 16, that wasn't compliant with our SNMP trap host rule and this is the this is the issue.

So this is the way how we can visually verify a lot of things that we can create in IB Fabric or that are already created in IB Fabric. There's a lot of things, in the intent that you can see if there are any interface errors on the interfaces. You can see if, we are compliant based on the operating system and the versioning or based on the quality of service information. There's a lot of things we can verify even on the end to end or in the diagrams directly based on the view that we are currently seeing. So okay.

That is for our intent based rule, and, let's move to our next phase, which is implementing new system or the payment system for our, for our topology. So as we observed before, there are a couple of warehouses. So there's 83 dot13, which is a new subnet that we wanted to add. The first one I wanted to focus on is the simulation, for the VLAN part. We can easily simulate the VLAN propagation over the over the network.

It's just by a single click, and we can add the VLAN 83 that is supposed to be created in topology. And here we can see how the VLAN is, going through network. So we have the server. It's connected to the switch over the interface e t 3, the VLAN 83. From the switch, it's going to the other switch over e t zero one.

This one is the root. We can verify that just by clicking checking the switchboard, and the VLANs, and see, and the 3. So we can see that the root ID is equal to the bridge ID, which is the root bridge. And, then the VLAN is going, to our firewall, which is the expected behavior, and it seems to all be fine. The the the reason why we have 2 interfaces is because, the redundant Internet is consisting is consisted of, 2 physical interfaces because the Retina Internet, in the way it works, it's the interface that is a special it is a special interface for the cluster, and, this is the firewall cluster.

So the way it works is either one or the second physical interface currently active. So the like like, kind of a umbrella interface is the a redundant Ethernet interface, and then there are 2 interfaces 2 or more interfaces that are belonging to interface. So that's why we are synced to interfaces, but in fact, only one interface is in use, which is, gigabit Ethernet 2. If, the primary node of the cluster will go down, it will switch up to the interface, but the logical or the umbrella interface written on Internet 2.83 will be active all the time. So that that's the reason.

Nothing else. So the first verification we wanna run is, we wanna verify. We're gonna leave this scenario. We're gonna verify that this little IP address cannot talk to the other parent system that we already implemented before, which is, the other subnet 24125512. Sir, is the 8383 to 13, and, the 82 to 12 is our previous system.

So let's verify the end to end path between those two system, which is never supposed to be open. And, here's the result. The way we show the end to end path over the over the topology is that, we are trying to separate the routed and switched part of network and the security part. So the routing is going, host to gateway directly to the firewall. It's going over the purple or the violet lines, so we can turn off layer 2 to see that.

And, however, layer 2 is going across the real path, which are which are the switches. So we see that it's going from the edit 3. It's going to the switch l one s w four. Once we click on that, we can verify it's going to the other switch, that it's going to the to the firewall. And from the firewall, however, because it's in red, we know that, forwarding seems to be okay.

It's kind of forwarding fine, but there are zone matching rules that are preventing the packet packets to get through. And, this one is just, the implicit deny. It's a default policy, which is blocking the traffic, which is what we expect, which is great. So next, we want to verify that, our server can communicate with the supporting system, which is in the different subnet and different network. So let's see what what kind of what it was.

So we see that the payment system is 10 dot241255.13. So let's verify that right now. And the payment system is going to communicate across HTTP, but we will be switching soon to HTTPS. So let's see how it works. Mhmm.

And this is our topology based on the source and destination. So we are going through the switch port. We're going through the firewall. The firewall is not red, which means the traffic is getting through. And then it's going to transit, which is the part of the network that we don't manage, so we don't care about that.

It's fine. We can verify the zone metric rules. So we are seeing it's going from zone, c u s t 83 to the management, and, we see that there is application Junos HTTP, which is permitting the traffic, which is great. Okay. So let's verify if in the future because we are planning to migrate to HTTPS.

So let's see if we can use the secured HTTP. No. It seems that we have an issue, because the firewall didn't let us through. Mhmm. So we can have a look what's going on.

So let's jump to the firewall very, very quickly and see what's going on. So we're gonna see the config, if you'd allow me. Let's reconnect. So okay. I see now.

So we have the this is the rule which is, permitting or denying the traffic from the zone to the zone where the server resides. We see that, we are allowing the source to communicate with the destination host. But the only application that we are permitting is, the HTTP. So we are not allowing HTTPS. HTTPS, so we can check that.

So let's add HTTPS. Okay. And because doesn't voice name doesn't match the rules anymore, so we can change it as well. K. And we're gonna rename the policy HTTP to policy let's call it web.

K. Let's verify the results, and we are seeing okay. So we're changing, from the application Junos HTTP to HTTP and HTTPS, and we are just renaming the policy. Okay. You can commit that.

So we need to wait a while because it needs to commit on both nodes on the cluster and, seems to be good. So let's go back to the topology. And another power of the IP fabric is that we can refresh the engine path directly in the diagrams. So let's refresh the data. We have 2 options here or or 3 to be to be to be exact.

The first option will create completely new separate minor snapshot from the diagram we are observing right now. The second one will just refresh the data in the in the snapshot, and that is what we are going to do. So I'm gonna refresh that. And, again, because of the speed of IP fabric, this is expected to be very, very quick. Okay.

We're seeing that the inventory is, filling up again. We are getting new devices and, very, very quickly. We're gonna reach the end of 38 seconds, 39, 40. Yeah. It seems that we are done.

K. Mhmm. We're done. Topology is, being calculated right now. It's finished.

Great. So let's go back to the end to end and see what it is. Alright. Seems much better. So the firewall is now permitting traffic.

And when we click on it, we can see the forwarding is green, and the zone matching rules are now passing the traffic correctly. And we are seeing that the Junos HTTPS is included as well, and the name of the policy is the name that we put it in. Okay. That's great. I think we, progressed with our apology.

It seems that our payment system will be operational even on a HTTP and HTTPS at the same time. One thing I wanted to verify because our old system is working as well, but I'm not sure if there was a rule that's supporting that. Let's verify if our old system was using similar type of the rule because what we did during the implementation, we just copied the rules from the old payment system and applied it to a new subnet, and it didn't work. So it's kind of strange, I think. Oh, and this is interesting because it seems that the old payment system is not going through the firewall.

That is a very interesting information to see. So it seems that it was really never going through a firewall, and let's see why. Because, I'm interested in why is it using the interface ge001.82? I mean, what is this interface? Alright.

Here we go. Okay. So it seems that someone used the subinterface on this router, link it to the house directly before the firewall was even in the topology, and they practically bypass all security. And, of course, it was just a temporary thing. So okay.

Thank you for watching the webinar. This was our last point, and, feel free to enjoy the recording, which we're gonna produce very, very soon, and the article will follow. So have a great day, and, hope you enjoy IB Fabric in the future. Thank you.