security Archives - TBL Networks

Cisco Umbrella Webinar – Watch Now!

Posted on April 18, 2019May 6, 2019 by Lauren Bell

Built into the foundation of the Internet, Cisco Umbrella is a cloud security platform that provides the first line of defense against threats, from wherever users access the Internet – on or off the corporate network. Join Nick Kelly, Cisco Cybersecurity Engineer, for an in-depth overview on how to deploy Cisco Umbrella in minutes and utilize the threat intelligence and context to block threats before they become attacks.

In this recorded webinar you’ll learn:

How to protect mobile users on laptops, Apple iOS devices and Chromebooks
The value of visibility and security for users both on and off networks at the DNS layer
How to discover which applications are in use in your corporate environment and by your roaming users

End to end virtual network security with the Cisco Nexus VSG

Posted on April 11, 2011February 11, 2019 by admin

So I’ve been spending a lot of time in our lab with the Cisco Nexus Virtual Security Gateway. I have come to the conclusion that it rocks! Finally, the virtual infrastructure is no longer treated as a second class citizen when it comes to securing network traffic between virtual machines. We are at a point now with the Cisco VSG that we can have robust Cisco infrastructure, including security, from the upstream physical network to the virtual network.

The Cisco Nexus VSG builds upon the Nexus 1000v distributed virtual switch and communicates with the Virtual Ethernet Modules in the Nexus 1000v to provide a very robust security policy engine that can perform granular filtering and matching on a number of parameters. For example:

Network (ip address, port number, etc.)
VM (VM Name, Installed OS Name, Cluster, Host, Zone)

Yep, that’s right, I said VM. Since the Cisco VSG integrates with the vSphere API’s and vCenter, you can filter on items like a virtual machine name or partial name, installed OS, cluster, etc. This is very powerful. I no longer have to rely on network and IP rules alone to filter traffic between virtual machines. This is a more intelligent approach to filtering that really highlights the synergies that Cisco and VMware have established. Best of all, once it is set up everything is managed from a single Cisco Virtual Network Management Center (VNMC) instance. This web-based management tool let’s you manage multiple Virtual Security Gateway instances. Let’s look at a simple example of how easy it is to perform traffic filtering in the virtual infrastructure with the Cisco VSG.

Topology and Components:

vSphere 4.1 Enterprise Plus Host Servers
Cisco VNMC VM
Cisco Nexus 1000v Infrastructure
Cisco VSG Infrastructure
tenanta-srv1 VM
tenanta-srv2 VM
tenantb-srv1 VM
tenantb-srv2 VM

The goal of this configuration is to allow the following communication flows:

tenanta-srv1 and tenanta-srv2 should communicate
tenantb-srv1 and tenantb-srv2 should communicate
The Tenant A servers(tenanta-srv1 and tenanta-srv2) should not be able to communicate with the Tenant B servers (tenantb-srv1 and tenantb-srv2)
Anyone else should be able to communicate with both the Tenant A and Tenant B servers
There is a further caveat that the Tenant A and Tenant B servers are both on the same subnet (don’t worry these servers belong to the same company )

Below are the network settings:

tenanta-srv1 VM – 10.91.41.200
tenanta-srv2 VM – 10.91.41.201
tenantb-srv1 VM – 10.91.41.202
tenantb-srv2 VM – 10.91.41.203
a client with another ip address

Here are the general steps for setting up this scenario once the Cisco VSG infrastructure is in place:

Create a tenant
Assign the VSG to the tenant
Create a zone each for the Tenant A and Tenant B servers (these zones match VM’s with names that contain “tenanta” and “tenantb” respectively)
Create a firewall policy for the VSG
Create a policy set that includes the policy
Bind the policy set to the VSG
Bind the tenant to a port-profile so that any VM that is on that port-profile is filtered with the policy rules

Below are the screenshots of the results after the VSG was configured.

These are the only rules that are required for the communication flows.

Here is what the port-profile looks like on the Nexus 1000v. Notice the org and vn-service entries. This means that this port profile is VSG aware.

The ICMP traffic from the Tenant A Servers.

The ICMP traffic from the Tenant B Servers (same result as the Tenant A servers. Only one is shown here.)

Finally the results from the external client

As you can see, we achieved our goal with just three filtering rules. Also, we were able to leverage VM name filtering instead of IP filtering which allowed us to filter on the same subnet without resorting to naming each IP address or different port numbers. Very cool! The Cisco VSG is capable of many complex configurations combining both networking categories (ip, port number, etc.) and VM categories. This was just a quick example of what can be done. As always, if you have any questions or would like to see a live demo feel free to contact me.

Active Directory Authentication – Accountability in ESX / ESXi 4.1

Posted on August 3, 2010February 11, 2019 by admin

As a part of TBL professional services datacenter practice, I perform many health and security checks on virtual infrastructures for clients. One of the common issues that I run into is the use of the default “root” account for administering ESX servers. This is an issue for two reasons:

The “root” account has a tremendous amount of power and the password for it is typically the same shared password on each ESX host.
If all administration is done with the “root” account there is no audit trail for accountability. It could have been Joe, Bob, or Sue that logged into the ESX host. You just don’t know.

Of course, most administration should be done through vCenter, but you still occasionally need to log into an ESX host directly. The solution to this that I have recommended in the past has been to create local user accounts coinciding with the Active Directory user name on each ESX host. Then do not use root unless absolutely necessary when performing administrative tasks directly on the host. However, this meant that the IT Administrators would need to manage user accounts in Active Directory and the local accounts on the ESX / ESXi hosts.

There has been a “less than ideal” solution to Active Directory authentication for quite a while (see Scott Lowe’s article). However, this solution was very laborious, involves the command line, and only worked on ESX Classic. Not ESXi.

With the release of vSphere 4.1, native Active Directory authentication is one of the many new features. Here’s how easy it is to implement once you have ESX installed.

Connect to your ESX/ESXi server with the vSphere Client.
Click on “Inventory” and highlight your ESX/ESXi server.
Click on the “Configuration” tab.
Navigate to “Software –> Authentication Services”
Click on “Properties” on the right hand side.
Change the “Directory Service Type” from “Local Authentication” to “Active Directory”
Once you do that and enter in your Domain, click “Join Domain” and you will be prompted for appropriate credentials to join the domain.
Click “OK” when you are done.

That’s it! Now you can have accountability controlled through Active Directory Authentication. Joe, Bob, and Sue can all use their respective Active Directory accounts for authentication. Accountability!

Permissions can now be added for Active Directory users and groups as well.

You can even use it with the vSphere CLI and the Direct Console User Interface (DCUI) on ESXi.

Should you still need the local “root” account for emergencies, it will still be available to you. Otherwise, do your company a favor and maintain an audit trail for administrative actions on your infrastructure.