nProbe with Cisco MARS

Ok following on from the previous post. This is another probably not supported, but probably possible article.

I`m not afraid to mix open source tools with commercial products, and this follows on from some testing on the Netflow front.

Not everyone has a netflow capable switch or router on the network, and similarly the following can be achieved just as easily with a snort sensor, or Cisco IPS/3rd party supported IDS/IPS Sensor, (the better options) and is purely for reference.

There are open source tools available, that will simply sniff the network, via a tap/span port, and spit this out in Netflow.

One such tool is nProbe, which is a An Extensible NetFlow v5/v9/IPFIX GPL Probe for IPv4/v6.

And there are others too for instance NDSAD. But for my testing i used nProbe.

Now we can simply send the Netflow records to MARS, and MARS will process these.

Now remember from yesterday, it is not recommended to store Netflow records, and i`ve not come across anyone who does, but for this testing i did enable this feature.

What happens now? Well MARS starts to store this data, and also sessionize it too, so we can run queries, but they are of the unknown event type...

and similarly looking at an individual session

and an example raw event message

You will also probably find, that in the CLI pnlog show backend command, you will some errors like the following...

Mar 29 09:59:11.194 2007@localhost@1980@LM_ERROR@./pnparser|Thread 15376:Netflow device with IP '192.168.2.34' is not configured in the GUI.

So how would we get MARS to recognise these events, when nProbe isnt listed on the supported device types? Well this was down to trial and error, but i found if i defined the nProbe box as an IOS device, this worked a treat.

You will get an obvious error, when this is submitted, and there was no SNMP available from my nProbe box, but this can be ignored,

Now when any queries are run, you will find, that MARS was able to sessionize these events forwarded by nProbe successfully (well at least the traffic i captured)

and similarly the session and raw event information.


As a final note, remember this is a very inefficient use of the MARS box`s resources, so it would not be recommended on a large production network!

So dont be blaming me!, if you ever try it out. :-)