nProbe

Amazon Virtual Private Cloud (VPC) flow logs and in essence text-based Netflow-like logs consisting of fields that describe the traffic flow. They are often collected on disk and published to S3 buckets or CloudWatch for an AWS-centric monitoring infrastructure (extra AWS charge is necessary). Now suppose that you want to use this information to monitor your VPC using ntop tools or turn these logs in industry standard NetFlow/IPFIX flows that can be ingested in any monitoring application unable to understand this proprietary log format. In this case you can use …

Network interfaces natively support RX and TX directions, so tools such as ntopng can detect the traffic directions and depict this information accordingly. In the above picture that ntopng shows in the top menubar, TX traffic is depicted in blue and RX in green. All simple. Now suppose you need to analyse sFlow/NetFlow/IPFIX flows, and be interested to understand how much traffic leaves/enters your network. Example suppose you generate IPFIX flows on your Internet gateway: how much of this traffic is sent to the Internet and how much is received? …

This is to introduce a new nProbe feature that brings IPS (Intrusion Prevention System) support via nDPI for Linux and FreeBSD (including OPNsense and pfSense). As shown in the picture below, nProbe acts as a transparent bridge (with kernel offload) for applying pass/drop/shape rules to the forwarded traffic. Our goal is to combine the power of DPI and nDPI cybersecurity features to all nProbe users. When deployed on a firewall/gateway (including OPNsense/pfSense), nProbe can both monitor and apply policies to monitored traffic. Typical use case include (but are not limited …

This is to announce nProbe 9.4 stable that is an incremental update of 9.2 released last fall. The goal of this maintenance release is to pave the way to pervasive embedded systems support as we now support OPNsense/pfSense/FreeBSD Soon we’ll make a separate announcement as soon as more ntop packages will be available for these platforms. Ubiquity EdgeRouter X Read this blog post for learning more about sub 100$ Ubiquity-based hardware probes. OpenWRT In addition we have decided to simplify the nProbe versions that were hard to understand for most …

This is to announce the release of nProbe 9.2. The main new features of this release are focused on flow collection speed and flexibility in particular for modern JSON-based flow consumers. This is to enable applications relying on nProbe, e.g. ntopng, to scale up when collecting flows: The new –collector-passthrough option allows the flow cache to be bypassed when flows are collected. This mean that flows are forwarded to remote collectors unmodified (i.e. -T is not used) without placing them into the flow cache (i.e. flows are not merged by …

This is to introduce nProbe 9.0 stable release whose the two main features are traffic behaviour analysis and high speed flow collection. Traffic Behaviour Analysis When in 2002 nProbe™ development started, the idea was to create a drop-in replacement for physical probes present in routers. Later the advent of IPFIX pushed the monitoring community towards standardisation of flow exports, and promoted interoperability across probes and collectors. Then the market started to ask solutions for visibility (and not just traffic accounting), and we developed nDPI™ for going beyond port and protocols …

nProbe (and ntopng) is a traditional packet-based application, whose lifecycle is Capture a packet and dissect/decode it Update the representation in memory of the network traffic (e.g. the flow table) Export the information Using packets for traffic analysis has several positive things including: Ability to analyse traffic using a port mirror/TAP without installing and agent on every monitored host, thing that might be a nightmare if your network is heterogeneous. Scalability issues have been solved (e.g. see PF_RING ZC) years ago, so monitoring a 40/100G network is no longer a …