Posts Tagged ‘Cisco ASA’
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!
Since Cisco announced EoX for both it’s traditional IPS and it’s CX-Modules it’s been time to start looking at the new SourceFire modules, however that can be quite an undertaking since SourceFire is a completely different beast from its predecessors. Which raises the question where do you start to begin getting familiar with this new system.
I’ve found a good place to start is with a Cisco Live Sessions BRKSEC-2018 (Link below), the reason I like this session is the fact it covers many of the initial questions for implementing or migrating to the new platforms:
- How is the new platform managed & maintained. Being able to successfully manage a platform is one of the most important aspects of deploying a technology. After you verify that technology will meet your deployment requirements of course.
- What is the best way to migrate from the traditional IPS or CX platforms. whether or not you using a software module in the 5500-X ASA Firewalls, hardware modules in the 5585-X platforms, or if you have been using dedicated IPS appliances.
- The new licensing structure. Sometimes we get lost in the technical details, however the licensing details can take our deployment and stop it dead in its tracks.
- How the new policies work. Next-Gen IPS is a much needed and drastic change from its predecessor, understanding the new capabilities and how to configure these features are detrimental to a successful and secure deployment.
Outside of the deployment considerations, this session skims the surface of a technical deep dive. However, There are a handful of other Cisco Live Sessions, (links are below) that go more in depth into other aspects of SourceFire and FireSight’s capabilities.
The next best stop is going to be reviewing the configuration guide for FireSIGHT, which is the management platform for the SourceFire platforms. Like many other configuration guides you are looking down a few hundred intimidating pages. So it might be best to start off with the topics you need and then expand.
There are also some great Configuration Examples out on Cisco.com that cover topics from the initial setup and install, URL Filtering, Active Directory Integration and required permissions, to some SNORT examples.
Small collection of SourceFire Links:
A few CiscoLive365 sessions:
- BRKSEC-2018: Tips & Tricks for Successful Migration to FirePOWER Solutions
- BRKSEC-1030: Introduction to SourceFire NGIPS
- BRKSEC-2028: Deploying Next Generation with ASA & FirePower Services
- BRKSEC-2139: Advanced Malware Protection
- BRKSEC-3034: FireSight Network Security Analytics
- BRKSEC-3055: Troubleshooting Cisco with FirePOWER Services
- BRKSEC-3126: Advanced Configuration & Tuning FirePOWER
As I was going through some CiscoLive365 sessions (Remember CiscoLive365 is great!) just this last weekend I came across the slides for BRKSEC-2028 – Deploying Next Generation Firewall with ASA & Firepower services. Unfortunately there is no video for this session yet but the presentation slides are there and luckily the slides are detailed enough so you can easily follow along with the content. One the slides that stood out of to me was where the new FirePower modules (Hardware or Software) falls into the order of operations as traffic passes through the ASA. Screenshot below:
I think the big call-outs here are:
- The FirePower module will not actually drop the traffic itself, the traffic gets ‘marked’ if the traffic is to be dropped. All the traffic that passes to the FirePower module will indeed get passed right back to the ASA and it is the responsibility of the Cisco ASA to actually drop the traffic.
- Even existing connections still get inspected if the security policy demands.
- ACL’s and XLate entries will filter traffic before the traffic even makes it to the FirePower module.
- This is only slightly different from how the existing IPS Module inspects traffic from ASA. In regards to the flow path.
Definitely some good information to know when building out your new policies.
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.
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.