Micro-segmentation and Beyond with NSX Firewall
VMware-based workload environments are the norm in private clouds for enterprise-class customers. 100%[1] of Fortune 500 companies deploy vSphere/ESXi. Further, ~99% of Fortune 1000 and ~98%[2] of Forbes Global 2000 companies deploy vSphere/ESXi. VMware’s deep presence in enterprise private clouds has made NSX Firewall the preferred micro-segmentation solution for these enterprises.
Below, we expand on how the NSX Firewall has developed its prominent position in enterprise private clouds.
Agentless and Agent-based Operation
Virtualized x86 workloads on hypervisors represent ~80%[3] of all enterprise workloads. VMware’s hypervisor-based micro-segmentation solution – NSX Firewall – is the preferred agentless solution for such workloads because of the solution’s tight integration with the rest of the VMware eco-system.
~15% of workloads at enterprises are x86-based (Windows, Linux) but not virtualized. The NSX Firewall handles these workloads with NSX agents.
~5% of workloads at enterprises are non-x86-based. VMware provides an (agentless) layer 2-7 gateway firewall that supports micro-segmentation for these workloads. Note that the gateway firewall eliminates the need for integration with physical switches, routers, and load-balancers.
Between these mechanisms, 100% of all workloads in the private cloud are protected. In practice, given VMware’s penetration of enterprises, VMware’s agentless solutions apply to the vast Continue reading
Hedge 121: Computing in the Network with Marie-Jose Montpetit
Can computation be drawn into the network, rather than always being pushed to the edge of the network? Taking content distribution networks as a starting point, the COIN research group is looking at ways to make networks more content and computationally aware, bringing compute into the network itself. Join Alvaro Retana, Marie-Jose Montpetit, and Russ White, as we discuss the ongoing research around computing in the network.
Is Network Observability Different from Visibility and Monitoring?
Network observability can provide significant value in the form of reduced Mean Time to Resolution, more productive employees, and more time for the IT team to spend on other projects.Tech Bytes: Solving WAN Problems With Singtel Solutions (Sponsored)
In this Tech Bytes episode we welcome back Singtel to discuss real-life examples of WAN problems from customers and how Singtel helped solve them.
The post Tech Bytes: Solving WAN Problems With Singtel Solutions (Sponsored) appeared first on Packet Pushers.
Tech Bytes: Solving WAN Problems With Singtel Solutions (Sponsored)
In this Tech Bytes episode we welcome back Singtel to discuss real-life examples of WAN problems from customers and how Singtel helped solve them.Day Two Cloud 137: Automating Windows Container Builds
Today's Day Two Cloud gets into the weeds of a real-world project build around Windows containers. Windows containers? Yes, the goal was to run a particular job and deploy it on Kubernetes using Azure Kubernetes Services (AKS). Our guest is Sai Gunaranjan, Principal Architect for a large healthcare company.Don’t Ask Who Invented the Internet because It Evolved
Not a simple origin story
DNSSEC issues take Fiji domains offline
On the morning of March 8, a post to Hacker News stated that “All .fj domains have gone offline”, listing several hostnames in domains within the Fiji top level domain (known as a ccTLD) that had become unreachable. Commenters in the associated discussion thread had mixed results in being able to reach .fj hostnames—some were successful, while others saw failures. The fijivillage news site also highlighted the problem, noting that the issue also impacted Vodafone’s M-PAiSA app/service, preventing users from completing financial transactions.
The impact of this issue can be seen in traffic to Cloudflare customer zones in the .com.fj second-level domain. The graph below shows that HTTP traffic to these zones dropped by approximately 40% almost immediately starting around midnight UTC on March 8. Traffic volumes continued to decline throughout the rest of the morning.
Looking at Cloudflare’s 1.1.1.1 resolver data for queries for .com.fj hostnames, we can also see that error volume associated with those queries climbs significantly starting just after midnight as well. This means that our resolvers encountered issues with the answers from .fj servers.
This observation suggests that the problem was strictly DNS related, rather than connectivity related—Cloudflare Radar Continue reading
Segment Routing vs LDP in Hub-and-Spoke Networks
I got an interesting question that nicely illustrates why Segment Routing (the MPLS variant) is so much better than LDP. Imagine a redundant hub-and-spoke network with hundreds of spokes. Let’s settle on 500 spokes – IS-IS supposedly has no problem dealing with a link-state topology of that size.
Let’s further assume that all routers advertise only their loopbacks1 and that we’re using unnumbered hub-to-spoke links to minimize the routing table size. The global routing table thus contains ~500 entries. MPLS forwarding tables (LFIB) contain approximately as many entries as each router assigns a label to every prefix in the routing table2. What about the LDP table (LIB – Label Information Base)?
Segment Routing vs LDP in Hub-and-Spoke Networks
I got an interesting question that nicely illustrates why Segment Routing (the MPLS variant) is so much better than LDP. Imagine a redundant hub-and-spoke network with hundreds of spokes. Let’s settle on 500 spokes – IS-IS supposedly has no problem dealing with a link-state topology of that size.
Let’s further assume that all routers advertise only their loopbacks1 and that we’re using unnumbered hub-to-spoke links to minimize the routing table size. The global routing table thus contains ~500 entries. MPLS forwarding tables (LFIB) contain approximately as many entries as each router assigns a label to every prefix in the routing table2. What about the LDP table (LIB – Label Information Base)?
Announcing experimental DDR in 1.1.1.1
1.1.1.1 sees approximately 600 billion queries per day. However, proportionally, most queries sent to this resolver are over cleartext: 89% over UDP and TCP combined, and the remaining 11% are encrypted. We care about end-user privacy and would prefer to see all of these queries sent to us over an encrypted transport using DNS-over-TLS or DNS-over-HTTPS. Having a mechanism by which clients could discover support for encrypted protocols such as DoH or DoT will help drive this number up and lead to more name encryption on the Internet. That’s where DDR – or Discovery of Designated Resolvers – comes into play. As of today, 1.1.1.1 supports the latest version of DDR so clients can automatically upgrade non-secure UDP and TCP connections to secure connections. In this post, we’ll describe the motivations for DDR, how the mechanism works, and, importantly, how you can test it out as a client.
DNS transports and public resolvers
We initially launched our public recursive resolver service 1.1.1.1 over three years ago, and have since seen its usage steadily grow. Today, it is one of the fastest public recursive resolvers available to end-users, supporting the latest security Continue reading
Device Management From The Ground Up: Part 1 – Accessing Your First Device
This post originally appeared on the Packet Pushers’ Ignition site on April 5, 2021. In this 8-part series, I explore the basics of managing network devices. This series is geared for the novice, but I hope readers with a bit more experience will find something useful as well. I cover the following topics: Device access […]
The post Device Management From The Ground Up: Part 1 – Accessing Your First Device appeared first on Packet Pushers.
How to Address Cloud Misconfiguration-Caused Breaches
While eliminating misconfigurations may be nigh impossible, we can limit them and the potential damage they may cause.CVE-2022-26143: A Zero-Day vulnerability for launching UDP amplification DDoS attacks
A zero-day vulnerability in the Mitel MiCollab business phone system has recently been discovered (CVE-2022-26143). This vulnerability, called TP240PhoneHome, which Cloudflare customers are already protected against, can be used to launch UDP amplification attacks. This type of attack reflects traffic off vulnerable servers to victims, amplifying the amount of traffic sent in the process by an amplification factor of 220 billion percent in this specific case.
Cloudflare has been actively involved in investigating the TP240PhoneHome exploit, along with other members of the InfoSec community. Read our joint disclosure here for more details. As far as we can tell, the vulnerability has been exploited as early as February 18, 2022. We have deployed emergency mitigation rules to protect Cloudflare customers against the amplification DDoS attacks.
Mitel has been informed of the vulnerability. As of February 22, they have issued a high severity security advisory advising their customers to block exploitation attempts using a firewall, until a software patch is made available. Cloudflare Magic Transit customers can use the Magic Firewall to block external traffic to the exposed Mitel UDP port 10074 by following the example in the screenshot below, or by pasting the following expression into their Magic Firewall Continue reading