Thanks everybody for the replies! I understand it's not Snort's job to resolve the domain and I don't have any problem with seeing these kinds of alerts. However I would have at least expected it would be able to show me which domain is being looked up, moreover once the communication is established (e.g. someone visits the website or downloads something from it) Snort would kill that state and put the IP in the blacklist.

@bmeeks said in How to send Snort alert logs to Graylog without Barnyard2?:

@rlrobs said in How to send Snort alert logs to Graylog without Barnyard2?:

Filebeat is the best option... but.. how to install the filebeats in pfsense?
https://www.elastic.co/downloads/beats/filebeat
Convert packet .deb/rmp in pkg?
Use .tar.gz?

No, it is not likely that things compiled for Linux will work 100% correctly within FreeBSD due to shared library issues.

It is my understanding that Beats in FreeBSD is a new and better (but still compatible) version of Filebeat. So FreeBSD's Beats is the same as Filebeat (at least that's my understanding).

@bmeeks There is an official beats package for pfsense.

http://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/

Ok, I'm fine with this netmap setup. I have been using it since you had posted that Inline mode is available.

This worked for me, but I had to go through the additional step of assigning my new list to the interface that was generating the error (LAN in my case). I went to Services, Snort, Interfaces, edited the interface, scrolled down to "Choose a Suppression or Filter List (Optional) and added my newly created list then clicked Save.

add new rule to interface

@swmspam said in Inline IPS to block students from using VPN in educational subnet:

bmeeks, I agree that writing some new rules for purposefully sneaky VPN clients would be useful to the community at large, especially for administrators struggling with middle schoolers and educational subnets. I'm starting by reading up on forum posts of detecting OpenVPN using Snort (including posts on this forum). It doesn't look very promising because OpenVPN can wrap itself in HTTPS or other legitimate protocols.

This is why I seldom favor or recommend using technical solutions to police what is fundamentally a problem of discipline and personal responsibility when it comes to Internet usage policy. As you see with this VPN client, the technical challenges are tough if you depend solely on technically preventing the software from functioning. On the disciplinary side, though, you generally only have to cut off one person's head in order to get the full attention of the rest of the crowd --- LOL. Okay, just a little bit of hyperbole there, and I'm certainly not suggesting cutting off the head of a middle schooler; but some strong disciplinary action on a few can many times convince the remainder that it's not worth taking a chance participating with the banned activity.

Contrary to my last answer.
As time flies away, it might have been before Jan 18 so this issue may be fixed.
I'll test again later.

CPU clock speed is going to be most important. Snort 2.9.x is single-threaded, thus it can't do much with multiple cores. Suricata is multi-threaded and supports multiple cores, but a number of independent tests of its multi-core multi-thread performance don't indicate huge gains across the board (at least not what most folks would expect).

One thing to consider with high core count processors (if you use Suricata) is the need for larger amounts of RAM. Suricata bases its initial TCP Stream memory buffer setups on the number of CPU cores. So, for example, with an 8-core CPU, Suricata will usually fail to start and throw a Stream Memcap memory error with the default package configuration. You have to greatly increase the Stream Memcap settings with high core count CPUs. There are some threads about that here in the IDS/IPS sub-forum.

For home use, any dual-core or quad-core CPU is plenty of horsepower. I would suggest 2.5 GHz or higher for the clock speed. Higher is better of course better.

@vbman213 said in Suricata Barnyard2 Remote Syslog. Broken?:

I'm trying to push Suricata alert logs to a remote syslog server. Barnyard2 doesn't seem to be working. The only way I can get Suricata alerts to the remote server is to configure Suricata to write to the local system log and then forward the local system log to the remote syslog server.

Any ideas? Is Barnyard2 broken?

Barnyard2 is slowly dying on the vine as the FreeBSD port has not been materially updated in several years. However, it should still run with Suricata and pfSense. Are you sure Barnyard2 is actually starting on the interface? Are there any messages in the pfSense system log relating to Barnyard2?

pfBlocker trying to resolve a host that i've blocked ☺

0_1551087452799_Screenshot 2019-02-25 at 09.37.08.png

@darkzero99 said in Pfsense 1100 and Suricata Does not work.:

Suricata does not start on the Pfsense 1100. I used pfsense with suricata before. on other systems. I just can't get it to work on the 1100. Any help would be great.

There is no useful troubleshooting information in your post. Have you checked both the pfSense system log and the suricata.log (available via the LOGS VIEW tab) to see if any error messages have been recorded?

Your post is the equivalent of me telling you "I got in my car and it won't go. Any help would be great". To help you, we need some tangible information about any error messages being logged and what exact configuration you are trying to use.

You also have multiple options for using a Suppress List entry. You can suppress a rule entirely for all IP addresses, or you can selectively suppress the rule based on either SOURCE or DESTINATION IP address in the packet. Hover over the little plus sign (+) icons by each alert on the ALERTS tab to see the options (they will appear in a tooltip pop-up).

@itsupport1212121
I don't currently have an open Suricata session in front of me, but from memory the settings let you select a maximum size for the packet log in megabytes and a limit on the number of captured packets. So the actual disk consumption is determined by the size of each packet (typically 1500 bytes) and how many packets you save. The log size limit is like an override that prevents the log from growing too large.

All log data lives in /var/log/suricata and then in a sub-directory underneath for each configured interface. The sub-directory will be named with the physical interface name combined with a random GUID.

@zermus said in WAN interface keeps dropping out of snort:

Years of using pfSense I would normally tend to agree with you, but that's the case. Under Snort Interfaces, if I use a heavy ruleset, it just somehow deletes itself out. There is no HA/Sync in this setup, it's a standalone box. The interface doesn't PHYSICALLY DISAPPEAR of course (I'm literally imagining a ghost going in and stealing my Intel NIC out of the box here), but it's dropping out of Snort Interfaces, exactly like someone goes in and deletes the WAN interface from Snort where I have to re-set it all back up again.

The only correlation I can find is using a heavy rulset, which in the past was never a problem up until recently. I'm not sure how recent because I just noticed my WAN interface was missing about a week ago when I normally never had a need to go in there and check it.

I'm not sure how it would resort to a previous config, because when I set this box up about 2 years ago, setting up Snort on the WAN/LAN was one of the first things I did.

I'm not disputing what you are seeing, but I see absolutely no failure mechanism of any kind within the GUI PHP code that could result in a Snort interface being deleted. Deleting an interface requires a manual action. Go to DIAGNOSTICS > BACKUP AND RESTORE in the pfSense menu and then click the Config History tab. Examine the history closely to see what you find. When Snort deletes an interface via user action, it logs a message in the config history. The only part of the PHP GUI code that can delete an interface resides within the INTERFACE SETTINGS tab, and that code will always log a config history message as well as log a message in the pfSense system log when it removes an interface.

@davetheriault said in Snort Blocking Host No Matter What:

Ya. I've tried 'removing' the individual entry in Blocked Hosts. And I have also tried the 'Clear - All blocked hosts will be removed' option each time I try to fix the issue.
After I clear it from the Blocked Hosts table, I am able to visit the host with one successful page load, but it immediately get's re-added to the Blocked Hosts table by snort, and I can't continue or reload the page from that host, no matter what rules I have suppressed or pass lists I have created.

I know of only two ways what you describe can physically happen.

You are disabling the wrong rule (i.e., you are not disabling the rule that is actually firing) or else multiple rules are firing and you still haven't found them all;

There is another duplicate Snort process running on the interface that is not responding to your rule changes. That can happen in rare circumstances. To see, run this command from a shell prompt on the firewall:

You should see only a single Snort process listed for each configured interface. If you see more than one per interface, stop Snort in the GUI and then kill any remaining Snort processes from the command line shell.

As for the Pass List "Snort_Pass_List" shown in your screen capture, do you have that list assigned to the Snort interface on the INTERFACE SETTINGS tab? There is a drop-down selector on that tab where you select the Pass List you want to use for the interface. Make sure "Snort_Pass_List" is selected, save the change, and then restart Snort on the interface. Using a custom Pass List is a two step process: (1) first create the list; and then (2) go to the INTERFACES SETTINGS tab and assign the list to the desired Snort interface.

The Suricata GUI package on pfSense is designed to make the deployment of an IDS/IPS somewhat simpler for users new to such technology. If you are at an advanced level where you want to integrate with multiple other systems and construct on-the-fly rules using script tools, then you really should abandon the GUI part of the package and simply use the Suricata binary itself. You can do that by simply installing Suricata from FreeBSD ports. You are going to have to install all of the other scripting language dependencies from there anyway.

I am not in favor of loading up the Suricata package with a ton of new dependencies when the vast majority of users would likely not need them for a basic IDS/IPS. I'm talking about things like Python, Go, (and heaven forbid one old suggestion even needed Java! Can you imagine the security holes your firewall would have with Java installed on it?).

There is a Github site for all of the pfSense packages here. You are free to submit pull requests there. I usally am asked for my opinion, but the pfSense developers have final say in what is accepted into the package.

@chudak said in Snort blocked hosts:

@bmeeks

You sound fine no worries 😉

And I’m actually not disagreeing on this point
Need to digest, but then to be consistent with this - why do we allow Remove Blocked Hosts Interval option? What do we need it for ? Snort blocks hosts for say 1 hour and automatically removes it and then if needed blocks again.

How does that sound ?

PS: I’m not advocating for this change, just underlining the point.

Because Snort hands off the actual blocking to the firewall packet filter, there needs to be an option to clean up blocked IPs after some period of time. Snort can't just "drop" packets like Suricata Inline Mode can. Think of a Snort block as a temporary firewall rule that is put in place. That rule needs to expire after some interval. Generally something like 15, 30 or 60 minutes is a reasonable expiration time. That is long enough to discourage port scanners and bot scripts that are say knocking on a bunch of port doors looking for a way in.

It's true that Snort could hand the IP to the snort2c table and then clear it again almost immediately, but that would take a lot of extra processing on the part of Snort. Instead, Snort creates a cron task that uses the interval selected by the Clear Blocked Hosts setting. That cron task runs the pfctl utility to scan the snort2c table and remove any IP addresses that have not seen activity within the interval set by the Clear Blocked Hosts setting. So if the interval is set for 30 minutes, then only IP addresses that have not been seen in any traffic for the last 30 minutes will be cleared from the table.

Just to finish off this thread - the workaround by adding the server ip to the interface passlist works in the sense that the server ip is no longer getting blocked. The downside of course is, that this server is now completely without protection from Snort.

@bmeeks I removed some rules and so far the process is staying on. Thank you very much for your input.

Not a huge deal, more of an annoyance. Thank's for confirming.