-
-
Notifications
You must be signed in to change notification settings - Fork 43
Future_Work
nfsen-ng has been developed to keep the compatibility with the nfcapd files from the nfdump tools. However, as several NetFlow collectors and analysers exist, it would make sense to redesign the overall nfsen-ng structure to allow compatibility with other collectors, similarly to what has been done during the project to allow several databases to be used for the graph part. As the NetFlow packet structure is known, no matter which collector is used and how it stores the files, it could be queried to provide the same data. This would make sense only if most of the collectors would provide the same features, otherwise a custom interface that allows to perform the wished operations should be developed on top of them.
nfsen-ng has only one database class implemented (for RRDtool) and therefore only creates and populates RRD databases. However, NetFlow provides much more information that could be displayed over time, but are not handled graphically in both NfSen and nfsen-ng. An extension could be built into nfsen-ng that allows to abstract the RRDtool database creation limited by the NetFlow fields supported by nfdump.
Like NfSen, nfsen-ng does not provide any authentication and authorization out of the box, nor user-specific features or roles. Nowadays security is getting more and more important on all branches of the information technology. It would be a good idea to add some security layers on top and allow the access to the application only through some multi factor authentication. The application could also be reworked to allow per-user features or per-user data sources, as some source may need various levels of confidentiality. Of course, it is recommended to use TLS (HTTPS) for a secure communication between the client and server. nfsen-ng does not need to be adapted for this to work, only web server configuration would need to be modified.
Unlike NfSen, for which some plugins can be found on the internet, nfsen-ng does not provide such mechanism. Implementing such capability and some plugins could probably motivate more users to use the application and enhance it.
nfsen-ng does not provide a profile feature like NfSen does. A profile would allow to create another view of the data and apply filters on it. As an example, two web server sources could be put together so that it shows a new one called “webservers”. NfSen documentation of profiles is a bit vague and refers to “history”, “continuous” and “shadow” profiles. As nfsen-ng provides the possibility to either use a daemon to populate data automatically or not, this part could be skipped.
By continuously monitoring the NetFlow data, an alert system like the one provided by NfSen could be put in place. Some actions based on conditions could be performed. As an example, if a flow is originated from a black-list of IP addresses, an e-mail could be sent. Another example could be the amount of connections on a particular port for a defined period of time that may suggest an attack and then call a command which results on a notification appearing on a smartphone.
For time reasons, the saving and restoring filter feature (which is available in NfSen) has not been implemented. Like the security section suggests, once a per-user authorization exists, a per-user filter handling could be developed to allow each user to manage its own filters.
Display a graph and dig into flows and statistics is probably good enough for active users, however providing a customizable dashboard providing key information for some period could be useful too. Additionally, a dashboard builder could be implemented to allow the application to grow. This should be flexible enough so that the user does not need to be a crack in web development.
While testing the application, sometimes the back end became slow. Questions like “did the back-end interface crash?” or “will I ever get an output for my query?” arose. The user of nfsen-ng is not supposed to have access to the remote system hosting the back end part of the application. It could be useful to provide the user some information about the resources he is using on the system (CPU, memory usage and give some information about the overview of the system resources on the back end (like the htop utility does).
By inputting a wrong date range, it came up that an “abort” or “kill” feature is missing. Without a remote access to the back end, a user is forced keep on wasting system resources. Additionally, if the user leaves the web page there is no mechanism in place to detect it and inform the back end to stop a potentially big and long computation. Providing a task killer could solve that and also prevent a denial of service.