Live data from Hacker News

Why firewalls won’t matter in a few years

etherealmind.com

121–130 of 139 posts

Re: Why firewalls won’t matter in a few years

#121
post #56

I'm not sure I agree with the argument that faster line rates creating a speed limit for firewalls. It seems like firewall hardware could parallelize internally at layer 3, sharding by source/destination IP or port, so all packets from a single flow will go through the same processing core, no? This would add a finite latency, but I don't think it would impact throughput. Am I missing something?

Firewalls today are able to filter at line rate for a single flow on an interface. If you want to allow 100G by handing 10 10G flows in parallel this is completely possible, but not quite the same thing.

Delivering this function is very costly, because of stateful inspection you must implement flow sticking which require buffering which then impacts performance

..... and so on and so on.

no, doesn't work.

Re: Why firewalls won’t matter in a few years

#124
post #5

The presentation audio quality is really unfortunate, I'm interested in the subject but it sounds like I'm listening from another room.

maybe you should pay to go to conferences ?

And maybe you could sponsor my travels.

I was simply pointing out that the audio could be better in case it would be a deal-breaker for others, or in case another source was available. Sometimes pointing out a problem is the first step to finding a solution!

P.S. The content is incredible and the presentation was great, I was just trying to help the audio from detracting from the overall excellent quality.

Re: Why firewalls won’t matter in a few years

#125
post #60

Earlier quoted context omitted.

Think of a blade chassis in a datacenter. If blade1 needs to talk to blade2, running it through a firewall means that the communications needs to flow out of the blade back to the datacenter network (ie. flowing north to the top of the rack switch). That adds latency and requires more network and firewall capacity, as all traffic needs to leave the chassis. If there is no firewall requirement, traffic flows east/west…

"If blade1 needs to talk to blade2, running it through a firewall means that the communications needs to flow out of the blade back to the datacenter network (ie. flowing north to the top of the rack switch). That adds latency and requires more network and firewall capacity, as all traffic needs to leave the chassis." For years (15 ?) I have been putting very simple, very small ipfw rulesets in place on non-firewall…

Indeed. But the view of the NetSec team is that you server is not trusted to secure itself.

If every service in your ecosystem implemented ipfw rules (or equivalent) then that's great. But if your box got popped, then can I be sure that it won't be used as an attack vector for other machines? I will turn off the ipfw ruleset locally, and start connecting out to other systems. If there was a firewall sitting there between me and other systems, this would hit rules that should never be hit, resulting in the NetSec team getting some alerts.

Now I believe, like most sane people, that if you've popped an appserver, it's already likely to be game over, and this is a moot point.

For most applications, the app server doesn't live in its own little DMZ, and usually does have privileged access to the DB, often shares the same authentication domain as other services which is not properly secured (e.g. your [backup|log|monitoring|deployment] server connects to every machine with a service account, not SSH protected, and now I have the service account for all machines).

You wouldn't be foolish enough to have mixed admin functions (content management?), and user functions on the same app server... right? Right? Oh... wait... almost everyone does that.

Etc.

Re: Why firewalls won’t matter in a few years

#126

"You can’t use firewalls to secure East/West data flows in the network." What does that mean?

You're diagramming your network. Typically network engineers like using a tree layout - core devices at the top, flowing down to aggregation devices, down to access devices, down to the end devices. Hence traffic to the North was to the core, and out, traffic SOuth was to the end devices.

Typically in a campus you would see traffic going from the end devices up to the core, and then out of the core, either to datacenters/machine rooms, or out to the internet.

In a datacenter, historically, you had a few servers that talked to each other, connected to the same "Access" switch (commonly refered to as the top-of-rack or end-of-row), and then almost all the traffic for those servers also went "north" to the core, with a much smaller amount going south. Almost all the traffic was from clients out in the corporate network, down to their specific set of services.

However over time, end users represent a smaller and smaller portion of what an application does. More systems integrate with more systems - pulling in data from many other systems, doing analysis, backup, etc. etc. This is the east - west traffic, that flows between things in the same tree diagram. East-west traffic is by far the largest throughput in a modern DC.

When the traffic was mostly north-south, network engineers secured the traffic at the edge of the DC - where the DC joined the core/internet. Now the traffic is between servers that are sitting in the same rack/row/room/DC, securing it in the same way just doesn't work.

Re: Why firewalls won’t matter in a few years

#127

Earlier quoted context omitted.

Appreciate the corroboration from the inside. I've suspected as much given that even the "controlled interfaces" are usually EAL4 at best. Did you know Navy people built an EAL7 IPsec VPN? I'm sure you can immediate realize (a) how awesome that is and (b) what value it has for our infrastructure/military. Yet, it got canceled before evaluation because brass said "no market for it." Virtually nobody in military or def…

EAL criteria are so operationally restrictive that useful work is effectively prevented from happening. No one needs worse security, we need better security.

A number of us have conformed to higher ones on a budget with small teams. The highest one's are indeed a ton of work to accomplish yet there's been dozens of projects and several products with such correctness proofs. They figured by the 80's they needed their certified TCB to be re-usable in many situations to reduce the issue you mentioned. Firewalls, storage, communications, databases and so on all done with security dependent on same component. Modern work like SAFE (crash-safe.org) takes this closer to the limit by being able to enforce many policies with same mechanism.

So, your claim is understandable but incorrect. Useful work repeatedly got done at higher EAL's. It continues to get done. The real problem is (a) bad choice of mechanism for TCB and (b) bad evaluation process. Most of us skipped high-EAL evaluations for private evaluations instead by people working with us throughout the project. Saves so much time and money while providing even more peer review.

They really need to improve the evaluation process itself so it's not so cumbersome and update their guidance on best mechanisms for policy enforcement. Probably sponsor via funding some of them like they did in the old days. Fortunately, DARPA, NSF, and EU are doing this for many teams so we can just leverage what they create.

Re: Why firewalls won’t matter in a few years

#128

Earlier quoted context omitted.

I have tried preaching similar message while I have worked for a C4I unit. I found it extremely hard to get anyone understand what the actual point was, and even after that I got mostly "but we're all COTS now" with a shrug. The previous, while working with netsec, stands practially for abandoning the sound principles and going for superficial compliance models. There is no real security architecture in place for mos…

Appreciate the corroboration from the inside. I've suspected as much given that even the "controlled interfaces" are usually EAL4 at best. Did you know Navy people built an EAL7 IPsec VPN? I'm sure you can immediate realize (a) how awesome that is and (b) what value it has for our infrastructure/military. Yet, it got canceled before evaluation because brass said "no market for it." Virtually nobody in military or def…

I was shocked to read a EAL4 summary for a product that I know to be extremely hard to secure.

But of course, if you follow all the steps, that only the vendor knows, it can be EAL4. Just don't miss one of the 100s of settings... :/

Re: Why firewalls won’t matter in a few years

#129
post #99

Earlier quoted context omitted.

"Firewalls are just some stupid crap industry made up and went with." -- I can't even begin to unravel how short sighted that comment actually is. I'm not sure you really understand the state of the firewall industry at this point in time if I'm allowed to be blunt. While I do think that traditional firewalling (L3/L4) has lost it's overall efficacy there are solutions on the market that address application control,…

in order to achieve 100Gbps at line rate, you have 6.7ns per frame. not a myth, but simple arithmetic.

That might be true if the system is monolithic ingress/egress, but that's not true for any chassis based firewall that's rated at, or above, 100Gb today (and there are quite a few).

Re: Why firewalls won’t matter in a few years

#130
post #92

Earlier quoted context omitted.

"Firewalls are just some stupid crap industry made up and went with." -- I can't even begin to unravel how short sighted that comment actually is. I'm not sure you really understand the state of the firewall industry at this point in time if I'm allowed to be blunt. While I do think that traditional firewalling (L3/L4) has lost it's overall efficacy there are solutions on the market that address application control,…

> Firewalls at the enterprise level are FULLY required for business to operate in a relatively secure manner today. They're also completely unsustainable, because "firewall traversal" will always be a thing. The result is a tit-for-tat arms race between firewalls and applications, with application protocols being encapsulated deeper and deeper, and firewalls trying to inspect packets deeper and deeper. The overall sy…

Appsec does not solve netsec and vice versa. A lot of these comments are being posted by people who may know appsec rather well, but know very little about netsec. Firewall technology has come a long way - again, if you think that it's simply L3/L4 filtering, you're completely off base.

People have been targeting firewalls and A/V for years already - this is nothing new and about to change as stated. However these systems are much easier to secure based on a generally small footprint and protected management access.

"they hurt everyone by turning connectivity into a hard problem" - again, sure - circa 90's technology. I'm not sure you're aware of the positive enforcement model that some vendors approach today, focusing on allowance of using applications that should be used and blocking those that shouldn't.

Firewalls are not temporary, they're like a lock and key on your house - they don't solve all security problems, but they're a key component within the system as a whole.

If you'd like to take a friendly wager I'll hold you to your last statement, because they're going to be around at least another two decades.

Post reply on HN