VMware Transit Connect – Simplifying Networking for VMC
The release of VMware Cloud on AWS (VMC) 1.12 brings a number of exciting new capabilities to the managed service offering. A comprehensive list can be reviewed in the release notes. A key feature that is now Generally Available (GA) in all VMC commercial regions worldwide is VMware Transit ConnectTM. VMware Transit Connect enables customers to build high-speed, resilient connections between their VMware Cloud on AWS Software Defined Data Centers (SDDCs) and other resources. This capability is enabled by a feature called SDDC Groups that helps customers to logically organize SDDCs together to simplify management.
The SDDC Group construct empowers customers to quickly and easily define a collection of SDDCs, Virtual Private Clouds (VPCs) or on-premises connectivity that need to interconnect. Additionally, the SDDC Group construct provides value inside the individual SDDCs by simplifying security policy as will be shown later in this post. Behind the simplification that SDDC Groups provide is the instantiation of an VMware Managed AWS Transit Gateway, a VTGW. The VTGW is a managed service from VMware and provides the underlying connectivity between the different resources.
The initial Transit Connect service provides three primary connectivity models:
- SDDC to SDDC
- SDDC to Native AWS VPC
- Continue reading
Using Flow Tracking to Build Firewall Rulesets… and Halting Problem
Peter Welcher identified the biggest network security hurdle faced by most enterprise IT environments in his comment to Considerations for Host-based Firewalls (Part 1) blog post:
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:
Reducing RPKI Single Point of Takedown Risk
The RPKI, for those who do not know, ties the origin AS to a prefix using a certificate (the Route Origin Authorization, or ROA) signed by a third party. The third party, in this case, is validating that the AS in the ROA is authorized to advertise the destination prefix in the ROA—if ROA’s were self-signed, the security would be no better than simply advertising the prefix in BGP. Who should be able to sign these ROAs? The assigning authority makes the most sense—the Regional Internet Registries (RIRs), since they (should) know which company owns which set of AS numbers and prefixes.
The general idea makes sense—you should not accept routes from “just anyone,” as they might be advertising the route for any number of reasons. An operator could advertise routes to source spam or phishing emails, or some government agency might advertise a route to redirect traffic, or block access to some web site. But … if you haven’t found the tradeoffs, you haven’t looked hard enough. Security, in particular, is replete with tradeoffs.
Every time you deploy some new security mechanism, you create some new attack surface—sometimes more than one. Deploy a stateful packet filter to protect a Continue reading
Why Don’t We Have Dynamic Firewall Policies
One of the readers of the Considerations for Host-Based Firewalls blog post wrote this interesting comment:
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.
Well, we have at least two protocols that could fit the bill: Universal Plug and Play and Port Control Protocol (RFC 6887).
Cliché: Security through obscurity (yet again)
Infosec is a largely non-technical field. People learn a topic only as far as they need to regurgitate the right answer on a certification test. Over time, they start to believe misconceptions about that topic that they never learned. Eventually, these misconceptions displace the original concept in the community.
A good demonstration is this discussion of the "security through obscurity fallacy". The top rated comment makes the claim this fallacy means "if your only security is obscurity, it's bad". Wikipedia substantiates this, claiming experts advise that "obscurity should never be the only security mechanism".
Nope, nope, nope, nope, nope. It's the very opposite of what you suppose to understand. Obscurity has problems, always, even if it's just an additional layer in your "defense in depth". The entire point of the fallacy is to counteract people's instinct to suppress information. The effort has failed. Instead, people have persevered in believing that obscurity is good, and that this entire conversation is only about specific types of obscurity being bad.
Hypothetical: non-standard SSH
The above discussion mentions running SSH on a non-standard port, such as 7837 instead of 22, as a hypothetical example.
Let's continue this hypothetical. You do this. Then an 0day Continue reading
The New Model for Network Security: Zero Trust
The old security model, which followed the “trust but verify” method, is broken. That model granted excessive implicit trust that attackers abused, putting the organization at risk from malicious internal actors and allowing unauthorized outsiders wide-reaching access once inside. The new model, Zero Trust networking, presents an approach where the default posture is to deny access. Access is granted based on the identity of workloads, plus other attributes and context (like time/date, source, destination), and the appropriate trust required is offered at the time.
Calico Enterprise Zero Trust Network Security is one of the most effective ways for organizations to control access to their Kubernetes networks, applications, and data. It combines a wide range of preventative techniques including identity verification, least privilege controls, layered defense-in-depth, and encryption of data-in-transit to deter threats and limit access in the event of a breach. Kubernetes is particularly vulnerable to the spread of malware as a result of the open nature of cluster networking. By default, any pod can connect to any other pod, even across namespaces. Without a strong security framework, it’s very difficult to detect malware or its spread within a Kubernetes cluster.
Zero Trust policies rely on real-time visibility into workloads, Continue reading
Considerations for Host-based Firewalls (Part 1)
This is a guest blog post by Matthias Luft, Principal Platform Security Engineer @ Salesforce, and a regular ipSpace.net guest speaker.
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).
Mitigating the Risks of Instance Metadata in AWS EKS
Compromising a pod in a Kubernetes cluster can have disastrous consequences on resources in an AWS Elastic Kubernetes Service (EKS) account if access to the Instance Metadata service is not explicitly blocked. The Instance Metadata service is an AWS API listening on a link-local IP address. Only accessible from EC2 instances, it enables the retrieval of metadata that is used to configure or manage an instance. Although you can only access instance metadata and user data from within the instance itself, the data is not protected by authentication or cryptographic methods.
A recent blog described a scenario where an attacker compromised a pod in an EKS cluster by exploiting a vulnerability in the web application it was running, thus enabling the attacker to enumerate resources in the cluster and in the associated AWS account. This scenario was simulated by running a pod and attaching to a shell inside it.
By querying the Instance Metadata service from the compromised pod, the attacker was able to access the service and retrieve temporary credentials for the identity and access management (IAM) role assigned to the EC2 instances acting as Kubernetes worker nodes. At that point, the attacker was able to pursue multiple exploits, Continue reading
Century Link/Level 3 Outage is one of the biggest Internet Problem! 3.5% Drop in Global Internet Traffic
On August 30, 2020, Level 3/Century Link, AS 3356 had major Internet outage. In fact this outage effected massive amount of networks, including very well know ones such as Amazon, Microsoft, Twitter, Discord, Reddit etc.
3.5% Global Internet Traffic was dropped due to this outage and entire network converged after almost 7 hours. This is huge amount of time. When we usually discuss convergence, specifically fast convergence, ‘Seconds’ if not ‘ Milliseconds ‘ are the target values.
No one wants to have minutes level network convergence. But when there is an Outage like this, we categorize them as ‘ Catastrophic Failures’ and unfortunately network design usually doesn’t take this kind of failures into an account.
But could it be prevented?
In the first place, let’s understand that, this event, similar to many other catastrophic network events, started at a single location. (According to a CenturyLink status page, the issue originated from CenturyLink’s data center in Mississauga, a city near Ontario, Canada.)
But it spread over entire backbone of AS3356.
In fact, I remember on 2014, which we famously know as 512k incident happened because of this network (Level 3) as well and that event also caused Continue reading
What’s the Big Deal About Multi-Cloud Networking – Part 2
If you were experiencing issues with Zoom calls today, you were not alone. But if you take a close look at today’s outage, it is clear that it was correlated with an AWS outage today. In fact, most of Zoom runs on AWS, according to AWS. This is despite Oracle’s claim that millions of users … Continue reading What’s the Big Deal About Multi-Cloud Networking – Part 2Perimeter Security is Changing
The long standing tradition of having a secure network perimeter and a lightly protected interior has been going by the wayside for quite some time now. But the introduction of new models of connectivity are forcing us to change the way we look at security all together and invent whole new models for protecting our networks. In today’s episode we’re going to be exploring how these changes are impacting security and talk about some of these new models that meet the needs of modern networks.
 |
Network Collective thanks NVIDIA for sponsoring today’s episode. NVIDIA is positioned as the leader in open networking and provides end-to-end solutions at all layers of the software and hardware stack. You can experience NVIDIA Cumulus in the Cloud for free! Head on over to:
https://cumulusnetworks.com/automationpod |
Mike Pfeiffer
Guest
Katherine McNamara
Guest
Tony Efantis
Host
Jordan Martin
Host
Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/
The post Perimeter Security is Changing appeared first on Network Collective.
Background on Stuxnet
The story of Stuxnet, the first cyber weapon in history. Focus is on the manipulation of machinery at Natanz, with detailed explanations of machine configuration and operation. A few takeaways for myself after watching: The Stuxnet software impacted the Iranian nuclear program by damaging the project budget. Instead of blowing up the centrifuges, they increased […]
The post Background on Stuxnet appeared first on EtherealMind.
Enforcing Enterprise Security Controls in Kubernetes using Calico Enterprise
Hybrid cloud infrastructures run critical business resources and are subject to some of the strictest network security controls. Irrespective of the industry and resource types, these controls broadly fall into three categories.
- Segmenting environments (Dev, Staging, Prod)
- Enforcing zones (DMZ, Trusted, etc.)
- Compliance requirements (GDPR, PCI DSS)
Workloads (pods) running on Kubernetes are ephemeral in nature, and IP-based controls are no longer effective. The challenge is to enforce the organizational security controls on the workloads and Kubernetes nodes themselves. Customers need the following capabilities:
- Ability to implement security controls both globally and on a per-app basis: Global controls help enforce segmentation across the cluster, and work well when the workloads are classified into different environments and/or zones using labels. As long as the labels are in place, these controls will work for any new workloads.
- Generate alerts if security controls are tampered with: Anyone with valid permissions can make changes to the controls. There is a possibility that these controls can be modified without proper authorization or even with a malicious intent to bypass the security. Hence, it is important to monitor changes to the policies.
- Produce an audit log showing changes to security controls over time: This is Continue reading
How to Simplify and Accelerate Network Segmentation
Network segmentation—splitting a network into subnetworks or segments—is widely accepted to be a powerful and effective method for improving cybersecurity within the data center. Yet even though it’s acknowledged to be an essential component of network security hygiene, organizations have frequently avoided putting segmentation into practice.
Why? Because historically network segmentation has been complex, disruptive, and time-consuming to implement, requiring extensive changes to the physical network and/or network addresses. The potential impact of taking applications offline for network changes means that many organizations decide to forego this industry-wide best practice. Teams that do forge ahead often face months- or years-long effort to create security zones by re–architecting the network, relocating equipment, and re-assigning IP addresses.
It doesn’t have to be that way. Today there’s an elegant solution that greatly simplifies and accelerates network segmentation: VMware NSX Service-defined Firewall. Purpose–built to protect east-west traffic, VMware Service-defined Firewall enables segmentation without any disruptive physical network or address changes.
Attackers Love Flat Networks
To back up a step, let’s examine why network segmentation Continue reading
Eliminate East-West Traffic Hair-Pinning
A firewall is a firewall, right? While on the surface that assumption may appear to be correct, a closer look reveals that there are critical differences between a traditional, appliance-based firewall that protects your network perimeter and a distributed, scale-out internal firewall that protects east-west traffic within your data center.
It’s true that both types of firewalls monitor network traffic, detect threats, and block malicious activity. However, appliance-based firewalls are designed to monitor north-south traffic, which has different volumes and characteristics than east-west traffic. Traditional north-south firewalls were never designed to be used interchangeably to protect both north-south and east-west traffic.
Figure 1: Data center traffic patterns
While it might appear to be the right choice, provisioning appliance-based firewalls for east-west traffic monitoring is not only expensive, it’s highly ineffective in delivering the level of control and performance required to protect growing numbers of dynamic workloads.
Creating Traffic Jams During Volume Spikes
One of the most common drawbacks of using appliance-based firewalls as internal firewalls is the need to hairpin east-west traffic to and Continue reading
Protecting Remote Desktops at Scale with Cloudflare Access
Early last year, before any of us knew that so many people would be working remotely in 2020, we announced that Cloudflare Access, Cloudflare’s Zero Trust authentication solution, would begin protecting the Remote Desktop Protocol (RDP). To protect RDP, customers would deploy Argo Tunnel to create an encrypted connection between their RDP server and our edge - effectively locking down RDP resources from the public Internet. Once locked down with Tunnel, customers could use Cloudflare Access to create identity-driven rules enforcing who could login to their resources.
Setting Tunnel up initially required installing the Cloudflare daemon, cloudflared, on each RDP server. However, as the adoption of remote work increased we learned that installing and provisioning a new daemon on every server in a network was a tall order for customers managing large fleets of servers.
What should have been a simple, elegant VPN replacement became a deployment headache. As organizations helped tens of thousands of users switch to remote work, no one had the bandwidth to deploy tens of thousands of daemons.
Message received: today we are announcing Argo Tunnel RDP Bastion mode, a simpler way to protect RDP connections at scale. ? By functioning as a Continue reading
Network-layer DDoS attack trends for Q2 2020
In the first quarter of 2020, within a matter of weeks, our way of life shifted. We’ve become reliant on online services more than ever. Employees that can are working from home, students of all ages and grades are taking classes online, and we’ve redefined what it means to stay connected. The more the public is dependent on staying connected, the larger the potential reward for attackers to cause chaos and disrupt our way of life. It is therefore no surprise that in Q1 2020 (January 1, 2020 to March 31, 2020) we reported an increase in the number of attacks—especially after various government authority mandates to stay indoors—shelter-in-place went into effect in the second half of March.
In Q2 2020 (April 1, 2020 to June 30, 2020), this trend of increasing DDoS attacks continued and even accelerated:
- The number of L3/4 DDoS attacks observed over our network doubled compared to that in the first three months of the year.
- The scale of the largest L3/4 DDoS attacks increased significantly. In fact, we observed some of the largest attacks ever recorded over our network.
- We observed more attack vectors being deployed and attacks were more geographically distributed.
The number Continue reading
The NSX-T Gateway Firewall Secures Physical Servers
To date, our blog series on securing physical servers with NSX Data Center has covered the use of bare metal agents installed in a physical server. In this scenario, NSX bare metal agents provide management and enforcement of security policy for the physical server. For a quick recap of how NSX Data Center secures physical server traffic, please review our first and second blogs in this multi-part series. In this article, we will discuss the use of one of the NSX-T Gateway services of an NSX Edge Node. Specifically, the NSX-T Gateway Firewall secures physical servers.
What’s The NSX-T Edge?
The NSX-T Edge is a feature-rich L3-L7 gateway. A brief review of some NSX-T Edge services:
- Via Tier-0 Gateway, routing between the logical and the physical using dynamic routing protocols (eBGP and iBGP) as well as static routing
- Via Tier-1 Gateway, routing between logical network segments, or from logical network segments to uplink to the Tier-0 Gateway
- Routing for IPv4 and IPv6 addresses
- Load Balancing via NSX-T Edge, which offers high-availability service for applications and distribution of network traffic load
- Network Address Translation (NAT), available on tier-0 and tier-1 gateways
- To manage IP addresses, the configuration of DNS (Domain Continue reading
Mirai Botnet Exploit Weaponized to Attack IoT Devices via F5 Appliances
Smart use of available resources.
The post Mirai Botnet Exploit Weaponized to Attack IoT Devices via F5 Appliances appeared first on EtherealMind.
Worth Reading: How CEOs think
Robert Graham wrote a great article explaining why CEOs don’t care much about cybersecurity or any other non-core infrastructure (including networking, unless you happen to be working for a service provider). It’s a must-read if you want to understand the **** you have to deal with in enterprise environments.