pfSense and SNORT issue

porettoa

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!

NogBadTheBad

@porettoa The Alerts TAB and the GID:SID.

Screenshot 2021-08-25 at 14.25.48.png

porettoa

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.

NogBadTheBad

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

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.

NogBadTheBad

@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

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.

porettoa

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.

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.

porettoa

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