cisco-sa-20160210-asa-ike advisory ACL question

[CHRISTOPHER ROSE]

Hello. I have a question regarding interface ACL's and IPsec VPN tunnels that was prompted by this advisory.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike

A VPN connection has many traffic components including isakmp, IKE, and ESP or AH protocol packets. The Cisco documentation states that IP-sec traffic by default will bypass an interface ACL. Does this just mean the ESP and AH packets? Or does this include the ISAKMP and IKE traffic as well. The reason I ask is I am wondering if we lock our outside ACL to only permit IKE traffic from the other L2L VPN tunnel endpoint then we can avoid this problem mentioned in the advisory. 

I know sysopt connection permit-vpn can turn on or off ACL bypass. My question is does this ACL bypass only involve "established" tunnel traffic or does it also include the traffic involve din establishing a tunnel? (ISAKMP/IKE)?

Any answers are appreciated as I am trying to guage our exposure and remediation options here.Thanks in advance

[Jon Marshall]

It doesn't mean AH and ESP packets.

When it says by default it will bypass interface acls it is talking about the decrypted traffic from the tunnel and that is what you control using the "sysopt connection permit-vpn" command.

The IKE and ESP packets are allowed by default on any ASA interface that has ISAKMP enabled and ,as far as I know, you can't filter that with an acl.

I could be wrong about that but that is always how I have understood it, if anyone knows different please correct me.

I suspect that is why the advisory says there are no workarounds for it.

Jon

[Karsten Iwen]

> I could be wrong about that but that is always how I have understood it, if anyone knows different please correct me.

In general, the ACLs only filter traffic that goes through the ASA but not traffic to the box. Traffic to the box is allowed/denied with other commands (ssh/http/icmp/...).

But: ACLs can also be bound to the control-plane. I've never used it that way in production and have never seen it somewhere. In theory, it could be possible to filter with that on valid peers. But the documentation states that these ACLs are overwritten by explicit commands like ssh/http and the security-advisory states that there is no workaround. So I expect that it won't work but it's worth a try.

[Jon Marshall]

Hi Karsten

I should stop posting in these forums and stick to Network Infrastructure as I am obviously not up to speed with all the possibilities :)

Sounds like it might be worth a try.

Thanks for correcting.

Jon

[Karsten Iwen]

And I should stop talking about the usage of /31 masks in the LAN-forum ... ;-)

[Jon Marshall]

:-)

[Karsten Iwen]

Another thought on using control-plane ACLs:

If the vulnerability is exposed already with the first packet of the IKE exchange, then this ACL can easily be circumvented by spoofing a valid peer. For sure, that would be already a directed attack, but the device would be still vulnerable.

Sadly, I don't find any detailed information on this vulnerability yet, and looking at the snort-rule details also doesn't really help.

[James Leinweber]

I think the control-plane ACL's can block other mischief, but are no help this time. The bug is in the fragment reassembly, which presumably takes place before a control-plane ACL could do anything.

-- Jim Leinweber, WI State Lab of Hygiene