@teamits Yes, log rotation is independent of the Directory Size Limit setting. The Directory Size Limit is a safety valve designed to prevent firewall DOS caused by running the system out of disk space due to growth of IDS/IPS logs. So if the Directory Size Limit value is reached, and the setting is Enabled, then logs are cleaned up until space drops down below the limit. Log Rotation is a slightly different animal. When Log Rotation is enabled, every 5 minutes a cron task executes that examines the configured log files to see if they have reached the rotation size limit. If reached, that log file is rotated. At the end of the log rotation script it checkes the ages of rotated logs and removes those older than the configured retention interval. So you can enable Directory Size Limit protection and leave Log Rotation and Aging disabled; or you can disable Directory Size Limit protection but enabled Log Rotation and Aging.

@boobletins said in Enabling etpro-exploit.rules causes rules in other non-active categories to become enabled in Suricata...: To confirm this could he check flowbit-required.rules? Do you know what happens in the case of rules like 2018959 where the same flowbit is both tested and set? flowbits:isnotset,ET.http.binary; --- then later --- flowbits:set,ET.http.binary; Is pulled pork (or whatever is being used) smart enough to know that if 2018959 is disabled and not used elsewhere it should stay that way? I have not looked at the full text of the rule you mention, but a rule author might use logic like that as a type of "if-then" statement. If not set, then set it; otherwise let it be. Use of flowbits is a totally arbitrary thing for rule authors. You can create as many as you like with whatever names you want, just so long as you don't duplicate the names. Pulled Pork is not being used in the Snort or Suricata packages, but the code logic is the same. It will enable rules as necessary to be sure at least one "set" operator exists for any flowbit with a corresponding "isset" operator. Now, if an admin truly wants a rule to always be disabled, flowbits be damned, then when you force a rule state to disabled on the RULES tab (or by clicking the X icon on the ALERTS tab), then that rule is disabled. The user-forced actions are the last operations performed on the set of rules when compiling the list for an interface. There is a Sticky Post here on the IDS/IPS sub-forum about how that works. You can also follow the program code in the file /usr/local/pkg/suricata/suricata.inc. Look for the function suricata_prepare_rule_files(). Edit: here is the Sticky Post I mentioned describing the rules building logic.

@veldkornet said in Suricata Update 4.0.13_9 PHP Warnings: Thanks, I recreated the interface and that fixed it indeed! Glad it is fixed for you. Thank you for the feedback.

Will test this later today. Your help is highly appreciated!

Some notes on lb: lb doesn't currently ship with FreeBSD or pfSense. It's possible to build it from the source repo, but if you do that it's not the same version of netmap. Building the new version of netmap + lb from source on FreeBSD 11.2 yields driver build errors and it's downhill from there. This package: https://github.com/bro/packet-bricks is more promising (don't let the "bro" dissuade you). If I knew how I would try to put together a pfSense package for packet-bricks. It would help in some cases with Suricata processing because it would allow for better load balancing across CPUs in combination with Suricata's CPU affinity settings. packet-bricks is run by the ICSI lab at Berkeley. It's a version of lb (also requires netmap) with creature comforts and additional capabilities. If I'm reading the commits correctly the lb tool from the creator of netmap was recently added to FreeBSD as well, but I can't tell when it will be available...

@boobletins said in Suricata inline mode - trunk interface: ou can see that on FreeBSD the bge driver is not supported. The em driver should work with netmap natively assuming there's no incompatibility in the VM. If you need inline mode with bge then you will need to run netmap in emulated mode as described in the link above: Emulation is also available for devices with native netmap support, whichcan be used for testing or performance comparison. The sysctl variable dev.netmap.admode globally controls how netmap mode is implemented. But you should know that if you put netmap in emulated mode to make it work on bge, then it will also be running in emulated mode for the em card. Also: what version of FreeBSD/pfSense are you running? Pfsense 2.4.4_p1 I will try intel nic. thank's

You can certainly do that -- mine is higher than default, but it won't help with any "bad pkt" errors if that's what you're trying to solve. Really what you would be doing there is buying yourself a larger buffer if Suricata starts falling behind -- you've set aside more RAM in case of a backlog of packets.

@bbcan177 said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything: To overcome those certificate errors, create a new DNSBL Alias and add those domains to the customlist at the bottom. Then select the "Disable Logging" and set the Group Order to Primary. Then run a Force Update... This assuming that you are on pfBlockerNG-devel. This will nxdomain those domains and also disable the logging of those domains. I did this already, thanks, I'm following your subsection on this forum also reddit... It worked, but then again it's not very much elegant solution... Especially that you can't add ALL possible sites there obviously and this list is getting bigger and bigger every day -it's a manual only process.. So yeah, not elegant at all..

@dolomite792 said in Snort missing under services?: The real fix is to increase /tmp RAM Disk Size large enough to handle all of the installation data. None of the fixes shown above worked until I increased the size. I reinstalled it and it actually installed faster and worked this time. +1 on this! I have advised Snort and Suricata users to not use RAM disks. Or at least if you insist on using them, make them at least 200 MB (or maybe larger) in size. You need enough space to hold all of the downloaded packages required for installation. This includes quite a few dependency packages in the case of Snort and Suricata. That's why it takes so much room. If you do not have enough free space, the package install will fail. And when that happens you are left with an incomplete installation and likely the Snort entry missing from the Services menu. Same thing happens with downloading and updating rules archives. Those files are copied down to /tmp and then unpacked into separate sub-directories for manipulation and eventual copying to the system volume. This also takes a lot of space if you use Snort, Emerging Threats and Snort Community rules all together. Not having enough free space will result in rules updates failing in strange ways.

@srijannandi said in netmap issue with Intel 82574L Network adapter: Has anyone got this working in 2.4.4... Yes. Could you review /var/log/system.log and /var/log/suricata/suricata_[specific-to-your-interface]/suricata.log for netmap errors and report your findings? eg cat /var/log/system.log | grep netmap

@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): [image: 1543882287158-grafana_example-resized.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.