Creating and applying a security profile

By now we have our, let’s call it, a cloud. It looks like this:

image

We have two tenants each of which has one client and one server. Each tenant has a VSG assigned to it from the previous blog. To be more clear what we are talking about, here is what this cloud looks like when viewed from Virtual Center:

image

We now want to use these VSGs to create and enforce a security policy.

Let’s define TENANT-STARABANKA a security policy:

  • This tenant is using only a RDP protocol for  conducting business
  • Both client and server has the RDP protocol set up
  • In order to make a RDP connection to a server, cloud client has to connect to XP-1 and then to server
  • No direct connection to a server is possible from the world
  • ICMP echo is allowed from the world to both the client and the server for troubleshooting

This is an imaginary security policy, but will do the trick.

Before we actually implement this policy, we need to make sure that all of our components are installed, registered and setup properly. By this I mean virtual infrastructure, physical networking, Nexus, VNMC and VSG.

Let’s make some things more clear within the VNMC. As we recall, the VNMC has a connection to the virtual center and thanks to that we can make our security policies based on virtual center attributes, such as VM name. Without that, we could only based our filters on IP parameters, which can be hard to do with dynamic IP address assignment.

If we open the VNMC and take a look under “Resource Management->Resources”, under the “Virtual Machine” tab for each tenant we don’t see anything inside:

image

Let’s change that. We log into Nexus1KV and see what our tenant’s port profiles look like:

port-profile type vethernet STARABANKA
  vmware port-group
  switchport mode access
  switchport access vlan 112
  no shutdown
  state enabled

 

port-profile type vethernet NOVABANKA
  vmware port-group
  switchport mode access
  switchport access vlan 112
  no shutdown
  state enabled

 

Nothing smart here. In order to make things in VNMC more clear, here is what we are going to do:

Nexus1KV-SPOP#
Nexus1KV-SPOP# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Nexus1KV-SPOP(config)# port-profile STARABANKA
Nexus1KV-SPOP(config-port-prof)# org root/TENANT-STARABANKA
Nexus1KV-SPOP(config-port-prof)#
Nexus1KV-SPOP(config-port-prof)# exit
Nexus1KV-SPOP(config)#
Nexus1KV-SPOP(config)# port-profile NOVABANKA
Nexus1KV-SPOP(config-port-prof)# org root/TENANT-NOVABANKA
Nexus1KV-SPOP(config-port-prof)# exit
Nexus1KV-SPOP(config)# exit
Nexus1KV-SPOP#

Now let’s see if things are better:

image

Much better 🙂

All stuff from now on we will do for TENANTA-STARABANKA. For other tenants things are similar.

First, let’s create two zones: “sb-clients” and place XP-1 inside, and “sb-servers” and place W2008-SB inside. Here are steps we need to follow to create these zones:

 image

After we click “Add vZone”, we specify the name and click “Add Zone Condition”. The “Add Zone Condition” dialog pops up. Within this popup we select VM for “Attribute Type”, VM Name, for “Attribute Name”, eq (Equals) for “Operator” and XP-1 for “Attribute Value”. We then click OK and OK again:

 image

After we do the same for “sb-servers” zone we should have this situation:

image

Along with these two zones, when creating security rules, we have to have in mind one “imaginary” zone: the world, or ANY zone.

We can create our security profile two ways: “top-down” or “bottom-up”. In the “top-down” method, we create a profile, then specify policy set, then policy and then rules. The “bottom-up” is exactly the opposite: we begin from smallest pieces and go upwards. Let’s go with the “top-down” method. 

Let’s follow a picture steps again:

image

When “Add Compute Security Profile” dialog opens, we give a name to our security profile and click “Add ACL Policy Set”:

SNAGHTML5c7d160

Now we create a policy set. Give it a name and click “Add ACL Policy”:nb

image

Then a “Add ACL Policy” dialog opens. We give it a name and create individual rules:

SNAGHTML5cc94cd

First rule will allow a world RDP access to machines within a “sb-clients” zone. “Source Conditions” we leave empty, which means ANY, and under “Destination Conditions” we specify two conditions: a zone “sb-clients” and destination port TCP/3389, which is RDP protocol. Here is our first rule:

image

We repeat this process for other rules…

Second rule says “permit a RDP traffic from client zone to server zone”:

image

Third rule will permit ICMP ping from the world:

image

Finally, we deny and optionally log everything else:

image

Our policy now looks like this:

image

After several OKs, we have now assigned a security profile to a “Compute Firewall” or VSG for this tenant:

SNAGHTML5dd88cd

If we, as a security admin, now log to this tenant’s VSG, we could verify that our profile is actually pushed down from VNMC:

STARABANKA-VSG#
STARABANKA-VSG# show run policy

Policy default@root
  rule default/default-rule@root order 2
Policy sb-pset-1@root/TENANT-STARABANKA
  rule sb-policy-1/sb-rule-1@root/TENANT-STARABANKA order 101
  rule sb-policy-1/sb-rule-2@root/TENANT-STARABANKA order 201
  rule sb-policy-1/sb-rule-3@root/TENANT-STARABANKA order 301
  rule sb-policy-1/sb-rule-4@root/TENANT-STARABANKA order 401

STARABANKA-VSG#

We can see our policy with four rules we defined. We can also see the rules:

 

STARABANKA-VSG#
STARABANKA-VSG# show run rule

rule default/default-rule@root
  action 10 drop
rule sb-policy-1/sb-rule-1@root/TENANT-STARABANKA
  condition 10 dst.net.port eq 3389
  condition 11 dst.zone.name eq sb-clients@root/TENANT-STARABANKA
  condition 12 net.protocol eq 6
  action 10 permit
rule sb-policy-1/sb-rule-2@root/TENANT-STARABANKA
  condition 10 dst.net.port eq 3389
  condition 11 dst.zone.name eq sb-servers@root/TENANT-STARABANKA
  condition 12 src.zone.name eq sb-clients@root/TENANT-STARABANKA
  condition 13 net.protocol eq 6
  action 10 permit
rule sb-policy-1/sb-rule-3@root/TENANT-STARABANKA
  condition 10 net.protocol eq 1
  action 10 permit
rule sb-policy-1/sb-rule-4@root/TENANT-STARABANKA
  action 10 log
  action 11 drop

STARABANKA-VSG#

This is exactly what we set up from the VNMC. We could do this process from the VSGs CLI, but, hey, these rules are not good old ACLs 🙂

 

Remember our “role separation” story? Here is where security admin goes to grab a coffee. After a first sip, he/she calls to a network admin, because this security profile just created needs to be applied to a port profile within a Nexus switch. The job of a network guy is rather simple. He needs to create a “virtual service” of type VSG and use it to call a security profile through it. On the Nexus:

Nexus1KV-SPOP#
Nexus1KV-SPOP# show run vservice node

!Command: show running-config vservice node
!Time: Fri Feb 15 11:03:38 2013

version 4.2(1)SV2(1.1)
vservice node STARABANKA-VSG type vsg
  ip address 10.1.10.144
  adjacency l2 vlan 144
  fail-mode open

Nexus1KV-SPOP#

 

Do you still remember infamous “Data IP Address”? You can see it above!

After a network admin created this virtual service, he needs to apply it to a port profile. Again, on the Nexus:

Nexus1KV-SPOP#
Nexus1KV-SPOP# show run port-profile STARABANKA

!Command: show running-config port-profile STARABANKA
!Time: Fri Feb 15 11:05:58 2013

version 4.2(1)SV2(1.1)
port-profile type vethernet STARABANKA
  vmware port-group
  switchport mode access
  switchport access vlan 112
  org root/TENANT-STARABANKA
  vservice node STARABANKA-VSG profile sb-profile-1
  no shutdown
  state enabled

Nexus1KV-SPOP#

 

If our tenants receive their IP addresses from a DHCP server, and chances are they do, most probably that DHCP server will be located outside all tenants. So in order for clients from tenants to be able to talk to the outside DHCP server, that communication should be allowed. For example, by adding two more rules to a policy:

image

So rules “dhcp-req” and “dhcp-resp” allows communication to and from a DHCP server. Without these rules, clients would not be able to obtain IP addresses, which could be verified in the syslog server entry:

policy=nb-pset-1@root/TENANT-NOVABANKA
rule=nb-policy-1/rule-4@root/TENANT-NOVABANKA action=Drop
direction=ingress src.net.ip-address=0.0.0.0 src.net.port=68 dst.net.ip-address=255.255.255.255 dst.net.port=67
net.protocol=17 net.ethertype=800 dst.zone.name=(null)  src.zone.name=(null)

Or better yet, we could create a separate policy, let’s say “dhcp-policy” at the universe, or root level:

image

Now this policy would be available to all tenants and the only thing we would want for each tenant is do add this policy in front of existing one within a security profile:

image

Perhaps there is more stuff to be added to these policies, but they are just examples. Production policies would be certainly more complicated and wider.

Now network admin can join a security admin on a coffee break. Then, after a first sip of his coffee he calls to a server admin and tells him to assign TENANT-STARABANKA clients and servers to this port group. Remember, server admin calls port profiles a port groups. This is example from XP-1:

image

Finally, all three admins can hang out together, enjoying their coffee 🙂

One final thought: whenever clients or servers from this tenant changes ESX hosts, for example because of vMotion, this security profile follows them. The only two ways this security profile wouldn’t apply are moving VMs to another port group or remove security profile setting from port profile on Nexus.

Next time we will add the “ASA1000V Cloud Firewall” to this cloud cake.

 

Thanks for reading!

Advertisements
This entry was posted in Cisco, Cloud, Security, Virtualization and tagged , , , , . Bookmark the permalink.

One Response to Creating and applying a security profile

  1. TJ says:

    Do you know how to actually add a rule directly from VSG via the CLI.

    For example your rule here:

    rule sb-policy-1/sb-rule-1@root/TENANT-STARABANKA
    condition 10 dst.net.port eq 3389
    condition 11 dst.zone.name eq sb-clients@root/TENANT-STARABANKA
    condition 12 net.protocol eq 6
    action 10 permit

    I am running VSG 5.2.1 and there is no “rule” command in config mode.
    VSG(config)# rule?
    ^
    % Invalid command at ‘^’ marker.

    Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s