4 ms·

These tools are interesting to play with but I'd prefer to leverage netflows, which are designed for this purpose. Netflow gives you protocol types, src/dst ip

by Jedd 3y ago

These tools are interesting to play with but I'd prefer to leverage netflows, which are designed for this purpose. Netflow gives you protocol types, src/dst ip & port, packet & byte counts, qos/tos, and more - much more cheaply than pcapping an interface. All SME and up gear support them, even Unifi USG's will eject NetFlows. I'm a bit jaded about some of the free tooling these days though. Weirdly it feels like we've taken a step back the past several years - but for anything beyond 'I wonder who this one computer is talking to' they're a much better approach.

unethical_ban 3y ago
Sure, just gotta spin up an elastic stack and find the right netflow parser! I know you know. Netflow to me is like snmp, supposedly easy but really not. Maybe I'm just lazy now.
- Jedd 3y ago
  I played with Elastiflow extensively some years ago - it was excellent, if a little hungry on memory, but I suspect most of that was the logstash & elasticsearch overhead. Rob did a big rewrite about 4 years ago, I think, licensing the new codebase in a way that led us to look elsewhere. There's some alternatives that aren't elastic under the hood, of course. The hard-to-type Akvorado looks very promising, especially given its heritage: https://github.com/akvorado/akvorado https://github.com/akvorado/akvorado Because we're moving to opentel / prometheus, this project (seems quite active) is especially interesting, with the promise of integrating OS & app metrics, tracing, and netflow insights: https://github.com/netobserv/flowlogs-pipeline https://github.com/netobserv/flowlogs-pipeline
jwiz 3y ago
I thought netflows were all just sampled nowadays, though. That is, if you want to see every packet, you can't use netflow. If you just want the general characterization of your data, then they are ok.
- Jedd 3y ago
  Nowadays? The protocols haven't changed, but you may mean that pipes are getting bigger while compute/storage aren't keeping up, so network admins are more likely to opt for sampling over raw/full. If you want to see every connection you certainly can use netflow, just means you need to spec out your solution properly - and if you've got a lot of chatty traffic it may get expensive. Obviously much less expensive than interface capture approaches like TFA - plus netflows will typically come from your routing infrastructure. EDIT: Apologies, I had not really processed the implications of 'if you want to see every packet'. Yes, you're right, but netflow was never about seeing every packet, but tracking every flow (which IIRC is usually defined as src/dst addr+port + protocol) - which will include a running total of bytes/packets over time, so it's counting every packet, but certainly not inspecting every packet, at least not in a DPI sense. Netflow will inspect every connection as it's established, and then track it until it's torn down. This is one of the reasons netflow, and especially sampled netflow, can report really skewed results against long-lived connections - think Citrix, f.e.
- zamadatix 3y ago
  SFlow is the packet sampled version, Netflix/Ipfix will give you details on every flow. There was a period high speed devices (>10G) started dropping full sampling but it seems to have come back for even 100G devices. Limits around the total number of tracked flows still exist of course, you can't just flood a trillion tcp syns and on a 100G port and expect the switch to report on all of them. Theoretically you could do that with a pcap based solution but realistically it's the same problem the switch runs into. Now if you actually care about per packet statistics rather than per flow statistics you'd want pcap. The more the world becomes encrypted the less interesting the actual packets become.
  - Jedd 3y ago
    > SFlow is the packet sampled version, Netflix/Ipfix will give you details on every flow. That's not 100% accurate. Netflow v5, v9, and IPFIX all support (for at least a decade) sampling, and depending on vendor that'll be random, time, or packet-count, based).
fulafel 3y ago
Besides the obvious advantages (you don't need to control the network & have the feature support in hw & have the energy to configure netflow stuff) - host local viewpoint has a lot of advantages vs monitoring from a on-path network element. You can associate stuff to local processes, you don't have the post-NAT warped view of traffic, you can see traffic that doesn't cross routers, you can see the actual traffic contents instead of just metadata, etc. But the high bit is of course that it's a self-contained normal app and just works. (And it actually exists unlike the hypothetical netflow version.)
- Jedd 3y ago
  Some good points, and I appreciate there are two semi-disparate domains here. Local interface monitoring addresses a different problem than network monitoring. I'd argue your advantages perhaps - you do need local root, or at least net_admin / net_raw (I haven't looked to see if TFA drops all but these - perhaps you have?) which raises some security questions. In Linux you may also hit some challenges with promiscuous mode, or capturing on wireless interfaces. The 'energy' to configure netflow is probably comparable to that required to install and configure this tool. If you don't have the feature on your network hardware, then, yeah, sure, it's moot. I accept that this, and other existing tools, that let you correlate local processes with local network interface activity can be useful. In my experience it's rare to have to dive into that level, but definitely handy. In a previous life I would frequently be flipping between Wireshark and Riverbed's Packet Analyzer (nee Pilot) which gives a higher level view than Wireshark. It feels like Sniffnet is aiming to be more in this category, so it's great to have a free software alternative. For traffic that doesn't traverse routers, you may not know that switches can send netflow. Also, your favourite GNU/Linux distro can send flows. > (And it actually exists unlike the hypothetical netflow version.) I don't get this bit. Are you asserting that netflow monitoring tools don't exist?

by Jedd 3y ago

unethical_ban 3y ago

Sure, just gotta spin up an elastic stack and find the right netflow parser! I know you know. Netflow to me is like snmp, supposedly easy but really not. Maybe I'm just lazy now.

Jedd 3y ago
I played with Elastiflow extensively some years ago - it was excellent, if a little hungry on memory, but I suspect most of that was the logstash & elasticsearch overhead. Rob did a big rewrite about 4 years ago, I think, licensing the new codebase in a way that led us to look elsewhere. There's some alternatives that aren't elastic under the hood, of course. The hard-to-type Akvorado looks very promising, especially given its heritage: https://github.com/akvorado/akvorado https://github.com/akvorado/akvorado Because we're moving to opentel / prometheus, this project (seems quite active) is especially interesting, with the promise of integrating OS & app metrics, tracing, and netflow insights: https://github.com/netobserv/flowlogs-pipeline https://github.com/netobserv/flowlogs-pipeline

jwiz 3y ago

I thought netflows were all just sampled nowadays, though. That is, if you want to see every packet, you can't use netflow. If you just want the general characterization of your data, then they are ok.

Jedd 3y ago
Nowadays? The protocols haven't changed, but you may mean that pipes are getting bigger while compute/storage aren't keeping up, so network admins are more likely to opt for sampling over raw/full. If you want to see every connection you certainly can use netflow, just means you need to spec out your solution properly - and if you've got a lot of chatty traffic it may get expensive. Obviously much less expensive than interface capture approaches like TFA - plus netflows will typically come from your routing infrastructure. EDIT: Apologies, I had not really processed the implications of 'if you want to see every packet'. Yes, you're right, but netflow was never about seeing every packet, but tracking every flow (which IIRC is usually defined as src/dst addr+port + protocol) - which will include a running total of bytes/packets over time, so it's counting every packet, but certainly not inspecting every packet, at least not in a DPI sense. Netflow will inspect every connection as it's established, and then track it until it's torn down. This is one of the reasons netflow, and especially sampled netflow, can report really skewed results against long-lived connections - think Citrix, f.e.
zamadatix 3y ago
SFlow is the packet sampled version, Netflix/Ipfix will give you details on every flow. There was a period high speed devices (>10G) started dropping full sampling but it seems to have come back for even 100G devices. Limits around the total number of tracked flows still exist of course, you can't just flood a trillion tcp syns and on a 100G port and expect the switch to report on all of them. Theoretically you could do that with a pcap based solution but realistically it's the same problem the switch runs into. Now if you actually care about per packet statistics rather than per flow statistics you'd want pcap. The more the world becomes encrypted the less interesting the actual packets become.
- Jedd 3y ago
  > SFlow is the packet sampled version, Netflix/Ipfix will give you details on every flow. That's not 100% accurate. Netflow v5, v9, and IPFIX all support (for at least a decade) sampling, and depending on vendor that'll be random, time, or packet-count, based).

fulafel 3y ago

Besides the obvious advantages (you don't need to control the network & have the feature support in hw & have the energy to configure netflow stuff) - host local viewpoint has a lot of advantages vs monitoring from a on-path network element. You can associate stuff to local processes, you don't have the post-NAT warped view of traffic, you can see traffic that doesn't cross routers, you can see the actual traffic contents instead of just metadata, etc. But the high bit is of course that it's a self-contained normal app and just works. (And it actually exists unlike the hypothetical netflow version.)

Jedd 3y ago
Some good points, and I appreciate there are two semi-disparate domains here. Local interface monitoring addresses a different problem than network monitoring. I'd argue your advantages perhaps - you do need local root, or at least net_admin / net_raw (I haven't looked to see if TFA drops all but these - perhaps you have?) which raises some security questions. In Linux you may also hit some challenges with promiscuous mode, or capturing on wireless interfaces. The 'energy' to configure netflow is probably comparable to that required to install and configure this tool. If you don't have the feature on your network hardware, then, yeah, sure, it's moot. I accept that this, and other existing tools, that let you correlate local processes with local network interface activity can be useful. In my experience it's rare to have to dive into that level, but definitely handy. In a previous life I would frequently be flipping between Wireshark and Riverbed's Packet Analyzer (nee Pilot) which gives a higher level view than Wireshark. It feels like Sniffnet is aiming to be more in this category, so it's great to have a free software alternative. For traffic that doesn't traverse routers, you may not know that switches can send netflow. Also, your favourite GNU/Linux distro can send flows. > (And it actually exists unlike the hypothetical netflow version.) I don't get this bit. Are you asserting that netflow monitoring tools don't exist?