Speaker 1: 0:00

This is the Art of Network Engineering, where technology meets the human side of IT. Whether you're scaling networks, solving problems or shaping your career, we've got the insights, stories and tips to keep you ahead in the ever-evolving world of networking. Welcome to the Art of Network Engineering podcast. My name is Andy Laptev. In this episode we have a new face, matt. Hmm, I should have figured this out ahead of time.

Speaker 2: 0:24

I'll let you try. Nailed it First try.

Speaker 1: 0:29

Matt, how are you Welcome to the show Quickly? Do you want to tell folks where you work? What do you do?

Speaker 2: 0:33

My name is Matt Lushner. I'm Cisco Solutions Engineer. I've been there for five years. I do data center networking automation. I actually just did a Cisco Live presentation on CML and I do a lot of random comment content on that on a day-to-day basis, just because it's a really good tool. I just like talking about it and showing people some of the cool things they can do.

Speaker 1: 0:54

Labbing. I love labbing, can you it's the easy life man. Can you lab anything above layer three Hint, hint foreshadow you. Above layer three?

Speaker 2: 1:03

hint, hint foreshadow you definitely can lab some things above layer three and in fact with the most recent release of Cisco Modeling Labs you can do the ASA but also Cisco's next generation secure firewall. So you can get the GUI and start figuring out how to do firewalls with the GUI.

Speaker 1: 1:21

Awesome, matt, thank you so much for joining us. And Jeff Clark, returning previous guest contributor, I think we're going with. Sounds good, all around, great guy who likes to help me out and hang out. Jeff, how you doing buddy? How are things?

Speaker 3: 1:33

Doing good. Nothing like, nothing more than hearing myself talk. So it's great. Perfect on a Thursday night.

Speaker 1: 1:40

Three nerds who love to hear themselves talk. What better panel for a podcast?

Speaker 3: 1:44

right.

Speaker 1: 1:44

Exactly. If you didn't like to talk, it'd be a really boring show for everybody. Jeff, where do you work?

Speaker 3: 1:48

I work over at Fortinet as an SE. Over there my main focus is network security, mostly in the firewall, SD-WAN side of things.

Speaker 1: 2:05

I'm the odd guy out. I am not an SE, I've never been an SE, I was almost an SE. So in this episode I thought it'd be cool to talk about firewalls. We have never done an episode in 160 something episodes about firewalls, network engineering. My experience in my career and in my studying and my certs for 15 years has gone to layer three and stopped Right, and from people I talk to I guess it depends on the environment you work in my buddy, kevin, who used to be on the show we started out.

Speaker 1: 2:22

I feel like you start out in network engineering Like does anybody just start in firewalls, right? Like you kind of have to learn the network. I was even talking about your career, jeff, with Matt before we started and like you're a network engineer with me and then you wanted to get into security and firewalls. You had to go get that job and to get to a vendor and stuff. So there seems to be a progression almost up the OSI layers, at least for me, right. I started in physical as a cable guy and then logical on the knock and yada, yada, yada. So I don't know much about firewalls and I don't know if other network engineers out there are in the same boat, but I just thought we could have a high level discussion. You're two security guys Jeff, you work at a security company, matt ton of experience with firewalls and production and I have none, so I'm hoping you guys can kind of educate me and anybody else along for the ride on all things.

Speaker 1: 3:07

Firewall, firewall 101, that the title of the live stream was like firewalls are friends, right, like it reminded me of Nemo. Like fish are friends, not food. Like firewalls are our friends. So let's start like really high level. Why do we need firewalls in our environments? Why is all the filtering we do, up to and including layer three, not enough? What do firewalls give us from a security posture or just in general? So let's start there. Why do we need firewalls in our networks? I?

Speaker 3: 3:31

don't know if you want to take this matter you want me to run with it but I guess I would look at it the same way as why do you have locks on your door right? Why do you have it? Why?

Speaker 1: 3:39

do you lock?

Speaker 3: 3:40

your car at night? Why, jeff?

Speaker 1: 3:41

I have acls and prefix lists and route maps. You can't get into my network. I have filtered it at layer three.

Speaker 2: 3:46

And I have Mac filtering at layer two.

Speaker 1: 3:49

So I hear what you're saying, right, but I have locks on my doors, I think Maybe I don't. What does a firewall prevent that? Routers and switches and all the security embedded in them. We are taught security from day one in networking, right.

Speaker 3: 4:03

So the big difference between what you're talking about and when you say firewall. When you talk firewalls, you're probably thinking more along the lines of the older, like ASAs. Talk about Cisco, the old ASAs, when they were brand new. They were maybe layer four firewalls where you were blocking stuff and you have port 22,. Or you're blocking port 23 because you didn't want to allow it to tell me, or whatever.

Speaker 1: 4:29

I've watched buddies configure, like pal is an example, right, so they set zones and then they have rules and then what thing is in what zone and what can connect to what? That I think that's layer four, but there's a lot of other like the next gen stuff, like there's other things happening, right, like. So I don't want to get too far ahead. I think you're going to like layer seven stuff, right, right and application aware and all that. But let's, if we could start slow.

Speaker 1: 4:45

If we could start slow there at layer four. Is that just what we're doing is like we're setting zones and then we're creating rules on what can talk to what is that kind of the basics of firewalling, or no?

Speaker 3: 4:56

that's like saying isn't the basics of routing just you just build these static routes and you're done, and then everybody just goes where they want. Well, my only context is watching, Right, Totally.

Speaker 1: 5:04

Totally. My only context is watching somebody, like we were trying to migrate from one environment to another at a job I had and it was failing. The customer testing was failing because the firewall wasn't configured right. So I was and he's like oh, I didn't have their 13 subnets that they're using in the rules, now they are Bing. So Now they are Bing. So that is very simple, but that's what I saw.

Speaker 3: 5:23

So the other thing to think about with firewalls. A lot of time, at least from a network engineer perspective. Before I started working in the firewall world, before I started working in security, I tended to think of firewalls as kind of on the edge right. That's what keeps you from getting into my network that world has. It's not.

Speaker 3: 5:40

That is still a very important part of a firewall, but more and more what we're seeing is security inside of our networks, because if you look at the vast majority of vulnerabilities, you look at the vast majority of hacks that are happening. They're not people that are coming in from the outside. They're people that have got something on the inside of your network already that are allowing you to kind of move laterally across the network. A good example there was a casino. This was not a customer of ours or anything like that, it's just a story that you can look up in the news. There was a casino a few years ago that had a ransomware attack and they were hacked because someone in the facilities said what we could do for this huge saltwater fish tank we have is we could put in a smart temperature sensor.

Speaker 1: 6:22

I was hoping this was the one you were going to reference, this huge saltwater fish tank we have is we can put in a smart temperature sensor a smart, I was hoping this was the one you were going to reference.

Speaker 3: 6:27

It's everybody's favorite right and what's great about the story, though, is it's it's such an absolutely simple, benign, basic thing. Of course it's not a big deal. This is just going to monitor the temperature. You can let me know. I can check the salinity of the water. I don't know anything about thing about fish tanks.

Speaker 1: 6:42

So I'm not making stuff up. You're doing great. But they probably left the default credentials on which a port scanner picked up, and then they used the default creds and got in.

Speaker 3: 6:49

Even if it wasn't, even if it wasn't the default credentials. Most of those IOT things you're out of things type of devices they're not patched regularly. There's all sorts of vulnerabilities on them. So what security has really become is not just protecting your network from the outside in, it's protecting that smart thermostat that you have from being able to talk to your servers. It's about where networking and security comes in is we're still using some of the same segmentation that we've done. We're using VLAN, so obviously we're functioning at layer three there.

Speaker 1: 7:21

We can even do security at layer two on a lot of devices, so you're going way faster than I was hoping to, but that's and I'd like to get so for a couple of minutes. I just want to jump back to the edge perimeter kind of. I think if we walk through historically, if we jump right into like, well, we've got an application, aware, and we're inside out and they're like so let's let for people like me who read that article but don't know much else about it but why do we need firewalls at the edge? When you say the edge, are you talking about where the internet connects? Do we need them where MPLS comes in?

Speaker 1: 7:51

Because one of the questions I had for you guys, even as placement, let's go back five years before IoT and the attack surface became everywhere, and let's just go back five years to like, okay, it's at the edge, people coming in and out, where do you put those firewalls? Logically, I know you say edge, but is that in every MPLS circuit that's terminating, or my routers? Is that just the internet? Is it my get VPN router? I have connected in a data center, like, where is the edge that you're protecting All of that? The edge could be anywhere. It could be anywhere.

Speaker 2: 8:21

Right. So you're looking potentially internet. It's the obvious point where you're going to put a firewall. But what if you have stuff internal? What if you have sensitive data projects, things like that that you want to protect and you would put firewalls in those locations? Because the idea is put like ACLs we put them on the inside interface, as close as possible to the source, and we block the traffic as close to the source With a firewall. We kind of do the same thing, except we're moving that perimeter from the outside in.

Speaker 2: 8:48

So the networks I've supported in the past we'd have it at the equivalent of the internet and then we might have data centers where we also have a firewall and you would actually be dual stacked. You'd have a firewall at your edge of your network but then in the data center you have additional firewall rules because you want to protect, kind of that network of people that are sitting in that in between area, your users and what they're allowed to go into in the data center. And if you have like systems, like I did, thin client work, if you have thin clients in the lake that are sitting there providing desktops, you want to protect within that data center where they're able to transit through the network. So the firewall placement is all about where you want to protect within that data center where they're able to transit through the network. So the firewall placement it's all about where you want to control access for your hosts.

Speaker 1: 9:31

So let's pull on that string just for a second. So let's say we have a sensitive area, you want to control access. There's a resource that you don't want everybody to be able to get to. Again, my point of reference is route filtering. So in the environments I managed, every client was given a slash 24 subnet. That's what we let in through our route filters. We'd have route maps tied to prefix lists and you were only getting in and out of our WAN if your subnet fell within a particular. But that's not to say that that say bank customer coming in to get a service once they're in to your point.

Speaker 1: 10:01

I guess there could be sensitive information internally. So this is just opening up my mind because I'm like well, there are customers, we gave them the subnet, we're letting them in. Why can't they go everywhere? Well, to your point, maybe there's a federal zone with classified stuff in a particular area that you need special access for. And just because you're through the routing, the route filters, doesn't necessarily mean you should get to the irx, irs database, right.

Speaker 3: 10:24

That right we may or may not be managing, so that that's helpful for me if I came to your house I wouldn't go into your bedroom and dig through your drawers, right? But ideally, ideally, someone's not doing that part of putting firewalls everywhere. Putting security everywhere is about making sure that you you've worked in data centers before you have the. You have the turnstile that everybody gets into a data center, you get through there, but then you have your man traps when you get. You've worked in data centers before. You have the turnstile that everybody gets into a data center. You get through there, but then you have your man traps. I mean, you've got to either card in or, in some cases, in a really secure area, they've got some kind of biometrics that are getting you in there. Security is the same way and it's all about putting those boundaries there.

Speaker 3: 10:57

And while, yes, subnets sound like they're sufficient, the problem is that not everybody that's on the same subnet should have access to the same thing. Like, for example, you're not a server guy, is there a good reason that you or me, who's not a server guy, should have access to those servers and you're like no, but that's what credentials are for. But that's just us employees who probably wouldn't go there. When you have people who are in your network with malicious intent. They're not abiding by the. You don't have the proper credentials, so you're not going to be able to log in. There's a lot of other ways that they're trying to get in.

Speaker 1: 11:29

That makes sense and I don't mean to ask, I don't want to say dumb questions. I know I'm asking really simplistic questions, but these are just some of the thoughts I've had, because I'm the WAN guy and we have firewall people and I don't have to worry about it and when it doesn't work, I know my transit's good, I kick it to the firewall people. But that doesn't help me learn what you guys know and I think that for me at least in the data center, the more systems I can learn, the better I become at my job. If I know about applications and a little bit of coding, I can talk to the app people when something doesn't work. Same with security right, like oh, this I might be able to tell as a routing guy like oh, looks like firewall, like I can see it getting here. They probably didn't submit the right, the right port or whatever.

Speaker 1: 12:05

But so that's all but that. So the last question I guess I want to ask in this old school historical context of the edge and sensitive information you helped me get that in my head, matt, one of the places I worked we didn't know where the firewalls were, we couldn't access them and and that was probably by design. But one day somebody shared with me a map of all of our firewalls. There's so many firewalls, so what's the strategy? What's the logic? I guess it's design, like if you're doing security design, where do you put them? And if you want to ignore the historical edge stuff and just bring it up to, if it's easier to do it, explain it in modern day parlance Okay.

Speaker 3: 12:41

And part of the reason it's easier to kind of ignore that is because the world of security is and especially firewalls is changing, and it has changed rapidly.

Speaker 1: 12:50

What we're saying what's changed? It Like IoT is one thing right.

Speaker 3: 12:53

Well, right now, the biggest thing that everyone's going towards is IoT is part of it. Right, you talk about that attack service. So many different pieces that are in your network are now attack-fect. When a person comes into your network, you can usually assume they're going to get between three and four IP addresses with the stuff that they've got, whether it's their phones or their tablets and their and their laptops, maybe their watch connects and whatever. They're coming in with a bunch of different things.

Speaker 3: 13:16

But the reason I say things are changing is so I work primarily with firewalls. The vast majority of the teams I'm working with aren't even the security teams. They're actually the networking teams, because in many cases they're beginning to collapse. That firewall goes here, routing device goes here, and now your router or your firewall is your router, that's Fortinet, that's the Firepower, that's Alo Alto boxes. That's the big thing that customers are starting to do with them is they're collapsing that core and edge into a single security edge. Because then you're able to do it at that layer three boundary, you're able to monitor the traffic between this VLAN and that VLAN. Your firewall becomes your router.

Speaker 1: 13:56

So I have a question yeah, go ahead. Like you and I worked at Comcast as an example I don't see. My question to you is who manages the network and who manages the security for the network? And if it's one device, I can't see a company like comcast or other places. I've worked making me the network guy, now the security admin, in a firewall like so. Does that change? The role is changing to your point. If you can replace a router with a security device that has routing built into it, does that create any problems organizationally for the? There's DMARCs, usually in roles, and now you're joining them. Does that mean the router guy has to learn security? Does that mean we get rid of the routing people because security can do it all? Like what have you seen?

Speaker 3: 14:36

I would say more so in enterprise than when you look at. When you look at Comcast you want to think that's more ISP. But for the guys that were handling our credentials there or the network that you and I would connect to to get to other Comcast stuff, they very well may also be the firewall guys. That wasn't the network you and I were handling. We were handling the network for the MPLS circuits and the EPLs and ELANs and all that stuff and in those cases we weren't handling security because we had customers who were looking for end-to-end connectivity and they were putting their firewalls in place. But in the case of an enterprise network, your firewall guys are as often as not your network guys. But you asked a question earlier which I think was important, which is is there a kind of a path? And I know some people who started out in security and it's harder for them to do firewalls than it is for a network guy Because a network guy already we understand how things connect.

Speaker 3: 15:27

We understand just basic rules of routing and where I might want to put in some ACLs All of that stuff we already get. We get traffic flows. People who don't understand networking don't necessarily understand traffic flows. They don't understand that when I say VLAN, which is something on a switch, that's really a layer three boundary, they don't understand that that is actually something that has to be routed, whereas we get that instinct. So I would say your network people are your best firewall. I'll be glad to be told wrong.

Speaker 2: 15:56

No, I totally agree Because, from my experience, being able to work with router switches, understanding routing protocols that's core, fundamentals to managing any kind of firewall, because you still have to set up an IP on the interface. You might be able to make it a transparent firewall and it's layer two, but in most cases we're using it as layer three. So we're going to set an IP up. Then we have to think about the concept of outside and inside interfaces. Where are our security boundaries?

Speaker 2: 16:23

And then the next level becomes like building those ACLs and the things that you want to allow in your network. Well, a network engineer if he's got a really good, she has a really good network diagram they should have a really good idea of what all their subnets are, what's on the network, and then they can start building out really good rules and ACLs and all the things they need to allow traffic out of the network. They just have that inherent ability because they've got all this documentation. That's how I've always been successful in my firewall management is I have good documentation, I know what's on my network and I make sure when people are asking for things, I understand why they're doing it and what these rules are. Having that routing, switching.

Speaker 1: 17:06

Experience as a network engineer is crucial, I think, for just managing, not even getting into the day-to-day operation of it, and that seems to be the progression. Like it seems like the firewall. Both of you, right, like you manage networks. I guess before you were managing firewalls and other buddies I've had. So okay, old school historical like was there a time? Was there pre-firewall time? Have we always had firewall in networks? You have to filter at layer four and above.

Speaker 3: 17:26

You can go back to the PIX firewalls. Those were some of the first.

Speaker 1: 17:30

PIX were the first. I remember the ZoneBase firewalls and the Cisco routers. I managed.

Speaker 2: 17:34

And I'd say one of the things you've mentioned earlier is like, why even have firewalls? And there's this idea today, like everything has collapsed. Switches can do routing, routing can do some bit of switching, and then firewalls are doing routing and those devices still are purpose-built to do certain things. You don't necessarily want to take a router and take a full BGP table, like that's not a thing. Can you run BGP on your firewall? Absolutely, but you're going to take performance hits potentially and there's other things you have to account for when you're managing that firewall. So, yes, the firewall can be a router, but you have to think about where it is on your network and whether it should be the first size accordingly said oh, we're collapsing routers in the firewalls.

Speaker 1: 18:16

I'm like I didn't want to ask and it sounded adversarial, but like are you hosting the BGP table?

Speaker 3: 18:22

If you get the right size box, absolutely, we have customers doing it. So where I used to work, which was a school district, it was a weird giant flat layer two topology and we had 300,000 students going through a single pair of firewalls which were the layer three device. Now there were I shouldn't say they were the only layer three devices, but for the most part that was all of the egress. Was there? All the BGP configuration was on the firewalls. Now we weren't taking in the entire routing table but we weren't hosting a lot of stuff. There weren't great reasons for us to take in the entire routing table but again, 300,000 users going through these were really beefy boxes.

Speaker 1: 18:57

I don't mean to harp on the details what are we? I know I've asked this before so I apologize for repeating myself but what are we filtering? Know I've asked this before so I apologize for repeating myself, but what are we filtering in the firewall? In my mind it's layer four, so it's ip and protocols.

Speaker 1: 19:10

And I'm only saying that because I remember when application teams would have a new app that we'd have to open up in the data center, they would submit the firewall request and be well, here's our ip, here's the tcp ip ports that we need opened and and firewall people would create rules. So is that old school edge like, oh, that was the old way and now we need opened and and firewall people would create rules. So is that old school edge Like, oh, that was the old way and now we're cause I don't understand the difference between that and then what you call like next generation application aware. So I don't know if we can have a discussion around like so is my first statement that firewalls, at least historically or at a minimum, are filtering at layer four. Is that fair?

Speaker 3: 19:43

That's table stakes. Everybody's going to do that, I understand, but that's the difference between a firewall and a router.

Speaker 1: 19:47

A router can't filter layer four, right, so any?

Speaker 3: 19:51

router non-next-gen will do and that's where you're doing it at the port level. But that is really pretty basic. So take SSL VPNs right. Ssl VPNs use port 443. If you're going across an SSL VPN or whatever, but they're often just using your standard internet ports, but with the next-gen firewall, I can block things like SSL VPN With the next-generation firewall.

Speaker 3: 20:13

If I'm doing things like full, deep packet inspection, which means I'm essentially doing a man-in-the-middle attack and I'm seeing every little nuance in that packet that's going, I can do things like say okay, you want to go to Facebook, all right, our organization has a Facebook page. Here's what you're allowed to do. You're allowed to view Facebook, but you're not somebody from the organization we want to post to Facebook. We're going to stop you from posting to Facebook. So we can take applications like Facebook. I know website application, however you want to define it. If we get really granular application, however you want to define it, if we get really granular, we can block it at the level of you can post. You can read School districts, for example, are using deep packet inspection to inspect the Google search that a student does or the chat messages that a student sends over Google chat.

Speaker 3: 20:59

So if they say something that seems like bullying. School districts can flag that kind of stuff. Like that all falls under security, not necessarily that you're the guy configuring it. A lot of the next gen firewalls have some of that stuff built in. So don't think about you configuring it. You're kind of applying some built in stuff and then you're monitoring it or that maybe with the security team, the guys that that's all they do with security are looking at is the logs for that stuff. But you can get really, really granular next gen firewalls way beyond ports.

Speaker 1: 21:28

So right. So that sounds fascinating and magical and I want to dig into that. But I keep asking very basic questions and you keep going to outer space. So is there anything in between layer four and next gen or or did and that sincerely like, did the jump happen of like you're just filtering it? Layer four to like woof application aware deep packet inspection, like did the industry jump or was it incremental?

Speaker 2: 21:51

So I know at one point the firewall services module, because they started upgrading some of that code. You went from the ability to just do your application layers or your transport layers. So you're doing TCP, udp, you're getting your applications, nfs, whatever those things might be. They released identity firewalls. That was the next progression where, instead of just monitoring the firewall and trying to see what packets and IPs and people were trying to get to, they wanted to do the domain control and say here's my list of users, here's the groups, and this is where those groups are allowed to go to. So now you have two layers of inspection Is this person on a network that I want them to come in on, and is this person in one of the groups that's approved to come into the networks? And now you're not only monitoring them by the IP address and location, they're also getting that user state data from the domain controller.

Speaker 2: 22:44

Like that was the first big leap, I would say, in firewalls. And then, at least from a Cisco perspective, they got the firepower stuff, they pulled that into the ASA and now you can do malware detection, you can do web URLs and you can still do the identity stuff. So you've got transport layer, you've got identity, you've got URL and malware and all these other different things that you can track. Now it just has continued to build up. We're getting into this whole world of AI which everybody talks about. What's the AI doing? How's the AI coming in to interface with your devices, to provide the security and threat intelligence on your network, to provide the security and threat intelligence on your network.

Speaker 3: 23:23

Essentially what Matt's kind of talking about is we're going from what an old school firewall was, which was can this machine on this subnet talk to this machine on this subnet we moved to can this machine with this user, or can this device with this user credentials talk to this device with this user credentials? And I think where we're really going, and this is what you're going to be, what we're seeing big in the industry, is that the firewall kind of becomes this central brains of a lot of other security components. So zero trust is a part of security and I know this is supposed to be a firewall one, but the problem is Well, no, I was hoping to touch zero trust.

Speaker 3: 24:08

That's on my list of things. And it's hard to talk about firewalls without starting to talk about some of the other components that can talk to your firewalls. So what zero trust does is it goes from okay, this machine has this IP address, or forget the machine to say, initially, we just know IP address and credentials, we've talked about that. What zero trust allows us to do is it allows us to say this machine that meets this criteria so company laptop that's on our active directory, that has our antivirus, that currently has no malware detected, that is managed by this user can talk to this machine over here. It's a ton of different things, but what's nice about it?

Speaker 3: 24:42

Current firewalls, the next generation firewalls. They're constantly checking. So the analogy I use is if you've ever been to a bar with a bouncer, that bouncer initially checks your ID and he's a guy you can go in and then you go into the bar, right, and then it's free reign, you can go, get all the drinks you want. There are some bars that don't have a bouncer. So you go up to the bartender and he checks your ID. He's like I'll give you a drink. You go up, you're like all right, let's order another beer. He looks at your ID, you can get a drink. Next-gen firewalls that's a really inefficient way to check people's credentials. But next-gen firewalls can do that efficiently, right, they're constantly checking does the device meet a certain criteria? So if somebody who's currently on your network downloads malware, for example, a next-generation firewall that's connected with your other security appliance is able to actually stop that user mid file transfer and say, okay, you can't go anywhere else in the network to get it fixed.

Speaker 1: 25:34

That's the new stuff I didn't know. Here's why I wanted to have this conversation, because I'm like, oh, we're just filtering it, layer four or whatever, like I don't need to learn this. But like, holy crap, I didn't realize how many. I didn't know the firewall was talking to other systems. You said active directory. So what kind of systems or what kind of things are talking to the firewall to give it all that intelligence so it can make decisions?

Speaker 3: 25:54

I'm going to say active directory, or I know it from Fortinet's side, matt knows it from Cisco's side. Anybody that's on here that knows Palo knows it from Palo's tools and I can tell you we've got endpoint security appliances that can talk to our firewalls. We've got a knack, just like Matt. They've got Cisco ice. We have Fortinac.

Speaker 2: 26:11

Cisco's secure client. When you connect to VPN, like, all of these things collect telemetry from the device, anything that you're doing. It all becomes a point of reference for what the person is doing on the network and how the firewall should respond.

Speaker 1: 26:27

How are they sharing information with each other? Is it API calls? Is it some other magic? It's a lot of API stuff.

Speaker 3: 26:32

And it doesn't even have to be within the same vendor. So Fortinet can work with Cisco Ice, we can work with Cisco Umbrella, we can work with Duo or third-party MFA solutions. The same is true with Cisco right. They can work with other vendors as well. That's what's becoming really nice with today's security. Though, is today's security stuff is it's a broader platform. So it's you come.

Speaker 3: 26:54

If you, as a network person, get into the world of security, you have a leg up on anybody else who's just been handling the AV and they've just been handling the endpoint, or maybe they've just been handling NAC, because you really understand how everything communicates. And that's the part that, again, I don't want to harp on it, but that's the part I think, as network engineers, we have that others don't have, that are in the security world, because we just know how things talk. We know, for example, you can have multiple routers in an environment, and as network engineers, we can figure out which of those routers was making that routing decision. Other guys just look at it and they just see a bunch of routers. They don't know where decisions were made.

Speaker 1: 27:32

And like layered security is, is, um is a strategy, right. Like you, again, I know that we're talking about some really cool stuff, but even like something as basic as like VLAN segmentation, right. Like if somebody gets into a network and they're they have bad intentions, if you have segmentation, like in my home network right now, everything's in one VLAN. It's very embarrassing.

Speaker 1: 27:53

I tried to segment it. I couldn't get it to work, I gave up. I have to read more documentation. I have a maybe Ubiquity UDM Pro and I tried to do it and then I couldn't access things and I panicked and gave up. There are many layers, right. One of the basics would be like segmentation, like if you have VLANs and everything segmented, hopefully you can't hop. If somebody gets in, they can only access what's in that one VLAN, right, like in theory.

Speaker 3: 28:15

but that's you can. You can even say where did that conversation start? So, for example, I have smart home stuff in my house. I can reach out to my smart home devices, but my smart home devices cannot start a conversation with something on my home subnet. Does that make sense? So I can make it a one way and then you can respond to communication, but they don't get to initiate the call.

Speaker 1: 28:34

If that was that is that because you set up those rules and put everything in subnet? Right, right, right.

Speaker 1: 28:39

So the problem is now, at least for me, which is why I wanted to segment my home network. I have IoT devices. I have all the stuff connected to the internet. I did DNS filtering at one point and I saw just how chatty these things were and how much it blew me away. But if someone were to get in, they can access anything in my Now. Listen, it's a home network.

Speaker 1: 28:59

I'm not housing government secrets or a billion dollars of crypto that you could steal, but it's not a great security posture, right? If you're in, you get the keys to the kingdom, whereas if I have it segmented, like to your point, all my IoT stuff should be on its own thing. It should only get internet access. It shouldn't talk to anything in my house, right, but I don't have that set up because I'm just a route switch guy and I don't know anything about security. I tried and failed. You said something earlier that got my attention and I've heard people say it, but I don't know what it means Deep packet inspection. Can you kind of explain to me what that is and what it does?

Speaker 3: 29:31

Do you want to run with it, matt, or do you want me to take this? I'll let you run with it. So when you look at, just take a website, websites are HTTPS and I'm going to tell you right now you're not going to believe this, but I'm a network guy pretending to be a security guy, so some of this stuff a security guy would be able to really really go into detail on it but essentially, stuff going over HTTPS is encrypted. So you've got encryption. That's happening so that only the initiator of the conversation and the person they're talking to are supposed to be able to encrypt and decrypt that communication. What deep packet inspection does is it puts a firewall in the middle. Smack my own mic here, sorry. Puts a firewall in the middle. The person like me let's say I'm trying to go to googlecom intercepts my package and says, okay, let me see what you're typing.

Speaker 3: 30:15

Okay, you're trying to search my encrypted packet Correct and it's a lot to do with signatures and with help me out in the chat here, guys, which word I'm looking for? I can find it, but I'm actually looking for the word.

Speaker 1: 30:25

They don't know we're teaching them security. Oh, they know.

Speaker 3: 30:29

The little thing with the lock on your HTTPS sites. What is that called? Oh, that thing, pki. If I couldn't remember the word certificate, see, I told you I'm masquerading as a security guy. That's why anybody can do this if you're a network guy. No, the certificates. So essentially what the FortiGate or I'm sorry, I work here, you got to forgive me what essentially the firewall is doing with the packet inspection is it's doing a man in the middle attack and it's decrypting that packet. It's your certificate that you're usually signing things by is actually the firewall certificate, not the end website.

Speaker 1: 30:59

And then, once I decrypt it Decrypting an encrypted packet that doesn't sound very secure. That's why I wanted to dig into this, because I've heard deep packet inspection I had a hunch. It was like seeing encrypted traffic, which breaks my brain, because you're not supposed to be able to see encrypted traffic.

Speaker 3: 31:12

So we'll give it to an analogy instead of the technical jargon, because, again, I'm not great with that technical jargon. Let's say, for example, you and I want to have a secure communication and the way that we do it is I have a little box with a lock on it that you can have a key to lock it and I have a different key that unlocks it. Right, that's encryption. Right, that's how it goes across the internet. What deep packet inspection does is it puts a thing in the middle that says okay, look, andy, if you want to send a packet to Matt, you first have to send it to me. I get to unlock it, I get to see what it says, and then I'm going to lock it with my key and then I'm going to send it to Matt. But how does the firewall?

Speaker 1: 31:46

get the unlock key.

Speaker 3: 31:47

It's because the firewall and the website are doing the actual communication.

Speaker 1: 31:51

So the website communicates with the firewall as a proxy, almost.

Speaker 3: 31:54

Correct, and it's okay.

Speaker 1: 31:56

Yes, well, but so it's a man in the middle attack basically, but Not basically it is. How is that? I understand why that's good for the firewall. If I were a hacker, couldn't I just put a firewall where I want to hack and decrypt everything and be in? I know that's probably not a smart thing to say but yes and no.

Speaker 3: 32:13

The person on the other end has to accept a certificate, so typically on a corporate laptop certificate management with SSL. Inspection is the biggest hurdle for everybody. It's why deep packet inspection is something we should do, but I shouldn't say nobody, but far fewer people do it than should.

Speaker 1: 32:29

But the same people managing the security in the organization with the laptops would have to also be administering the firewalls, because somehow they have to make it all work together. Like you just can, can't come in, put a firewall in and decrypt https, okay because the certificate needs to be installed on that laptop, right?

Speaker 3: 32:44

the certificate that talks to the firewall needs to be installed on the end and the end user's machine it's not a pre-shared key, but same like correct an ipsec tunnel.

Speaker 1: 32:52

We got a thing, we're sharing it.

Speaker 3: 32:53

Okay, all right, all right yeah, again, this is, this is gonna go on the internet and we're going to get completely blasted.

Speaker 2: 32:59

That's why I let you run with it, yeah, but just to kind of like provide some insight on what the firewall is doing. So this gets into the difference between the router and the firewall. The router, or I should say the firewall, you've got those inside and outside interfaces and I actually ran into this as a issue at one of my customers trying to troubleshoot the network. The firewall has CPUs that process all that data and there's internal interfaces basically on those firewalls that as you transition from your inside to your outside interface, the CPU processes the packet. So it's kicking it up to make sure it's matching ACLs or if it's permitted, not permitted, and that's where that deep packet inspection is occurring. So it's kicking it up to make sure it's matching ACLs or if it's permitted, not permitted, and that's where that deep packet inspection's occurring. So if you've got the certificate, this backplane is doing this inspection.

Speaker 2: 33:48

The issue specifically just kind of talk about it was that those internal interfaces can get overrun if you've got a lot of people sending lots of small packets, just like a router interface. If you're getting too much stuff, the CPU starts to drop packets because it can't process fast enough. You just have to kind of reconfigure the firewall, I should say, to process those packets more efficiently. But the firewall is essentially a server where it's processing these packets, it's making sure things are allowed to do it, all the things that firewall does today. These are big servers now that are multi-core, lots of memory, storing all this data, buffering and then sending it out to whatever host or server application you're supposed to go out to.

Speaker 3: 34:27

Are your eyes glassing over yet, Andy?

Speaker 1: 34:29

No, no, no. So last week we talked to Anita Chatterjee, a very brilliant friend who's an EVPN VXLAN expert, and by this time my eyes were glazed over, just because you really got to go slow with me on that stuff. I think because something you said, jeff that a lot of this stuff is relatable to the networking things that we know.

Speaker 1: 34:50

It's kind of an add-on. It's not magic necessarily, and I do want to hit zero trust at some point. But I'm looking at the chat, I'm looking at their like. Somebody wrote something about signatures. I don't know what a signature is. Can you guys like what the hell a signature is? What they're talking about? I've heard it used in security. Is that just the traffic? Like, is it a fingerprint of the traffic? Like what you guys were talking about? Like here's the person, here's their permissions, here's where they're coming from.

Speaker 2: 35:14

I guess that's a signature, like an identity of a similar, similar, like virus scanners had signatures that detect viruses and malware and things like that, like there's, there's like a known fingerprint, that's this is what the, the, the bad actor or the thing would look like and this you should block it because it matches the signature that's kind of one of those broad terms.

Speaker 3: 35:33

It also can mean a couple of different things, but yes when I, when I hear signatures, that's kind of what I think about is, you know, signatures and av and all stuff like that. Again, I'm not really an av guy, I'm not an endpoint person. I tend to be network guy masquerading as a security guy on the firewalls.

Speaker 1: 35:45

But to your question on zero trust, we got zero if we want to get there yet I know that's probably I, I'm right like I well, so I'm reading through some notes that that I took and what made me think of it was you're creating a barrier between trusted and untrusted right. Maybe that's the old school way, with zero trust, and I guess we'll just jump in if we want because we're here, but there is no trusted right. It's in the name, the name is the recipe, but it used to be zones and this can talk to this, but not that. How the hell do we not trust anything and how does anything work? Do you guys? Are you familiar with zero trust enough to like speak about it a little bit?

Speaker 3: 36:19

I can't go back to my bar analogy right. Zero trust is I'm worried about you, Jeff.

Speaker 2: 36:24

There's a lot of bar analogies here it's been a day.

Speaker 3: 36:28

No. But going back to the bar analogy, you've got the bartender that checks it every time. That's somebody who trusts Noah, his jobs and the line. But if you went up and ordered a water, he wouldn't check your ID for that right he's only checking your ID for the thing that he needs to know your ID for.

Speaker 3: 36:43

So zero trust is all about checking and making sure that the machine you're coming in on is safe, that the IP address you're coming in on is the IP address that we expect. The user's credentials are the ones that we're looking for and the destination that you're going to is one that the person that meets all those criterias on that box is allowed to go to. But you don't necessarily have to apply zero trust at every part of your network. So the parts that it doesn't matter. Going out to the internet, I don't care if they're going out to the internet. What I care about is maybe I don't want to go into certain web pages, but that's not zero trust. That's web filtering.

Speaker 3: 37:15

Zero trust is more about are you allowed to traverse laterally inside of my network? And if you are, then I have to know that you're on a safe device. I have to know that your credentials are right. I have to know that the machine that you're coming in on is safe and that's all. Zero trust is, and it's a lot of times I think it gets pitched some product, but it really is is more of like a framework, it's a, it's an idea, and it takes more than just one thing. It often takes some kind of an endpoint plan and then it takes the firewall or some device that's doing the checking in the middle as you try to traverse that network.

Speaker 3: 37:50

Zero Trust is just that idea of checking it constantly.

Speaker 1: 37:52

Do you guys know who started that?

Speaker 3: 37:53

Do I know who started?

Speaker 1: 37:53

Zero Trust. What company Rhymes with Schmoogle?

Speaker 3: 37:57

Oh, actually I didn't know that. Yes, I know you didn't know that Google was. I forgot about that.

Speaker 1: 38:01

I worked a contract and we were creating some stuff. For whatever reason, I went up down the rabbit hole. I was working on some security stuff for cloud. I learned about this 2008 hack of Google and that was the. Google went down for X number of whatever, and it was this really bad thing. As it turned out, they were like well, how do we prevent this from ever happening again? And I can see the lady's face. I forget her name, but she, I think, was like we can't trust anything anywhere and we need to create a framework around that.

Speaker 2: 38:28

And here we are, so thank you.

Speaker 1: 38:29

Thank you, schmoogle for Schmoogle, all right, so zero trust really have I understand firewall more now than I did before? Oh, and one day I just jumped back into my head Did public cloud kind of make securing networks harder? And the reason I say that? I've worked in data centers where public cloud appeared and it just complicated the hell out of almost everything. And I don't I assume it has ramifications in like do you the security, do firewalls care where it's coming from? Does it matter if it's coming in public cloud, or do you just see that as another place? People are coming in and it's not that big of a deal?

Speaker 2: 39:04

I would say it's another source of traffic. It's one more thing that you need to be aware of and I would say just let's look at the public cloud side. If you set up AWS, azure, whatever you have to set up firewall rules to allow things into it. Like it inherently blocks that traffic, deny all, deny all, and even going out it doesn't necessarily let everything out. So you've got to start building rules. So now you need to start setting up not only the rules for what can leave the cloud, but where do you want that traffic to go and what IP should it be coming in on and what IP should it be going to. So, from a complication standpoint, it's one more thing to keep track of, because now you've got these big networks in the cloud and then you've got your network in the on-prem data center that you want to allow traffic and services to flow between these two entities.

Speaker 3: 39:56

I think the other problem with some of the public cloud stuff is that a lot of the network stuff in there is built by server guys who are not security guys and they're not route switch guys.

Speaker 3: 40:08

All they really care about is I just need to be able to get to this and I need this thing to be able to talk to this thing, and a poorly built cloud can allow all of your things to talk to one another.

Speaker 3: 40:20

And I think what often happens is, as people decide to start jumping into an Azure AWS type of environment, they don't think security first on that. They think they're moving their smart guys that understand service and those guys are starting to build things, and now those guys have a little bit more of the keys to the kingdom. They can build a VNet to make things talk to one another, and what I think it's done is it's a little bit letting the tail wag the dog with some of that, the stuff that normally the security guys would protect the server guys from themselves on. If you're not careful they can kind of run amok. So a lot of that kind of comes down to depends on the company, depends on what strategies they have in place. Are they thinking security first. We hear five nines with the cloud and I think people tend to forget that that's uptime, that's not security. The cloud doesn't care about security. They've got some security appliance stuff up there, but it's not the same thing as what you're paying for and I'm not trying to knock cloud- I get the benefit of

Speaker 1: 41:17

it and it's amazing, but as a network person, it made troubleshooting complex, Like three in the morning. You get a call, something's not working and you get on the bridge and you're like where is this application when?

Speaker 2: 41:29

it was all on-prem.

Speaker 1: 41:30

I know what to check and what shouldn't be working when you're in multi-cloud. If you're in four CSPs and you get on a bridge and something's broken, like well, where is this thing and how does it work? Like just so, I'm assuming from a security standpoint. It would also complicate things possibly a little bit, like OK, where is this thing? Or how to.

Speaker 3: 41:47

There's some similar complications in cloud that I think we tend to forget with things like MPLS or SD, when security was kind of forgotten in those because people just treated MPLS circuits as side traffic.

Speaker 3: 42:01

Well, that meant that as people started doing more network segmentation they kind of forgot that MPLS was another venue into their network from sites. That tends to be another place where firewalls don't always sit at the edge of your east-west traffic on MPLS. The same thing is true of SD-WAN. It's why everybody is now talking about secure SD-WAN. The same thing is true of SD-WAN. It's why everybody is now talking about secure SD-WAN. It's all about putting security appliances at the places, trying to put them at the places where there's that possibility of things talking to one another. It's really like your router, your layer three stuff where things could go between subnets. That's largely where your firewalls are, and the cloud makes it more complicated than some of the other stuff does too. That's interesting too, and that's what where your firewalls are, and the cloud makes it more complicated than some of the other stuff does too.

Speaker 1: 42:39

That's interesting too, and that's what happens in these episodes. You're like we'll go 30 minutes an hour and a half later. I'm like oh my God. But you say something which sparks again to the earlier conversation, like where to put firewalls and what traffic are we inspecting? So if you're running microservices and 80 filtering the server to server services coming up and down, or are you like you might?

Speaker 2: 42:59

right, so on you. How big that, I guess that microservices environment.

Speaker 2: 43:02

Right, and so what that microservices environments like? What is it? Two different microservices environments talking to each other? Should they be talking to? Even going back to vxlan, now you're getting into service chaining with the firewall, where you're allowing a vtep to talk to another vTEP, or I should say, a VNI to talk to another VNI, but it has to pass a firewall before it can even process to the next segment of the VXLAN network. So again, this is where the firewall has evolved to. It's not just sitting at the edge of your network, it's sitting in the middle of your data center. Now, so it's not at the edge of the data center, it's in the middle of all the eSports activities.

Speaker 1: 43:37

I would hate to see a modern firewall request for this next gen thing that we just like. So if you're running an application with a microservice architecture, like again, the old school was like here's my IP, here's the TCP ports I need done, I can't imagine what the request looks like.

Speaker 2: 43:57

Well, here's the 72 services that this has to talk to, for this application to work Like and by the way.

Speaker 1: 44:00

Is that? What is that what those requests look like? It's a lot of. They have to be more. They have to be longer than they used to be Like, or maybe there's somebody there's still similar, at least I think they're still similar.

Speaker 2: 44:10

I'd say the bigger issue is you get into it's not just a data center now, because you've got these multiple points. You've got the middle of the data center, the edge of the data center. What if it wants to talk to another data center. So you've got multiple locations where you're managing data. So there's more firewalls in the path potentially to a host. For a network engineer, it's valuable for them to understand that device on their network, what it's doing, what it's protecting and how it with their network. So hopefully network engineers are managing them and they're getting good direction from their security people of what things should be allowed in the network, what things should be dropped, permitted, et cetera. But it's definitely evolved quite a bit.

Speaker 1: 44:52

What's the career trajectory? Like would you want to be a CISO someday, aren't they like the CEO of no, okay, no, but Like would you?

Speaker 2: 44:57

want to be a CISO someday, aren't they like the CEO?

Speaker 1: 44:58

of no, okay, no, but they're like. They're the ones that set all the policy. Is that correct? Like in big organizations?

Speaker 3: 45:03

So Matt was saying something that maybe I think if you don't work in this world at all, you may it may be easy to misunderstand. So he's talking about the security people. The security people are not the firewall people. The security people are the ones that are setting up the policies. They're the ones that are saying here's what we need to make sure we have visibility into, here's what needs to be allowed or not allowed. That's a group of nerds who loves data. So the firewall guys, we're the cable guys, like you started.

Speaker 1: 45:33

We're the guys that are the network guys, you implement the stuff right, like they're almost like security architects. I would say right like the architects, design yeah and give it to the and they're not even.

Speaker 3: 45:43

They're not even designing it architecturally from a they're. They're even higher level than that. They are very much. They don't know how you're going to do it, whereas architects tend to know how you're going to do it because they had to get there. These are the guys. I don't know how you're going to do it, but here's what I need done. I need to be NIST compliant, or I need to meet this set of standards, or I need to be able to pull records from such and such as email from four years back. They're the ones that come up with impossible tasks. We're the ones that have to figure out how to do it.

Speaker 2: 46:07

And it's interesting because you asked if I'd ever wanted to be a security professional, and to that point where the security people are kind of making these wild things, like, hey, I want you to do this. Wait, it's not going to do that. It's not a magic box, it could just do these things. I had thought about a career of getting into being more technical as a security engineer and helping people understand, like, hey, here are the technical limitations of the device and what it can do, because it's just one of those things. It helps to have that experience and background. And then I realized I don't want to deal with security. I like protecting things and making things secure, but I don't want to be in that kind of day-to-day of creating policy.

Speaker 1: 46:46

Daniel Pelfrey in the chat just said something that kind of rung true for me. He said you need to understand the workflow of your application, whether on-prem, hybrid, whatever. And again I don't mean to sound, I don't want to come off a certain way, but in my experience the application people would submit the firewall requests and then they would go to test and things wouldn't work and they'd say the network was broken and in the end it seemed to be that the application people didn't know what they needed to submit to get the right. So you guys in your careers, do you find, see, there's a disconnect and this is like a higher order bit that I want to talk about in other episodes but the disconnect between application folks and network folks. And I'll throw security in there, right, firewalls, cause it's you're traversing the network.

Speaker 1: 47:26

But if application people don't know what they need for their application to traverse the network and we don't understand application people like that, unfortunately it was just that disconnect and we're on troubleshooting calls until we do a packet capture. We're like, oh well, this is, you didn't submit the thing and you need this port open, like so when daniel said you need to understand the workflow of your applications, my experience has been the application. Peoples do not understand enough networking half the time to know what to even submit no firewall requests. Have you run like you've run into that right, like the network's broken? We submitted what we needed. Well, you submitted what I guess you thought you needed.

Speaker 2: 47:57

But right, yes, and the firewall is going to tell you they're going to start sending, let's say, an application flow and it's supposed to go through the firewall. Well, you might see permit, permit deny, if you're monitoring that traffic and you're like, oh, hey guys, you didn't put a request in for this one thing, and that's the one thing that's keeping their application from working. 100 yep. So then they go back and they submit and policy is pushed through.

Speaker 1: 48:20

We've been going close to an hour so I'm going to quick fire a couple of things I just wrote down so we can get there. So I don't have you guys on this time.

Speaker 3: 48:27

it was a tough question, Matt. I'm handing it to you.

Speaker 1: 48:30

All right, well, I wrote down application awareness, but I think we kind of talked about that right, that's Jeff when you were talking about like, well, you can get on Facebook but you can write this but read that, or so somehow the firewalls maybe I should shut up and just ask, like, what is application awareness? Did we cover that already? I wrote it down because I wasn't clear on it.

Speaker 3: 48:47

Application awareness could be again, depending on what you're wanting to do with it. If you want to block or allow, that, that's the simplest firewall thing I could say. I want to block any type of a proxy application, right. So that's an application, is proxy stuff that someone might normally go to circumvent my firewall policies. That's an application that I can be aware of. But I'm not going in and trying to name every proxy application. Typically it's a category that I'm clicking. That's why next-gen firewall, the application aware stuff a lot of it is behind the scenes nerd magic that as the network guy I don't necessarily I can look up what application belongs to what category and that kind of stuff. But realistically I'm applying, I'm applying a category filter or I can get right.

Speaker 3: 49:29

I can say that's the kind of stuff. Application is some of its applications, like ring central or stuff like that. You may want to do specific traffic steering. One of the things that firewalls can do and routers can do it too but is policy-based routing where I can say, based off of this source and this destination and even this application, you get to go out this route. So maybe something that that's like voice, it's going to be super sensitive to jitter. I might steer that out. A different interface. That's something a firewall can do because it's application aware.

Speaker 1: 49:57

So you said voice and that just was a perfect segue into one of these things I wrote down. So firewalls slow down the network?

Speaker 1: 50:03

No, no, they don't, but like there's processing overhead and like well, right, so, void, you got to get there, right. So I guess A can firewalls slow down your network connectivity, like I know, when I connect to a VPN, my connection gets way slower right Because of the overhead I get. There's work being done. Are you filtering voice? It's UDP. Do you just let everything go because it has to be real time? Is there filtering of voice traffic? I've never filtered it.

Speaker 3: 50:26

You can, but I mean you don't. Because you typically know the source, you typically know the destination and they end up being trusted source, trusted destination. So you aren't going to do a ton of inspection, right?

Speaker 1: 50:38

So I'm going to build a separate policy for that application, okay, but, like, with the right kind of design, the right kind of box, you've spent enough on the hardware firewall. Like, shouldn't slow down your network.

Speaker 3: 50:47

There's always going to be some type of an impact and the only reason is because it's inspecting something. Now you can do some stuff where there's no inspection and it should be fairly line speed Right, but a router slows down every time there's a hop. You're going to take some kind of a hit. It's overhead, right, you're doing work, it's going to all depends on what you're looking at and what that firewall is trying to do.

Speaker 1: 51:07

OK, I wrote down threat intelligence, but I don't really have anything intelligent to say about it or know how to ask that question. But I saw the notes and does that mean anything to you? Or this is just something we'll ignore? Like what does that mean? So a couple of concept like yes, firewalls detect threats. Like what is it?

Speaker 3: 51:23

So we kind of go back to what Matt was talking about earlier with some of the stuff in the next gen firewalls. When I think threat intelligence, I think something like the Cybersecurity Alliance. The Cybersecurity Alliance is a partnership between Cisco, palo Alto, fortinet, juniper you can look it up. There's a bunch of others, but the Cybersecurity Threat Alliance or I'm probably getting the name a little wrong that is a place where all of these security vendors are starting to share their threat intelligence. Threat intelligence is what we gather by having boxes out in the field. It's saying I've seen that one before. That's a bad website. Or I've seen this signature in this file before. We know that that's a virus.

Speaker 2: 52:01

Or I've seen this type of behavior, exactly ransomware.

Speaker 3: 52:04

That's your threat. Intelligence, that's the stuff that your devices are learning and AI is really accelerating that, because it's not AI like large language models. You're chatting with it, although that's coming too. A lot of it is the ability for those devices to learn that, to update a centralized database that can then be shared with other vendors and say, hey, we're kind of all this together to keep the bad actors out.

Speaker 1: 52:30

Here's our threat and that's the thing. Like everybody, there's a common database Absolutely To secure everything.

Speaker 3: 52:34

It's typically every vendor is going to have their own, but they do share across them.

Speaker 1: 52:38

It makes sense to not silo that information right. It makes the whole community safer. Sometimes I ask questions I'm embarrassed to ask but what is a DMZ? I know it's a demilitarized zone, but like what is that? Why do you use it? Like, does that mean there's no security there? Like, is that the wild west of the internet?

Speaker 2: 52:56

It's a magical place in between your inside and outside networks.

Speaker 1: 53:00

And you can actually understand.

Speaker 2: 53:01

So the DMZ is kind of like, let's say you've got people coming from the outside the Internet, whatever, maybe you don't want them on your internal network, maybe you have a special area, special networks system data center that you want them to go into. The DMZ can be the shared resource so people on the inside can come in and go to the DMZ and access resources. They provide customers. But when the customers come in, instead of coming into your internal data center they get steered into the DMZ, where all the services and applications that they want to access are available to them.

Speaker 3: 53:36

It's often the place where you it's your public facing often. It's often where your DMZ it's your public facing often. It's often where your DMZ is Kind of that public facing or that section where there's not a huge expectation of a ton of security and you're kind of aware it's a little bit of the Wild West.

Speaker 1: 53:52

I apologize but I'm still not getting it and that's partially because Jeff and I were making cute googly eyes with cups as you were talking.

Speaker 3: 53:58

I apologize.

Speaker 1: 54:00

It's a place you said it's between the inside, like the trusted and the untrusted, or the inside outside.

Speaker 2: 54:06

So let's back up and go. It's another trusted area, but it doesn't sound trusted right Like is it.

Speaker 1: 54:11

It's less trusted, and why are we creating a less trusted environment? What's the point of a DMZ?

Speaker 2: 54:20

creating a less trusted environment. What's the point of a DMZ? So our most trusted environment is generally where our most sensitive data is sitting our clients, our servers, whatever but we may have data that comes from that internal network that we want to share with another set of systems on our network that customers need to be able to access. So generally, the security rules of a firewall allow anything from a higher interface to go to the lower. So you update databases from your higher interface to your lower, to the DMZ, and then when customers come to access their data, or when people come in to use your tools or in your environment, the DMZ is where they go. So it's kind of that playground for them to do things where they're not doing anything to your internal network. And then if there's things in a DMZ that need to be pulled back into your internal network, you've got specific systems that are allowed to process that data back up to the more secure internal inside network.

Speaker 3: 55:13

A couple examples Website right, you're hosting a website. You might want to put that in your DMZ. I guess someone going to your website isn't getting they're not bypassing your firewall to get into your network. I shouldn't say they're not bypassing your firewall. They're still going through your firewall to get to that DMZ. But that DMZ is a separate network. It's isolated from the rest of your environment. Dns if you have an external DNS, that external DNS might sit in your DMZ. You can get to that thing and things can be looked up there.

Speaker 2: 55:42

But they're not getting into your network to see that stuff and another way to look I was going to say another way to look at it is maybe don't even consider it a DMZ, maybe it's just you have different tiers of customers that you allow access to in your network and those different tiers of people have different levels of access. So it might be security level 50 and everybody goes there, and then you've got 60, 70, 80, all the way up to 100. And the rules and things that you're allowed to get to are based on all the different things we've talked about tonight your identity, where you're coming from, what you're allowed to have access to, and it's just these controlled areas on your firewall that are just separate, isolated networks.

Speaker 3: 56:19

I host a Minecraft server for my brother and some of his friends that sits in my DMZ right. They can get to it. They have to have credentials to get to it, but even once they're there they don't have access to the rest of my network so they can get to a public-facing resource like a web server or Minecraft server or something like that, but they can't get in, they can't get to your inside network.

Speaker 1: 56:40

It's an island, it's segmented off. So I see the purpose, but that doesn't. That doesn't increase your attack surface. Like now, they're in your firewall and they, like they're not closer to getting in. Like they're, they're not getting in. That's it. You can't get through the DMZ.

Speaker 3: 56:54

This is the stuff that they have to be able to have access to, right, if I'm hosting a website they have to have access to that website, but if they somehow have-.

Speaker 1: 57:00

Security vulnerabilities or like bugs or whatever the hell like. Can you hack through a DMZ and get inside under certain circumstances, like, are you at increased risk by having a DMZ zone? I guess is what I'm trying to get at. Are you putting your company or you need a DMZ, you have to have one. This is the way it works, right? You don't?

Speaker 2: 57:19

even have to have a DMZ. You could just have an inside-outside and call it a day. But a lot of that comes back to how you design your network and your firewalls and what people are allowed to do on those systems. If they can sit like, say, we SSH from the outside to the DMZ, if there's some rule that says they get on a server and then they can SSH into the internal network, well that's a hole that was in the firewall that allowed the attacker or whoever to get in. And that gets back to application flows, how you design an architect, how people should be able to access your network and your devices and making sure that you secure your boundary. You don't want to have a hole in the firewall where somebody could accidentally get into your DMZ or purposefully get into your DMZ and accidentally end up in your internal HR system.

Speaker 1: 58:06

So this is all very helpful, thank you. And it's one of those terms I've seen and I've just never been brave enough to ask, especially in a public forum, because I feel like we're all supposed to know what a DMZ is at this point in our careers. So the last question I have around that, and then we can wrap it up with my final question. So like if I'm hoax, let's say I want to host a blog for my server I have at home right and I want it to be publicly accessible because I want people to read my brilliant words. That would have to be in a DMZ right. It's something I want publicly available to people who can hit it, but I don't want them to get into my network, as an example.

Speaker 1: 58:37

But in my mind, if I'm opening my server up to the internet, that doesn't seem safe. Great, somebody is going to get me somehow in ways I don't understand. But is that just? I guess there's other security parameters you're putting in place so people don't get to your server to read your blog and destroy your server right. As an example, like layered security, like we were talking about before, just because my, just because I have a VM running on my server hosting a web, a blog, and I put it in my DMZ to protect my inside but allow access for outside people. That doesn't mean somebody's going to come in and crush my server.

Speaker 1: 59:09

The worst case they're going to do is somehow log into that VM, destroy it, and I'll just replace it right now.

Speaker 3: 59:12

As a network guy, I think of a DMZ, another subnet, right, you're just putting them into a different subnet.

Speaker 1: 59:17

That subnet's not allowed to talk to your main home stuff right, like opening resources to the wild west of the internet and something called a DMZ just sounds scary to me, but that's what we do. That's how it works. Well, it's because you have something you do have to make publicly accessible, so that Not necessarily the service sitting on that web server.

Speaker 3: 59:41

They're still going through a firewall to get to it, they're still looking at rules, they're still mainly going through an IPS, that kind of stuff. But in the end you are aware this is a publicly facing utility and with it being publicly facing, I don't want there to be a way for them to get there and I keep smacking this mic To get to the DMZ or the server that's on the DMZ and then back into my really valuable stuff.

Speaker 1: 1:00:04

So I know I keep saying I'm done with DMZ. But last question Amazon is an example Amazoncom, when I go shopping. That's a publicly available resource. It's a website sitting on a bajillion servers. Somehow that's in their DMZ. Right, cause it's publicly. Can we make that leap? Is right because it's publicly like.

Speaker 3: 1:00:23

Can we make that leap? Is anything publicly accessible on the internet probably sitting in a dmz? If it's managed properly from a security posture, probably gonna be dmz to death. But um, if you were to hack their server that hosts that application that is amazon, the chances are you could not ping their ceos. A laptop right that helps.

Speaker 1: 1:00:34

unless you're jeff or matt, what you're doing, all right, is net net security I see people argue about like it's not a security, just because you're not something, you're not hiding anything. We're changing the outside to the inside address, right? Like, is that a layer of security? That's why I asked. I knew it would annoy you.

Speaker 3: 1:00:50

I'm sure there will be somebody that has more knowledge on this that will completely blow what I have out of the water, and I just hope they don't see this. From my experience, it's an aspect of security, but it's not Just because you're changing your outside address to a different address.

Speaker 1: 1:01:06

Doesn't really you're?

Speaker 2: 1:01:07

not securing that resource. You can do one more layer. The NAT can act as one more layer of security for things as they transition out. So by function, the firewall can add security to the net translation. But in and of itself, all you're doing is creating this stateful connection between the inside network and what it was translated to to go out to the internet, and that you've obfuscated what was on the inside.

Speaker 1: 1:01:32

Oh, you said obfuscated I know, right, that's the word you talk about when you talk about this thing is this do it?

Speaker 2: 1:01:38

is this the word of the day?

Speaker 1: 1:01:39

It is, you win. Whoever said obfuscate wins this round and you won. This has been really informative for me, and hopefully the folks listening or watching were able to learn some things too. Is there anything that I probably should have asked you that I didn't Were you like? Oh, andy, you really should ask me such and such. I have so many questions. I don't know if I left anything unasked, but is there anything you guys want to add or put a point on at the end here?

Speaker 3: 1:02:03

I just think one of these days, what we have to be able to do is share our screens, and then we'll just help you build a firewall policy. That's what we need to do. What we need is for one of these episodes, instead of us just being in action, and then you see it block that ping and you see it allow that ping. You're like, oh okay, that makes sense.

Speaker 1: 1:02:20

Well, let's do that because I and then matt, I'll let you go. But there's some changes happening in the show and we'll talk about it some other time. But we just had a nindo on talking about evp, nbx land and then I was speaking to him yesterday and he offered to come on here and start teaching it and labbing in and going through it. So I kind of like the format of hey, we talk about security here, we're talking about firewalls and then maybe do either another shorter episode or maybe a series of like all right, let's build a policy, let's try to do some things A little more technical content, maybe some labbing, and we can take the concepts we talked about, make them real and make them tangible.

Speaker 3: 1:02:50

Learning with laptops. If you're game for that Jeff.

Speaker 1: 1:02:53

I'd love to, and, or Matt I, I'd love to do something like that. What were you going to say, matt? I'm sorry to cut you off.

Speaker 2: 1:02:58

I was going to say it sounds like a great CML episode on how to use an ASA or how to build a DMZ, and why would you build a DMZ?

Speaker 1: 1:03:06

Awesome Guys. Thank you so much. This was informative and educational to me. This is my favorite part of the show is I get to learn something every time with some cool people joining. On YouTube.

Speaker 1: 1:03:15

You can find all things Art of Network Engineering on our website, artofnetworkengineeringcom, but we have a link tree, linktree, forward slash, Art of NetEng which takes you to all the things. There's a merch store, there's our website, there's all the social media links. What I like to point direct people to every time we talk about it is our Discord server. It's all about the journey. Discord server, Thousands of people in there. It's a community. One's pretty much studying something right, Because we work in tech and it never ends and everything's evolving. If you don't have a community, I would recommend you get one.

Speaker 1: 1:03:44

What I love about this show and what became the Discord server is it's the community I wish I had when I was coming up and sitting in my cable guy truck and all the cable guys telling me I was wasting my time, money and effort studying for my CCNAs. I to see all these people in there lifting each other up, helping each other out. That's pretty much it. Check it out. Thank you very much and we'll see you next time on the Art of Network Engineering podcast. Hey folks, if you like what you heard today, please subscribe to our podcast and your favorite podcatcher. You can find us on socials at Art of NetEng, and you can visit linktreecom forward slash Art of NetEng for links to all of our content, including the A1 merch store and our virtual community on Discord called it's All About the Journey. You can see our pretty faces on our YouTube channel named the Art of Network Engineering. That's youtubecom forward slash Art of NetEng. Thanks for listening.