hi - need a sanity check - we have a dead IDS sensor. that sensor normally talks to MARS server 1.
while being replaced, in the interim, the suggestion was made to utilize an unused interface on another IDS sensor (this one currently talks to MARS server 2).
the end result would be 2 distinct MARS boxes trying to pull logs from the same IDS, which would be sniffing traffic on multiple interfaces until the replacement IDS unit is installed. Assuming a lot of reconfiguration on the MARS side to accomodate the temporary setup, but beyond that, is it even possible to do this? I would think the MARS boxes would potentially conflict when connecting to the IDS and copying logs?
There is no issue having two (2) CS-MARS pull events from a single IPS sensor. Each CS-MARS will open its own SDEE subscription to the IPS sensor for event retrieval. Each subscription will maintain its own, distinct, view into 'current' events on the IPS sensor. The only limitation is that the IPS sensor is limited to five (5) active SDEE subscriptions. Other products, like IPS Manager Express (IME), can also make use of an active SDEE subscription.
You can monitor open SDEE subscriptions from the IPS sensor CLI by issuing:
so if I can have 2 MARS boxes pulling events, then a remaining (secondary) issue is that processing the "new" events (on the previously unused interface / network) will require some reconfiguration on the MARS servers - the MARS box that currently sees this IDS will need to know what to do with the new event stream (from the add'l interface), and the MARS box that currently looks at the dead IDS will have to know that it's now looking at a different IDS (temporarily).
my main worry is that the monitored network where the dead IDS lives is extremely noisy, and the "surrogate" IDS where we're thinking of lighting up the add'l interface is by design very quiet. We're essentially introducing a ton of noise into an otherwise quiet IDS/MARS relationship (which is tuned accordingly) - it will light up like a Christmas tree - this seems to suggest a lot of re-tuning / filtering / etc. to accomodate the temporary change and additional noise.
is there a way we can split an IDS event stream coming into MARS so that the previously "quiet" MARS ignores / drops any "new" events from the newly activated IDS interface? It would be good if we can set this up in a way that the MARS box already talking to the surrogate IDS will not be impacted by the additional data. Will a specific list of monitored networks added in the MARS IDS config for the surrogate IDS help out here?
not sure we will go this route but just want to understand the implications.
There is certainly the potential that you will need to make modifications to both CS-MARS to account for changes in the incoming IPS events.
In the interim, if you do not want to adjust CS-MARS to accommodate this monitoring, you could use IPS Manager Express (IME) to monitor IPS events for the temporary time-frame. This precludes the full correlation provided by CS-MARS, but does let you continue to see events occurring on the monitored network.
thanks Scott - if I undersrtand this option, to avoid any reconfig on MARS, we would take the IDS out of the MARS loop (temporarily) - light up the interface, and use the IME instead to monitor individual event status. Then bring MARS back into the loop when the broken IDS is repaired / replaced and the temp interface is disabled again?
I'm not following the implications here, but depending on active subscriptions you should be able to simply install IME and add the sensor in question to it for monitoring. If your concern is regarding excessive events arriving at the CS-MARS, then yes, you might want to remove the sensor from CS-MARS (or perhaps provide invalid credentials so CS-MARS cannot pull events from the sensor). Not being directly famliar with your exact setup I am reluctant to give direct details on how to adjust things to meet your needs.
yes the (greater) concern is the excessive events showing up at MARS (and the subsequent jigging on MARS to accomodate). I completely understand the reluctance to advise on specifics - just looking for advice and sanity checks which you've provided - thanks once again for the great feedback
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :