Archive

Category Archives for "Security"

VMware NSX Micro-segmentation – Horizon 7

Organizations that embark on the journey of building our virtual desktop environments, are taking traditionally external endpoints and bringing them into the data center.  These endpoints are now closer and most times, reside on the same networking infrastructure as the backend application servers that they may access. These endpoints run Windows or even Linux desktop operating systems with multiple end-users that can access them. Malicious attacks that would traditionally take place outside the data center should an end-user find their desktop or laptop machine infected, could now take place on their virtual desktops inside the data center.  With physical equipment, it’s easy to isolate the physical desktop or laptop and remediate the attack.  Securing virtual desktop environments requires a different approach, but not one that’s unattainable.  Securing an end user computing deployments is one of the primary security use cases for VMware NSX and can help provide a layered approach to securing virtual desktop workloads in the data center.

The NSX platform covers several business cases for securing an end user computing deployment.  Each of these use cases, helps provide a multi-layered approach to ensure end user endpoints are as secure as possible in the Continue reading

Enhancing NSX with Check Point vSEC

While VMware NSX enables micro-segmentation of the Software Defined Data Center, it mostly polices traffic in layers 3 and 4, with only limited application level (layer 7) support.  Sometimes additional layers of protection are needed for use cases such as Secure DMZ or meeting regulatory compliance requirements like PCI, in which case partner solutions can be added to the platform, with traffic steered into the supplemental solution prior to reaching the vSwitch (virtual wire).  The resulting combination is high throughput due to the scale-out nature of NSX, but can also provide deep traffic analysis from the partner solution.

The usual enemy of deep traffic inspection in the data center is bandwidth.  NSX addresses this issue, micro-segmentation security policy is zero trust – only traffic explicitly permitted out of a VM can pass, then steering policy to 3rd party solutions can be designed in order that bulk protocols such as storage and backup bypass them, leaving a more manageable amount of traffic for Check Point vSEC to provide IPS, anti-virus and anti-malware protection on, including Check Point’s Sandblast Zero-Day Protection against zero day attacks.

The connection between vSEC and NSX enables dynamic threat tagging, where traffic from an VM reaches Continue reading

14,000 Incidents: a 2017 Routing Security Year in Review

How was the state of the Internet’s routing system in 2017? Let’s take a look back using data from BGPStream. Some highlights:

  • 13,935 total incidents (either outages or attacks like route leaks and hijacks)
  • Over 10% of all Autonomous Systems on the Internet were affected
  • 3,106 Autonomous Systems were a victim of at least one routing incident
  • 1,546 networks caused at least one incident

An ‘incident’ is a suspicious change in the state of the routing system that can be attributed to an outage or a routing attack, like a route leak or hijack (either intentional or due to a configuration mistake).[i] Let’s look at just a few examples of incidents picked up by the media.

March 2017. SECW Telecom in Brazil hijacked prefixes of Cloudflare, Google, and BancoBrazil causing some outage for these services in the region.

April 2017. Large chunks of network traffic belonging to MasterCard, Visa, and more than two dozen other financial services companies were briefly routed through a Russian telecom. For several minutes, Rostelecom was originating 50 prefixes for numerous other Autonomous Systems, hijacking their traffic.

August 2017. Google accidentally leaked BGP prefixes it learned from peering relationships, essentially becoming a transit provider instead Continue reading

“Building NSX Powered Clouds and Data Centers for SMBs” is available now

I am honored and humbled to announce my new book “Building NSX Powered Clouds and Data Centers for Small and Medium Businesses”.

 

 

Building VMware NSX Powered Clouds and DCs for SMB Book Cover Page

 

This is a concise book that provides step by step information to design and deploy NSX in Small and Medium size data centers. My aim for writing this book is to give architects and engineers the necessary tools and techniques to transform their data center from legacy architecture to software defined (SDN) architecture. The SDN architecture is the foundation to build the private cloud.

The book has about 90 pages covering following topics:

  • NSX and SMB data center introduction
  • Important vSphere design considerations
  • vSphere cluster design and NSX deployment models
  • NSX individual component design and deployment considerations
  • NSX Operations: monitoring and troubleshooting
  • Growing NSX deployments

Many technology vendors tend to focus efforts in the large data center space, the fact remains that the small/medium business (SMB) space represents a substantial part of the IT marketplace.

The book is available to purchase from NSX Store.
Electronic version of the book can be downloaded from here.

The post “Building NSX Powered Clouds and Data Centers for SMBs” is available now appeared first on Network Virtualization.

VMware Cloud on AWS with NSX: Communicating with Native AWS Resources

If you haven’t already, please read my prior two blogs on VMware Cloud on AWS: VMware SDDC with NSX Expands to AWS and VMware Cloud on AWS with NSX – Connecting SDDCs Across Different AWS Regions; also posted on my personal blog at humairahmed.com. The prior blogs provide a good intro and information of some of the functionality and advantages of the service. In this blog post I expand the discussion to the advantages of VMware Cloud on AWS being able to communicate with native AWS resources. This is something that would be desired if you have native AWS EC2 instances you want VMware Cloud on AWS workloads to communicate with or if you want to leverage other native AWS services like AWS S3 VPC Endpoint or RDS. Continue reading

VMware Cloud on AWS with NSX: Communicating with Native AWS Resources

VMware Cloud on AWS with NSX: Communicating with Native AWS Resources If you haven’t already, please read my prior two blogs on VMware Cloud on AWS: VMware SDDC with NSX Expands to AWS and VMware Cloud on AWS with NSX – Connecting SDDCs Across Different AWS Regions; also posted on my personal blog at humairahmed.com. The prior blogs provide a good intro and information of some of the functionality and... Read more →

Meltdown and Spectre: Why We Need Vigilance, Upgradeability, and Collaborative Security

Today the tech media is focused on the announcement of two security vulnerabilities, nicknamed Meltdown and Spectre, that are found in almost all CPUs used in modern devices. Mobile phones, laptops, desktop computers, cloud services, and Internet of Things (IoT) devices are all vulnerable.

There are many articles being published on this topic. The best source of information I’ve found is this site by the security researchers at the Graz University of Technology:

https://meltdownattack.com/

At the bottom of that page are links to the security blog posts, advisories, and other statements from companies and organizations across the industry. In an excellent example of the principles of Collaborative Security, the announcement was coordinated with the release of patches and updates for a wide range of operating systems and devices.

For readers wanting a deeper technical dive, the site from Graz University has links to multiple academic papers. Google’s Project Zero team also published a detailed technical analysis.

From our perspective, today’s news highlights a couple of points:

  • Keeping up to date on patches is critical. We each need to ensure that we upgrade our own systems and devices. If we work for organizations/companies, we need to ensure that processes are in place Continue reading

Some notes on Meltdown/Spectre

I thought I'd write up some notes.

You don't have to worry if you patch. If you download the latest update from Microsoft, Apple, or Linux, then the problem is fixed for you and you don't have to worry. If you aren't up to date, then there's a lot of other nasties out there you should probably also be worrying about. I mention this because while this bug is big in the news, it's probably not news the average consumer needs to concern themselves with.

This will force a redesign of CPUs and operating systems. While not a big news item for consumers, it's huge in the geek world. We'll need to redesign operating systems and how CPUs are made.

Don't worry about the performance hit. Some, especially avid gamers, are concerned about the claims of "30%" performance reduction when applying the patch. That's only in some rare cases, so you shouldn't worry too much about it. As far as I can tell, 3D games aren't likely to see less than 1% performance degradation. If you imagine your game is suddenly slower after the patch, then something else broke it.

This wasn't foreseeable. A common cliche is that such bugs Continue reading

Why Meltdown exists

So I thought I'd answer this question. I'm not a "chipmaker", but I've been optimizing low-level assembly x86 assembly language for a couple of decades.





The tl;dr version is this: the CPUs have no bug. The results are correct, it's just that the timing is different. CPU designers will never fix the general problem of undetermined timing.

CPUs are deterministic in the results they produce. If you add 5+6, you always get 11 -- always. On the other hand, the amount of time they take is non-deterministic. Run a benchmark on your computer. Now run it again. The amount of time it took varies, for a lot of reasons.

That CPUs take an unknown amount of time is an inherent problem in CPU design. Even if you do everything right, "interrupts" from clock timers and network cards will still cause undefined timing problems. Therefore, CPU designers have thrown the concept of "deterministic time" out Continue reading

Let’s see if I’ve got Metldown right

I thought I'd write down the proof-of-concept to see if I got it right.

So the Meltdown paper lists the following steps:

 ; flush cache
 ; rcx = kernel address
 ; rbx = probe array
 retry:
 mov al, byte [rcx]
 shl rax, 0xc
 jz retry
 mov rbx, qword [rbx + rax]
 ; measure which of 256 cachelines were accessed

So the first step is to flush the cache, so that none of the 256 possible cache lines in our "probe array" are in the cache. There are many ways this can be done.

Now pick a byte of secret kernel memory to read. Presumably, we'll just read all of memory, one byte at a time. The address of this byte is in rcx.

Now execute the instruction:
    mov al, byte [rcx]
This line of code will crash (raise an exception). That's because [rcx] points to secret kernel memory which we don't have permission to read. The value of the real al (the low-order byte of rax) will never actually change.

But fear not! Intel is massively out-of-order. That means before the exception happens, it will provisionally and partially execute the following instructions. While Intel has only 16 Continue reading

Fortinet FortiGate-VMX and NSX use cases

NSX is an extensible platform; other vendors security solutions can be added to it by means of the Northbound REST API, and two private APIs: NETX for network introspection, and EPSEC for guest introspection.

Fortinet’s FortiGate-VMX solution uses the NSX NETX API to provide advanced layer 4-7 services via service insertion, also called service chaining.  This enables the additional inspection of VM traffic prior to that traffic reaching the vSwitch.  This enhances micro-segmentation where there is need for greater application recognition, anti-malware, and other Next Generation Firewall features.  The scale-out nature of NSX is maintained as NSX handles the instantiation of FortiGate service VMs on the hosts within the deployed cluster retaining its operational advantages, if the cluster grows additional FortiGate-VMX service machines will be created as needed.

 

 

One of the primary advantages to FortiGate-VMX is the availability of VDOMs for multi-tenancy in a service provider or enterprise environment – this enables segmenting traffic by organization, business group, or other construct in addition to application.  The segregation includes the administration, VDOMs are managed independently of one another, this can also be used to split the different security functions such as anti-virus, IPS, and application control into isolated units or only Continue reading