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

    pfSense and Snort DDOS and syn flood

    Scheduled Pinned Locked Moved IDS/IPS
    15 Posts 2 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
      jmanatee @bmeeks
      last edited by

      @bmeeks said in pfSense and Snort DDOS and syn flood:

      @jmanatee said in pfSense and Snort DDOS and syn flood:

      I have searched and I believe the answer is not but Is there a way to have my custom Snort rules block the IP but NOT add an alert?

      No, that's not possible. The blocking mechanism used in pfSense depends on a custom binary plugin compiled into Snort. That plugin triggers off the alert log hook in the Snort binary. With no alert, there is no call to log and thus "no hook" for the blocking plugin to recognize.

      @jmanatee said in pfSense and Snort DDOS and syn flood:

      block udp any any -> any 53 (msg: "MY Suspicious DNS Query ferc"; content: "ferc|03|gov", nocase,fast_pattern; sid:1000003; rev:1;)

      For this rule, I would put the specific IP address of my DNS server in the Destination IP field.

      @jmanatee said in pfSense and Snort DDOS and syn flood:

      This is one of the syn flood rule I am using:
      block tcp any any -> $HOME_NET 443 (flags: S; msg:"Poss Syn TCP DoS 443 dst"; flow: stateless; detection_filter: track by_dst, count 15, seconds 5; sid:1000009; rev:1;)

      Did you verify that $HOME_NET is correctly populated with the move from WAN to LAN? Not knowing your IP addressesing scheme or whether NAT is in play, I can offer any advice beyond making sure that HOME_NET and EXTERNAL_NET are set properly. The default for EXTERNAL_NET is !$HOME_NET -- which is usually sufficient. I would use $EXTERNAL_NET as the "source" in your rules to be sure I did not inadvertently alert on internal traffic (unless you want to rule to trigger from internal hosts talking with each other).

      I will fix the DNS rule to have the DNS servers IPs

      pfsense is setup as a 1:1 NAT with all my public IPs as virtual IPs -> to NAT IPs

      In pfSense I created the alias "srvips" which contains my private IPs 192.168.2.0/24
      In Snort under Pass Lists I have a "passlist_srvips" which has the pfsense alias "srvips"

      I also have all 5 check boxes checked
      Local Networks
      WAN Gateways
      WAN DNS Servers
      Virtual IP Addresses
      VPN Addresses

      I looked at HOME NET it is set for "passlist_srvips" and it has all all my local IPs, DNS Servers and virtual IPs

      But when I look at EXTERNAL NET the list is identical to Home HOME NET That is odd isn't it?

      Not sure where I should go from here....

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

        @jmanatee said in pfSense and Snort DDOS and syn flood:

        I looked at HOME NET it is set for "passlist_srvips" and it has all all my local IPs, DNS Servers and virtual IPs

        But when I look at EXTERNAL NET the list is identical to Home HOME NET That is odd isn't it?

        What do you have the HOME_NET and EXTERNAL_NET drop-downs set for under the INTERFACE SETTINGS tab for your Snort LAN interface? In the majority of cases, leaving those set to "default" is sufficient. But if you are using 1:1 NAT with Virtual IPs that's going to present a different "IP address" to the Snort instance on the LAN. That's because when the traffic reaches Snort on the LAN interface (as the traffic is outbound to the clients on the LAN) the IP address is going to be different than what the Snort interface was seeing when run on the WAN interface. Remember that Snort sees traffic before the firewall rules are applied to inbound traffic. You may have to rethink how you populate HOME_NET (and EXTERNAL_NET) when running on the LAN side.

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

          @bmeeks said in pfSense and Snort DDOS and syn flood:

          @jmanatee said in pfSense and Snort DDOS and syn flood:

          I looked at HOME NET it is set for "passlist_srvips" and it has all all my local IPs, DNS Servers and virtual IPs

          But when I look at EXTERNAL NET the list is identical to Home HOME NET That is odd isn't it?

          What do you have the HOME_NET and EXTERNAL_NET drop-downs set for under the INTERFACE SETTINGS tab for your Snort LAN interface? In the majority of cases, leaving those set to "default" is sufficient. But if you are using 1:1 NAT with Virtual IPs that's going to present a different "IP address" to the Snort instance on the LAN. That's because when the traffic reaches Snort on the LAN interface (as the traffic is outbound to the clients on the LAN) the IP address is going to be different than what the Snort interface was seeing when run on the WAN interface. Remember that Snort sees traffic before the firewall rules are applied to inbound traffic. You may have to rethink how you populate HOME_NET (and EXTERNAL_NET) when running on the LAN side.

          Where is the INTERFACE SETTINGS tab in snort? I think this is what you mean

          Currently I have
          In Snort Interfaces -> WAN Settings -> General Settings -> Interface I have WAN

          In Snort Interfaces -> WAN Settings -> Choose the Networks Snort Should Inspect and Whitelist
          Home Net is passlist_srvips
          External Net is Default
          Pass List is a list of IP from some of my clients

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

            @jmanatee said in pfSense and Snort DDOS and syn flood:

            Currently I have
            In Snort Interfaces -> WAN Settings -> General Settings -> Interface I have WAN

            In Snort Interfaces -> WAN Settings -> Choose the Networks Snort Should Inspect and Whitelist
            Home Net is passlist_srvips
            External Net is Default
            Pass List is a list of IP from some of my clients

            The INTERFACE SETTINGS tab is the one that opens when you edit a Snort interface in the package GUI. The settings you show above should be correct.

            Are you not getting alerts or not getting blocks? If you are not seeing alerts, have you cleared the snort2c table? If the IPs were placed in snort2c by the previous Snort instance when it was running on the WAN, and if you have not cleared them, they will still be enforcing and therefore blocking the traffic inbound from the WAN and it will never reach the LAN to be seen by the new Snort instance there.

            Snort "blocks" by using a system call to populate the snort2c pf table. That table is referenced by a hidden built-in pfSense rule to block any source or destination IP that resides in that table. The table is only cleared by a reboot, by manual user action, or by a cron task if you have configured that on the GLOBAL SETTINGS tab via the "Remove Blocked Hosts" option.

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

              @bmeeks said in pfSense and Snort DDOS and syn flood:

              @jmanatee said in pfSense and Snort DDOS and syn flood:

              Currently I have
              In Snort Interfaces -> WAN Settings -> General Settings -> Interface I have WAN

              In Snort Interfaces -> WAN Settings -> Choose the Networks Snort Should Inspect and Whitelist
              Home Net is passlist_srvips
              External Net is Default
              Pass List is a list of IP from some of my clients

              The INTERFACE SETTINGS tab is the one that opens when you edit a Snort interface in the package GUI. The settings you show above should be correct.

              Are you not getting alerts or not getting blocks? If you are not seeing alerts, have you cleared the snort2c table? If the IPs were placed in snort2c by the previous Snort instance when it was running on the WAN, and if you have not cleared them, they will still be enforcing and therefore blocking the traffic inbound from the WAN and it will never reach the LAN to be seen by the new Snort instance there.

              Snort "blocks" by using a system call to populate the snort2c pf table. That table is referenced by a hidden built-in pfSense rule to block any source or destination IP that resides in that table. The table is only cleared by a reboot, by manual user action, or by a cron task if you have configured that on the GLOBAL SETTINGS tab via the "Remove Blocked Hosts" option.

              Currently I am on the WAN interface and Oh boy I am getting alerts and blocks My syn flood rule was so busy I couldn't see any other alerts. The snort2c table had 86k ips in it.

              This is what I am trying to solve. I have now blocked the bulk of bad actors in the firewall but the alerts are still coming in so I guess the best solution is to move to the LAN interface but when I tried my rules stop working....

              Should the External Net list be identical to the Home Net list?

              Do you have suggestions on how to correctly populate the Home Net and External Net lists?

              I am foggy on src vs dst with snort on LAN vs WAN

              On the WAN interface inbound traffic the src IP is the public IP

              On the LAN interface inbound traffic is src the public IP or the virtual ip or the NAT IP?

              If on the LAN side and traffic is coming in to the server (Syn request) is that src? Is my servers ACK response src

              So confused...

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

                @jmanatee said in pfSense and Snort DDOS and syn flood:

                Should the External Net list be identical to the Home Net list?

                No, those two should not be identical. The IP addresses listed in EXTERNAL_NET should have a "!" character in front of each of them to signify the logical NOT operator. At first glance they may look the same, but examine closely for the "!" character. If it is missing, then something is not right for sure.

                @jmanatee said in pfSense and Snort DDOS and syn flood:

                On the LAN interface inbound traffic is src the public IP or the virtual ip or the NAT IP?

                It should be the Virtual IP if I understand your setup correctly. Using an example INBOUND packet from the bad guy, here is how it will flow:

                Bad Guy on web --> pfSense WAN port interface --> WAN pf rules --> LAN pf rules (if present) --> Snort --> LAN port interface --> LAN client

                If I understand your setup correctly, then the Snort instance on the LAN is going to see the "bad guy's IP" as one of your 1:1 NAT virtual IPs. That's because the NAT processing is happening within pf on the WAN interface as the traffic enters that interface.

                When you have Snort on the WAN, remember it is going to see the traffic before pf does, so no NAT has taken place at that point for inbound traffic. But on the LAN instance, the WAN's pf rules have already acted on the inbound traffic from the bad guy and it has been processed through NAT and any "deny" rules that were present on the WAN.

                You will probably need to remove your Virtual IPs from the Pass List if you want to block the traffic when running Snort on the LAN. Run a packet sniff on the LAN to see what is actually coming across in terms of IP addresses. You can do that under DIAGNOSTICS in the pfSense menu.

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

                  @bmeeks said in pfSense and Snort DDOS and syn flood:

                  @jmanatee said in pfSense and Snort DDOS and syn flood:

                  Should the External Net list be identical to the Home Net list?

                  No, those two should not be identical. The IP addresses listed in EXTERNAL_NET should have a "!" character in front of each of them to signify the logical NOT operator. At first glance they may look the same, but examine closely for the "!" character. If it is missing, then something is not right for sure.

                  @jmanatee said in pfSense and Snort DDOS and syn flood:

                  On the LAN interface inbound traffic is src the public IP or the virtual ip or the NAT IP?

                  It should be the Virtual IP if I understand your setup correctly. Using an example INBOUND packet from the bad guy, here is how it will flow:

                  Bad Guy on web --> pfSense WAN port interface --> WAN pf rules --> LAN pf rules (if present) --> Snort --> LAN port interface --> LAN client

                  If I understand your setup correctly, then the Snort instance on the LAN is going to see the "bad guy's IP" as one of your 1:1 NAT virtual IPs. That's because the NAT processing is happening within pf on the WAN interface as the traffic enters that interface.

                  When you have Snort on the WAN, remember it is going to see the traffic before pf does, so no NAT has taken place at that point for inbound traffic. But on the LAN instance, the WAN's pf rules have already acted on the inbound traffic from the bad guy and it has been processed through NAT and any "deny" rules that were present on the WAN.

                  You will probably need to remove your Virtual IPs from the Pass List if you want to block the traffic when running Snort on the LAN.

                  When reading about Snort when I first set this up years ago I was under the impression you put Snort on WAN to protect from outside threats and you put Snort on LAN to protect from things like maleware or viruses already inside trying to reach outside. This is a very basic understanding I have

                  Would snort on LAN see the public IP of the bad guy? Could snort on LAN block it or would it only see the virtual IP or NAT IP If this is in fact the case I have to leave Snort on WAN

                  Interestingly the bulk of these IPs are coming from Brazil so I used pfBlocker to geoip block Brazil the attack is still occurring I see it in the pfblocker logs but not in Snort alerts. How is pfblocker before snort? I though pfBlocker only added firewall rules.

                  Thanks for the help

                  bmeeksB 3 Replies Last reply Reply Quote 0
                  • bmeeksB
                    bmeeks @jmanatee
                    last edited by bmeeks

                    @jmanatee said in pfSense and Snort DDOS and syn flood:

                    When reading about Snort when I first set this up years ago I was under the impression you put Snort on WAN to protect from outside threats and you put Snort on LAN to protect from things like maleware or viruses already inside trying to reach outside. This is a very basic understanding I have

                    This is not really true. Think about how a packet from the Internet traverses your firewall. It comes into the WAN, hits the WAN firewall rules, then is routed out the LAN or whatever the destination interface needs to be (based on the destination IP). But if you run Snort on that internal destination interface, the packet still must pass through Snort before it can reach the final destination client. Refer back to the diagrams I posted originally in this thread. So, it does not matter where you run Snort in terms of it being able to see traffic flowing to internal hosts. You run Snort to protect your internal clients -- not your firewall.

                    The downside of running Snort on the WAN is two-fold. First, Snort will expend CPU and RAM resources analyzing traffic that the pf firewall rules on the WAN may already be configured to block. You are seeing that issue now when you run Snort on the WAN -- the IPs are in the pf snort2c table and are blocked from reaching your internal hosts, but Snort on the WAN is still expending CPU and RAM resources analyzing that "blocked" traffic. The second downside is that all of your internal hosts will be hidden behind the NAT IP. You will notice that all of the alerts show only your public IP as the "source" or "destination" for any internal hosts. That makes tracking down a malware infected internal host difficult.

                    Running Snort on an internal interface lets the WAN firewall rules filter out the crap initially thus lessening the workload on Snort. It also means internal host IPs are not masked by NAT.

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

                      @jmanatee said in pfSense and Snort DDOS and syn flood:

                      Would snort on LAN see the public IP of the bad guy? Could snort on LAN block it or would it only see the virtual IP or NAT IP If this is in fact the case I have to leave Snort on WAN

                      Yes, in a normal setup (without your 1:1 NAT) Snort on the LAN or other internal interface would see the real public IP of the bad guy. But your 1:1 NAT setup with virtual IPs changes things. Snort on the internal interface is only going to see the virtual IP that resulted from the 1:1 NAT.

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

                        @jmanatee said in pfSense and Snort DDOS and syn flood:

                        Interestingly the bulk of these IPs are coming from Brazil so I used pfBlocker to geoip block Brazil the attack is still occurring I see it in the pfblocker logs but not in Snort alerts. How is pfblocker before snort? I though pfBlocker only added firewall rules.

                        If you are seeing this behavior with Snort running on the WAN, then it does not make sense. Snort definitely sees traffic before the pf firewall when running on the WAN. Now, if you mean Snort running on the LAN, then yes it would make sense as the WAN rules would be filtering the traffic before it gets to Snort on the internal LAN interface.

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

                          @bmeeks

                          For now I will leave it on WAN and over time setup a virtual sever to test and play with configuring Snort on LAN

                          Thank you for all the help and taking the time to explain this to me.

                          Jon

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