I have been trying to feed data from an ASA to flowd using netflow. Cisco appears to have taken a rather non-standard approach with their implementation of netflows on the ASA. In my flowd.conf I have configured store ALL, so all the information received from the ASA should be recorded. I properly receive the port source and destination information, however the octet and packet counts remain at 0. When I output the records using flowd-reader -vd I form the impression that the additional fields are not being recorded by flowd. Here is an example of output: FLOW recv_time 2011-08-22T15:00:54.124271 proto 6 tcpflags 00 tos 00 agent [172.25.233.25] src [172.16.238.149]:1784 dst [206.167.78.40]:80 in_if 4 out_if 3 sys_uptime_ms 2w17h40m31s.044 time_sec 2011-08-22T15:00:54 time_nanosec 0 netflow ver 9 According to this document [1] on the ASA netflow implementation I should expect field type 85 to contain the number of bytes sent in the flow, this field will only [exist/have a non zero value] on the flow record sent when the connection is torn down. I''d like to be able to record the additional fields that the ASA sends, while I''m most interested in traffic volume it would also be interesting to record translated addresses and some of the other information being sent. I would really appreciate any assistance anyone can offer in helping me to record and make use of the additional information in the ASA flows. Thanks in advance, [1] http://www.cisco.com/en/US/docs/security/asa/asa82/netflow/netflow.html#wp1028790 -JohnF
I have implemented some extremely basic ASA support in the attached patch; It implements the following ASA functionality: If a packet with field type 85 is received, it will set the octet counter to match the value from that field, this will override any value expressed in the standard octet counter NF9_IN_BYTES, field type 1. If the number of octets is greater than 0 it will also set the packet counter to 1. It would be possible to add other functionality, such as: - recording of translated IPs and ports - recording of the start time of the flow as well as / instead of the termination time - recording of flow denial (flows are created for traffic that is denied) This patch implements the initial support that I need, if I develop anything else I will share it with the list. -JohnF -------------- next part -------------- A non-text attachment was scrubbed... Name: asa_patch.diff Type: text/x-patch Size: 972 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/netflow-tools/attachments/20110830/3ed46e04/attachment.bin>
I have updated my patch so that it reports all ASA reported flows as having at least one packet. This allows reporting on blocked traffic with the flow-tools utility flow-report. -JohnF -------------- next part -------------- A non-text attachment was scrubbed... Name: asa_patch_2.diff Type: text/x-patch Size: 939 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/netflow-tools/attachments/20110831/4e3bad4a/attachment.bin>
On Wed, 31 Aug 2011, John Marrett wrote:> I have updated my patch so that it reports all ASA reported flows as > having at least one packet. > > This allows reporting on blocked traffic with the flow-tools utility > flow-report.Ugh, I knew that vendors would abuse NetFlow v.9''s flexibility sooner or later. My vague plan is to change the storage format of flowd to protocol buffers[1] so it will be able to store near-arbitrary data with good forward and backwards compatibility, but I haven''t got around to it yet. -d [1] http://code.google.com/apis/protocolbuffers/docs/overview.html
Damien,> My vague plan is to change the storage format of flowd to protocol > buffers[1] so it will be able to store near-arbitrary data with good > forward and backwards compatibility, but I haven''t got around to it > yet.It would be very interesting to have a way to do this. There''s interesting data that my "patch" is leaving on the table. The most significant are: - If the flow was permitted or denied; I tried to implement this, it didn''t go very well though. It didn''t seem that the value NF_F_FW_EVENT was being correctly set by the ASA (more likely, I wasn''t reading it correctly). Right now you can use a 0 byte flow as an indicator that the traffic wasn''t permitted but that''s far from perfect. - Translated addresses and ports -JohnF