My Honest, Unfiltered Thoughts About Big Firewalls!
Hi. Max Clark. Let's talk about a mistake I've seen companies make for 25 years, and that mistake is buying big firewalls. These are those big, sexy, enormous boxes that have incredible specs and features and, you know, have gone through all the different test labs and can push a bajillion, you know, packets per second, maintain 1,000,000 VPN endpoints and do this and do that and do the next thing. And the point is is who cares?
Speaker 1:You don't care. It's probably just ton of money for you don't need it. Right? And again, this comes from my personal experience of building networks and data center infrastructure and applications and blah blah blah blah for over 2 decades, 25 years. And let's talk about what firewalls are and what people buy them for.
Speaker 1:1st and foremost, people buy firewalls to be a NAT device. Right? They're running private IP space on the inside of the firewall, and they're running public IP space on the outside of the firewall. And typically, they have far less public IP space on the outside of the firewall than they do on the private IP space on the inside of the firewall. So now you need to create NAT rules.
Speaker 1:And by the way, let's get really specific. 99% of the time, you think you're creating that, you're really doing what's called port address translation because your firewall rule has something that says anything inbound going to the Internet, translate to this one IP address and just use a different port and then do match port matching. So let's get really nerdy here and just call it what it is, which is pat and not nat. Nat is a translation of an IP address on the outside to the inside. And then you can do other fun stuff with your firewalls, which is like you can have public IP address with port 80, go to a web server.
Speaker 1:Hopefully, you're using SSL support 443, go to the web server, and port 25 goes to your mail server. And you're actually using, s s you know, encrypted email TLS. Your port 8587 go to the mail server, and you got, you know, yada Yeah. Yeah. Okay.
Speaker 1:So majority firewall is implemented deployed are net boxes. What is a firewall? A firewall, it gives you the ability to set and enforce policy of traffic flowing through it. So you have an ACL that gets implemented on this firewall. And depending on the make and brand and type and generation and whatever of the firewall, how you build these NAT rules out, they do these policies.
Speaker 1:They do different things. They apply and they work slightly different. And again, 99.infinity nines of firewalls in the market have a rule that says allow anything from the inside to go anywhere on the outside and net it. Right? So and do okay.
Speaker 1:So you're setting policies. And so then you're, you know, you get sucked into this, like, you know, the sexy mistress of having, you know, DMZs and segmented networks inside of your it's that you don't just have one, you know, network on the inside. You've got now you start doing VLANs. You got a server VLAN. You've got a printer VLAN.
Speaker 1:You've got a this VLAN. You got DMZ. And, you know, if you're if it's a web application, then you start talking about how you're doing load balancing between your application stacks and how full what flows through and yada yada yada. Right? So this gets this lots of squiggly lines happen very quickly.
Speaker 1:I try to keep myself restrained and keep this at a at a higher level. Okay. So firewall does policy enforcement for you. Firewall typically does a VPN endpoints for you. Usually does it horribly.
Speaker 1:If you've ever configured VPN on a Cisco ASA, it is the dark arts of configuring VP, you know, like, trying to I mean, and and I will tell you the overall majority of network engineers that have configured VPNs on an ASA will get it to work and have absolutely no idea why it's working. And when it stops working, have no idea why it stopped working and then starts working and they have no idea. I'm in that category. The ASA, even with the bugging turned on, you start going through stuff and you start talking about, you know, IKE exchange and all this different stuff. It is like there's a reason why GRE is so popular in the Cisco world because it is so much easier to implement and actually turn on and debug and figure out what the heck is going on with it and trying to do IPsec.
Speaker 1:But then you also have to talk about is IPsec. Is it point is it device to device IPsec? Is it device to end user v, you know, VPN? Do you have a remote client? Are you doing SSL VPN VPN through my client?
Speaker 1:Yada yada yada. And again, you've got some sort of device that has to authenticate, and then the firewall has to create another pool of IP addresses for that, you know, if it's a remote user for that remote user that then applies policy that says this. Once this remote user authenticates, creates a VPN session, gets its IP address, now it has a policy can go inside your network. A little little segue. This is I think why part of the reason why Meraki got so popular.
Speaker 1:But, you know, Cisco bought Meraki. Why can you still buy, you know, the ASA, the the firepower, the the the PIX derivative, and you can buy Meraki? They do different things for different people. One of the things that Meraki does very quickly is, you know, point click click click click. Boom.
Speaker 1:VPN turns on. Very nice. Meraki is not SD WAN. Meraki is auto configured VPN. Just a little segue.
Speaker 1:Okay. What else do firewall manufacturers sell you? Firewall manufacturers then sell you again, this is the other sexy mistress that they sell you is deep packet inspection, DPI, and UTM, so threat management. And the DPI and UTM implementation is a similar experience if if you ever decided to install some sort of IDS IPS on your network where you turn the thing on and guaranteed you turn it off almost immediately. Right?
Speaker 1:Because it is spewing junk out at you that you have no idea what to do with, and it makes no difference. And it cripples the performance of the device, and everything just goes belly up and you're like, why am I running this thing and you turn it off? And I laugh every time I see specs or get into conversations and people start talking about how many you know, what their what their DPI or UTM like thresholds are. Because it like, almost universally a meaningless metric. Okay.
Speaker 1:Other issue with firewalls. So now you've got a box you're pinning all your traffic through. So as your traffic increases, the size of that box has to increase. And if you're doing very basic policy, let's just use data set. If you're doing a data center example, most likely you're running a Linux derivative operating system which has a firewall built into it, and you can run firewall policies on the box.
Speaker 1:And you're not doing WAF and you're not doing DDoS mitigation on your own infrastructure because you just don't have the capacity to do it. Running the firewall, running IPFW on the Linux box is gonna give you the same amount of policy that you're already doing on your firewall, which is gonna say accept port 8 and port 443. You can put that on your switch, and you can put that on your router. You can create policy in AC on your router that says only allow port 40 and port 83, and all that traffic's already flowing for the device. And by the way, you can't do a lot of policy on a switch on a layer 3, you know, by the way, was every switch is a router at this point because they do layer 3.
Speaker 1:We won't get into that nuance too much. But you can set basic policy on it, and you can cover almost all of what you were doing with your firewall on your switch by setting the policy on the switch, and you get more performance throughput. You don't have this extra really expensive box that you have to maintain. Other issue with firewalls. Now you've got a box.
Speaker 1:You have to maintain. You have to buy the box. You have to buy support in the box. You have to update the box. Right?
Speaker 1:If you're running Barracuda, you know this pain recently because Barracuda had an issue and they said, hey, we can't even update the box. We have to replace physically replace the box. Now as the amount of boxes increase, the complexity of maintaining and updating that box increases exponentially as well. If you're running the boxes in high availability the complexity of that increases as well. Let's say you're a medium sized retailer and you've got 500 stores and you wanna run because your stores are so critical to you that they can never go down.
Speaker 1:You'd have a 1,000 devices in the field that you have to purchase, configure, ship, install, update, monitor, maintain firmware patch, power cycle, test times a 1000, and they're in remote locations that you don't have physical access to all of the time and you've got somebody at the store that you have to say hey you know coordinate go get this person to go do this work over here on this device is that the world in the life that you actually want to live in and the answer is let me be honest the answer is just no the other issue with firewalls that I absolutely hate is the second you put a centralized infrastructure in place and you have remote users by the way I don't care if you're on the work from home the w t h or the return to office RTO side of these things the reality of the world is there's always going to be a large remote workforce going forward. You know what percentage it is and what your rules are and how often do people have to be in the office and how long can they be out of the office and all these different things.
Speaker 1:I mean, who knows what's actually going on with that? But the reality is, is now you have to account for a large remote workforce and that workforce is mobile and they have lots of devices. So if you're running infrastructure that's based around the idea that you have a large firewall and by the way, there are firewall manufacturers in the market today that are going to sell you their sassy solution. And their sassy solution is taking your remote user and pinning it to a data center or to your main office to their big firewall and then sending out to the Internet. Okay.
Speaker 1:Great. So now you have a centralized resource that all your remote users have to have to connect to, and you're running, network architecture circa, you know, 2,000 late. Right? But as the distances and first off, as the quantity of your remote users increase, the load on that firewall increases with it and the performance of it decreases and the efficiency of it decreases and the cost of it increases. You know, like, these are bad things.
Speaker 1:You don't want, like, that seesaw to happen. You want predictability. Right? You know, it'd be really nice to be able to say, hey, as our utilization increases, like, our actual cost per unit decreases, like, those are good situations to be in. But let's just use basic stuff.
Speaker 1:Right? Like, let's say you're in, a New York based company. So you have a New York based really big firewall, and you have a satellite office in the sales team on the West Coast. Right? Really, what that means is that you have something in Southern California, something Northern California, and something probably in Seattle or Portland.
Speaker 1:Right? Those users traversing from the West Coast to New York and then back to stuff on the West Coast, it's a hard experience for them. And by the way, it's now gonna be a hard experience for the business because those people productivity is gonna suck. They are gonna be I don't say scrumptled morale is gonna go down. Your best case scenario is you, you know, I don't know.
Speaker 1:It's best case. Like, you're gonna lose the top people and the people that are gonna accept that reality are not like high performers. There's gonna be, like, hey, you know, whatever, you know, like, we can just come in and do whatever our thing is. Right? Now you've got people and you wanna go international and you wanna establish operations in South America.
Speaker 1:Right? So you you're moving into the LATAM market or, you know, you go and you have a European play. Now you got a pin traffic or Asia. I mean, like, I mean, Europe and New York, like, even worse financial services in New York and, you decide to, you know, be shed into to Tokyo or into Australia. Like, holy moly.
Speaker 1:Like, it's just not good. This architecture is a this is just the way it's done argument. Like, oh, we're supposed to do this because this is the way it's done. This is the way it's always been done. This is the way that our auditor wants it done because they've never seen anything else because they're still, you know, stuck in, you know, 97.
Speaker 1:By the way, in late what year was this? It must have been, like, 98, 99. We were going through a PCI audit, and the auditor told us that we needed to have a firewall in between our web server and the application server and another firewall in between the application server and the database server. And I wouldn't say that I lost my cool, but I lost my cool. Right?
Speaker 1:Like, the application server has the passwords to connect to the database server and to do stuff on the database. Like what is a firewall in between the application server and the database server going to actually do to improve our infrastructure? And what threat or risk are we actually mitigating? Because if somebody gains access to the application server, they have access to everything on the database server everything that's valuable they already have access to what is the point here well it's what you have to do the answer was well it's what you have to do I think that's when I started really hitting like this idea of like firewalls everywhere I mean load balancers early 2000 you got to this crazy thing you know cockamamie stuff of like how you load balance firewalls and maintain session state between them to scale out your firewall infrastructure because for some crazy reason, you need to have 6 firewalls running. So you need to have a load balancer in front and behind the firewall in order to make do session state maintenance on the firewall to then come behind that and then go to your app.
Speaker 1:I mean, like, nobody is gonna draw this on a whiteboard and say this is a good idea. Let's step back. I did not coin this term. A friend of mine, you know, explained how they were designing their network, and they looked at it. He was just like, our offices are Starbucks.
Speaker 1:You know, I don't care if my users in an office or if they're at a Starbucks or if they're at their home. It's the same infrastructure for us. Our responsibility in our office is to provide stable and fast Internet. And that is it is not a policy engine. It is just a location.
Speaker 1:It is not like a castle. You know? And Google really pushes us with BeyondCorp with the idea of of 0 trust, and this was the like, all these things were kind of taking place around that time. But the point there and the important thing about it is associating a location with safety is just not true. You can't say, oh, we have a perimeter.
Speaker 1:We have this firewall. We have an office. And if you're in your office, we're trusted. We trust you because you're in the office, and we're safe. Light bulbs and fish tanks have been hacked to gain access into corporate networks.
Speaker 1:Like, because it's physically in the office does not make it safe. Again, big thing for with firewalls. And this is really the promise and what I mean, SASE as an architecture is great and really comes from a place around, like, integrating all this stack together into one thing. Right? So, you know, you get your firewall and you get your remote access and you get your SD WAN and you get your, you know, circuit selection, path selection, and you get your MPLS OTT and all these different things.
Speaker 1:You can, you know, slam it into one thing, and now we're gonna call it Sassy. And I agree and I like that. You know it's great you know from a surface of like less stuff is better you know less stuff that you have the better off you are but the real value for sassy for me is just this push towards a real modern security infrastructure related to how you do policy and entitlement enforcement across your devices and your users regardless of where they are we're now a user that is in Tampa Florida is connecting through a resource that's optimized for them out of Tampa floor probably they're connecting they're gonna be up Atlanta you know or Miami who knows like something that's physical it's close to them and that platform is not a physical box in your data center that you have to maintain or in your office that you have to maintain you have to update that is maintained by a service provider that has a team looking at traffic flowing through these things aggregate across their network real time and can apply updates like, hey, this log for j thing is a problem.
Speaker 1:Let's push an update out across our infrastructure to prevent a log from j from being exploited for our customers. Like, if you look at the time to I don't wanna say resolution. Resolution is not the right word. Let's just say time to fix. I'll just say time to fix.
Speaker 1:Right? If you look at the time to fix for that for a modern, like, real sassy platform versus an enterprise running let's just make it easy for the enterprise. They have, 15 offices. They're running 30 firewalls. The time it takes for the firewall manufacturer to create, test, and publish a fix, and then push it out.
Speaker 1:And then for that enterprise to change management approvals, scheduling an actual deployment of the I mean, it's you're talking like same day, a month later. What's your threat profile in between those two points? I can rant about this all day. I'm not going to. You wanna rant about it with me?
Speaker 1:It's one of my favorite rants to talk about. Give me a call. Let's rant about it. If you have any questions, comments, you wanna get on the rant as well, comment below, and I'll get back to you. Max Clark.
Speaker 1:Have a great day.
