[00:00.000 --> 00:14.360] Okay, good morning. This time it's a turn to talk about something different. And top [00:14.360 --> 00:22.440] ng. What is in top ng? It's an open source application, of course. We are here. And you [00:22.440 --> 00:29.340] can download the code on GitHub. We'll see the link at the end of the talk. What is in [00:29.340 --> 00:33.920] top ng doing? It is, first of all, a real-time network and traffic monitoring application. [00:33.920 --> 00:37.960] So it means that it displays you on a web interface what is happening in your network [00:37.960 --> 00:44.360] live. Okay, no delay. This is unless, of course, we are receiving flows coming from a router [00:44.360 --> 00:49.480] that are somehow a little bit delayed because by nature they are on average. So they have [00:49.480 --> 00:55.640] a certain lifetime. And it is designed for network monitoring and cybersecurity. It means [00:55.640 --> 01:01.280] that there are some behavioral checks. So we are not bound to rules. You have seen Suricata [01:01.280 --> 01:06.280] representation before. You see there are some rules in case this happens then. So this is [01:06.280 --> 01:12.240] not our case. So we work based on behavior. So it means that if you have a host that is [01:12.240 --> 01:16.240] misbehaving, more or less similar to what you have seen before, that suddenly start [01:16.240 --> 01:22.360] to send too much traffic with respect to the past, or starting to, you know, fire up a [01:22.360 --> 01:30.360] new application. So accept connection on a certain port for TLS that was not open before. [01:30.360 --> 01:36.560] This is a typical example. So therefore it means that the application simply starts up [01:36.560 --> 01:41.880] and learns what is happening on the network. There are some levels of learning. So sometimes [01:41.880 --> 01:47.040] it is an immediate learning because, you know, you specify some sort of configuration. But [01:47.040 --> 01:50.960] usually this is not the case. The case is that the application learns what is happening [01:50.960 --> 01:58.600] and in case something goes wrong, goes different, fires up and alert. This is the idea. And [01:58.600 --> 02:04.480] the architecture is actually divided in two parts. Okay. First of all, the pocket processing [02:04.480 --> 02:11.400] part that is based on more or less PF ring or lead pickup. So this means that you can [02:11.400 --> 02:17.840] run on Windows, Linux, Mac OS, FreeBSD, whatever. Instead, PF ring is something that we have [02:17.840 --> 02:22.280] co-developed that is a Linux technology for accelerating pocket capture, but not only [02:22.280 --> 02:27.720] for that, but also for merging traffic for multiple adapters, for distributing traffic. [02:27.720 --> 02:33.240] So it's much more than simply RX acceleration. And top of this, there is an open source [02:33.240 --> 02:37.760] library that we still maintain at N-top called NDPI. So this is the only open source library [02:37.760 --> 02:42.640] that is doing the pocket inspection. But for us, it means that we try to understand from [02:42.640 --> 02:47.680] the traffic what is the application protocol. So if it's TLS, if it's a generic protocol, [02:47.680 --> 02:54.200] if it's Google mail, but it's a very specific protocol. And out of the traffic, we extract [02:54.200 --> 02:59.720] the metadata. So for instance, we extract certificate information and we generate something [02:59.720 --> 03:04.880] we call RISC. So looking at the traffic, we see if there is something wrong, okay, such [03:04.880 --> 03:10.000] as for instance, an expired certificate just to give you an idea. And we trigger an alert. [03:10.000 --> 03:15.080] On top of this, there is a TopNG because this is the first part that is basically provided [03:15.080 --> 03:20.880] by the operating system. And TopNG has a C++ engine that is processing packets, that is [03:20.880 --> 03:25.920] in essence doing traffic analysis, creates internally, okay, the representation of the [03:25.920 --> 03:30.600] data based on the concept of network interfaces because we can have a multiple network interfaces [03:30.600 --> 03:34.400] from which the traffic is received. It can be a virtual interface such as, you know, [03:34.400 --> 03:39.960] a NetFlow collection or a physical interface, ETH0. And then we have something we call [03:39.960 --> 03:45.760] behavioral checks, where we check flows and hosts. Flows means that each independent communication, [03:45.760 --> 03:52.600] such as a TCP connection, is checked. Instead, a host, we take the host as a whole. So in [03:52.600 --> 03:56.600] essence, if a host is doing a port scan, each individual communication is okay, or more [03:56.600 --> 04:02.480] or less okay. But the fact that this host is doing this, you know, in a sequence, in [04:02.480 --> 04:07.120] a network or in a host, it's a problem. So this is called behavioral checks. And on top [04:07.120 --> 04:14.080] of this, we trigger alerts that can be consumed locally or sent elsewhere. This is the fast [04:14.080 --> 04:19.760] part. On top of this, we have the Lua interface. Why Lua? Because we like C++. But C++ is [04:19.760 --> 04:26.160] something not for everybody, okay? So we need to simplify, for instance, the development [04:26.160 --> 04:30.840] of the web interface. So for instance, the REST API is written in Lua, sitting on top [04:30.840 --> 04:37.040] of C++. So we have created an API that allows us to avoid typical problems of C++ at the [04:37.040 --> 04:43.400] same time we simplify the way the application is working. So therefore, we use Lua for operations [04:43.400 --> 04:49.520] that are not critical, such as the web GUI, or for checking interfaces that are not necessarily [04:49.520 --> 04:57.600] real-time, so for the SNMP. For SNMP, we fetch the data every five minutes and do the checks. [04:57.600 --> 05:03.720] So traffic ingestion, as I said, is done in multiple ways. Sometime is serial traffic, [05:03.720 --> 05:10.200] so packets. Sometime it is not. It's a flow. And this is handled by the C++ engine. So [05:10.200 --> 05:16.400] the C++ engine is doing it efficiently. And then we have other type of ingestions based [05:16.400 --> 05:21.840] on events. So something that we don't really control completely, but that are relevant [05:21.840 --> 05:28.120] for us. So we have seen Surikata, the presentation before, some minutes ago. This is a typical [05:28.120 --> 05:34.640] example of input. Why this? Because, as I said at the beginning, we don't have rules. [05:34.640 --> 05:38.840] We don't want to have rules. So we don't want to say if the payload contains this and this [05:38.840 --> 05:45.400] and this and this then, because we don't believe that this is what we should do. Instead, there [05:45.400 --> 05:49.200] are wonderful tools such as Surikata that are doing that very well. So therefore, the [05:49.200 --> 05:54.240] idea is to combine network monitoring and behavior analysis with these type of tools. [05:54.240 --> 05:57.920] So therefore, indirectly, through tools such as Surikata that is optional, of course, you [05:57.920 --> 06:03.280] don't have to run it with N-top-ng monitoring, you can have this type of information that [06:03.280 --> 06:10.160] can be combined directly by N-top-ng. Of course, we have firewall logs and syslog. Why this [06:10.160 --> 06:15.960] is important? Because we can have a look at information that is not visible from the traffic. [06:15.960 --> 06:21.440] So we always play with packets, me and Alfredo. But we understand that packets have limitations, [06:21.440 --> 06:26.680] okay, especially for encryption. So we have seen before rules saying if you are downloading [06:26.680 --> 06:31.400] a buyer application, that is fine if it's plain text. But if TLS, you will never see [06:31.400 --> 06:37.160] that happen, okay. So you have to use things like rules on top of this, on top of this, [06:37.160 --> 06:44.200] but they are just guesses. So instead, if through syslog or other means, we know that. So for [06:44.200 --> 06:48.240] example, we see an attack or a wordpress saying that this host is trying to guess the password [06:48.240 --> 06:52.520] of administrator user. This is much relevant information. And from the network standpoint, [06:52.520 --> 06:56.920] it looks simply nice. Everything is okay. The problem is from the application. That's [06:56.920 --> 07:01.840] why we believe in network. By the same time, we need to have some other information that [07:01.840 --> 07:07.720] is injected into the application. And of course, we have historical data. We use a database [07:07.720 --> 07:13.160] called Clickhouse. So we can put a billion of records. Everything is working very fast. [07:13.160 --> 07:18.800] This is also an open source database. And for time series, we use round robin database [07:18.800 --> 07:28.200] or influxdp. And as I said before, we have checks that are divided in two parts. C++ [07:28.200 --> 07:33.760] for efficiency. So the fast part, in essence, where you have to process traffic in line, [07:33.760 --> 07:38.920] such as when you have a pocket, an incoming pocket, you have to check if this pocket belonging [07:38.920 --> 07:46.680] to a flow is relevant. And then we have other types of checks that are not so real time. [07:46.680 --> 07:53.520] So for a check on an SNMP interface, that need to be easy to be developed. But at the same [07:53.520 --> 07:57.480] time, that don't need to be fast. Because as I said, if we pull SNMP out in five minutes, [07:57.480 --> 08:03.480] we have plenty of time for doing that. And of course, we have notifications that we send [08:03.480 --> 08:09.160] out. So for instance, we trigger a shell script, a webhook, syslog, you know, telegram, you [08:09.160 --> 08:14.200] know, usual thing. Nothing new here. Okay, let's now start the talk after this introduction [08:14.200 --> 08:21.200] of NTOC and GIM. The problem is the following. So we have added over 150 checks, behavioral [08:21.200 --> 08:25.960] checks on the traffic. But there is always somebody that comes and says, I want to do [08:25.960 --> 08:32.480] something different. How can we support these people? How can we enable new programmers or [08:32.480 --> 08:36.880] let's say people that used to use Python, shell script, you know, this type of programming [08:36.880 --> 08:42.800] language or that don't want to learn the internals of our application? How can we do that? And [08:42.800 --> 08:47.400] many times this happens when you are in a harsh. So that is an attack. That is something [08:47.400 --> 08:54.000] happening on your network that you want to check. And we have, you know, two levels of [08:54.000 --> 08:58.760] the problem. First of all, we have to extend the behavioral checks in order to have some [08:58.760 --> 09:04.440] behavioral detection in a different way. And in the second part that Alfredo will describe [09:04.440 --> 09:10.200] later. So how can we use NTOC and G as a data lake from languages such as Python, for instance, [09:10.200 --> 09:15.360] that is very popular. So that you can use NTOC and G as a source of data for your own [09:15.360 --> 09:21.040] application. Of course, you have time series. As I said, we save data in influxDB if you [09:21.040 --> 09:24.680] want. So therefore, you can use Grafana for creating your own dashboard. But these are [09:24.680 --> 09:29.200] simple dashboards. So if we want to do something more complicated, if we want to go beyond [09:29.200 --> 09:36.800] that, in addition to that, how can we do that? So this is the idea today. So we like C++. [09:36.800 --> 09:43.440] C++ is super efficient. We like it. Okay. We are used to play with it since many years. [09:43.440 --> 09:48.400] But we understand that it's not what everybody wants. Okay. We need something easier. And [09:48.400 --> 09:53.800] we would like to understand also how it was possible to develop checks in minutes for [09:53.800 --> 09:59.440] people who are saying, okay, if I see this specific certificate or if I see this specific [09:59.440 --> 10:04.400] behavior, then there is a problem. Something very peculiar to an organization. So not general [10:04.400 --> 10:08.800] for everybody, but for specific people. So for instance, how do I trigger an alert if [10:08.800 --> 10:13.040] there is traffic, TLS traffic within host A and B? So for instance, a printer should [10:13.040 --> 10:18.560] not make any TLS traffic just to make an example. So if this happens, and how can you trigger [10:18.560 --> 10:24.360] an alert? Another problem is the following. If I have a certificate signed by a certain [10:24.360 --> 10:28.720] organization, or for instance, if I have a BitTorrent connection that is going above [10:28.720 --> 10:35.040] one gigabit, or notifying me if there is a Zoom call with bad quality, things like this. [10:35.040 --> 10:42.760] Things like very, very peculiar, very specific checks that people want to do. Maybe on an [10:42.760 --> 10:48.800] operating, sorry, on an autonomous system, and not on another, or on an actor, and not [10:48.800 --> 10:51.520] on another. So things that are not general that we can implement for everybody. How can [10:51.520 --> 10:58.360] we do that? So let me talk how it works in top NG internally. Let's have a look at the [10:58.360 --> 11:04.040] flow, also communication. So in top NG creates a data structure inside itself as soon as [11:04.040 --> 11:08.920] we see the first packet of the flow. So we see episodes of the destination, source parts [11:08.920 --> 11:14.440] of destination, protocol, VLAN, whatever. And then this is the first event that is relevant [11:14.440 --> 11:20.840] for us. And then, as I said, everything sits on top of NDPI, so the yellow part. So we [11:20.840 --> 11:25.880] have another event when the application protocol is detected. Actually, this one is divided [11:25.880 --> 11:32.120] in two parts. First of all, as soon as the main protocol is detected, such as TLS, okay, [11:32.120 --> 11:36.880] and then we can refine this information with metadata saying, okay, this is TLS that is [11:36.880 --> 11:41.720] going to Google mail, and not Google search or Google something else, okay. So second [11:41.720 --> 11:47.760] event and NDPI. And then we have, for long-standing flows, some periodic activities. So in essence, [11:47.760 --> 11:53.200] every minute, we do something different, something like, you know, I want to trigger, [11:53.200 --> 11:58.720] you know, an action. And then at the end, the flow end notification, so as soon as the [11:58.720 --> 12:05.680] flow is over. So what we wanted to do, we wanted to create a low API that allows people [12:05.680 --> 12:10.840] to create the simple checks that are efficient. Efficient enough for most people, because [12:10.840 --> 12:14.960] not everybody needs one and a gigabit, but many people have one gigabit networks or, [12:14.960 --> 12:19.960] you know, two, five gigabit networks. So they need some sort of efficiency, but they are [12:19.960 --> 12:24.840] not super extreme. So let's say use Lua for prototype on a check for some people who need [12:24.840 --> 12:30.080] speed, or use Lua for people who have, let's say, an industrial network or a network that [12:30.080 --> 12:36.280] is, you know, running at one gigabit or two. So in essence, we have created an API that [12:36.280 --> 12:42.920] allows from Lua to see internally, in N-top and G, properties of the flow. For instance, [12:42.920 --> 12:47.480] the number of bytes, multicast, layers, seven information, these type of things. And the [12:47.480 --> 12:53.160] API calls are very small. So in essence, we don't want, you know, the application to [12:53.160 --> 12:58.200] be inefficient simply because we download to Lua the representation of the host, the representation [12:58.200 --> 13:02.920] of the flow. Well, simply the method that we are interested in. So in the left side, [13:02.920 --> 13:06.520] you will see the C++ code, how it implements the stuff. On the right side, you will see [13:06.520 --> 13:13.520] an example of the Lua code. So in this case, just to give you an idea of how it works. [13:13.520 --> 13:17.280] So whenever there is one of the events, so for instance, we have to check the flow because, [13:17.280 --> 13:21.520] you know, NDPI is over, so the protocol has been detected. So if you want to block, let's [13:21.520 --> 13:29.160] say, Google Mail, okay? So what you need to do is to execute a Lua check after this happened. [13:29.160 --> 13:35.040] So in essence, the C++ code, we have put the code to the Lua VM that executes a script, [13:35.040 --> 13:39.760] okay? A script that can be, you know, applied to many flows, not just for one. So this is [13:39.760 --> 13:44.600] where, you know, this happens. And this is an example of a check. So we have a simple [13:44.600 --> 13:51.000] example. If you have a flow that is either TLS or quick from, started from host or anything [13:51.000 --> 14:02.040] in 192.68, 178.2, 1.1. And if it's TLS, and if the protocol issue is, so a very simple [14:02.040 --> 14:07.920] check that, for instance, a friend of mine has asked because it's monitoring IoT networks [14:07.920 --> 14:15.600] and they have found a vulnerability on a specific type of rule and the client was a specific [14:15.600 --> 14:20.880] device. So something that is not general. Okay. So this is the way it works. Very simple [14:20.880 --> 14:25.640] to write. The problem is the following. That the overhead introduced, this is a very slow [14:25.640 --> 14:30.840] Intel I3. So just to give you an idea of the super worst case, is 30 microseconds for everything, [14:30.840 --> 14:36.600] okay, in average. Whereas with C++, we can do it in one microsecond. Now, you say, this [14:36.600 --> 14:42.200] is bad. In a way, it is bad. I agree because we are 30 times lower. But you have to think, [14:42.200 --> 14:45.680] first of all, on one gigabit networks, that this is not the problem. Also, you have to [14:45.680 --> 14:50.920] think that most of these checks are asynchronous. This is one of the few ones that are synchronous. [14:50.920 --> 14:55.320] So in essence, as soon as the protocol has been detected, we call this method. But it [14:55.320 --> 15:00.200] is not why the packets are coming. So in essence, we have another threat that is calling this [15:00.200 --> 15:05.640] while the traffic is coming. But we don't stop the execution tree. So in essence, just [15:05.640 --> 15:11.160] to make it short. So if you take this overhead that you have introduced and you sum to everything [15:11.160 --> 15:15.280] and you stay below certain boundaries, so if you want for every minute to execute the [15:15.280 --> 15:20.600] flow checks on all the flows, you are good, okay. And of course, we trigger an alert. [15:20.600 --> 15:25.800] And the result of the alert is a notification on the GUI that can be sent, for instance, [15:25.800 --> 15:29.400] through Microsoft Teams, just to give you an idea. Or we can trigger a shell script [15:29.400 --> 15:35.960] for something or can send an alert to my friend on Telegram. So this is the way it works. [15:35.960 --> 15:43.120] Okay, now I have this. Okay, so we have seen how to extend the N-top-ng engine with Lua [15:43.120 --> 15:49.040] scripts to access traffic information and use those information to check the traffic [15:49.040 --> 15:55.520] and trigger alerts, for instance. Now, recently released also a Python package that you can [15:55.520 --> 16:03.400] install with pip install N-top-ng that allows you to, you can use it as a library to create [16:03.400 --> 16:10.240] a Python script which is able to access traffic information in N-top-ng. And this happens [16:10.240 --> 16:19.040] through the REST API. This means that you can run your script even on a remote location. [16:19.040 --> 16:24.440] For example, you can access live data in N-top-ng. In this case, we are importing the N-top-ng [16:24.440 --> 16:31.200] class. We are connecting to N-top-ng using the N-top-ng class. We get an instance of [16:31.200 --> 16:39.040] the, of an interface in N-top-ng, for instance, eth0. We use this method to get all the hosts [16:39.040 --> 16:45.160] which are active in my network with all the metadata. And there are plenty of methods [16:45.160 --> 16:49.560] in this class or another class in this library that allows you to get traffic information. [16:49.560 --> 16:58.200] So you can get alerts, flows, hosts, whatever. And you can also get historical data. So the [16:58.200 --> 17:02.800] same way, so you connect to N-top-ng, you get an interface. From this interface, you [17:02.800 --> 17:07.720] get the, an instance of the historical class. And you can run queries in the database. For [17:07.720 --> 17:13.320] instance, you can get alerts statistics from this time to this time, for instance, for [17:13.320 --> 17:21.600] the last 24 hours. And just print the, of the alerts that you have. [17:21.600 --> 17:29.960] Now, those are two examples of querying the, the engine to get the data. Of course, we [17:29.960 --> 17:37.480] have seen that N-top-ng is able to, when a check or an external event detects something, [17:37.480 --> 17:42.920] an event, we can trigger an alert. And we have seen that N-top-ng supports several endpoints. [17:42.920 --> 17:51.480] So we can send this alert using mail, a messaging system, like telegrams, LAC. We can run a [17:51.480 --> 17:57.600] shell script. We can call a web book. So we can run a shell script. For instance, in [17:57.600 --> 18:05.840] this script, it can be a Python script. So let's try to put all the pieces together. [18:05.840 --> 18:12.880] So we receive an event from, which is generated by an internal check or an external check. [18:12.880 --> 18:18.440] This event can call a Python script. This Python script can get information from the [18:18.440 --> 18:25.080] alert itself or can query the engine through this API that we created to get more data, [18:25.080 --> 18:30.320] to fetch more data and argument the alert information. And this can have some logic [18:30.320 --> 18:38.840] and trigger some action. So you can write your actions here to react to this event. [18:38.840 --> 18:42.480] In order to implement this, what you have to do in N-top-ng is, first of all, you have [18:42.480 --> 18:48.600] to enable the check that you want to use to analyze the traffic. For instance, in this [18:48.600 --> 18:58.800] case, we are using a custom check that the user creates in Lua as Luca showed you before. [18:58.800 --> 19:03.800] Then if you want to write your Python script that reacts to this event, you have to write [19:03.800 --> 19:10.720] an alert tender, which is a script that you place under N-top-ng script shell. And this [19:10.720 --> 19:16.280] case is a simple script, which is just getting, as in the standard input, the traffic information, [19:16.280 --> 19:23.000] the metadata. And, for instance, if the alert type is our user script, I want to do something. [19:23.000 --> 19:28.880] In this case, I'm just logging the IP address related to the host that triggered the alert [19:28.880 --> 19:37.320] and a message from our custom script. Then you have to go inside N-top-ng. You go under [19:37.320 --> 19:43.360] notifications. You set that you want to send alerts to the shell script. Here you have [19:43.360 --> 19:49.120] all the options, like email, whatever. And you select your handler. And then you specify [19:49.120 --> 19:53.880] for your handler that you want to receive just critical alerts. So you specify the severity. [19:53.880 --> 19:57.960] You specify the category that you want to, of alerts that you want to handle, from this [19:57.960 --> 20:08.040] case, cybersecurity, and the entity. In this case, I want to handle alerts about hosts. [20:08.040 --> 20:13.600] And then we can extend our handler. We have seen how to print just the alert information, [20:13.600 --> 20:21.080] but we can, again, we can use our Python library and N-top-ng to access more information about [20:21.080 --> 20:26.840] the host. So we receive this alert, which has been triggered on a specific host in our [20:26.840 --> 20:32.640] network. For instance, this host has been infected by malware. It's generating unexpected [20:32.640 --> 20:39.920] traffic, whatever. We want to get more information about this host to build a report, for instance. [20:39.920 --> 20:43.840] In fact, in our library, we also have the ability to generate a report, or you can generate [20:43.840 --> 20:52.440] your own report using the API that we have. So we build this report and send an email. [20:52.440 --> 20:57.520] So this is a simple script that you can use. It's a few lines of code to handle alerts [20:57.520 --> 21:05.480] and generate reports and get, for instance, an email or your mobile phone with the alert. [21:05.480 --> 21:11.560] So this is the big picture of the example that we're seeing right now. So we have defined [21:11.560 --> 21:18.840] a user script that triggers an alert, or we receive, again, events from any other source [21:18.840 --> 21:24.640] or internal checks. We are calling our script, which is getting more information from the [21:24.640 --> 21:30.920] engine to build a report and send this report by email. So the result is this. So the system [21:30.920 --> 21:36.480] is checking your traffic, is building a report when something happens, and we'll send you [21:36.480 --> 21:42.640] an email with the report of the traffic for the host with the top alerts sorted by severity [21:42.640 --> 21:49.000] or by count, the top contacts for the host, the chart of the traffic generated by the [21:49.000 --> 21:55.720] host, where you can add more, like the top applications used by the host, et cetera. [21:55.720 --> 22:01.200] Do you want to wrap up? Okay. So we have seen that within top ng, you can collect traffic [22:01.200 --> 22:11.240] information from traffic, flows, events, events from Suricada, for instance, et cetera. And [22:11.240 --> 22:16.400] we started with the top, actually Luca started with the top, then we moved to the top ng. [22:16.400 --> 22:24.440] It was mainly a traffic monitoring tool. Today is also a cybersecurity tool able to do behavioral [22:24.440 --> 22:32.800] checks, not just for providing visibility, but also providing cybersecurity monitoring. [22:32.800 --> 22:39.840] You are now able to extend this engine, both with new scripts integrated in top ng or even [22:39.840 --> 22:48.040] with C++ plugins, let's say checks, if you need to scale with performance, or you can [22:48.040 --> 22:56.120] use our Python library to write Python tools that can run externally, even remote boxes, [22:56.120 --> 23:04.240] to access traffic information in the top ng engine, and be, for instance, a PDF as we [23:04.240 --> 23:08.840] have seen with reporting what's going on in your network. Of course, all the code is available [23:08.840 --> 23:14.720] on GitHub, so if you want to contribute, you are welcome. Especially now, you don't have [23:14.720 --> 23:22.920] excuses. We have a lot of libraries, scripting languages for interacting with the engines, [23:22.920 --> 23:29.520] or something else to add. No. The only thing I want to say is that this [23:29.520 --> 23:33.880] is an efficient way from our point of view to do network monitoring and cybersecurity, [23:33.880 --> 23:38.000] and at the same time to extract information in a way that does not interfere with the [23:38.000 --> 23:43.800] main engine, so that allows, I believe, most of the people sitting in this room to do whatever [23:43.800 --> 23:47.720] they like to create a monitoring tool that is tailored for their own needs, and that's [23:47.720 --> 23:54.720] the first set that is open source. That's all. Thank you very much. [23:54.720 --> 24:00.680] Any questions? Any questions? [24:00.680 --> 24:08.800] Wait, wait, wait. It's just a simple question. How does it compare with CN tools? It looks [24:08.800 --> 24:14.600] like it does everything CN could do. CN tools. Yeah. [24:14.600 --> 24:21.920] I don't know the tools. No problem. I am not familiar with them. [24:21.920 --> 24:39.160] Any other questions? The scripts can be compiled to be more [24:39.160 --> 24:51.400] performance, or do you not have this task in your developer timeline? To compile script, [24:51.400 --> 24:59.920] to have more performance. Loa script, or like CCC, we saw that CCC script [24:59.920 --> 25:12.320] takes one millisecond, but the Loa script takes 30 milliseconds. Yes, of course, you [25:12.320 --> 25:17.480] can compile them, but you have to code it in C++ at the moment. So we used Loa just [25:17.480 --> 25:22.360] in time to compile the one seen before by a stamp switch, but it is not available everywhere [25:22.360 --> 25:27.080] for its own arm, and we want to support it as various. So yes, it is possible, but again, [25:27.080 --> 25:34.080] these are microseconds, not milliseconds. So one million of them per second. [25:34.080 --> 25:43.960] Any questions? Anybody else? [25:43.960 --> 25:50.200] Hi, thank you. Do you have some figures about performance you are able to achieve on typical [25:50.200 --> 26:00.520] server, about flow per second? Some figures to share on Loa scripting, and also some example [26:00.520 --> 26:09.480] on Python, which should be less efficient? Okay. We are, when you process packets with [26:09.480 --> 26:16.000] Ntop.ng itself, you are able to process like a few gigabits per second, depending on the [26:16.000 --> 26:22.200] drivers you use, how you tune Ntop.ng, let's say, to scale with the performance, you can [26:22.200 --> 26:28.760] get 10 gigabits, for instance, but more or less, we range from a few gigabits to 10 gigabits [26:28.760 --> 26:34.240] in Ntop.ng itself. You can use it in combination with our probes, which is Nprobe, or we have [26:34.240 --> 26:39.840] other probes like Cento. In that case, you can scale with the performance up to 100 gigabits [26:39.840 --> 26:49.720] per second, but the architecture changes a bit. It's one 100 gigabit in plus. As of [26:49.720 --> 26:56.120] the checks, it depends on the checks that you enable, of course. Okay. I think we are [26:56.120 --> 26:59.120] running out of time. Many thanks for being here now. [26:59.120 --> 27:10.320] Thank you.