Good reporting out of OPNSense

[beneix]

I have recently implemented an OPNSense firewall and router for my home network. Looking at the built-in reporting available, I would like to see how I can get more comprehensive data and analysis of the traffic in/out, firewall actions, etc. Since my HW is limited, I suspect I'll set up the reporting on a separate machine, perhaps running the ELK stack or something similar. But, before I embark on this...

1. Are there more advanced reporting possibilities in OPNSense itself, perhaps with some added packages, even on modest hardware such as mine? I have seen mention on Routerperformance of Grafana, InfluxDB and other packages, but I am not sure if they would fit the bill.
2. If I go down the route of sending OPNSense data to an external reporting box, what would be a good way to start? I assume it should be possible to get some good data with what is already being generated on my OPNSense and without installing Zenarmor, right? Then should I go for pfELK, the integration from Elastic or something else?

[phoenix]

Have you considered Netdata? There's even a plug-in for it in OPNsense, have a look at their website: https://www.netdata.cloud/

[36thchamber]

You're being replied with performance counters suggestion every time, and that's not the solution. I also have the same goal and don't need yet another fancy SNMP charting.

Did you have any success with the analysis (PFELK)? There's still nothing to view the network activity properly, except the Plain View which noone has stomach to read. I just want to see the blocked historical packets, and there's no way. Even ZenArmor won't persist them as they push their own blocklists. Not even ntop. Not netflow. Not maltrail. Live View is very short term.  I saw a very low motivation to improve the Plain View when reading the forum. So i wonder what to do next. I'm totally unaware about dangerous activity in and out and that's not cool.

[andrwhmmr]

So I would suggest you start by enabling Logging to an external device:
System -> Settings -> Logging / "Logging / targets" to get a read of the Firewall actions.

For Perfomance I use the Prometheus node_exporter Plugin.

And the netflow data is also "exportable" so... with this setup you should get everything you need, right?

[36thchamber]

Out of desperation i now watch the blocked connections in NTOPNG using this sync: https://t.ly/ugg2p
Alarms are persistent so it basically shows firewall rule hits on blocklists. For the rest of the data, like traffic charts, live views, ntop is already very good.

[Patrick M. Hausen]

Why would I be interested in blocked connection attempts? If they are blocked, they are not of any concern.

I am much more interested in permitted connection attempts with malicious intent. For that I run a Caddy reverse proxy and CrowdSec.

There might be more capable tools but that's what I use.

[36thchamber]

that is fundamentally a similar approach, except broader blocklists actually block them while Crowdsec alerts become blocklists anyway and block it later after "unnecessary test".

Knowing of block hits can raise awareness, help recognize the patterns, and improve the blocks even more. It's sad that despite admins store such filter, it's not promoted anywhere. It's like Unbound removed the "Blocked" and "Top blocked domains" UI parts because "well the client DNS filter or upstream DNS will pick it anyway, don't worry". Why.

Furthermore on a system that is almost isolated, with most traffic already bounced off by external DNS/CDN prefiltering, caching, or VPN forwarding, it'd be shocking to see anyone actually hit filter or nginx at all. Way too late for Crowdsec to pick it.

[Patrick M. Hausen]

Hook up any system to the legacy (IPv4) Internet and it will instantly be port scanned 24x7. So why care?

We populate our IPv6 address space sparsely. So every customer container gets a random address inside a common /64. That means all the customer containers (FreeBSD jails, actually) share one /64 or the entire legacy (IPv4) Internet squared.

No way to port scan that.

[36thchamber]

scanning is irrelevant and not happening on such environment (neither IP4 ISP NAT home users). So every blocked connection is significant. There's no reason to "hide" it. In your case, that's so similar in fact, i'd love the same overwatch.

[johnmcallister]

Hook up any system to the legacy (IPv4) Internet and it will instantly be port scanned 24x7. So why care?

We populate our IPv6 address space sparsely. So every customer container gets a random address inside a common /64. That means all the customer containers (FreeBSD jails, actually) share one /64 or the entire legacy (IPv4) Internet squared.

No way to port scan that.

Nice way of conceptualizing that. Hadn't ever occurred to me but it's obvious when you point it out that way. An address space too large to port scan effectively, assuming sparse & reasonably random assignment within it.