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

    pfSense and SNORT issue

    Scheduled Pinned Locked Moved IDS/IPS
    10 Posts 3 Posters 1.8k 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.
    • P
      porettoa
      last edited by

      I have SNORT running on pfSense 2.5.2 . I have an on-prem server that use ports 80/443 for the outside world to access. When users from the outside to access the site, it shows as unavailable. If I clear the BLOCKED HOST, it will work for a few seconds and fail. I created an aliases and added the NAT address, the internal IP and domain name for it and it still seems to get caught by a rule. I have other on-prem servers that work fine for the outside and don’t get caught by SNORT. This is on the WAN interface. How can I fix or determine what rule is causing the block? I reaced out to the SNORT team and they said it's a pfSense issue. Thanks!

      NogBadTheBadN 1 Reply Last reply Reply Quote 0
      • NogBadTheBadN
        NogBadTheBad @porettoa
        last edited by

        @porettoa The Alerts TAB and the GID:SID.

        Screenshot 2021-08-25 at 14.25.48.png

        Andy

        1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

        1 Reply Last reply Reply Quote 0
        • P
          porettoa
          last edited by

          Thanks for the quick reply. When I check alerts I see the NAT that alerted for ET CINS Active Threat Intelligence Poor Reputation IP TCP group 51, 59, 97, 55 etc. When I got to the blocked listed and clear, the site works for a few seconds. Is there away to whitelist the internal server? I tried using the aliases by adding the internal and NAT IP. That did not help. I'm missing a step somewhere. Thanks again.

          NogBadTheBadN 1 Reply Last reply Reply Quote 0
          • NogBadTheBadN
            NogBadTheBad @porettoa
            last edited by

            @porettoa If you click on the [+] it will suppress the rule.

            Andy

            1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

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

              Your problem is the external users accessing your server are coming from banks of IP addresses that are on known poor IP reputation subnets. In other words, those IP addresses are frequently associated with malicious traffic. That's why Snort is blocking.

              I assume that what you are clearing on the BLOCKS tab are external client addresses. Your internal server's IP should not be getting blocked.

              Your only recourse here is to disable the offending rule. On the ALERTS tab, click the red X to disable that rule.

              But I would be quite nervous about this whole setup, to be honest. Why would you want users accessing an internal server from known suspicious IP ranges? But if you don't care, then you will need to disable that rule, and probably many others that check for known suspicious IP domains.

              NogBadTheBadN 1 Reply Last reply Reply Quote 0
              • NogBadTheBadN
                NogBadTheBad @bmeeks
                last edited by

                @bmeeks I just had a look at the ET CINS Active Threat Intelligence Poor Reputation IP TCP group 9 rule:-

                alert tcp [14.128.33.117,14.128.33.125,14.141.174.230,14.141.64.123,14.141.67.86,14.154.28.28,14.165.33.24,14.17.115.56,14.177.234.1,14.180.13.113,14.18.101.26,14.18.96.48,14.189.136.13,14.198.15.220,14.199.110.193,14.2.34.92,14.204.211.122,14.206.50.10,14.21.81.17,14.21.81.66,14.215.165.144,14.215.237.133,14.233.190.4,14.238.12.150,14.241.247.124,14.248.94.208,14.254.217.156,14.29.180.172,14.29.64.43,14.33.65.143,14.4.62.35,14.45.236.40,14.46.35.235,14.53.67.51,14.97.14.222,14.97.41.58,14.99.37.242,14.99.37.244,18.117.254.40,18.118.30.251,18.142.21.55,18.144.80.162,18.159.90.118,18.163.226.242,18.166.73.142,18.181.175.22,18.229.244.82,20.1.2.2,20.105.172.104,20.106.204.50] any -> $HOME_NET any (msg:"ET CINS Active Threat Intelligence Poor Reputation IP TCP group 9"; flags:S; reference:url,www.cinsscore.com; threshold: type limit, track by_src, seconds 3600, count 1; classtype:misc-attack; sid:2403316; rev:68283; metadata:affected_product Any, attack_target Any, deployment Perimeter, tag CINS, signature_severity Major, created_at 2013_10_08, updated_at 2021_08_24;)
                

                I was surprised by the last IP address as the whole of 20.x.x.x was owned by a company I used to work for and sold off a chunk of its IP address space to Microsoft.

                AS details for 20.106.204.50:-
                
                route:      20.64.0.0/10
                descr:      Microsoft
                origin:     AS8075
                notify:     radb@microsoft.com
                mnt-by:     MAINT-AS8075
                changed:    mkasten@microsoft.com 20200721
                source:     RADB
                
                route:      20.0.0.0/8
                descr:      REACH (Customer Route)
                tech-c:     RRNOC1-REACH
                origin:     AS17916
                remarks:    This auto-generated route object was created
                remarks:    for a REACH customer route
                remarks:    
                remarks:    This route object was created because
                remarks:    some REACH peers filter based on these objects
                remarks:    and this route may be rejected
                remarks:    if this object is not created.
                remarks:    
                remarks:    Please contact irr@team.telstra.com if you have any
                remarks:    questions regarding this object.
                notify:     irr@team.telstra.com
                mnt-by:     MAINT-REACH-NOC
                changed:    irr@team.telstra.com 20090917
                source:     REACH
                

                Andy

                1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

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

                  @nogbadthebad said in pfSense and SNORT issue:

                  @bmeeks I just had a look at the ET CINS Active Threat Intelligence Poor Reputation IP TCP group 9 rule:-

                  alert tcp [14.128.33.117,14.128.33.125,14.141.174.230,14.141.64.123,14.141.67.86,14.154.28.28,14.165.33.24,14.17.115.56,14.177.234.1,14.180.13.113,14.18.101.26,14.18.96.48,14.189.136.13,14.198.15.220,14.199.110.193,14.2.34.92,14.204.211.122,14.206.50.10,14.21.81.17,14.21.81.66,14.215.165.144,14.215.237.133,14.233.190.4,14.238.12.150,14.241.247.124,14.248.94.208,14.254.217.156,14.29.180.172,14.29.64.43,14.33.65.143,14.4.62.35,14.45.236.40,14.46.35.235,14.53.67.51,14.97.14.222,14.97.41.58,14.99.37.242,14.99.37.244,18.117.254.40,18.118.30.251,18.142.21.55,18.144.80.162,18.159.90.118,18.163.226.242,18.166.73.142,18.181.175.22,18.229.244.82,20.1.2.2,20.105.172.104,20.106.204.50] any -> $HOME_NET any (msg:"ET CINS Active Threat Intelligence Poor Reputation IP TCP group 9"; flags:S; reference:url,www.cinsscore.com; threshold: type limit, track by_src, seconds 3600, count 1; classtype:misc-attack; sid:2403316; rev:68283; metadata:affected_product Any, attack_target Any, deployment Perimeter, tag CINS, signature_severity Major, created_at 2013_10_08, updated_at 2021_08_24;)
                  

                  I was surprised by the last IP address as the whole of 20.x.x.x was owned by a company I used to work for and sold off a chunk of its IP address space to Microsoft.

                  AS details for 20.106.204.50:-
                  
                  route:      20.64.0.0/10
                  descr:      Microsoft
                  origin:     AS8075
                  notify:     radb@microsoft.com
                  mnt-by:     MAINT-AS8075
                  changed:    mkasten@microsoft.com 20200721
                  source:     RADB
                  
                  route:      20.0.0.0/8
                  descr:      REACH (Customer Route)
                  tech-c:     RRNOC1-REACH
                  origin:     AS17916
                  remarks:    This auto-generated route object was created
                  remarks:    for a REACH customer route
                  remarks:    
                  remarks:    This route object was created because
                  remarks:    some REACH peers filter based on these objects
                  remarks:    and this route may be rejected
                  remarks:    if this object is not created.
                  remarks:    
                  remarks:    Please contact irr@team.telstra.com if you have any
                  remarks:    questions regarding this object.
                  notify:     irr@team.telstra.com
                  mnt-by:     MAINT-REACH-NOC
                  changed:    irr@team.telstra.com 20090917
                  source:     REACH
                  

                  Yep! The vagaries of IP Reputation Lists. Because IPv4 address space is so rare, and thus valuable these days, there is a lot of that space changing hands. What once was legit may become "suspicious", and what once was suspicious may become "legit". The problem is you can't really know for sure.

                  If the OP trusts the list in the ET rule, then I would be hesitant to allow those IP addresses. But if the OP feels (or determines) that the presence on the list is a false positive, then disabling the rule is the only choice.

                  It has to be hard these days to maintain a public web presence. You never know for sure who is "good" or "bad" visiting your site. Best course of action is to be absolutely paranoid about keeping all the web server software updated to avoid exposing known vulnerabilities.

                  Edit: oh, and keep any public-facing servers in a DMZ and securely isolated from your trusted LAN. Treat your DMZ almost the same as you would the Internet.

                  1 Reply Last reply Reply Quote 1
                  • P
                    porettoa
                    last edited by

                    Now that makes sense. The IP address belong to Comcast and Verizon. I verified several with our teaching staff. The odd thing, is those same IP address are accessing other on-prem web servers with no issues.

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

                      You may have other Snort rules firing for that web server. The built-in HTTP Inspect rules can produce a lot of false positives these days. Many modern web servers do not strictly adhere to all the relevant RFCs. The same is true for web clients (browsers) as well. So examine your ALERTS tab carefully to see if any of those HTTP Inspect rules are firing. You likely will want to disable lots of those. Many folks use the SID MGMT tab features to list the GID:SID identifiers for those rules, and put those identifiers in a disablesid.conf file and assign it to the applicable Snort interface.

                      I don't know your experience level with running an IDS/IPS. If you are new to doing this, then you most certainly do NOT want to start off with blocking enabled. You will get lots of nuisance blocks from false positives while you tune your ruleset. Better to do all of that while blocking is disabled.

                      Tuning an IDS/IPS is a difficult task that takes much experience to do well. I advise admins new to the Snort package to run it in IDS-only mode (with blocking disabled) for several weeks on their network. Examine the logged alerts multiple times a day. Trace each alert to see if it might be a false positive in your network environment. Remember that every alert you see would represent a block event when blocking is turned on. And that block either prevented an internal user from going to their desired destination, or it prevented an external user from accessing an internal resource.

                      Once you are confident you have tuned your ruleset to reduce or eliminate false positives while still protecting against valid threats to your internal network, then you can enable blocking mode.

                      1 Reply Last reply Reply Quote 1
                      • P
                        porettoa
                        last edited by

                        It was the HTTP inspect rules. Thanks for the help!

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