virtual grind thoughts from the virtual world


Cisco Vulnerability – CVE-2016-1287

Recently, Cisco published an advisory highlighting a critical buffer overflow vulnerability that affects the ASA, ASAv, Firepower ASA, and ISA products. This vulnerability is remotely exploitable and the SANS ISC is reporting large spikes in UDP 500 scanning.

The vulnerability affects many different ASA versions and some older 8.x versions are not able to be patched, without doing a major version upgrade. This could be challenging for some organizations since there are numerous operational changes within the ASA firmware and how the ASA deals with NAT, for instance. Fortunately, Stack8 has released a workaround for older versions if an organization cannot upgrade. This also may be a good idea for organizations that need time to plan their upgrade or wait for a change window.

I would urge all organizations to take this vulnerability very seriously and patch as soon as possible. I already see exploits in the wild that can do things like reboot the ASA, download/upload config, and also install an ASA rootkit.

For the technical readers, a full explanation of the vulnerability is here.


vCloud Director Cell Firewall Settings – Cisco ASA

In a vCloud Director environment, vCD cells are usually placed in a DMZ network. Based on best practices, a load balancer is also used in multi-cell environments, which is placed in front of the vCD cells.

Access to/from the vCD cells should be restricted not only from the public side, but also internally. For instance, vCD cells do need to communicate with a database vlan where a database server lies and a management vlan where services such as vCenter live.

When configuring multiple vlans, certain access lists are placed between the vlans for communication. An example of this would be an access list that allows your vCD cells to communicate with the database vlan. For example, you may have an access list that allows tcp port 1521 (Oracle) from your vCD cells to your database server.

Another issue that may come up are keepalives for tcp streams between your vCD cells on one vlan and your esxi hosts on another vlan. vCloud Director will also email messages such as:

"The Cloud Director Server cannot communicate with the Cloud Director agent on host "hostname". When the agent starts responding to the Cloud Director Server, Cloud Director Server will send an email alert.

If you are using a Cisco ASA environment, this issue can be fixed easily with a feature called Dead Connection Detection.

The following config will allow you to do this:

1. Create an access-list that allows the ip addresses or subnet of your vCD cells:

access-list vcd_dcd extended permit ip host any
access-list vcd_dcd extended permit ip host any


access-list vcd_dcd extended permit ip any

These access lists would allow your vCD cells on and .11 or Note that you can also make this access-list more specific by defining the destination, which would be your esxi hosts or subnet. An example of this would be:

access-list vcd_dcd extended permit ip host host
access-list vcd_dcd extended permit ip host host


access-list vcd_dcd extended permit ip

2. Next, you need to make a class-map:

class-map vcd_keepalive_class
match access-list vcd_dcd

3. Create a policy-map that defines your timeout and dcd settings:

policy-map vcd_keepalive_policy
class vcd_keepalive_class
set connection timeout idle 2:00:00 dcd 0:10:00 3

4. Finally, create a service policy for the interface where your vCD cells reside:

service-policy vcd_keepalive_policy interface INTNAME

* Note that you will change "INTNAME" with the ASA interface (nameif) name.

For reference, this Cisco article covers DCD in detail:

Configuring Connection Limits and Timeouts