@chc-pr:

Hi Bill. Thanks for your help. /tmp only has mnt and snap as subdirectories …

is /tmp part of a longer path?  Thanks

No, it is directly off the root but I forgot about something in my earlier reply.  When the update process completes (even if unsuccessful), it deletes the temporary sub-directory it created to hold the downloaded gzip rules archive.  So you will not see it except during the interval the rules update process is running.

Still, though, how much free space is showing?  Getting MD5 errors on VRT, Coummunity and ET archives is a rare occurrence.  Is there anything unusual in your setup such as a proxy (Squid, for example)?

Bill

I guess I didn't mention that pretty much the same thing happened on the primary as well…

Ok.  I'll put it on a test bed and do the upgrade again to see if I can replicate it and this time check the config.xml.

Thanks again

Dino

@techbee:

It seems that my location is blacklisted on their firewall and that causes the "Block reason: Gateway GEO-IP Filter Alert"

Well, unless you can get them to whitelist your IP address; you won't be able to use the OpenAppID feature in the Snort package unless you create some of your own rules.  There are a few examples of user-written OpenAppID rules here in the IDS/IPS sub-forum.  You could try a search for "OpenAppID" to see what turns up.  There are also a few examples to be found with a Google search.

Bill

@gc75:

Hello all,

I'm having this problem with the latest snort update:

Jun 10 15:01:32 php-fpm 3909 /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 3825 -D -l /var/log/snort/snort_re03825 –pid-path /var/run --nolock-pidfile -G 3825 -c /usr/local/etc/snort/snort_3825_re0/snort.conf -i re0' returned exit code '1', the output was ''

Jun 10 15:01:32 snort 17998 FATAL ERROR: /usr/local/etc/snort/snort_3825_re0/snort.conf(6) !any is not allowed in EXTERNAL_NET.

Who helps me?

# Define Local Network # ipvar HOME_NET [0.0.0.0,8.8.4.4,8.8.8.8,127.0.0.1,192.168.1.1,192.168.1.99/24,192.168.1.100,192.168.2.0/24,192.168.3.0/24,::1,fe80::1:1,fe80::20d:b9ff:fe3c:b614,fe80::20d:b9ff:fe3c:b615,fe80::f6f2:6dff:fe7e:a976] ipvar EXTERNAL_NET [!0.0.0.0,!8.8.4.4,!8.8.8.8,!127.0.0.1,!192.168.1.1,!192.168.1.99/24,!192.168.1.100,!192.168.2.0/24,!192.168.3.0/24,!::1,!fe80::1:1,!fe80::20d:b9ff:fe3c:b614,!fe80::20d:b9ff:fe3c:b615,!fe80::f6f2:6dff:fe7e:a976]

Something in your setup is returning a null address.  The problem entry is "!0.0.0.0" in the EXTERNAL_NET declaration.  That is coming from some interface, DNS server, VPN or VIP.

Bill

I use the default admin profile and had the same issue so that's not likely the problem.

Two things are necessary for OpenAppID to function.  First, the OpenAppID preprocessor must be enabled within the Snort binary.  That happens when you check the OpenAppID Detector box on the PREPROCESSORS tab.  The second thing that has to happen is the preprocessor you just enabled needs some rules to know what apps to look for.  Those get downloaded from a third-party repository (currently hosted in Brazil I believe).  You enable the OpenAppID rules download on the GLOBAL SETTINGS tab.

The Snort VRT folks don't publish their own set of OpenAppID rules.  You either have to write your own or find a third-party site.  A contributor volunteered last year to provide a package of common OpenAppID rules and to host them on a University web site.  That's the Brazil site (if I am remembering the location correctly).  The URL is hard-coded in the GUI code and was provided by the contributor.

Bill

@djseto:

Thanks for the info.

bmeeks, I was looking at your sticky post: Quick Snort Setup Instructions for New Users and post #3 has a response about disabling rules vs. using suppression lists. Is disable vs suppress one of those religious debates where there isn't a right or wrong answer ?

With today's highly capable hardware, "yes" it is sort of a religious debate.  If you have super heavy traffic loads or marginal hardware for the task (low memory, slow CPU, etc.), then disabling is better than suppressing.  Just be careful and don't willy-nilly disable flowbit required rules.  Search for "flowbits" in this sub-forum to find some of my responses to others about the importance of flowbit rules.

Bill

Wow. I tried the search and even hit Google and got nothing. Thanks for the info.

Through trial and error, I decided the best way is to set the filtering on high and expect to investigate false positives for a few weeks.

Snort enables you to easily allow exceptions at a granular level directly from the alerts page. Anything with a '1' is suspicious. If it involves port 80 and, for example comes from Google or Akamai, it's probably OK and you can put it through there. But look into it a little first. I have found the need to suppress full rules not needed as badly with this approach.

I'm seeing a lot of this now as well.  Seems to all be originating from one machine running Storjshare. I tried increasing the Flow Memory Cap, but so far that hasn't accomplished anything. It's at 256MB at the moment.

edit I tried restarting Suricata on the LAN interface, and now it refuses to start even after resetting things back the way they were.  :o
edit2 Needed to remove commas from the byte sizes in flow and stream memory cap.  pfSense should automatically parse this or at least return an error if you attempt to provide invalid input parameters.
edit3 I'm not certain whether it was necessary to completely restart Suricata on the interface for the setting to take effect, so it's possibly that my current 512MB setting is way more than necessary, but it's stopped the error messages, so I'm going to leave it alone for now.
edit4 Nope.  Up to 1GB and still receiving this error.  I don't think increasing the flow memory cap is a solution.
edit5 I noticed that there's a separate Flow/State Memcap setting under LAN App Parsers -> DNS App-Layer Parser Settings.  The default is only 512KB.  I upped it to 1MB and reset the Flow Memory Cap setting to its default.

@coffeecup25:

@bimmerdriver:

So, the snort service stopped again.  Am I the only one this is happening to?

https://forum.pfsense.org/index.php?topic=130993.msg723503#msg723503

No. I also complained. The thread this link is in mentioned a possible third reason it fails to start properly. To me, it looks like a buggy upgrade as it worked great before updating pfSense and snort to the newest versions. Right now, I have snort disabled. I will enable it when I see a new package update for it being made available.

Getting the exact behavior here on my APU2C4 since the upgrade.

Were you able to get this working ever?

I only get a sample log like such to my syslog server from using the barnyard2

May 31 01:42:38 pfsense.rando.local nginx: 10.0.0.3 - - [31/May/2017:01:42:38 +0000] "GET /css/pfSense.css HTTP/1.1" 200 7239 "https://10.0.0.1/snort/snort_barnyard.php?id=0" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36"

I don't actually get the snort alerts…if I turn it to log to the pfsense system log, it works fine but I want it to be a separate log.

I used to have an "SuricataWhitelist" alias containing hosts (also alliasses). Now it's type is "networks" (old hosts aliasses are still there).
So this has changed. Maybe this is causing the blocks since the last version?

nevermind, solution and explanation can be found here:

https://forum.pfsense.org/index.php?action=profile;area=showposts;u=17262

There are issues with Inline mode and many NICs.  The links provided to another thread here on the forum provides the evidence.  The problems with Inline IPS mode are related to compatibility issues between various NIC drivers and the Netmap module.  This is complicated even further on pfSense because some things done to help with limiters seem to have a negative impact on Netmap.  In short, if you have problems with Inline mode it is almost certainly due to something with your specific NIC driver and Netmap.

There is a known issue with traffic shaping on pfSense and Netmap (that's the limiter thing mentioned above).  Those two absolutely don't play well together at this point.  Things will eventually improve as Netmap bugs are ironed out.  Until then, you may have to be content with Legacy Mode blocking.  Usually em drivers are OK, so do you by chance have a traffic shaper enabled?  If so, try disabling it and see if Inline mode works then.

Bill

Either of these two methods would be correct for syntax –

#DHCP Guest Range suppress gen_id 0, sig_id 0, track by_src, ip 192.168.20.10/28 #DHCP Guest Range suppress gen_id 1, sig_id 0, track by_src, ip 192.168.20.10/28

The first will apply to all Generator IDs and SIDs, while the latter will apply only to generic rules and not to other preprocessors.

Exactly how are you assigning the Suppress List you created to the interface?  I assume you know that after creating a manual Suppress List, you then have to go to the INTERFACE SETTINGS tab for the interface where you want to use it and assign it to that interface.  You do that by selecting the named list in the drop-down box in the Suppression List section.  Save the change and then restart Snort on that interface.  Simply creating the list on the SUPPRESS tab is only 50% of the work.

Another possibility is you have multiple Snort instances running on the same interface.  Run this CLI command to make sure only a single Snort instance is running on each configured interface:

ps -ax |grep snort

Bill