Using nProbe for Solving General Traffic Monitoring Tasks

Posted · Add Comment

Most people use nProbe just as a basic NetFlow/IPFIX probe where traffic monitoring is limited to packet header analysis, without further dissecting protocols. This practice is very common inside the NetFlow community and it’s one of the reasons why flow-based analysis has not changed much since its inception. Fortunately nProbe can do much more than this (e.g. it can inspect traffic on tunnels, or geo-locate flow peers), and below are just some use cases:

  • Browsing the Internet is slow, some URLs cannot be accessed
    Most likely the DNS is not working perfectly, is either unresponsive or slow. With nProbe you can enable the DNS plugin so that you can monitor the DNS queries/responses as well the response time.
  • Monitor HTTP latency
    HTTP is a pervasive protocol, also used by non-web applications. When latency of selected URLs increases, the services relying on it are affected as well the user experience. nProbe allows HTTP URLs to be monitored by analyzing the service time as well computing the network latency, so that network administrators can figure out if the problem is on the web server or on the network. Furthermore for advanced HTTP analysis or for reconstructing HTTP traffic communications, nProbe can generate  comprehensive traffic traces in text format that could be used for pinpointing the problem.
  • SSL/HTTPS Monitoring
    In addition to HTTP, nProbe can also analyze HTTPS traffic. SSL certificates are decoded, thus it is possible to figure out whether a certain HTTPS connection is used for home-banking or for accessing web-mail. Being able to identify the site we’re connecting to, it’s useful for detecting SSL connections that are used to tunnel out traffic and thus violate the network policy. If the user can supply the private SSL key (e.g. we decide to monitor our web site), nProbe can fully decode the HTTPS traffic and thus generate the same statistics produced for HTTP.
  • Application Detection
    Since the end of last year, nProbe supports application detection by means of an open-source DPI library we’re developing. As we’re supporting more that 120 application protocols (including popular applications such as Skype, BitTorrent, Facebook, Twitter and YouTube), it’s very easy to know which portion of bandwidth is used by a specific protocol, what application protocol is using port X, and also for detecting known protocols on non-standard ports (e.g. detect HTTP on ports other than 80, 3128, 8080) that might indicate a security issue.
  • VoIP Traffic Analysis
    nProbe natively detects SIP/RTP traffic and produces CDR (Call Data Records) including voice quality parameters (e.g. jitter, packet loss, and packets out of order) that can be both dumped on disk/database and also exported via NetFlow. This means that you can create a permanent VoIP traffic monitor application relying on nProbe’s traffic analysis.
This year we are planning to introduce selected extensions on nProbe that could further simplify network traffic analysis. Some of them include:
  • Emit Flows on Demand
    In NetFlow, flows are always generated when a flow expires. This puts a lot of  pressure on collectors that have to discard unwanted flows. We are planning to enhance nProbe so that you can specify which conditions must be met in order nProbe to emit a flow. This would allow for instance to emit only those flows with specific characteristics (e.g. skype flows or flows with high latency) thus saving bandwidth and reducing the load on collectors.
  •  Create Custom NetFlow Fields
    Many collectors are a simple dump-to-database and select-data-from-database  applications with a web GUI. As these application are not able to do complex operations, nProbe will offer the ability to define custom fields containing pre-computed values on which collectors can rely. For instance it will be possible to define a new numeric field named FLOW_QUALITY that indicates whether such flow needs to be further analyzed as it has been characterized by high latency, or too many packets out-of-order/retransmitted, or too many fragments.
You can do many things exploiting nProbe beyond the basic NetFlow traffic analysis that all flow probes do. And if a given features it is not present, it can be developed and added to nProbe by coding it onto a plugin. This is true beauty of open-source software.