My best guess is it is simply pfBlockerNG doing a reverse PTR lookup to find the corresponding domain name, and that lookup is triggering the Snort alert. Since pfBlockerNG runs on the firewall, DNS Resolver (unbound) would perform the lookup by going directly out to the WAN. In that scenario, nothing would ever have need to cross your LAN interface because all the traffic is internal to processes on the firewall, and thus that Snort instance sees nothing to alert on.

In summary, it is most likely harmless. If it bothers you, you can see what a packet capture on the WAN shows. My guess is it will show unbound on the firewall doing a lookup and that's it. The "SRC" will be the firewall itself.

Similar behavior has been posted before (several months to maybe more than a year ago) and the culprit was simply a package on the firewall attempting to get a domain name for an IP address so it could write the domain to its log file. Harmless behavior.

@NollipfSense Thanks. Then I will have to go back to legacy mode.

Yes, that is correct. CPU cycles are still burned processing the rule. You just don't get alerts from those rules.

@bmeeks
Thank you, exactly what I was looking for

@heliop100

If http://that.site.com/ keeps moving from one of their IP addresses to another its your only hope, can't vouch for if its safe or not.

That's were the IDS might come in handy.
But ..... for security reasons you would NOT run it on a firewall / router.
This one acts only asthe traffic cop.
Place your reverse proxy just before your web server on a dedicated, isolated LAN. The reverse proxy will terminate the SSL traffic", exposing itself to the world as the "web server", it will unwrap the SSL traffic, inspecting (like border control) the content and passing on the traffic, it could even stay ordinary http because the ext hop = one cable away, will be the web server.

IDS was nice add on ones, but then that new kid come on the block : TLS ....

@BCSNetAdminDF said in Better Blocking for Snort Package:

@bmeeks said in Better Blocking for Snort Package:

the only way to install and take advantage of the new Snort 4.x package is to upgrade

I had no idea, thank you so much. I'll set that up in my lab right away.

Once you get the new Snort 4.x package installed, have a look at this Sticky Post for configuration instructions: https://forum.netgate.com/topic/143812/snort-package-4-0-inline-ips-mode-introduction-and-configuration-instructions.

Thank you for your help.

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:

@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.

Screen Shot 2020-01-26 at 1.24.03 PM.png

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.

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!