15 ms·
Why firewalls won’t matter in a few years
- sargun 11y agoI agree with this heavily. I outlined some of these problems in my "Critique of Modern Network Design" post: https://medium.com/@sargun/a-critique-of-network-design-ff8543140667 https://medium.com/@sargun/a-critique-of-network-design-ff85...
- snowwrestler 11y ago> In the questions at the end, he points out the bug bounties are a PR Problem. When you pay a bug bounty and fix, the researcher needs to shutup instead of going public about the vulnerability. Of course, the researcher needs the publicity to build a business & credibility. So bug bounties are likely to die. Because security researchers need to build their business, they will find vulnerabilties and disclose them, no matter what. The biggest splashes in the past year were Heartbleed and Shellshock. Correct me if I'm wrong, but neither were driven by bug bounties. Bug bounties are a PR problem, but they are a smaller PR problem than a zero-day disclosure that results in massive exploits. The point is get the company slightly ahead of the PR curve, not to kill disclosure (which would be impossible).
- devnul3 11y agoBug bounties are a PR problem if handled badly. If handled well, bug bounties say "look at all of the ways we've made our product more secure". Put another way, do you think Google is less secure or more secure because of their engagement with security researchers?
- sarciszewski 11y agoWhen I report a vulnerability, I ask (if it's not already known) what their timetable is for patching it. If they want more than 30 days for a simple fix, I disclose immediately. The turnaround time for most projects I've reported to was less than a week.
- jerf 11y agoBug bounty programs do not in general involve "shutting up the researcher". See the HackerOne disclosure page, for instance: https://hackerone.com/disclosure-guidelines https://hackerone.com/disclosure-guidelines The "Disclosure Process" doesn't explicitly spell it out, because I think it's just the mental baseline assumption all the authors were operating under, but everything ends up disclosed in the end. It's just a matter of timing. Perhaps sometimes things are hidden and never disclosed, but it is at least not the general policy. (Disclaimer: I work for a company that is a bugcrowd customer; I chose HackerOne's policies as my point to avoid any entanglement. I'm not aware of anything we've ever permanently hidden, either.)
- davidu 11y agoStrong agree, network based firewalls don't make sense based on performance needs and placement at the edge of an increasingly ephemeral network perimeter. Host and edge / stub firewalls with strong orchestration will be far more pervasive along with lots of network traffic auditing and anomaly detection that happens in near real-time, but out of the line of fire (out of band).
- scurvy 11y agoI haven't seen firewalls on the edge in ages. I guess it's more of a Fortune 500 attitude than tech company thing. "Firewall" devices still have a place inside your network beyond the perimeter. Today they do ACL enforcement as well as DPI, IDP, IDS, tap data, etc. It's not unheard of to run a "firewall" in completely passive, monitor-only mode to generate telemetry data.
- nerdy 11y agoThe presentation audio quality is really unfortunate, I'm interested in the subject but it sounds like I'm listening from another room.
- EtherealMind 11y agomaybe you should pay to go to conferences ?
- nerdy 11y agoAnd 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.
- KaiserPro 11y agoI'd like to counter, IoT will probably change this view. (however the points raised are still valid.) IoT devices generally have utterly terrible security, and you'll not want them public exposed. I can envisage a place for a house wide firewall of somesort, to stop publicly addressable devices being knocked offline, or exploited by persons unknown. So there will be a need for a "virtual front door" something that home router should really do, but fails utterly in most cases.
- brentjanderson 11y agoI think the article is referring more to enterprise installations for firewalls - I don't think we're worried about 100G internet to domestic endpoints any time soon. Domestic use will still make sense, likely for years to come. In data centers? Not so much.
- nickpsecurity 11y agoFirewalls are just some stupid crap industry made up and went with. We've known since the Orange Book days that security had to be done holistically involving every endpoint and network. Their standard for security was a strong TCB on endpoint with trusted path (see EROS or Dresden's Nitpicker); a network card with onboard security kernel, firewall, and crypto (see GNTP + GEMSOS); connections between networks through high assurance guards (see Boeing SNS or BAE's SAGE); proxies + guard software for risky protocols such as email (see mail guards like SMG or Nexor). All of this collectively working together was what it took to enforce a fairly-simple, security policy (MLS). More flexible attempts happened in capability model with KeyKOS + KeySAFE, E programming language, CapDesk desktop, and so on. So, the above was the minimum that NSA et al would consider secure against adversaries on their level. Every security-critical component was carefully spec'd, implementation mapped against spec 1-to-1, analyzed for covert channels, pen-tested, and even generated on-site. Commercial industry, aiming at max profit and time to market, just shipped stuff with security features but not assurance. Broke every rule in the field. Came up with firewalls (knockoff of guards), AV, and so on to counter minor tactics. Of course that didn't work as it doesn't solve the central security problem: making sure all states or flows in the system correspond to a security policy. The best route is to put security in the end-point along with E-like tools for distributed applications and hardware acceleration of difficult parts. Within your trust domain, you just check data types and use that for information flow control (aka security). Outside trust domain, you do input validation and checks before assigning types. The hardware will be like crash-safe.org or CHERI processor in that it handles the rest. A security-aware, I/O offload engine will help too. Fixing the root problem along with a unified model (capability-based, distributed) will make most security problems go away. At that point, firewalls will be about keeping out the riff raff and preventing DOS attacks.
- pyre 11y ago> AV How does Anti-Virus play into this as a counter to "minor tactics?" Are you expecting all end-users to personally verify all of their software? No matter how secure the network connection is, end-users need software to use their computers to do work/have fun/etc. Unless you have a completely closed system of 100% trusted software. If you're part of an organization like the NSA, that might be doable, but home users don't really have this luxury unless you advocate for a walled-garden type system.
- danellis 11y ago"You can’t use firewalls to secure East/West data flows in the network." What does that mean?
- thomble 11y agoLateral flows of data within a network, as opposed to traffic that goes through a gateway.
- danellis 11y agoInteresting. Never heard the term before.
- deleted 11y ago[deleted]
- RyJones 11y agoI think it's from American football - east/west is lateral movement, north/south towards/away from the goal lines. Apparently this has nothing to do with getting sun in your eyes. http://stupidquestionarchives.blogspot.com/2008/03/football-fields-oriented-north-south.html http://stupidquestionarchives.blogspot.com/2008/03/football-...
- scurvy 11y agoI'd guess it more has to do with physical colo/datacenter layouts. Traffic moving between racks is considered east/west*. Traffic moving in and out of your routers (and through to the meet-me-room) would take place over fiber pairs up into the ceiling or down through the floor. Just a guess.
- arbitrage 11y agoIt's a little new-speakish, but it basically means traffic flowing between servers in the same hosting tier.
- deleted 11y ago[deleted]
- kstenerud 11y agoNote that there is a difference between isolating devices and firewalling in the sense of packet inspection. You're still going to want selective routing and packet forwarding (like port forwarding). Firewalls will continue to be useful for complex devices that connect directly to the internet (like laptops on public wifi), where all sorts of things you wouldn't want others accessing are exposed by default.
- snuxoll 11y agoWhat most consumers and sysadmins think of "Firewalls" and what the presentation are talking about are two different things. Simple packet filters like "don't allow communication on port 123 unless it's from IP a.b.c.d)" will always be part of a defense in depth strategy, but things like stateful packed inspection tools from big-name firewall vendors do not scale when the number of cycles they have to inspect a packet keeps getting lower, especially when they have fewer cycles to actually do basic I/O to get the packet through to the destination. High performance networking means networking hardware has to get the packets moved faster, so there's less time to do processing on them.
- deleted 11y ago[deleted]
- TheLoneWolfling 11y ago> adding a tiny fixed latency is independent of total system bandwidth Incorrect on both counts. A) it's not a tiny latency, not compared to the overall system latency in many cases. This is explained in the article. The speed of light isn't getting any faster, whereas communication rates continue to increase. Which means you have more data on the line at once, which brings me to: B) most data flows are finite - any reliable communications (such as, for instance, anything over TCP, and a good chunk of things over UDP as well), take a certain number of round trips to come up to speed. Which brings me to: As such, the overall bandwidth of a TCP (or ghetto TCP via any other means - pretty much any reliable protocol suffers from this) connection is held up more by a fixed delay the faster the link is.
- stcredzero 11y agoPasswords are unsafe Passwords are unsafe for the same reason that roads are unsafe: human beings. Things work well enough for most people, most of the time. However, during certain situations, most people aren't trained correctly and often do the wrong thing. What's more, there's even an accepted culture of doing the wrong thing.
- TheLoneWolfling 11y agoI'm thinking more and more that the best way to do passwords is to not - you generate a random diceware passphrase (or similar) and give it to the user via a secure channel, run it through the KDF, and throw the original away. Preferably on an entirely separate server from everything else. It still doesn't prevent users from being stupid w.r.t. writing down passwords, but it at least presents users with reasonably secure logins that are relatively easy to remember.
- jimktrains2 11y agoBest way is to not send credentials in plain text. I wish SRP had taken off and become standard.
- TheLoneWolfling 11y agoThis doesn't send credentials in plain text.
- jimktrains2 11y agoWhat is being sent to the server then? And by plain-text, I mean the server receives information that could then be used to authenticate later. For instance, if you send the sha of a password, and then store the sha of the sha, you're still sending the password in plaintext, it's just that it's not the password the user entered.
- TheLoneWolfling 11y ago
- Dmatad 11y agoFirewalls fall into a dark category for IT -- cover-your-ass implementations done without questioning the problem-solution dynamic. For years, the cloud applications I work with have been slowed or made glitchy due to company firewall interference. I will not miss them when my users' experience improves by leaps.
- oldpond 11y agoThanks for sharing. Very interesting presentation. As soon as he said the browser is the new OS he lost me, but I understand he's coming from the Internet Industry. I completely agree that we need to design secure application architecture though, and that's why I am excited about languages like Go which facilitate a new client server model that doesn't involve the browser.
- stephengillie 11y agoThe browser took over that throne 10 or 15 years ago, with the rise of web 2.0. We make and download way, way more applications that run in web browsers (aka every web site) than applications that run on Windows, OSX, or any other OS.
- teacup50 11y agoOnly by redefining what "application" means.
- stephengillie 11y agoPlease look up the definition of "application". I don't mean to be pedantic; it was enlightening to me as well.
- Spooky23 11y agoI have a deck somewhere illustrating this. My team supported something like 500 installed applications with more than 50 users across a 30,000 user base in 2004 or so. Programmers were churning out PowerBuilder and VB apps, all of which sucked to varying degrees. Today, I'm not on that team, but the number is something like 50-75. I cannot remember the last time I saw a new bespoke client/server app.
- oldpond 11y agoNo denying there was lots of breakage back then, and you would have to go back to the late 90's to find the days when Powerbuilder and VB were new. Developers making mobile apps don't assume the browser is the platform. Developers making games don't assume the browser is the platform (even though there are plenty of in-browser games), but it seems we don't question the browser for every other solution. All the recent development in sockets, channels, messaging, etc. has reopened the box of potential solutions for non-browser client server, IMHO.
- api 11y agoFirewalls were always an ugly hack that got grandfathered in as a 'best practice.'
- drcross 11y agoI also wonder how the move to IPv6 will also affect the current paradigm. Internet facing firewalls were typically also NAT machines to save IPv4 address space but all of that is gone in IPv6 meaning your global address is now exposed and a hacker can persistently try to compromise your machine if you don't firewall.
- netman21 11y agoOn top of that many modern defenses are based on IP reputation, or black lists. There are several companies that track the reputation of all 4 billion IPv4 addresses. Scores are updated every 5 minutes. With several quadrillion IPv6 addresses this will be a lot harder to do.
- deleted 11y ago[deleted]
- EtherealMind 11y agoA firewall doesn't prevent compromise. An attacker can always reach your Internet connected system, and attack through the firewall. Firewall is useful for protecting servers that don't have well managed IPTables or similar.
- rcthompson 11y agoMy takeaway from this post, as someone who's not a security professional: "Security is hard, swearing is normal."
- bnewbold 11y agoI'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?
- scurvy 11y agoProbably a lot. I'm not sure exactly what it is though. If it were that easy, we'd have line-rate firewalls from every manufacturer. Considering that the performance rates are much lower, there are indeed challenges. Tuple based hashing can get complicated and is highly dependent upon the installation. Some would want source IP. Some want destination IP. Some want a mixture of destination IP and source IP and port. How much you can get through each core (in aggregate) definitely impacts throughput. Think of a volumetric DDoS attack that rolls into a network over a single path and overwhelms a 1/10/40/100G link. You could have a dozen of those links, but your throughput is hosed because that link is effectively saturated. It might only affect 1/12 of your capacity, but you can't use any of the other links. I hate to bring BGP pathing into a firewall discussion, but maybe it makes sense.
- readams 11y agoFirewalls 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.
- EtherealMind 11y agoDelivering 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.
- EtherealMind 11y agoThere are some non-obvious issues: 1. Why not firewall in the operating system and distribute/scale the load evenly ? Centralising the firewall was done when OS provisioning was bad, now we have Puppet/Chef/Ansible, firewalls operations is simple enough. 2. Simple firewalling is effectively worthless when 99% of all traffic is HTTP/S and SSH. To add value you perform flow analysis combined with deep packet inspection to build a meta-data data to pass through a heuristics/pattern analysis to perform threat detection. 3. Passing through any device creates latency in the order of milliseconds, which is not acceptable in east/west traffic loads. Parallelisation, caching, flow cut-through will all incur a latency penalty. HTH greg
- madsushi 11y ago"NSX is getting strong traction" With fewer than 500 paying customers, I don't see how you can describe NSX as having "strong traction".
- EtherealMind 11y agoTwo things: 1. the number is more than 800. 2. NSX is being deployed primarily as a security tool for micro-segmentation. It is displacing firewalls in the data centre is substantly way. 3. Change in the data centre is slow. Infrastructure is commonly built on 10-15 year cycles so actual purchases are a lagging indicator.
- kator 11y agoYears ago at a large car manufacturer I had an argument with the "Data Security" team about firewall settings. They had some crazy dumb ideas of what had to be on the firewall and it was constantly causing us pain. I went to visit this person in charge and argue my case. He was in another building outside of the "Secure Datacenter".. He argued with me for about 45 mins about how nothing leaves that data center and the firewall is our last line of defense. I pulled a 5Gb 8mm tape out of my pocket, dropped it on his desk and said "That's a copy of every single customer in our database and our entire parts catalog with all order history so much for your firewall". The next day we had more intelligent discussions about firewall settings, and permissions on the mainframe for tape backups... Additionally my favorite trick to this day when visiting a company is just plugging in a laptop to various random ethernet ports. I was recently as at a place where they have a "Guest Wifi" that changes passwords every week and the password is emailed to everyone. Sitting in a random conference room I plugged in and had 100% access to their corporate network. In today's work of IOT this is basically gross negligence to only rely on a firewall for security. To think a firewall is much protection at all is to stick your head in the sand and pretend everything is ok.
- thyrsus 11y agoI've seen multiple security audits that didn't see fit to mention such ethernet ports as a problem. I don't know why; it's possible management told them it was "out of scope".
- nickpsecurity 11y agoGreat stuff through and through. It's why I use end-to-end security that doesn't trust the network wherever possible. Let them screw with my Ethernet ports: the NIDS just tells me there's a problem and where to find it. Or they walk away with a lot of data that might be useful for... Monte Carlo simulations or studies in random numbers? Haha.
- cm2187 11y agoOne of the bullet points says "DNSSEC is dead". But what is the plan then? it sounds odd to rely on a completely insecure, unencrypted service for DNS (plus all the new ways in which a secure DNS service could be used, to distribute public keys for instance).
- iyn 11y agoI'm also interested in this. DNSCurve? Something else?
- xorcist 11y agoDNSCurve solves none of the problems DNSSEC solves, and vice versa. The only realistic alternative to the DNSSEC PKI is the global SSL CA PKI, with authenticating higher up in the protocol stack. That does not necessarily mean status quo though, as the latter have obvious room for improvement.
- bortels 11y agoIt simply means you cannot rely on DNS (and domain names and such) for your security; your security must be achieved via other means (user auth or such). DNSSEC does not help that much, in reality, despite the implication it might, and that's part of why SSL and Signed Certs exist - it's a given that when I connect to www.microsoft.com from starbucks wifi, the IP DNS returns may or may not be microsoft's. With DNSSEC - presumably you may have a higher level of assurance the IP is from Microsoft, but it is not really practical to implement everywhere due to complexity, so you cannot depend on it to solve for this sort of issue.
- pshc 11y agoGreat speaker! Thanks for all the system design advice for my next webapp. I want to do it right next time, with lots of containerization.
- arca_vorago 11y agoYou know, I keep hearing this, especially related to ipv6, but the problem to me isnt that the industry is being lazy, its that all the guard systems you reference are archaic black boxes to most IT people. If you want to start pushing Guard to the endpoint of every server and desktop, ok, but show me a product that makes it easy to do and I dont have to be a unixbeard from an defense agency to know how it works... I dont disagree, but I hear a lot of terminalogy thrown around by you with very little substantial practical and technical information. How about a guide to Guard, EAL etc for the common sysadmin?
- bortels 11y agoAwesome Stamos talk (as per usual), but the headline here is a tad clickbaity. Perhaps more accurate to the talk is that they will matter less and less as time goes by. If you don't like that headline - do go watch the talk, there's a lot more subtlety than 8 words convey, and Alex is a fun speaker, with one of the highest signal-to-noise ratios around. Heck - if you agree with the headline, still go watch the talk. If you care the slightest bit about security, you won't be sorry. Firewalls are not a 100% solution, nor have they ever been. Defense done correctly is always defense in depth, and hardware firewalls are always likely to be part of that solution. Alex's point in the video - and one well-made, I think - is that as the landscape evolves, the value-add of hardware firewalls becomes less and less, because assumptions about the environment they are in are changing. Anyone depending only on firewalls (I have called this the "hard candy shell" in the past) was vulnerable before - and as time passes, they are becoming increasingly vulnerable, because the things a firewall can be useful about are becoming less relevant, due to architectural changes and exploits moving up the stack toward the app. I've said for a long, long time - I don't care how good your perimeter defenses are, you gotta harden the hosts. And in the end, this also is moving up the stacks. Your hypervisor may be secure as all-get-out, but if your app is open to trivial exploits, you're still screwed. You need to do a reasonable amount of security at all levels, including bits like user evangelism (disallowing of insecure passwords, perhaps promotion of MFA) if you want to have an expectation of security founded in reality. The human element - users and passwords - cannot be underestimated, because a chain is only going to be as strong as it's weakest link, and if you do all of YOUR shit right - that's gonna be the end-user. Someone who can figure out how to replace passwords with a mechanism that ties access and authentication to a single human being in a non-trivially spoofable and inexpensive manner could become very rich...
- deleted 11y ago[deleted]