@Grunt0307 said in Suricata Log Interpretation: Makes sense, let me ask you this then. I intend to have a DMZ network setup on another interface. If I configured Suricata to inspect my LAN and DMZ interfaces, that will increase the load on the system, correct? I'm assuming it would launch an instance of Suricata for each monitored interface resulting in duplicate data being loaded for each interface. That is correct. Each monitored Suricata interface will be a separate instance, and so resource utilization will increase when monitoring multiple interfaces. You can manage this by limiting the rules applied to each interface to only those needed to protect the assets behind that interface. Refer to my earlier example about mail servers, public-facing DNS servers and so forth. But in the end there is no free lunch. Using a tool like an IPS with rules takes CPU resources. Fortune 500 corporations do this by throwing a lot of really big iron at the problem (servers with lots of RAM and multiple Xeon server CPUs). My first reply about not putting the IPS on the WAN was based on the assumption you had only a WAN and LAN. That's the most common configuration for pfSense users. Some may have a number of VLANs running on say the LAN interface. In that case you can have Suricata run in promiscuous mode to see all the traffic on the interface to help with resource conservation. Promiscuous mode doesn't help with separate physical interfaces, though. I would think that with configuring the NIC's sysctrl settings like those I linked to several replies back, and choosing wisely which rules to enable, that you can achieve very close to linespeed on the SG-5100. Making sure flow control is disabled on the NIC is said to make a big difference.

Make sure you acutally have not enabled any blocking yet. Go to the INTERFACES SETTINGS tab for your WAN and verify the Block Offenders checkbox is unchecked. Save that change and then start or restart Suricata on that interface. See if it starts successfully. Look in the suricata.log file to see if any errors are printed. That file can be found on the LOGS VIEW tab. Select the WAN interface in the Interface drop-down and then choose the suricata.log entry in the Log drop-down. Post back the content of thesuricata.log and also look in the pfSense system log to see what errors may be logged there.

I would not have the GUI make that change everywhere. Only on interfaces with Suricata that are configured for inline IPS mode. I'm pretty sure netmap wants that off, but I will do more research to be sure. This whole business with netmap only comes into play when you choose Inline IPS Mode in Suricata. As for the load error message, that message actually means the netmap TX rings are filled with packets and there is no more room for the incoming packet. It might be due to the fact that hardware NICs have multiple sets of TX and RX rings for handling traffic, but the host OS stack end of the pipe has only a single software ring. So that means it would be possible for the NIC to process more traffic off the wire than the software ring of the host OS stack can handle. I need to research this some more as well. I have been trusting the netmap plumbing within FreeBSD and Suricata to the developers on those sides, and my work was just adding support to the GUI package. As a side note, the pfSense team is currently doing testing in-house with the new Snort Inline IPS Mode I introduced last week. They are helping me sort out the possible throughput and identify any bottlenecks. because I don't have the hardware on hand to do that.

Thank you again for explaining

@cTar -- Good deal. Thanks for the feedback confirmation!

Two great surprises in one day! Thanks again for your work. Bill

@bmeeks It was a DNS issue. After I configured DNS Resolver properly it began to work again.

@OpenWifi said in Snort not blocking P2P IP addresses: @bmeeks Thank you. The screenshots i am attatching are of the current block tab and my network topology respectively. [image: 1558856469990-img_20190526_103409_108.jpg] The highlighted Ips confirm that i enabled OpenAppID feature. [image: 1558856571128-img_20190526_101207_560.jpg] This is the Network topology. Kindly consider the reason as to why i didnot disable DHCP on the ISP router is because the router lacks bridging capabilities and so i decided to port forward some few ports i.e 53(DNS) and 1194(OpenVpn). What is the WAN IP address on your pfSense box? And what is the default route given to the clients hanging off that switch. For that setup to work, you would need your pfSense box to have a WAN address in the 192.168.1.0/24 network and then the LAN be the 192.168.7.0/24 network. Finally, the DHCP settings in the ISP router where you have the DHCP server enabled should handing out your pfSense box's LAN address as the default route to be used by the clients. Does the ISP route have wireless capability? If so, it should be disabled; otherwise it could provide a bypass of the pfSense firewall. I can tell you from the screenshot you posted that the pfSense box and Snort are working correctly. With those IP addresses listed on the BLOCK tab, they will and are being blocked for anything trying to go through your pfSense box. Now, if clients have another way to access the ISP router that bypasses pfSense, then obviously pfSense can't block them. And because pfSense with Snort runs the interfaces in promiscuous mode, Snort will see all traffic on the segment even if that traffic is not targeted to the MAC of your LAN interface. As a final test, try to ping those IP addresses of the Torrent servers listed on the BLOCKS tab. They should fail to respond to a ping request if they are blocked. If they respond to a ping, them I'm almost 100% certain your problem is going to be the clients have another path to the Internet that bypasses the pfSense box.

@tsame said in Disabling IPv6 in Snort: You can't disable IPv6 within Snort. Support for that is compiled into the binary. You can, as @NogBadTheBad suggested, and disable IPv6 on your network if you don't need it. Would I need to disable IPv6 on every device on the network? Perhaps. Snort puts the interface it runs on in promiscuous mode, so any traffic hitting the interface is seen.

Snort for home is only $30/yr, but Snort for business is more. I assume you are needing a subscription for a business. In terms of actual security, the rules between the two vendors are pretty much equivalent. Where things get differentiated is the support of certain rule options and keywords between Snort and Suricata. The short version of this is that there are a number of rule options and keywords that Snort supports but Suricata still does not. So if you use a Snort rules package on Suricata you will likely encounter some rules that Suricata will refuse to load. How many rules this is depends on which exact rules you enable. The Emerging Threats team (now part of ProofPoint) partnered with the Suricata development team several years ago, and Emerging Threats produces a rule set optimized for Suricata. So if you want to use Suricata, and your budget can take it, I would choose the ETPro rules subscription. If the $1000/yr is too steep, you might consider switching over to Snort instead and then use the Snort rules subscription. Obviously Snort will support all of the Snort subscription rules. You can use Snort rules on Suricata, but expect some of the rules to fail to load. Suricata will print errors for incompatible rules and log a summary in the suricata.log file for the interface. If you enables lots of rule categories, you can easily have more than 100 Snort rules that will fail to load on Suricata.

Thank you for the help. I'll try that out.

It is processed first and then those IPs don't hit the other rules, but they will still generate a "blacklist" alert. Are you getting alerts beside the "blacklist" alert?

@DmitryDev said in Suricata Custom rule: error in with content, offset... How it works? INVALID SIGNATURE: @bmeeks Sorry for my very bad English. You understood me correctly. I read the documentation from the official Suricata site. I'll try to see log file. I do not mean to fault you for your English! I speak and write only a single language, so I am impressed with those who are multilingual. It's just that the differences in sentence structure among the world's languages make translation a bit tricky sometimes ... . Post back if you need additional help. User @NogBadTheBad frequents this forum and he is a very good rule author.

Thanks! It is working now.

@bmeeks said in Suricata syslog is truncated!: You will have much better luck with something like GrayLog or setting up an ELK stack on a separate host. Suricata is logging more and more of its output in JSON format. This is the direction of the upstream developers. So you need to enable the JSON logging options for each interface and then create a system on your own to suck up the JSON log files and export them off to a separate consolidator host. I believe some users here have tried filebeat and had success with that. It can process JSON logs. Thanks, actually i'm receiving EVE JSON over syslog now (bcoz payload data is needed). it seems i should try filebeat.

@Simbad said in Flowbit IDs in the current ruleset exceeds the maximum number of IDs that are allowed (1024): The number of flowbit IDs in the current ruleset exceeds the maximum number of IDs that are allowed To fix this, edit the following file: /usr/local/pkg/snort/snort_conf_template.inc Add this new line immediately above line 38: # Configure maximum number of flowbit references. For more information, see README.flowbits # config flowbits_size: 2000 The maximum allowed value for flowbits_size is 2048, so you can experiment by lowering or increasing this value for your setup, but you can't exceed 2048. After making this edit, got to the INTERFACE SETTINGS tab for each configured Snort interface and click Save to re-generate the configuration file for that interface. Then go to INTERFACES and start/restart that interface. This change will be overwritten if you remove and install Snort again. I will put this on my bug fix list and increase the value in a future Snort package update.

@rizkhan99 said in Suricata/Snort not starting (Resolved): @bmeeks @JohnSCarter Guys, even after following all the guidelines, my snort and suricata packages remain disabled even in the "Status" -> "Services" option. Trying to enable them from the "Interfaces" option in "Services" -> "Snort" or "Suricata" is also not working. The log files e.g. suricata.log are also empty. System log file show the following message (for Suricata) which seem to be normal but still these services don't start: May 3 22:04:56 php /tmp/suricata_bce039898_startcmd.php: [Suricata] Suricata START for WAN(bce0)... May 3 22:04:56 php /tmp/suricata_bce039898_startcmd.php: [Suricata] Building new sid-msg.map file for IPCORE... May 3 22:04:55 php /tmp/suricata_bce039898_startcmd.php: [Suricata] Updating rules configuration for: IPCORE ... May 3 22:04:55 php-fpm 63967 /suricata/suricata_interfaces.php: Starting Suricata on IPCORE(bce0) per user request... May 3 22:04:41 SuricataStartup 20258 Suricata START for WAN(39898_bce0)... May 3 22:04:25 check_reload_status Syncing firewall I have tried enabling snort and suricata from terminal by the following commands: /usr/local/etc/rc.d/snort start /usr/local/etc/rc.d/suricata start The output says the service has started however "ps -ef | grep snort" or suricata doesn't show up anything. The following commands also say that the service is "not" running: /usr/local/etc/rc.d/snort status /usr/local/etc/rc.d/suricata status I have checked all this on both snort and suricata by having installed only one of these packages at a time, to avoid any conflicts between these packages, if any. However, no success. My pfsense version is: 2.4.4-RELEASE-p2 FreeBSD version is 11.2-RELEASE-p6 Snort version is 3.2.9.8_5 Suricata version is 4.1.2_3 Please help... Regards, Rizwan First of all, you do not start/stop these packages using the command line. You need to do it from the GUI on the INTERFACES tab in either Snort or Suricata (depending on which you have installed at the moment). Have you done all of the steps outlined in my previous post? If so, then go to SERVICES > SURICATA and the Interfaces tab will be showing. Click the start icon to start the process. You will see a green gear spinning while the process starts up. If it fails to start, then you will find the reason by going to the LOGS VIEW tab and opening and viewing the suricata.log file for the interface you tried to start up. If the above steps do not either resolve the issue or give you a clue on what's wrong (Suricata is very good about logging any errors during startup), then open a CLI session on the firewall and type this command just to see if Suricata and its dependencies are properly installed: /usr/local/bin/suricata -v That should result in a printout to the terminal showing the installed Suricata version and some basic copyright info. If you see any messages about missing libraries or anything else, then Suricata did not properly install. For what it's worth, the only time I've seen an empty suricata.log file for an interface is when the installation did not complete and therefore some dependency library is missing. In that case, Suricata can't even start as the OS will refuse to start it due to the missing libraries. When it isn't allowed to start by the OS, then of course it can't log anything to the suricata.log file for the interface. If that's what is happening in your case, then the CLI command I posted will uncover the problem. Post back here what you find if you still have problems.