Before we start: if you’re new to my blog (or stumbled upon this blog post by incident) you might want to read the Considerations for Host-Based Firewalls for a brief overview of the challenge, and my explanation why flow-tracking tools cannot be used to auto-generate firewall policies.
As expected, the “you cannot do it” post on LinkedIn generated numerous comments, ranging from good ideas to borderline ridiculous attempts to fix a problem that has been proven to be unfixable (see also: perpetual motion).
I have NEVER found a customer application team that can tell me all the servers they are using, their IP addresses, let alone the ports they use.
His proposed solution: use software like Tetration (or any other flow collecting tool) to figure out what’s really going on:
Perhaps a paradigm shift is due for firewalls in general? I’m thinking quickly here but wondering if we perhaps just had a protocol by which a host could request upstream firewall(s) to open access inbound on their behalf dynamically, the hosts themselves would then automatically inform the security device what ports they need/want opened upstream.
Having spent my career in various roles in IT security, Ivan and I always bounced thoughts on the overlap between networking and security (and, more recently, Cloud/Container) around. One of the hot challenges on that boundary that regularly comes up in network/security discussions is the topic of this blog post: microsegmentation and host-based firewalls (HBFs).
Two weeks ago Nicola Modena explained how to design BGP routing to implement resilient high-availability network services architecture. The next step to tackle was obvious: how do you fine-tune convergence times, and how does BGP convergence compare to the more traditional FHRP-based design.
Remember the “BGP as High Availability Protocol” article Nicola Modena wrote a few months ago? He finally found time to extend it with BGP design considerations and a description of a seamless-and-safe firewall software upgrade procedure.
After publishing the Disaster Recovery Faking, Take Two blog post (you might want to read that one before proceeding) I was severely reprimanded by several people with ties to virtualization vendors for blaming virtualization consultants when it was obvious the firewall clusters stretched across two data centers caused the total data center meltdown.
Let’s chase that elephant out of the room first. When you drive too fast on an icy road and crash into a tree who do you blame?
- The person who told you it’s perfectly OK to do so;
- The tire manufacturer who advertised how safe their tires were?
- The tires for failing to ignore the laws of physics;
- Yourself for listening to bad advice
For whatever reason some people love to blame the tires ;)
In last week’s continuation of EVPN never-ending story Lukas Krattiger described how you could use EVPN constructs (VNIs, VRFs) to implement service insertion, and how you could combine then with policy-based routing.
TL&DW: It’s bridging and routing ;)
You’ll need Standard ipSpace Subscription to access the videos.
I spent a lot of time during this summer figuring out the details of NSX-T, resulting in significantly updated and expanded VMware NSX Technical Deep Dive material… but before going into those details let’s do a brief walk down the memory lane ;)
You might remember a startup called Nicira that was acquired by VMware in mid-2012… supposedly resulting in the ever-continuing spat between Cisco and VMware (and maybe even triggering the creation of Cisco ACI).
This is a guest blog post by Andrea Dainese, senior network and security architect, and author of UNetLab (now EVE-NG) and Route Reflector Labs. These days you’ll find him busy automating Cisco ACI deployments.
Following the Ivan’s post about Firewall Ruleset Automation, I decided to take a step forward: can we always have up-to-date and clean firewall policies without stale rules?
We usually configure and manage firewalls using a process like this:
If you’ve been in networking long enough you’d probably noticed an interesting pattern:
- Some topic is hotly debated;
- No agreement is ever reached even though the issue is an important one;
- The debate dies after participants diverge enough to stop caring about the other group.
I was reminded of this pattern when I was explaining the traffic filtering measures available in private and public clouds during the Designing Infrastructure for Private Clouds workshop.
One of my readers sent me a description of their automation system that manages firewall rulesets on Fortigate firewalls using NAPALM to manage device configurations.
In his own words:
We are now managing thousands of address objects, services and firewall policies using David Barroso’s FortiOS Napalm module. This works very well and with a few caveats (such as finding a way to enforce the ordering of firewall policies) we are able to manage all the configuration of our firewalls from a single Ansible playbook.
The did the right thing and implemented an abstracted data model using GitOps to manage it:
After figuring out how packet forwarding really works within AWS VPC (here’s an overview, the slide deck is already available to ipSpace.net subscribers) the next obvious question should be: “and how do I integrate a network services device like a next-generation firewall I have to use because $securityPolicy into that environment?”
Please don’t get me started on whether that makes sense, that’s a different discussion.
Christer Swartz, an old-time CCIE and occasional guest on Software Gone Wild podcast will show you how to do it with a Palo Alto firewall during my Amazon Web Services Networking Deep Dive workshop on June 13th in Zurich, Switzerland (register here).
Some of my readers got annoyed when I mentioned Google’s BeyondCorp and RFC 1925 in the same sentence (to be perfectly clear, I had Rule#11 in mind). I totally understand that sentiment – reading the reactions from industry press it seems to be the best thing that happened to Enterprise IT in decades.
Let me explain in simple terms why I think it’s not such a big deal and definitely not something new, let alone revolutionary.
One of my readers sent me a vivid description of his interactions with one of the so-called next-generation firewall vendors. Enjoy!
We’re using their highly promoted Next Generation Firewall (NGFW) management solution. New cutting edge software, centralized manager… but no CLI for configuration (besides some initial bootstrap commands). "You don't need that because everything is managed from our centralized manager GUI", says $vendor sales managers.