51–60 of 139 posts
Am I missing something?
Strong 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).
"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.
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?
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.
Earlier quoted context omitted.
If this observation is meaningful, shouldn't it also be the case that firewall deployments aren't meaningful to enterprise security? Because: that seems intuitively not to be the case. To wit: on an annual site-wide pentest of any major enterprise network (this is a project every security firm does for a couple clients a year), the moment the pentester gets "behind the firewall" (ie: code execution on any application…
'Game over': I think this is exactly the problem. In all the organizations I've been in, firewalls have been an excuse for negligence. 'We don't need to think about security because we are behind the firewall.' Right now the compliance world is addicted to firewalls, to the detriment to reasonable appsec. In my fantasy world, I'd like the auditors to be telling companies 'in 5 years, you won't be allowed to firewall…
Your fantasy world also has auditors. What concerns me most is "self-auditing", mostly because it's a joke, partly because a lot of places don't take it seriously.
Passwords 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.
I'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 se…
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 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…
If this observation is meaningful, shouldn't it also be the case that firewall deployments aren't meaningful to enterprise security? Because: that seems intuitively not to be the case. To wit: on an annual site-wide pentest of any major enterprise network (this is a project every security firm does for a couple clients a year), the moment the pentester gets "behind the firewall" (ie: code execution on any application…
Earlier quoted context omitted.
I'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 se…
Best way is to not send credentials in plain text. I wish SRP had taken off and become standard.
With fewer than 500 paying customers, I don't see how you can describe NSX as having "strong traction".
"You can’t use firewalls to secure East/West data flows in the network." What does that mean?
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…
For years (15 ?) I have been putting very simple, very small ipfw rulesets in place on non-firewall systems that allow only the traffic I believe that system should be sending/receiving.
It's a firewall. It's on the host itself. It is a firewall that is securing "east/west traffic". It's a simple model that any host can implement and has very low (typically zero) cost.
Related:
This is the first, and last, time I will ever use the term "east/west traffic". Christ.