Can pfSense integrate with another device? (mirrored-port⇄API)
-
Reading The pfSense
BookDocumentation, I saw one of the common use cases was to use pfSense as a packet sniffer, it made me sit up straight right away because Is soft of wanted to test that in a lab. I read further and it appears that yeaḥ-it can be a packer sniffer but for the random small capture via the GUI or with a remote Wireshark.Can it though?
bolded textSome weeks back, I was playingwith/learning Mikrotik's CHR, it lacks IDS/IPS plugins/modues (and an easy ruleset UI like pfSense's) but what it lacks it makes in up in its crazy advanced routing abilities so you can just very well route out to pfSense to filter then back to distribute or something.
That's not how it's done though, apparently it's inefficient; what they do over there is (a) mirror a port or (b) set some sniffing protocol (something named with sharp letters like "TZK") which is sent to a Suricata appliance out of the traffic's path, suricata then would send back to CHR the instructions of what to block.
I got lost somewhere in the end, but it's sort nice and fast. Could pfSense do this? Maybe not for CHR but for another pfSense appliance if you'd wanted to offload the task or something like that.
I read another way that uses the EVE JSON Log which I¡m positive pfSense can output somewhere else but I'm more curious about the API first. pfSense's fork OPNsense has a published API that I sort of hope exists in pfSense too, they're not too keen on documenting so can't tell. :/
-
The Suricata package on pfSense already does all of this for you. It sniffs all traffic on the interface using the libpcap library, then has a custom blocking module compiled into the binary. That module will extract IP addresses from alerts and insert them into a pre-configured
pf
table called snort2c. That table is used by a built-in pfSense rule to block any IP address entered into the table.The pfSense Suricata package also offers an Inline IPS Mode (for supported NIC drivers) that literally drops individual packets between the NIC hardware driver and the OS kernel network stack.
Read the Sticky Posts at the top of this forum to learn more.
-
@bmeeks Yeah, I knew about inline, I set it up once a loong time ago but went back bc it was "too automatic" if you will, and I was still learning what warnings meant what. Thankfully, I know now what do disable in advance to avoid going through the learning period, duplicate interaces and rarely come back. I might give in line another shot now that you mention it.
I'm not doubting the capabilities of Suricata in tandem with pfSense at all. I swear by them. I just want to know what it can do (or rather how) when paired with another appliance when it's not literally in line. :)
Does the snort2c table live in memory or is it written somewhere? I think I'm starting to puzzle things out. I checked out the EVE JSON thing again in the firewall and now the options are huge in comparison to the last time I was there. Last time there was only a checkbox, now the same checkbox unfolds a section of its own. :D
I think I just have to sort out the ingest to make it work.
Thanks for answering, BTW, I passed the stickies bc I didn't think out of the ordinary use cases and non-serup guidance would be in them, but I'll check 'em out right away. Thanks again!
-
The snort2c table is a packet filter memory construct. It exists only in RAM. It is created as one of several hidden tables when pfSense starts up.
You can query it via the
pfctl
command-line utility. I'm not understanding what you want to accomplish. The package can't communicate with any external appliance (unless you count creating EVE.json logs for a logging server to ingest as "communication"). There is no API to expose.Reading your original post again, it seems as if you want Suricata to run on one box, and then communicate over the wire with a different box and tell it what to block. Why? That is horribly inefficent, and packets will leak unless you slow the network traffic down to a trickle and hold packets up on one box while the other box is inspecting them and then sending instructions over some kind of back channel to the control device. Inline IPS mode with Suricata integrated into the pfSense firewall is way, way better for that kind of operation.
-
@bmeeks said in Can pfSense integrate with another device? (mirrored-port⇄API):
packets will leak unless you slow the network traffic down to a trickle and hold packets up on one box while the other box is inspecting them and then sending instructions over some kind of back chan
Thanks, this is incredibly informative. Just to be clear, my edge device and firewall is pfSense and it's also the one running Suricata (not inline though). I'm just experimenting with stuff for fun, and sure, anything's going to be super inefficient if it's not within kernel's reach but it must be at least better than diverting back and forth the full stream of data.
The big really big enterprise firewall-routers, something like TNSR or these 30-something core ASICs out there usually don't have these features. They do seem like they'd benefit from this approach but that's just speculation of mine, I came here to learn in the first place, I've nothing to teach.
Thanks again!