Add monitoring capability #2588
Conversation
IvanNardi
force-pushed
the
monitoring
branch
3 times, most recently
from
debd35e to
c2ff178
Compare
There was a problem hiding this comment.
Thanks for that feature Ivan. That is something that Cybersecurity folks need!
Do you think that it would make sense to also provide an API in which makes it possible to dynamically add a certain flow to the "special observation treatment" and dissect literally all packets of it?
@utoni, could you elaborate please? Do you mean something like: the application want to put on monitoring only THIS specific STUN flow and not all of them? |
|
Exactly, but I would like to use that specific behavior for other protocols e.g. suspicious TLS or BitTorrent flows. |
Right now the code has been updated only for STUN; to add support for monitoring to other protocols you need to update their dissectors code. About the specific flow. The configuration is per protocols, so all the STUN flows or none of it, but the final decision is always of the application itself: the application can simply stop invoking nDPI for the "uninteresting" STUN flows. That is the current state; we can always improve and extend it |
Allow nDPI to process the entire flows and not only the first N packets. Usefull when the application is interested in some metadata spanning the entire life of the session. As initial step, only STUN flows can be put in monitoring. See `doc/monitoring.md` for further details. This feature is disabled by default. Close ntop#2583
|
Allow nDPI to process the entire flows and not only the first N packets. Usefull when the application is interested in some metadata spanning the entire life of the session.
As initial step, only STUN flows can be put in monitoring.
See
doc/monitoring.mdfor further details.This feature is disabled by default.
Close #2583