What are the right steps to locate a neighboring device adjacent to a Cisco ASA firewall? Can anyone help me with the steps please, one by one?
This answer by Cisco that "we don;t support it because it is a security device" is fairly poor.
The Device, if it's a good security device, could easily have this implemented as a passive-only feature if they are concerned about it.
IN FACT: The ASA already receives all of the CDP/LLDP packets from it's neighbors, it just doesn't respond to them and has no ability to show their info to you directly.
However you can still use the ASA to Capture the broadcasts coming to it, and then use wireshark to see their content to know what the neighbors are.
Whether you do that manually or they implement it as a feature to passively report on them, there is no information given to the other hosts about the existence of the ASA.
That said, security through obscurity is anything but.
We have about 23 ASAs give or take in our environment and they're good, but some of the official word from cisco why things are the way they are "for security" is more than a bit disingenuous.
They STILl do not support Secure Renegotiation, they used to but a bug was found 5+ years ago, and their oficial solution was to remove this security feature instead of fixing the bug.
When we have audits we have to explain this.
They also fully support these protocols out of the box which is great:
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
However if you enable the free license of Anyconnect they provide you, then they purposefully drop the supported Encryption without warning, and the handshake to many new browsers doesn't correctly support Forward secrecy when connecting using them.
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 2048 bits FS
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 2048 bits FS
Furthermore ASDM doesn;t support Forward Secrecy at all (at least as of 7.8.11) so to use ASDM to manage their firewall, they seem to require you to leave this enabled (as all other options are worse #DES/RC4 etc):
- TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) WEAK
And to be clear the RA Anyconnect Client software does not change I use the same client to connect to a system with a "free"license as I do to one where the free license is disabled.
Now, you might be thinking well they only want you to use good TLS security with the paid license because they had to code to support the better TLS protocols.
Well then limit us to IPSEC VPN tunnels, since we already use those, since they are more secret then the HTTPS protocols you do allow on the free license.
In that scenario it's only the external web page which users access to log in and download the client initially which is being compromised by this.
So it actually makes us more vulnerable on the ASA and not on our RA VPN connections themselves, which might have been what they were trying to do?
Regardless this is clearly a "Go To" answer for them if they can make more money by not implementing a feature, or fixing a bug, or trying to force you to purchase another license after having sold you a product with an intentional flaw in the feature you were specifically selling us "includes 750 free RA VPN licenses, no need to buy premium if you don't need to put a Firewall on the end user"
Okay I am getting a little grip-y here.
The long and short of it is there is a way to get this info if you need it, but it takes a lot of work to get at it so you'd only bother if you REALLy needed to get it that way.
Another way to get some of the info you want, from the switch side (find your firewalls) which I like to use is to change the MAC address of your Firewall to be something you can easily find (especially for our clusters) and make sure you make them in such a way which tells you their interface, which makes it a snap to find them by using sh mac add and sh ip arp on the switches.
Yes CDP would be better, and like I said you can get it if you need it, but only fro the firewall side.
And yes, most of the info the info LLDP/CDP provide can be determined through a bunch of work, and if you were a security threat, you might be interested in getting some of that info, although some would be useless, but you could absolutely find it through some muscle work on your own, and a hacker, they're gonna have time, they're gonna do that anyway, everyone makes the argument about not making it easier for them but look if they are going to open all of your kitchen drawers anyway, having a label that says "spoons" on one and "Plates" on another isn't a realistic problem.
And even assuming the broadcast of this info was dreaming to be coming from the ASA, they could still change the devices capture and report it so you could see it's neighbors, which are probably all switches YOU control and run CDP on and see other things the ASA can not, like the ISP router.
On most Cisco equipment you say
show cdp neighbor
But my undestanding is that ASA devices don't do CDP.
I believe you can look at the learned ether address tables in SNMP, but it's hard work in comparison.
The ASA is a security device, so it was designed to communicate with untrusted devices. That means it doesn't send or receive any more information than necessary. So things like CDP are not available.
Generally, the only information on a neighboring device you can get is the MAC addres, via arp.
will list all the MAC addresses the ASA has recently communicated with.