Archive for the ‘ASA’ Category
Cisco ASA presents self-signed cert in certain SSL negotiations – CSCuu02848 / CSCuw02001
Just kind of a shout-out to those running ASA’s, be careful when you upgrade to v9.4+ or v9.5+, and beyond.
In v9.4+ when the ASA attempts to negotiate an SSL connection it will attempt to use an ECDSA Cipher as part of TLS v1.2 if the client supports Elliptic Curve ciphers. In this situation the ASA will present it’s self-signed certificate regardless of it’s configuration.
You’ve got 2x Options to fix this:
- Use an ECDSA Certificate
- Disabled ECDSA Cipher with the following command: (Might want to cut-out some of those weaker ciphers)
ssl cipher tlsv1.2 custom “AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DES-CBC3-SHA:DES-CBC-SHA:RC4-SHA:RC4-MD5”
Funny thing is, this is mentioned in the v9.4 release notes. However, it is not mentioned in the v9.5 release notes, so if you were to say upgrade from v9.2 or v9.3 and hop directly to v9.5 (A fully supported upgrade path) this could be something that creeps up on you. After all why you read through the release notes of release you are completely skipping!
Direct Link to the bug can be found here.
You can easily verify this by capturing the SSL Negotiation and checking the Client Hello for TLSv1.2 and EC Ciphers:
Of course the Browser Certificate error will be a dead giveaway but sometimes it’s nice to check.
Do keep in mind though, in order to be affected by this you must be doing the following:
- SSL Services running the ASA
- Running v9.4 or beyond
- Running the default SSL Ciphers for TLSv1.2
- Be running an RSA only certificate for SSL negotiation.
Happy hunting, I mean Labbing!
DHCP Reservations on a Cisco ASA 5505. Maybe?
So the Cisco ASA 5505 is the smallest ASA firewall in the ASA family, only designed for SOHO and real small branch office. It’s even cheaper than most of the current 800 series routers, can provide IPSec VPN access, AnyConnect access, and basic routing sounds like a great deal right? Well, it is however after a while you will notice some functionality is missing from this nice ASA that we take for granted in our normal everyday ISR Routers.
One of those of features is the ability to setup a DHCP reservation, the 5505 can run a DHCP server with various scope options but the ability to setup reservations has been left out. We can only speculate as to why such a simple feature would be excluded. However setting up a static ARP entry provides a quick work around for this feature. Somehow when the static ARP entry is configured, the ASA apparently knows not to hand out the address to a different host. I tested this out with a scope handing out a single IP address and a scope handing out multiple addresses with the same result. The end device configured with the static entry got the IP address in the static ARP entry configuration. When the scope was configured with a single address and a static ARP entry, I connected a different PC and the ASA would not hand out that single IP address to a different host.
However, one small caveat this feature is not supported by Cisco TAC so if you put in a ticket about DHCP reservations and static ARP entries you won’t get too far. I tested this on a few different 8.4 versions with success but since it isn’t a supported feature I wouldn’t really rely on this for anything mission critical but it something to keep in mind if you are in a pinch.
When does the Cisco ASA IPS module inspect traffic?
Sure we can put an IPS module inside an Cisco ASA firewall but the first you may ask or will be asked is at what point does that traffic get inspected by the IPS Module? Which might not seem like a tough question but it can make you think if you got VPNs terminating on your ASA, does it inspect the traffic before encryption, after encryption, or is encrypted traffic bypassed? I did a post about the packet flow through a Cisco ASA some time ago and it did mention the IPS is involved after NATs, application inspection, and even ACLs however there was no mention of how encrypted VPN traffic.
Well, as it turns out the traffic is redirected to the IPS module after it enters the ASA on the ingress interface, the VPN traffic is decrypted, and the firewall inspection policies have been applied. Now for outgoing VPN traffic the IPS inspects that traffic and then it is encrypted and sent through the IPSec connection. Makes perfect sense.
Here is a quick visual from Cisco.com:
You’ll notice once the traffic enters from the outside interface, if it is VPN traffic it is then decrypted sent though the firewall policies and is then diverted to the IPS module. Once the IPS module has had a chance to inspect the traffic it is then sent back to the ASA to be sent out the inside interface.
Something I want to point out the IPS Modules work in 2 different modes, inline mode which is shown above where the traffic is sent through the IPS module and back into the ASA this mode may degrade throughput depending on the model of the module and the amount of traffic being inspected. We also have Promiscuous mode where the traffic is not sent directly though the IPS Module but the IPS module instead receives a copy of the traffic to inspect. The upside of promiscuous mode is the fact throughput is not effected however it is less secure than inline mode since the traffic sent to its destination at the same time it sent to the IPS module, the IPS module however can sent a RST packet ending connection or ‘shun’ the offensive IP address. When an address is ‘shunned’ any traffic from that source is dropped.
Here is a quick visual of promiscuous mode:
You can read more about the IPS ASA module inspection process here.
Packet flow through a Cisco ASA.
As I was reading my Cisco Firewalls book I found this picture (very early on to) concerning how a Cisco ASA handles traffic passing through the device and the logic behind it. it’s a chart worth paying attention to in my opinion. I mean we are going to be practical here, you are not going to run off and debug ip packet for every ASA issue you run into but knowing and understanding the flow chart below will surely give you an edge when troubleshooting ASA connectivity issues.
Now looking this at first glance might be slightly intimidating but in the end this is nothing more than a flow chart. Now, as you follow this flow chart much of the actions will seem like common sense:
- If the ASA does not have a route to the destination the traffic gets dropped. (Of course)
- If the traffic is denied by an ACL it gets dropped. (As we would expect)
- If an Inspect rule is configured to drop the it get dropped. (Once again, as we would expect)
What I think makes this flow chart most valuable is the fact you see in which order these rules are applied looking at the flow chart we see the following order:
- ACL’s will be checked first.
- NAT rules will checked second.
- Inspect policies will applied next.
- Then after all that the packet enters IPS-AIM Module for inspection, after that it leaves through the egress interface.
CCIE or Null! 