@boobletins said in reference.config - overwritten after edit?:

Yes, that worked.

So it's possible that either I manually edited reference.config in the past or clobbered it by unzipping Snort rules there or something.

My apologies Bill -- looks like I managed to break it without knowing and assumed it was broken in the code.

Glad you got it sorted out.

The $cfgs variable is an array in PHP. It is loaded with the filenames of all the reference.config files it finds in the /tmp directory where the rules tarball is unpacked. Each vendor's rules unpack into their own sub-directory under /tmp. The $suricatadir variable does indeed point to /usr/local/etc/suricata where the original reference.config file that was installed with the binary portion of the package is located. So if you have both Snort and ET rules enabled, during a rules update three different reference.config files will be combined into a single reference.config with any duplicates removed. That file will be written to the interface sub-directory under /usr/local/etc/suricata/suricata_xxxx for each Suricata instance.

@nogbadthebad

I just followed Jim's reco and it solved the Barnyard2 starting issue. I am able to start it now.

Thanks for the suggestion.

@sophware said in Suricata crash each time DNS logs are viewed:

@bmeeks Sounds good. Your quick replies are appreciated.

I can now view the log. Did the 500k setting take effect right away, or did a scheduled job take place?

There is a log pruning cron task that executes periodically. I can't remember if the interval is 1 minute or 5 minutes. You probably got lucky and made the change right before the cron task's next execution cycle.

With some trepidation (the setup for this isn't simple), I suggest you look into setting up a Graylog server to receive EVE JSON from Suricata on pfSense and then using Grafana to interact with the data in a useful way.

I'm not an expert on either, and won't be much help should you run into issues. I know that Graylog has an OVA image that can be used and I have a Grafana dashboard I've configured to my liking that I can share. It looks like this (modified from an example found online):

0_1543882286291_grafana_example.png

This type of setup can use an enormous amount of disk space depending on what you log. If you just want Suricata Alerts, it won't be too bad. But if you enable all of the EVE logging from Suricata you can easily end up storing multiple GB of log data per day...

@admins
The only way would be if the remote VPN peers are all in the same netblock. If they are, you could whitelist (Pass List) that netblock. I sort of doubt they are in the same netblock, though.

Snort cannot currently handle dynamically changing host IP addresses for anything other than the actual interfaces on the firewall.

You need to examine what rules are firing and see about disabling or suppressing any rules that are false positives. If the triggering rules are not false positives, then you need to really have a look at what your remote VPN peers are doing!

@whizzy said in Netmap errors in console:

I did a comparison of the hundreds of netmap errors I have seen over the last week and noticed some common occurrences.
Most happen at the same minute of every hour. Almost like on a schedule, but Cron does not have any events at the same time.
This can't be a coincidence.

Hi Whizzy -- sorry for the necro.

I'm going back through old posts to see what packet sizes people were running into with the bad pkt error.

Of those that I see you've posted, 3104 seems to be the largest packet size. dev.netmap.buf_size of 4096 in ui system tuneables will solve that issue.

But really, I'm more interested in your comment above that there are some patterns in the times. Do you have those old logs? I'm trying to track down why people are getting larger packets in the pipeline than they should be.

.

@bmeeks said in Snort block on selected interface only:

@expert_az said in Snort block on selected interface only:

I'll will try pfBlockerNG Dev,
But my question is about the possibility of creating snort2c table per interface.
In my example, snort will block streaming DST ip addresses on the GUEST interface, but people on LAN will access streaming sites.

It this possible with snort just now?

No, this is not possible now. There is only a single snort2c table created in the packet filter at pfSense boot-up.

But if you just want to block on your GUEST interface you can do the following:

Run Snort on the GUEST interface and set the "Which IP to Block" option on the INTERFACE SETTINGS tab to "SRC" (or source IP). This would prevent users from your GUEST interface from initiating outbound sessions based on the Snort rules that fire. So if you did not want them to access Facebook at all, you could enable the Facebook OpenAppID rules and configure Snort to block the SRC IP. So then if a user on the GUEST network attempted to establish a Facebook session the AppID rule would trigger and block the SRC IP (which would be an IP in your GUEST subnet). It would not block the DST (or destination) IP which would be Facebook. Thus users on other firewall interfaces would not be impacted.

The downside of this approach is that the user would be blocked for all outbound traffic since their IP address is in the snort2c table now. I would change the "Removed Blocked Hosts" interface setting on the GLOBAL SETTINGS tab to a very low value if you take this route so blocks removed relatively quickly.

Thank you for quick response.
As you sad GUEST user will lose all outboud connection min. 15min(snort min. block duration).
Because of this reason I'm asking blocking DST adress per interface.
It will be very userfull option because of L7 openappid addon,I think application layer blocking best effective mothod .

Thanks,
Hafiz.

@boobletins said in IP Reputation - "Assign a whitelist file":

I just wanted to double check that the pfSense package isn't modifying the interface ip reputation functionality? I ask because the "add" button for the reputation lists reads "Assign a whitelist file" which is the exact opposite of what I want to do...

The Add button lets you add a text file containing IP addresses to the list. There are two lists if I recall correctly. One for whitelists and one for blacklists. It may just be a tooltip text typo. You can add a list, and if it's not what or where you wanted it, just delete it using the trash can icon.

@kreeblah said in Suricata rules firing when I don't think they should be:

I actually tracked this down. Restarting Suricata on the interface didn't take care of it, but I noticed that when I used ps to check what was running, I saw two Suricata processes running on the LAN interface, even though it was disabled. Killing those took care of this.

Yep, this can happen from time to time because of how the pfSense subsystem restarts all packages each time an interface IP changes or is otherwise touched. Several back-to-back "restart all packages" commands can get sent that can cause duplicate copies of Suricata to run on the same interface. In this state, one sort of becomes a runaway in that it will no longer respond to GUI changes.

@aminbaik said in appid on facebook not working:

@bmeeks said in appid on facebook not working:

bled o

it's already enabled.
thanks.

If you have done all five things I listed in my post above, then you should get alerts from AppID when visiting Facebook. Now that assumes the device you are using to test actually has its network traffic traversing the firewall interface where Snort and OpenAppID are configured.

Lots of users have OpenAppID working on Snort.

@bmeeks

Hi.

With SpamHouse, yes, But Sorbs NO.

Sorbs no have list ip.

thanks.

@stewart said in Multiple php-cgi's using all CPU:

@bmeeks

There were 28 of these exchanges from 8:36 to 8:56 for a total of 56 entries. At one point we saw it give us a private IP:

21/11/2018 -- 08:50:32 - <Info> -- alert-pf -> added address 108.189.X.X to automatic interface IP Pass List. 21/11/2018 -- 08:50:49 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1. 21/11/2018 -- 08:50:49 - <Info> -- alert-pf -> deleted address 108.189.X.X from automatic interface IP Pass List. 21/11/2018 -- 08:52:50 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1. 21/11/2018 -- 08:52:50 - <Info> -- alert-pf -> added address 192.168.100.20 to automatic interface IP Pass List. 21/11/2018 -- 08:52:54 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1. 21/11/2018 -- 08:52:54 - <Info> -- alert-pf -> deleted address 192.168.100.20 from automatic interface IP Pass List. 21/11/2018 -- 08:53:49 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1. 21/11/2018 -- 08:53:49 - <Info> -- alert-pf -> added address 108.189.X.X to automatic interface IP Pass List. 21/11/2018 -- 08:54:12 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1. 21/11/2018 -- 08:54:12 - <Info> -- alert-pf -> deleted address 108.189.X.X from automatic interface IP Pass List.

The key is seeing if your "blocked" WAN IP address ever showed up in any of those messages. Is that 108.189.x.x IP the WAN that got blocked? The log entry you posted up earlier indicated the block happened at 08:56:19, but the latest entry I see in the suricata.log data you posted in 08:54:12.

What I would expect is that as your WAN interface flapped up and down and received different IP addresses, the log entries you pulled from the suricata.log file should have followed the changes. What this thread is doing is looking for dynamic IP address changes and updating an internal table in the blocking plugin that holds the list of IP addresses to never block. It does this by subscribing to FreeBSD kernel routing messages. So if this thread works properly your current WAN IP should always be in that table and thus never blocked. I'm trying to see why it got blocked anyway. That's why I wanted to see the entries from suricata.log that match up with the 08:56:19 blocking event.

@compuomari said in Snort custom rule, alert only no blocking, Snort is in blocking mode:

in other words, can i have exception for rules not to block traffic, although snort is in blocking mode. (block offenders is selected)...

No, the Snort package does not allow that option. You might could use a Pass List entry for a given host or group of hosts (via a firewall-defined alias) to prevent blocking of the specified host. But a Pass List would mean any host in the list would never be blocked. That may not be what you want.

The Suricata package has this functionality. You can implement a mode in that package where only rules with the action DROP will block traffic. I would like to add this capability to Snort, but the internal workings of the Snort binary do not make this an easy task.

Here is a link to a Sticky Post in this sub-forum about the "Block on DROP Only" mode of operation possible in the Suricata package.

That seems the way now !

Thx!

@bclothier said in Suricata not working after update 4.0.13_9:

Suricata is up and running. Per your recommendations, I did the following:

[1] I updated the package to 4.0.13_10 Of course, at present, my suricata.log is relatively short. But I presume the overflow PHP error is resolved.

[2] I went to Interfaces --> WAN --> WAN Flow/Stream. In Stream Engine Settings, I quadrupled the Stream Memory Cap to 268435456 (i.e., 256MB). I read elsewhere that four times the default value is necessary to completely eliminate the allocation error (i.e., https://chrislazari.com/pfsense-suricata-service-fails-resolved/). I did not bother testing other values.

[3] I changed the Snort VRT subscription rules from snortrules-snapshot-3000.tar.gz to snortrules-snapshot-29120.tar.gz. Now I get:

<Info> -- 2 rule files processed. 14273 rules successfully loaded, 83 rules failed

which is quite the opposite of my previous post. So this issue is resolved. I can absolutely live with 83 failed rules.

I also made one other change, namely, I switched Suricata to run in inline mode. In doing so, I also needed to change Max Pending Packets in the Detection Engine Settings to a value equal to or greater than 2048. I choose 4096. Otherwise suricata.log would gerenate error messages. My system is based on an Intel C3758 8-Core Denverton Atom SoC (i.e., a Supermicro A2SDi-8C+-HLN4F motherboard). This SoC incorporates Intel's X553 NIC silicon which supports netmap functionality. So far,at 4096, everything is running smoothly. I will tweak Suricata a little more on the WAN interface before setting up the LAN interface.

Anyway, thank you so much for your help. You quick responses are very much appreciated!

Glad you got things sorted out. The PHP overflow error is resolved. Now, with each restart of Suricata, that suricata.log file will get truncated to zero length. This means it will contain startup info for just the currently running (or just "failed to start") Suricata instance on the interface. Each interface configured to run Suricata has its own instance of this log file.

This is fixed in the next update that should be posted very soon. The fix will simply truncate that log file upon each startup of Suricata as that file only contains startup information pertinent to the current run of Suricata. No alert information is logged to that file.

Working nice here, the alerts i see is from wan side as i use SCAN and DROP rules from ET.

I did a week or 2 get from LAN side though but i am not sure if it was because of microsoft store or it was malware on that computer.

I did run antispyware and it found trackers not actually malware.

Anyway i hope snort will soon or in 2019/20 support/run on all cores.
This alpha stage has been going on for ages.

It seems, there was just some mistakes in my syntax, now it works on my VM too.

I missed the rev-number and the ";" at the end of the rule.

The "/32" on the end of some of those IP addresses should not matter. The IP address strings read from the Pass List text file are handed off to Suricata's internal functions to be converted into their binary equivalents. Those functions supposedly do not care if the /32 is present or not.

As for triggering Suricata at will, that depends on what your loaded rules are like. You will need to generate traffic that you have a rule watching for. My usual test scenario is to enable the ET Scan rules category and then use nmap from another host to port scan the firewall interface where Suricata is running. That will generate several alerts.

In syslog, they look correct but on the GUI side, there is unfortunately no way to check this due to the display having an upper limit of 2000 entries...