What you have is a botnet with a brute force attack and or tcp flood attacks. Only enterprise class firewalls have this feature, ie sophos, fortinet, and there's no guarantee it will work to stop it. But I found ways. As for ISP not detecting. The ISP or most of them don't care to block or firewall any attacks from their network outbound. Most don't even have a firewall for servers they colocate for clients. Their excuse is to not block any colocation client traffic which is complete nonsense. They didn't even know if it was a server or a coworkers desktop inside frontier. Eg Frontier networks, they don't protect any customer who buys business internet from them in which botnets source from their networks. They claim to have no department to take care of a rogue hacker server in their network. They wash themselves of liability. In turn advocating hackers in their network. Frontier ISP claimed we need to change away from default ports for services which won't prevent bots from trying every port. So we had to buy both software on the server and dual firewall updates that support botnet and tcp flooding. Which are off by default. That the tech support didn't even know about what it was. Even after enabling it. It stopped some but not all of the attack. Maybe another brand firewall would have been more effective. It cost us thousands. So any normal non business and business customer are at complete risk of attacks from this server and servers listed in my logs still today. Shocking but disgusting. The sad thing was, that if I didn't turn in 'audit login' information on the servers then 1 million more attempts would have made it thru the "pseudo firewall" We called fortinet and sophos for help if they could give a demo firewall to test and 2 weeks later they wouldn't. Even though they couldn't guarantee their filter would work or not. They told us to buy and try. If you still need help with this do reach out for my services.

@InfnBiz No, there is no staff support for Snort or Suricata. I am a volunteer package maintainer for those packages. In fact, the vast majority of the pfSense packages are supported by volunteers. This statement is incorrect: So with that said, there are 3 remote syslog server points on pfesense (system logs, snort/ids logs, barnyard2logs) There is no built-in mechanism within just Snort for remote syslog servers. You must either configure Barnyard2 for syslog export or use the built-in pfSense remote syslog option to export all system logs to a remote server. In order for that last method to work with Snort, you must then configure the option on the INTERFACE SETTINGS tab to log Snort alerts to the system log. So which of these two methods are you using? All pfSense system logs are being exported to a remote syslog server and Snort is configured to log to the system log for the interface in question; Barnyard2 is configured on the interface and Barnyard2 is configured for remote syslog logging.

A quick forum search with this error information will uncover lots of posts that give you the cause and the fix. Short version is the log file you are trying to open and view is too large to be read into the available PHP memory. Enable automatic log management on the LOGS MGMT tab and don't let your log files get so large. Or else don't try to view them via the LOGS VIEW tab and instead open them with a third-party editor from a command-line session. Or better still, export them off the firewall into a SIEM-type server. This is a limitation of the PHP sub-system that the GUI works on top of.

It helped me: ln -s /usr/lib64/libdnet.so.1.0.1 /usr/lib64/libdnet.1

@bmeeks said in Suricata IP Reputation Configuration Help: he IP REP tab was originally put in place to s Thankyou good info

@hebein You can use SID, edit the dropsid.conf and add the list. In my example below shows different individual SID and not a whole rule set. Also, you might not enable that rule set. [image: 1580066854890-screen-shot-2020-01-26-at-1.24.03-pm.png] [image: 1580066885721-screen-shot-2020-01-26-at-1.23.37-pm.png]

@petrt3522 Any Netgate hardware would, I believe because they would use a NIC that supports!

I noticed both Suricata 4.1.6_2, and 4.1.6_3 caused a crash report to be generated...I am also on pfSense 2.5 and dual Intel i350. [image: 1579884504854-screen-shot-2020-01-23-at-11.09.04-am.png]

@twennywonn said in Suricata breaks when I lose internet from ISP.: @NollipfSense I’m not sure you’re great at reading. He mentioned that could be the issue depending on what the logs say. I mentioned I didn’t know if I have access to those logs as I have uninstalled Suricata entirely. To answer the other question I do not have PPPoE. I will reinstall tonight and simulate and internet loss. Then if Suricata fails I’ll let you know what the logs indicate. The logs are likely still there unless you specifically checked "Remove Logs when Uninstalling" under the GLOBAL SETTINGS tab. The PID file would automatically get removed, though, when removing the package. To see the logs without Suricata being installed you will need to use the DIAGNOSTICS > EDIT function in pfSense and browse to /var/log/suricata/suricata_xxxxx where that last bit is a sub-directory created for each configured Suricata interface. The subdirectory name will be the physical interface along with a randomly-generated UUID. If you install the Suricata package again, the suricata.log from the previous install will get overwritten when Suricata is started. That file is overwritten with each start of Suricata on the interface. I don't recall anyone else ever posting with this particular issue. It seems strange for loss of Internet connectivity to crash Suricata. The only other possibility is if your interface is rapidly cycling and as a result Suricata is getting sent multiple "restart all packages" commands in quick succession. When interfaces come up, pfSense will issue an internal "restart all packages" command which attempts to restart all the installed packages. If that happens multiple times in quick succession, you could wind up with multiple copies of Suricata all attempting to start at the same time on a single interface.

So I change the setting from IPS Selection group to manual configuration and was able to start logging App info. Thanks for the recommendation and will be looking into the possibility of customizing the IPS selection groups.

@Chinojames said in Suricata Error PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 540538808 bytes) in /usr/local/www/suricata/suricata_logs_browser.php on line 54: @bmeeks said in Suricata Error PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 540538808 bytes) in /usr/local/www/suricata/suricata_logs_browser.php on line 54: sure the automatic log management is enabled already. how can i avoid this error? you said i allowed my log files to get too large, how can i manage my log file and reduce it to the limit so that this error will not occur anymore. or whats the best should i do? my pfsense keep on giving me this error and it said fatal error. thanks for your response. Are you running the most recent version of the Suricata package? When you go to SYSTEM > PACKAGE MANAGER does it show any update available? If it does, install that update. There was an issue some time back where the autotmatic log management was not functioning properly. What exactly are you trying to view when you get this error? Which log file are you choosing? Or does this error happen before you choose any log to view? Looking at the code in the area of line 54, I see that it is attempting to load the contents of the log file into memory in preparation for viewing. The log file is larger than the amount of available PHP memory in pfSense, hence the crash. You will not be able to open that file in the web GUI. It is possible that on a busy network, you may have to reduce the file size limits substantially in order to keep some logs from chatty sub-systems from getting too large. The Suricata binary itself does not have built-in log limiting for some logs, so the GUI code does its own check every 5 minutes of log file sizes and prunes and rotates when necessary. However, on a very busy network a log file can possibly get very large (beyond 200-500 MBytes) in that short period of time.

Ok, so after 5 days of running snort with same rulset as suricata without single problem I would say that suricata was a problem. So I will keep using snort as stability is more important for me. Thank you for help!

Hi, I have the same error, I have 2 pfsense server, the pfsense-A doesn't have that problem and Update all. But the pfsense-B(VM) have a pfsense out of the box whitout any config extra, just snort. this server have the same Snort Oinkmaster Code that Pfsense-A, maybe that's the problem?

Suricata upstream removed CUDA support two years ago. Here is the upstream pull request that removed it: https://redmine.openinfosecfoundation.org/issues/2382. So with the feature removed from upstream, that also makes it unavailable on pfSense. But the pfSense package never supported CUDA anyway. There are currently no plans for such support.

@Simbad said in reinstalling snort problem: Hi! After reinstalled snort, i dont see snort in menu & recive this error: PHP ERROR: Type: 1, File: /usr/local/pkg/snort/snort.inc, Line: 2340, Message: Allowed memory size of 402653184 bytes exhausted (tried to allocate 301989888 bytes) @ 2020-01-12 08:29:01 How can I complete the installation without previous configuration? It looks like from that message that PHP itself ran out of available memory. That particular line of code in the snort.inc file indicates you have something miconfigured perhaps in your SID MGMT files. You can try these steps to recover. Make a backup of the firewall's config.xml file. Under DIAGNOSTICS > EDIT open /conf/config.xml. Search through that file and find this line in the XML code: <auto_manage_sids>on</auto_manage_sids> Change the "on" to "off" and save the file. That will tell Snort not to use SID MGMT. Delete the package and reinstall. Since your installation is not completing, you likely don't have a Snort menu option under SERVICES, so you will be stuck with manually editing the config.xml file. That is very dangerous, so make a backup before making any modifications to the file.

@jpgpi250 said in Is this something that will be part of suricata in the future?: On reddit, there is a topic, discussing code, added to suricata to detect, among other things, DOH connections. I wonder if this feature will ever make it into the pfsense version of suricata, detecting and possibly blocking DOH might be a real benefit for users that absolutely want to prevent it. GitHub code here. Only if and when that code is merged into the offical upstream release of Suricata. The pfSense package uses the upstream binary. The only patch applied is to incorporate the custom blocking plugin. So if Suricata upstream accepts and merges that programmer's code edits, then it will appear in pfSense when the Suricata package updates to the latest upstream binary. If the programmer does not submit it to the Suricata upstream team via their Github site, then it will never make it into pfSense.

The solution was just upgrade to pfSense 2.5-dev...now, running Suricata inline mode WAN and Snort inline mode LAN...like it so far, especially having Snort preprocessors on LAN in inline mode.

The option to specify a custom file-store logging directory is now available in the latest 4.1.6_1 version of the Suricata package. See the Release Notes in this post: https://forum.netgate.com/topic/149490/suricata-v4-1-6_1-package-update-release-notes.

@kiokoman THX! System is up and running :)