pfsense sync pf table snort2c to another firewall by scan loop, but what if use barnyard2 ?

lexxai

May be will be interest my result of :
pfsense sync pf table snort2c to another firewall

Loop batch with 2 seconds delay is currently analyzing the pfSense side snort2c table and transmitting commands when changes are detected to the FreeBSD server using the snmp protocol by the snmpinform command.
https://lexxai.blogspot.com/2019/11/pfsense-pf-snort2c-firewall.html
alt text

But may be can be it easy method with barnyard2 instead of in loop scan pf table snort2c for changes ?

bmeeks

Why would you want to do this?

Do you for some reason think the Snort rules on the second firewall box will never be able to trigger on the same traffic, generate an alert, and then block like the first firewall box did? That would really be the only rational reason to want to duplicate blocks: that you think the second firewall can't detect the same traffic, if it recurs, and block it.

This is as unnecessary as persisting snort2c table IP blocks across reboots. What would be the ultimate point of such complexity? Just let Snort detect the traffic again, if it recurs, and block it again.

Using Inline IPS mode (which Suricata already has both in pfSense RELEASE and DEVEL, and Snort 4.0 has in pfSense DEVEL) syncing the snort2c table is worthless because it isn't even used. With inline mode, packets are just dropped without using firewall rules. The snort2c table is really a kludge that allowed a crude imitation of "dropping" traffic by inserting firewall block rules in lieu of inline packet drops.

lexxai

I may not have fully described the diagrams.
Real gateway server only one (192.168.0.1) only this server can block ip for local LAN,
pfSense on VM (192.168.0.2) only used as external IDS server and not have access to local LAN and used only for listening WAN (ISP Mirror).
Server (192.168.0.1) not have installed SNORT app.

bmeeks

@lexxai said in pfsense sync pf table snort2c to another firewall by scan loop, but what if use barnyard2 ?:

I may not have fully described the diagrams.
Real gateway server only one (192.168.0.1) only this server can block ip for local LAN,
pfSense on VM (192.168.0.2) only used as external IDS server and not have access to local LAN and used only for listening WAN (ISP Mirror).
Server (192.168.0.1) not have installed SNORT app.

Why would server 192.168.0.1 not have Snort installed? If you want that box to protect the LAN, that's really where Snort should be. It makes no sense to me to run Snort on the 192.168.0.2 box, but not let it actually block anything locally and instead copy its snort2c block table over to FreeBSD at 192.168.0.1. I assume you have created that table in pf on the FreeBSD box and created the matching firewall rules to use that table.

You do realize that there will be delays in getting the blocks copied over and put in place on the 192.168.0.1 firewall. Also, what are you doing about the states that get established on the 192.168.0.1 firewall while it is waiting on your update script to run and copy the contents of the 192.168.0.2 snort2c table over to the 192.168.0.1 firewall? The very first packet to hit on the 0.1 firewall will create a state entry, and thus any further traffic from those IP addresses will be allowed no matter what you put in the snort2c table. You will need to clear out the existing states for every IP in each block you copy over from the 0.2 firewall.

The default Snort configuration is to use libpcap to analyze copies of packets as they traverse the interface. The original packet will continue on to the FreeBSD (or pfSense) network stack while Snort works on the copy. That original packet will create a state table entry on the 192.168.0.1 box, and that state table entry will then let all other traffic from that session pass without ever consulting another firewall rule (unless you kill that particular state).

As I said to start with, this is a large amount of complexity with several breaking points for no gain in security. Just run Snort on the 192.168.0.1 firewall if you want the protection afforded by Snort. You can run the Snort binary package just fine from FreeBSD ports over on that FreeBSD server. No need for all the complexity.

lexxai

Thanks for answer.
By scripts code that posted https://lexxai.blogspot.com/2019/11/pfsense-pf-snort2c-firewall.html states killed when ip added to snort2c.

/sbin/pfctl -t snort2c -T add ${SendIP}
/sbin/pfctl -k 0.0.0.0/0 -k ${SendIP}
/sbin/pfctl -k ${SendIP} -k 0.0.0.0/0

It's ok ?

@bmeeks: Just run Snort on the 192.168.0.1 firewall

For current configuration it can't be installed on 0.1.

bmeeks

@lexxai

My concern now is that you are resetting all state table entries. This will break all other established connections besides just any for the IP you are adding. So any clients that were involved in another session completely unrelated to the session you are trying to block will now get severed.

You need to clear states only for the IP you are adding.

Still looks like a lot of complexity to do something you could do much better by simply running Snort on that 0.1 firewall.

You say you can’t run Snort on that other firewall. Why? There is a Snort package for FreeBSD. Just install it and configure it.

lexxai

@bmeeks said in pfsense sync pf table snort2c to another firewall by scan loop, but what if use barnyard2 ?:

You need to clear states only for the IP you are adding.

by https://www.freebsd.org/cgi/man.cgi?query=pfctl(8)&sektion
A network prefix length of 0 can be used as a wildcard. To kill all states with the target "host2":

  # pfctl -k 0.0.0.0/0 -k host2

I use same way (/pfctl -k 0.0.0.0/0 -k ${SendIP}), why states for other ip should be cleared ?

Can use :

tcpdrop -l -a | grep "${SendIP}" | sh

but why not use "pfctl -k" ?

You say you can’t run Snort on that other firewall. Why?

Not have rights do it. I can use only installed apps, with small chganges after checking by other IT security personal.

bmeeks

@lexxai

Okay on the state clearing. I misread the original post. Working on a smartphone with small screen and old eyes.

Still a bit strange to me your IT folks are fine with running scripts that modify firewall rules across the network yet are not okay with installing the standard Snort binary package from FreeBSD ports.

lexxai

@bmeeks said in pfsense sync pf table snort2c to another firewall by scan loop, but what if use barnyard2 ?:

standard Snort binary package from FreeBSD ports

clear Snort it not ready solution.
need load rules by subcribes, by other apps ...
barnyard2 for read raw log from snort, for barnyard2 ideally need to have sql....
for visualize alerts need other app...
ip list etc ....

On other office many years used pfsense as main gw with snort as you say.
And will to say that 8G RAM not so much if enabled barnyard2 with snort and multiple interfaces on snort.