Serious vulnerability in Cisco IOS

Jeremy Kirk at Databreach just wrote about a serious vulnerability found on nearly all of Cisco’s IOS devices (Including ASA’s). The vulnerability named Thangrycat requires a good amount of effort to patch the affected hardware, although at the moment, its saving grace is that the attach requires the  “local attacker” to be authenticated in order to write a modified firmware image to the component.

Not all gloom and doom, but a significant find!

 

 

Inside access to external NAT IP services

The corporate office has an environment where there is a separate “guest” network for vendors, visitors, etc. that can use their own devices, to use internet services through Wi-Fi.
Due to the fact some internal services are needed such as joining internal Audio/Video conferences, and access to collaborative services, we had a requirement that access to those services be available through this semi-public network that is “external”, i.e. uses external DNS resolution, but is still “inside” the firewall boundary as shown below.

Access from GuestNet-Diag

To spell it out, we had the following infrastructure:

  • Internal services only accessible from inside the corporate network and internal devices.
  • External services accessible from outside the corporate network.
  • Guest network with external/public DNS resolution.

The requirements are as follows:

  • Internal services accessible externally if secured with boundary extending services, primarily Microsoft Direct Access, or if explicitly approved, Cisco VPN software.
  • Skype for Business availability for Guest Wi-Fi to join conferences and collaboration.
  • SharePoint services (specifically Office Online Server) for collaboration access from Guest Wi-Fi.

Cisco has a good article here: https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/72273-dns-doctoring-3zones.html to make this process work, the D-NAT methodology was used, but the article can a bit confusing, so I just wanted to explain a couple things to clarify it, and show how the final NAT rules end up looking.

The following are the relevant NAT rules:

Access from GuestNet

  • For the Match Criteria:
    • Source is the Guest network.
    • Destination for the Skype for Business services is the “inside” DMZ interface, as in this case, the DMZ is sandwiched, has an internally facing network, and an externally facing network, or wherever the service resides, as some services are on the “services” network.
    • IP source is the Guest network object.
    • IP destination is the External IP of the service.
  • For the Action:
    • Source is wherever the service resides.
    • Destination is the Internal IP of the service.

I hope this helps clarify the Cisco article.