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

    Snort no alerts or blocks

    Scheduled Pinned Locked Moved IDS/IPS
    12 Posts 3 Posters 1.4k 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.
    • J
      jonna99 @jonna99
      last edited by

      @jonna99 said in Snort no alerts or blocks:

      Hi!
      Snort not working as it should. Since a few weeks there are no blocks or alerts.
      I´ve been using the same settings for years.
      Settings are default and using;
      -legacy mode
      -IPS policy, security
      -ET Open Rules
      -snort paid subscriber rules
      -block offenders
      -AC-BNFA-NQ
      -no supression list
      -auto flowbit rules

      Installed Suricata with default settings alongside with Snort and Suricata delivered a bunch of alerts in "balanced mode"

      Pfsense+ 24.03
      Snort 4.1.6_17

      Any ideas much appreciated
      Jonna

      Still no alerts. Something that affects this changed from 23.09 to 24.03. Started in connection with upgrading.
      Or can it have something to do with Kea-dhcp instead of ISC ?

      Enabling WAN interface (in addition to the other 5 interfaces) with same settings I do get some alerts but only from Emerging Threats and nothing from Flowbit-rules, security-mode.

      Jonna

      bmeeksB 1 Reply Last reply Reply Quote 0
      • bmeeksB
        bmeeks @jonna99
        last edited by

        @jonna99 said in Snort no alerts or blocks:

        nothing from Flowbit-rules, security-mode

        Flowbit rules do not alert in the traditional sense. They are bit flags that are set when particular conditions are true and let the IDS maintain a sort of "state" across multiple sessions. Almost every flowbit rule will have the noalert keyword in the rule's text thus inhibiting actual alerts.

        The number one reason for not seeing alerts would be the HOME_NET and/or EXTERNAL_NET variables not set correctly.

        J 1 Reply Last reply Reply Quote 0
        • J
          jonna99 @bmeeks
          last edited by

          @bmeeks
          Hi!
          Thanks for answering.
          I"Home net"," External net", "Passlist". and "Alert suppression and filtering" are all set to default.

          Thanks
          Jonna

          J 1 Reply Last reply Reply Quote 0
          • J
            jonna99 @jonna99
            last edited by

            @jonna99
            Hi!
            Sorry if I wasn´t clear in my answer.
            The settings are all in default and have been for the last few years. Haven´t changed anything. I have 3 Pfsense boxes and none of them have generated any alerts for weeks now.

            Any ideas plz

            Jonna

            bmeeksB 1 Reply Last reply Reply Quote 0
            • bmeeksB
              bmeeks @jonna99
              last edited by bmeeks

              @jonna99 said in Snort no alerts or blocks:

              @jonna99
              Hi!
              Sorry if I wasn´t clear in my answer.
              The settings are all in default and have been for the last few years. Haven´t changed anything. I have 3 Pfsense boxes and none of them have generated any alerts for weeks now.

              Any ideas plz

              Jonna

              I just tested a Snort-4.1.6_17 install on a virtual machine by scanning it with nmap. I saw alerts and blocks as expected. For this particular VM I run Snort on the WAN so that I can easily scan it with nmap from another VM running Kali Linux.

              Are you sure the Snort daemon is actually running on your firewalls? When you run this command from the CLI, do you see output indicating running Snort processes:

              ps -ax | grep snort
              

              Are you running Snort on the WAN or LAN interface? If LAN, realize that the default drop rules likely in place on your WAN are going to drop pretty much all traffic that would otherwise generate Snort alerts.

              When you installed Suricarta, which specific rules were alerting? Suricata's built-in Events rules will trigger on a lot of "noise" and generate alerts. Snort does not have those same built-in Events rules and thus won't alert on them. Post screenshots if you have them of the specific alerts you were seeing with Suricata installed (from the ALERTS tab).

              In summary, my test just now with a freshly installed Snort package shows no issues whatsoever. I get alerts and blocks when scanning with Kali Linux as expected.

              1 Reply Last reply Reply Quote 0
              • J
                jonna99
                last edited by

                Hi!

                -I´ve tried fresh install with same poor result.

                • I paste one line from the command "ps -ax | grep snort" ;
                  "36783 - SNs 0:01.15 /usr/local/bin/snort -R _41880 -M -D -q --suppress-config-log --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_igb1.6041880 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 41880 -c /usr/local/etc/snort/snort_41880_igb1.60/snort.conf -i igb1.60"
                  the other lines look the same as above.

                • I´m running seven interfaces on one of the boxes but no WAN. Tried enabling WAN for a few days and there I do get alerts from "ET Open rules". A bunch of alerts from scan- and torrules but nothing else.

                • Concerning my test with Suricata, I don´t remember which rules specifically but I tried to set the same as I have in Snort.

                Jonna

                bmeeksB 1 Reply Last reply Reply Quote 0
                • bmeeksB
                  bmeeks @jonna99
                  last edited by

                  @jonna99 said in Snort no alerts or blocks:

                  I paste one line from the command "ps -ax | grep snort" ;
                  "36783 - SNs 0:01.15 /usr/local/bin/snort -R _41880 -M -D -q --suppress-config-log --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_igb1.6041880 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 41880 -c /usr/local/etc/snort/snort_41880_igb1.60/snort.conf -i igb1.60"
                  the other lines look the same as above.

                  I see you are running Snort on a VLAN interface. That can be dodgy. I do not have a mechanism for testing with VLANs in my development setup.

                  @jonna99 said in Snort no alerts or blocks:

                  I´m running seven interfaces on one of the boxes but no WAN. Tried enabling WAN for a few days and there I do get alerts from "ET Open rules". A bunch of alerts from scan- and torrules but nothing else.

                  When running on the LAN or any other internal interface, you are likely not going to see many (if any alerts) because the WAN-side firewall rules are dropping traffic that otherwise Snort would see. Check out this diagram that shows where Snort sits in the traffic flow path --

                  ids-ips-network-flow-legacy-mode.png

                  Notice in the above diagram how the traffic goes directly from the NIC to the IDS/IPS BEFORE it gets to the pf firewall engine. So, looking at this diagram, if Snort is on the WAN it sees all the normal Internet noise before the pf firewall engine has filtered it and thus generates alerts. But those alerts are worthless really since the pf firewall is already going to be dropping that traffic due to the default "deny" rule.

                  But if Snort is on the LAN, then you can see that the WAN firewall rules will effectively "filter" the traffic and thus reduce the number of alerts seen (and quite possibly reduce them to zero).

                  If you want to see whether Snort is working, install nmap on an internal machine on one of your LAN-side networks and use it to scan the firewall interface IP. Enable the Emerging Threats Scan rules (ET-Scan), restart Snort, then run an nmap Syn scan targeted to the firewall's interface IP on the network where the nmap machine is located. You should get alerts. You won't get blocks because of the automatic default passlist, but you should see alerts.

                  J 1 Reply Last reply Reply Quote 0
                  • J
                    jonna99 @bmeeks
                    last edited by

                    @bmeeks
                    Yes of course, you are right. I did the Nmap scan and sure enough, alerts showed up.
                    Reading your answer I think I made a mistake enabling the VLANS, The LAN should be enough since the VLANs are just "sub interfaces" to LAN? I don´t really need to see where and which part of the network someone/something tried an intrusion as long as it´s stopped. Enabling only LAN would, I guess, also use less CPU -power.

                    Jonna

                    bmeeksB 1 Reply Last reply Reply Quote 0
                    • bmeeksB
                      bmeeks @jonna99
                      last edited by

                      @jonna99 said in Snort no alerts or blocks:

                      The LAN should be enough since the VLANs are just "sub interfaces" to LAN? I don´t really need to see where and which part of the network someone/something tried an intrusion as long as it´s stopped. Enabling only LAN would, I guess, also use less CPU -power.

                      Correct. Snort, by default, puts the monitored interface in promiscuous mode. That means it sees all traffic traversing the physical interface no matter what VLAN it may be associated with.

                      J 1 Reply Last reply Reply Quote 0
                      • J
                        jonna99 @bmeeks
                        last edited by

                        @bmeeks
                        Not too old to learn something new ,thanks to you.

                        Many thanks
                        Jonna

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.