• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

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

Scheduled Pinned Locked Moved IDS/IPS
9 Posts 2 Posters 729 Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L
    lexxai
    last edited by Nov 8, 2019, 10:25 PM

    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 ?

    –
    We have what we have. Everything that happens - for the better.

    1 Reply Last reply Reply Quote 0
    • B
      bmeeks
      last edited by bmeeks Nov 11, 2019, 1:53 PM Nov 10, 2019, 11:50 PM

      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.

      1 Reply Last reply Reply Quote 0
      • L
        lexxai
        last edited by lexxai Nov 11, 2019, 7:17 PM Nov 11, 2019, 7:12 PM

        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.

        –
        We have what we have. Everything that happens - for the better.

        B 1 Reply Last reply Nov 12, 2019, 4:49 AM Reply Quote 0
        • B
          bmeeks @lexxai
          last edited by bmeeks Nov 12, 2019, 12:32 PM Nov 12, 2019, 4:49 AM

          @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.

          1 Reply Last reply Reply Quote 0
          • L
            lexxai
            last edited by lexxai Nov 12, 2019, 9:45 PM Nov 12, 2019, 9:43 PM

            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.

            –
            We have what we have. Everything that happens - for the better.

            B 1 Reply Last reply Nov 12, 2019, 10:17 PM Reply Quote 0
            • B
              bmeeks @lexxai
              last edited by bmeeks Nov 12, 2019, 10:20 PM Nov 12, 2019, 10:17 PM

              @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.

              L 1 Reply Last reply Nov 12, 2019, 10:32 PM Reply Quote 0
              • L
                lexxai @bmeeks
                last edited by lexxai Nov 12, 2019, 10:39 PM Nov 12, 2019, 10:32 PM

                @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.

                –
                We have what we have. Everything that happens - for the better.

                B 1 Reply Last reply Nov 12, 2019, 11:12 PM Reply Quote 0
                • B
                  bmeeks @lexxai
                  last edited by Nov 12, 2019, 11:12 PM

                  @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.

                  L 1 Reply Last reply Nov 12, 2019, 11:26 PM Reply Quote 0
                  • L
                    lexxai @bmeeks
                    last edited by lexxai Nov 12, 2019, 11:26 PM Nov 12, 2019, 11:26 PM

                    @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.

                    –
                    We have what we have. Everything that happens - for the better.

                    1 Reply Last reply Reply Quote 0
                    9 out of 9
                    • First post
                      9/9
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                      This community forum collects and processes your personal information.
                      consent.not_received