Thursday, March 29, 2007

Netflow from a HP Switch?

I was at a MARS meeting with a potential customer the other day, and it was one of those meetings where all is going great, the customer loves the idea of what MARS can do, and then we get onto what devices the customer has in their network.

Ok, HP Switches across the board, some 3rd party firewall in a DC that they are not allowed to touch, no IDS/IPS in place or any plans/skills for etc.. if you`ve been there you will know!

Coming home from the meeting got me thinking.

I know most high end HP switches can export Sflow, as opposed to Netflow that is supported by MARS.

Now what if there was a tool that could convert Sflow to Netflow?, at least we would be able to get some useful info into MARS, for anomaly detection at least.

Remember, MARS does not store netflow by default, only the records that are part of an incident. But you do get the option to store Netflow, though this is not recommended! (This has the potential of slowing the system by drastically increasing the events per second that it must process.)

Now i have not tried the following, or do i recommend it (i dont even have a Sflow supported HP Switch), nor do know if it would be supported by MARS, but here is the theory!
There is a tool called the Sflow Toolkit, by a company called InMon

This runs on Linux, Solaris or Windows, and will take Sflows and convert them to Netflow, to forward onto a Netflow collector such as MARS.

The following example shows sflowtool converting sFlow packets into NetFlow and sending the NetFlow packets to a NetFlow collector specified by a host and port.

sflowtool -c -d 9991 > /dev/null

If anyone has ever tried this, let me know.

1 comment:

Anonymous said...

Converting sFlow to Netflow does have a draw back from a forensic perspective as an sFlow record is a 1 in N sample. You don't know where in the conversation the packet has come from and by using sFlow as a source the Netflow data has very limited value.

Foundry have a proprietary helper here with their 'first packet' feature so you can get the initial handshake for the conversation as an sFlow record in addition to the sample.

Without the initial handshake it is very difficult to accurately define the source / destination and it takes longer to detect scanning from sFlow - especially the 'low and slow' probes.

If you are in an sFlow environment you need an sFlow forensics tool that can scale and work with the limitations of sFlow.

Foundry have a paper available from Lancope who have a solution that supports both Netflow and sFlow.
Netflow is by far the better flow record for forensics.