If you allow Mars to ssh to devices, does it still need snmp RW access?
I ask this because, while reading the Cisco Press - Understanding Security - MARS, it says to give Mars a RW snmp string on each devices. But the user guide says to only create RO strings. I would like our Mars to function at its fullest potential without unnecessary configurations.
Since I know Mars will not block things till I tell it to, I would like to setup ssh without snmp RW.
From my experience if you want MARS to function to its fullest potential then use SNMP RO strings so MARS can discover the network topology.
MARS can also be configured to SSH to devices in order to provide a mitigation solution.
I prefer that MARS understands topology as opposed to having it be my tool for mitigating problems. I don't configure MARS for mitigation because it is very easy for an inexperienced admin to accept a MARS recommendation and then have them disable a trunk port, instead of only an access port.
The 'RW' strings are used to perform mitigation on the switches (Cisco). Normally RO strings are enough. By giving MARS SSH/Telnet access you also let MARS import 'configurations' into its database to have a better understanding of the network. This is particularly important if you are running FWSM/IDSM modules or want to sessionalize events when NAT etc. are employed.
I'm not sure I understand how SSH/telnet access is required in any way for sessionization. The events provide all the relevant data necessary for this. I don't understand, outside of mitigation, why that same information (routing tables, CAM tables, etc) can't be pulled via SNMP. One of the biggest challenges we have always had with MARS is the lack of appropriate details that tie specific functionality with access requirements. When you're in a larger enterprise, these details really start to matter because other areas "own" the devices and simply stating that something is required so MARS can run at "level n" doesn't cut it.
Well this is what a Cisco SE told us in one'Partner Training' :).
I myself faced an issue with a CAT6513 not showing SVIs properly (resulting in a disconnected MARS network map). As soon as I gave SSH/Telnet accesss to the core switch, MARS was able to discover the SVI's. Faced similar issues with Netscreen ISG Redundant interfaces.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...