@powerextreme said in SNORT ET Alerts: can I set up snort to just capture when this rule is triggered? Or will it do it for all rules? No, the PCAP capture option is not rule specific. It would be for all rules. The easiest thing might be to just kick off the backup job on the Synology again and capture the traffic on the LAN interface (or whatever interface it is traversing) directly on pfSense using the network caputure feature under DIAGNOSTICS on the menu.

After some further reflection, I decided to go back to running Snort in legacy (pcap) mode for now. I was able to try out Suricata as well for comparison, but after some initial testing in inline mode I saw similar throughput limitations. Given the interesting asymmetry I saw in upload and download speeds, I plan to revisit inline mode in Snort once pfSense 2.5 is released and there is support for multiple host rx/tx rings to see if that will help improve (upload) throughput.

@buggz said in Performance on IDS/IPS: Was this change on both the WAN and LAN, or just the Snort interface, which for me is LAN. Thanks! Both. (all)

@5cub4f1y said in Suricata Not Starting, Blank Log File: It won't let me edit any post older than 3600 seconds. Oh well. Anyone viewing this will obviously be able to tell its resolved anyway, and working like a charm. :) Let me see if it will let me change it. I am supposedly a moderator for this sub-forum. Edit: Yep, let me do it.

And you get really good info ones like: 1:2009968 # Potential Corporate Privacy Violation - Src.192.168.2.45:27960 Dest.68.232.172.16:27960 ET P2P eMule KAD Network Connection Request(2) Though this is showing I am the Source? Hmm, time to thorough scan... Haha, that WAS me, playing Enemy Territory. BUSTED! hehe...

No, if you have the package installed and one or more interfaces with Enabled checked on the INTERFACE SETTINGS tab, then the system will attempt to start the services at boot. The only way to prevent that is to go to the INTERFACES tab, select a Suricata or Snort interface, and then edit it. On the INTERFACE SETTINGS tab uncheck the Enable checkbox to disable that interface. That will prevent it from starting on future boots. Of course you can delete the entire Suricata or Snort instance on the interface as well using the Delete icon.

Questions about Snort 2.9.x support would need to be directed at the Snort team over at Talos/Cisco. My guess is no new features will get into Snort 2.x, but critical bug fixes might be addressed going forward after Snort3 goes full release. Of course it's been many years since any really new feature was added to Snort 2.x. I think the last big one was OpenAppID. You would run Snort3 on pfSense just like you would run it on any other Unix-type system. Install the binary, hand-edit the necessary configuration file or files, install the rules manually using something like PulledPork or other tools, and then either create your own or use any provided shell script to start Snort3. There would be absolutely no GUI interfacing at all. No logs to see in the GUI, no configuration in GUI, and no control from the GUI. As for netmap support, that actually depends on the shared DAQ library produced by the Snort team. There is a new version of DAQ used in Snort3. I do not know for sure, but I don't believe they have imported support into the Snort3 DAQ for software host rings. I think it is still limited to supporting only hardware rings. That means you can't set up Snort3 to sit between the NIC and the host stack like you can with Snort 2.x and the older DAQ-2.2.2 that I modified. So netmap will work, but to do anything meaningful with it in pfSense will require you to use two physical interfaces on the box in order to implement a true inline-IPS mode. Not very interface efficient for sure. And finally, unless you use two physical interfaces as mentioned above, there would be no blocking with Snort3 on pfSense. It would be IDS only. No IPS as there is no custom legacy blocking output plugin for Snort3.

@p54 said in URLHaus - Anyone have a mod already?: for me it does not work at all according to the instructions linked above. just i overwrite the custom.rules with the following script: #!/bin/sh fetch -o /usr/local/etc/suricata/rules.local/urlhaus_suricata.tar.gz https://urlhaus.abuse.ch/downloads/urlhaus_suricat a.tar.gz tar xvfz //usr/local/etc/suricata/rules.local/urlhaus_suricata.tar.gz -C /usr/local/etc/suricata/rules.local/ rm /usr/local/etc/suricata/rules.local/urlhaus_suricata.tar.gz rm /usr/local/etc/suricata/suricata_32296_igb1.300/rules/custom.rules mv /usr/local/etc/suricata/rules.local/urlhaus_suricata.rules /usr/local/etc/suricata/suricata_32296_igb1.300/rules/cus tom.rules chown root:wheel /usr/local/etc/suricata/suricata_32296_igb1.300/rules/custom.rules chmod 644 /usr/local/etc/suricata/suricata_32296_igb1.300/rules/custom.rules under cutsom.rules was nothing to see and after the refresh the custom.rules had shrunk to 0 kb :/ anybody still some tips for me? BR Guys, Snort and Suricata on pfSense are GUI applications! That means everything is configured within the GUI, stored in the config.xml of the firewall, and then written out to the pertinent configuration and rules files each time Suricata or Snort is started. So all those changes you make via a CLI session are immediately overwritten the instant you go back into the GUI and start Suricata or Snort. Custom rules must be entered from the RULES tab in the GUI. They are then stored in config.xml as Base64-encoded text. That text is read back out and written to the custom.rules file each time the GUI is used to start Suricata or Snort. If you absolutely must have those rules, then you have to make an edit to the PHP source code files of the package. And be aware that change will be overwritten the next time you update or otherwise reinstall the package. You will need to manually edit the file /usr/local/pkg/suricata/suricata_yaml_template.inc and include a path to your URLHaus rules file in that template. The template is used to create the suricata.yaml file for each interface. Be warned that if you are not familiar with PHP coding syntax, you can very easily break your Suricata installation.

Thanks guys to you both. In fact, I actually looked through the rule sets in more detail over the last couple of days and noticed quite a number of rules that wouldn't be applicable in my particular case, which is just a standard home network. For example, there are number of rules specifically for mail servers which wouldn't be needed (I don't run any mail servers). Since the traffic would be dropped by the firewall anyway there's no need to have it go through the Snort detection engine first and occupy CPU cycles unnecessarily. Anyhow, I was able to grab the relevant rule GID and SID's and add them to the disable list under SID Management. Rebuilt the rule set for the interface(s) and showed up disabled as expected.

@powerextreme said in SNORT Alerts and Interfaces: @NogBadTheBad I have a similar rule earlier in the thread. How does your's effectively differ? You didn't post the whole picture with the pass sections. Why just not log the blocks to a syslog server, I send my logs to the syslog server on my NAS. Check out TCP port 7000:- https://www.speedguide.net/port.php?port=7000

There is, I believe, a Snort Subscriber Rules mailing list you can subscribe to. Search for it on Google. You might find an answer to your question there. I suspect anyone can submit a rule to the Snort team for consideration and inclusion in their set of rules. And I would expect an organization such as CISA (US-CERT) to have considerable clout with the Snort rules team.

Go do some Google research on flowbits in Snort (and Suricata uses them as well). They are the mechanism that allows a sort of primitive "state engine" to be created by rules so that some additional logic can be applied, Here is an example I have used in the past to explain what flowbit rules are all about. Suppose there is a given exploit that comes down only in PDF files. Rules would detect the exploit code by doing pattern matching on the content of packets. So when a rule saw the matching content in a packet (or several packets if the exploit payload is large), then it triggers. But a pattern is simply a collection of bits either turned on or turned off. In this example, the pattern is only malicious when it is contained within a PDF file. It would certainly be possible for other types of files to by sheer chance contain the same pattern. One possibility might be a simple GIF image. So how can the rule know what type of file is being downloaded so that it can only trigger when it detects the pattern in a PDF? This is where flowbits come in. You have flowbit rules that sense different types of activity (PDF file download, Chat session opening, etc.). These rules then set bit flags that other rules can later examine to see what's happening. When you have rules that check certain flowbits before alerting, and those flowbit rules are not enabled, then the "checking rule" will never fire because its flowbit logic check will fail. Consider my earlier example of the PDF file download. If the flowbit that says "PDF download in progress" is not set, then my malicious payload detection rule won't fire because it will check the "PDF download" flowbit before firing. So the idea behind auto-flowbit rules is that the Snort GUI application will determine what flowbit rules are required by the active rules you have selected, and then it will make sure those flowbit rules are activated. Any rules it automatically enabled will be listed in the Auto-Flowbits category on the RULES tab. The Snort Subscriber Rules always tag their flowbits rules with the "no-alert" keyword so that the rule fires and sets the appropriate flowbit, but it does not generate an actual alert. The Emerging Threats folks for some reason fail to do that. They do not put the "no-alert" keyword in their flowbit rules. Thus their flowbit rules will trigger actual alerts as well. That is why you are getting the block from that ET-Chat rule that is listed in the Auto-Flowbits category. Your best course of action with those ET-Chat rules that got sucked in by the auto-flowbits logic is to suppress them by GID:SID. That will prevent the actual alert and thus the block, but it won't prevent them from setting the appropriate flowbits.

@bmeeks Complicating the issue the other folks upstream is HardenedBSD 12.1.

Thank-you @bmeeks for the learning experience. Bumping the memory alloc to 128GB solved the problem. Best regards!

What version are you running, I'm on 3.2.9.14_1 and it looks fine here. [image: 1600114547736-screenshot-2020-09-14-at-21.13.43.png]

Okay, gotta setup cert. and setup MITM Transparent SSL in Squid. I just loaded LightSquid, wow.

@1OF1000Quadrillion I would use a DMZ ... this reference will help you: https://www.youtube.com/watch?v=QFk5jX-oeSo

So before we start, my problem was that my default $HOME_NET wasn't anywhere near broad enough, because of the configuration of my network. My network is fully NATed and includes all RFC1918 addresses, so since those RFC1918 hosts that are on non locally-attached networks are creating the traffic I want to inspect, and the default $HOME_NET is just locally attached networks, I did the following. If this isn't your problem, this won't help you, but here we go: I went to Firewall - Aliases and made an alias called InternalIPs that contained the RFC1918's: 172.16.0.0/12, 10.0.0.0/8, 192.168.0.0/16 I went to Services - Snort - Pass Lists tab and created a new pass list , checked off all the auto-generated IP Addresses, and added my InternalIPs alias by name in the "Assigned Alias" field I then went to the Snort Interfaces Tab (under Services - Snort still) and under general settings for the relevant interface (LAN in my case), in "Home Net" under "Choose the Networks Snort Should Inspect and Whitelist" I chose the pass list I created in step 2, and also clicked "View List" and verified that all the networks I wanted to inspect traffic from were included. Save and then go back to Snort interfaces, stop and then start snort and see if stuff starts showing up. Of course also check the normal stuff - both Sourcefire OpenAppID Detectors options checked off in Global Settings, up-to-date AppID signatures in the Updates tab, you've got the right rulesets selected in the <Interface Name> Categories tab, and you've got both options under Application ID in the <Interface name> Preprocs tab checked off. Hope this helps!