That "3" in the output is the Priority. The Snort implementation on pfSense uses the CSV output logging option of Snort to produce the alert log. The code within the GUI knows which CSV field is which in the alert log output. You can't add any additional text to the CSV output.

Yep, you will find that OpenAppID generates a lot of noise. I would suggest carefully pruning the rule categories so that you are seeing only the specific traffic types you want to eliminate. For example, maybe Facebook stuff in a corporate network. OpenAppID will generate a lot of log alerts and will tend to completely dominate the info on the ALERTS tab. Unfortunately there is no way within the Snort binary at present to have OpenAppID log to a separate log file so those alerts could be isolated from all the others.

Glad you figured out a novel solution. I am surprised that Suricata does not complain about the duplicate output sections in the suricata.yaml file, though. I've never investigated the parsing portion of the YAML code in the binary, so maybe it's the case that the last value read from the file is the one stored in the in-memory configuration array (overwriting any previous value for the same parameter). I would expect the ALERTS tab in your custom configuration to be blank and not showing any alerts. As I said in my earlier reply, the alerts.log file is how that tab gets populated in the GUI. You will still see any alerts in the other configured output logs, though, such as EVE.

Thanks.

Hi, I am able to implement Suricata-Redis architecture. Please let me know whether we can use Redis-sentinel feature at Suricata Config block. Because my application will be required redis failover support so if I can also configure Suricata with Redis Sentinel then it would be the best for me. Shubham

It seems that the changes I made via the web/browser wasn't taking despite it saying so; however, when I made the changes (sysctl dev.netmap.buf_size:4096) at the shell on the machine itself, I haven't seen any more alert. I'll keep my fingers cross!

Solved upgrading to pfSense 2.4.4 Thank you

@bmeeks Thank bmeeks. I agree that the alerts can be overwhelming. To that effect, I have a rule set up to put alert e-mails into a particular folder so they don't pummel my Inbox. This is something I wanted to set-up for a few days, more of an observation than anything else. Thanks for taking the time to reply, your answer gave me a little better understanding of the architecture of pfSense.

At least, enable signature logging in Snort. Then, you'll see what blocking signatures (if any) are being blocked and could ignore/suppress those.

@siil-it So the Snort SO rules are the only ones that don't survive the SAVE operation? Do you have the latest Snort package version? That would be 3.2.9.7_2 if my memory serves me correctly. Might be a bug in the GUI code. Several changes have had to be made to the GUI source code in order to accomodate the move to PHP 7.2 in pfSense.

@teamits is correct. The ALERTS tab will list SRC and DST addresses for detected alerts. He is also correct on which IP will show depending on the chosen interface on which to run Snort. I recommend running Snort on the LAN interface. That way you can see internal addresses before NAT rules are applied (in the case of outbound traffic) and after NAT rules are removed (in the case of inbound traffic from the Internet). On the WAN, all local IP addresses behind NAT will just show up as having your public WAN IP. That's not useful for tracking down which internal host has a problem. You should pretty much always let Snort block both SRC and DST IP addresses to be confident the bad traffic is stopped. Anti-virus software has no bearing on this. It detects different things and misses other things. For example, anti-virus software won't detect buffer overflows in your web browser or services. Basic anti-virus software examines executables as they run (or right before), but it does not examine network flows/streams like a true IDS/IPS such as Snort or Suricata.

Thank you, Bill.

@bmeeks Thank you for your candid answer bmeeks. Duly noted and will not be attempted.

Have you made a pass list yet?

Thanks for the responses! It is interesting as I just installed the Snort package the other day so I THOUGHT it would be the most up to date. If the problem was with the OINK code, then it makes sense that the error would be different also. The 505 code makes it seem like the client cannot speak with the server properly to get the ruleset. Perhaps it was the time of day - something wrong on the server end with retrieving the file. I'll have to try again later.

@stalemartyr said in Snort newbie : LAN Interface Destination IP setup: Good day, I recently configured a pfsense in our office and enabled snort package. I configured LAN interface and noticed that all the alerts traffic is from local network to internet i.e. 192.168.1.105 => [external ip address], can I configure it so that it will also show suspicious traffic from router to lan network? [external ip address/pfsense] => 192.168.1.105. Thanks! It should already be doing that if such traffic exists. Remember that by default the WAN on pfSense is configured to block all unsolicited inbound traffic. That means your LAN interface will never see something unsolicited from the Internet (say a connection attempt to SSH or something unless you have port forwarding enabled, and enabling port forwards is generally not a secure practice -- use VPNs instead for external connections to your LAN).