@jeffh:

Thanks fsansfil, that looks good, but it looks like there might be one more column.

Between the DPort and Class columns I have a column with large numbers. These numbers don't appear in the Alerts in the GUI, so I am having a hard time matching them up.

Any help would be appreciated.

That is the IP Header ID field.

Bill

@fsansfil is spot on with his answer.  You will find all the files in the /var/log/snort tree.  In that tree there will be a subdirectory for each configured Snort interface.  The name will be a combination of a GUID and the physical interface name (for example, em0 is one if you have an older Intel NIC).

Bill

@RayP:

The old firewall didn't load, but didn't give the same error.  I re-downloaded the AMD image and tried to load again.  The previous error is gone, but now it's stopping at "Additional Files…" with a failed message.  Since it's a new problem I'll look for a new thread that is related.

Thanks for the help.

If it fails at the "additional files…" part, that would indicate some kind of problem downloading files from the package repository server.

Bill

Oh…and one other small point.  Each time you update the Suricata package (or it gets reinstalled as part of a pfSense update), you will need to repeat the hand-edit of that /usr/local/pkg/suricata/suricata_yaml_template.inc file because it will be overwritten when Suricata is reinstalled.

Bill

Never mind… looks like it might've been something else...

From the system log...

Mar 28 14:48:45 php-fpm[44942]: /pkg_mgr_install.php: XML_RPC_Client: Connection to RPC server packages.pfsense.org:443 failed. Operation timed out 103 Mar 28 14:48:45 php-fpm[44942]: /pkg_mgr_install.php: XMLRPC communication error: Operation timed out

Another attempt a bit later worked just fine.

@jeffh:

That worked perfectly, thanks!

Glad it worked.  I added that feature a few revisions back, but it has not gotten a lot of use yet so far as I can tell.  It offers an easy way to manage rules using various lines in the enablesid.conf, disablesid.conf and modifysid.conf files.  It can work with just SID values, or you can also use regular expression matching.  This functionality was ported over from the Oinkmaster and PulledPork utilities.

Bill

@2chemlud:

Hi!

No, I had an eye on the RAM on the Dashboard, nothing went out of control. And the problem is apparently at the end of the procedure (snort is there and running, only not included in the GUI), while reinstalling the rules sets for the interfaces.

It worked fine during the update from 2.1.5 to 2.2 and from 2.2 to 2.2.1 on all three boxes. But this time…

Kind regards

I don't mean necessarily RAM as in free system memory, but rather free space on the RAM disks used for the various system partitions.  These can be filled during the package download and unpacking process.  You would really have no way of seeing them run out unless you were monitoring them in a shell session while the package installation happened in the GUI.  After Snort starts up during the installation process, it returns control to pfSense where the package manager code of pfSense completes the installation.  This last step, done by pfSense itself and not the Snort package, is where the menu entry is created under SERVICES.  That step frequently dies for some reason on Nano installs.  I think it is because of RAM disk exhaustion.  Some other users have been able to get successful installs by manually increasing their RAM disk partition sizes.  For example, increasing /tmp to 300 MB (or at least 100 MB) in size.  That is the directory partition where the package downloading, unpacking, and other temp file creation happens.  By default it is somewhat small on Nano installs.

Bill

@ghostshell:

What problems would this cause? I did do an uninstall, reboot and then reinstall. If there maybe any issues at all I would like to know so I can do a fresh install.

If your reinstall was successful, then things are OK with Snort.  If it shows up in the SERVICES menu and start normally, then it is OK.

Bill

@trvsecurity:

Sorry to be a pain, but where in the pfsense sirectory structure can I find that file so that I can edit it?

It will be in /usr/pbi/snort-amd64/etc/snort/appid/odp/libs/DetectorCommon.lua.  This is assuming you have a 64-bit install.  If you are on 32-bit architecture, change the amd64 to i386 instead.

Remember that each time the auto-update process brings down a new version of OpenAppID rules, it will wipe that directory and reload it.  So any edit to that file will be lost.  On the other hand, maybe the VRT will actually fix the problem in the next update and hand editing won't be necessary.

Bill

@trvsecurity:

This problem started with the previous version of Snort and forums said that it would be fixed however the pfsense system logs continue to fill up with the following error:

snort[12893]: server /usr/pbi/snort-i386/etc/snort/appid/odp/lua/service_EIP.lua: error validating …i/snort-i386/etc/snort/appid/odp/libs/DetectorCommon.lua:318: table index is nil

Anyone have a fix for this? Any help would be much appreciated!

See temp fix posted by another user here: https://forum.pfsense.org/index.php?topic=89393.msg499494#msg499494

PPS:

Wanted to have a look at the firewall logs, but apparently size is fixed to 500 kB, and the log was filled with nonsense "allow multicast" messages (IGMP 224.0.0.22 and stuff like that, no rule indicated why this nonsense is logged…), so that all relevant info from yesterday is gone.

I tried to find the place where I can increase the log-size, but without success... Any suggestion where to increase the size of the log files?

Many thanx in advance!

chemlud...

Found it! Increased log size, but it still logs this 224.0.0.22 IGMP although I have for more than a year now an "allow" rule for that without (!) logging (to stop flooding the logs), but pfSense simply doesn't care and logs this traffic anyway. Don't know what to do with that....

PPPS: Erased the allow rule for IGMP from LAN to 224.0.0.22 and set it up newly, but again this traffic was in the log file. Switched to "block" and now it subsided... Strange....

The update has been approved and posted.  See the Release Notes thread in this forum for information.

Bill

After a couple of reboots, Snort started with no errors.

Looking forward to 2.2.2 :D

You guys are GENIUS! Just to take a chance, I disabled IPV6 on my WAN, rebooted, and ba-bam! It's working now! Thanks!  ;D

Hello,

Well if you are refering to the classtype, these are just pre-defined categories with a priority from 1-4

http://manual.snort.org/node31.html

If you want to know what a specific rule is alerting for, youll have to look at the rule it self. In the GUI, go to your snort interface, select the Rules tab, and browse the categories youll be able to select the rule.

Most rule have a reference part with a URL or a CVE number, that could give you some info on what the rule in looking for.

Example:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT_EVENTS MS Office Macro Dridex Download URI Dec 5 2014"; flow:established,to_server; content:"GET"; http_method; urilen:13; content:"/stat/lld.php"; http_uri; fast_pattern:only; content:!"Referer|3A|"; http_header; reference:url,blog.trendmicro.com/trendlabs-security-intelligence/banking-trojan-dridex-uses-macros-for-infection/; classtype:trojan-activity; sid:2019877; rev:2;)

See the reference part ?

F.

Cool, Ill do that, thanks for your support Bill.

F.

I have the same feeling as you. I really do not know how barnyard2 perform with several sensors and do some queries/update.
I definitively have to put some monitoring on the mysql/mariadb database to know exactly what's going on a do better things than "drop the database and reinstall snorby" :)

Maybe barnyard2 itself should produce some alerting info when it sees that there is an issue with the database.

Well, I will start to find some good monitoring solution for mysql and keep you updated.

Romain

The latest pfSense stable release is 2.2.  Upgrade to that, and the Snort package will show up in the Packages listing.  The current Snort version is 2.9.7.0 for the binary and 3.2.3 for the GUI package.

Bill

@thx2000:

Thank you!  The last paragraph was my problem.  For some reason, I assumed when adding the pass list that was modifying the default pass list.  For future reference, what is the recommended procedure for adding hosts to the whitelist?  I'm assuming I just need to update the alias, and restart the daemon on the interface?  Are there any other tricks I should be aware of?

Thanks again.

Yep, update the assigned alias and restart the interface.

I think I will put some notifications and/or extra text on the PASS LIST tab in a future release to make this more clear.  It has tripped up several folks.

Bill

Hi Bill,

No, no duplicates otherwise, just snort alerts (but not, eg. snort startup notices).