@johnpoz said in DNS Servers being blocked: @justme2 said in DNS Servers being blocked: With the roots and TLD servers, they only see the "lower level(s)". A forwarder sees the entire FQDN requested - of every request. RE: minimization, correct. Should have more clearly (or perhaps more generically correctly) stated that the roots and TLD infrastructure may see the full FQDN, but no other 3rd party would have full visibility of all the queries generated by an organization. Generally, roots/TLD infrastructure are uninterested parties due to mandatory involvement. Pfsense unbound config is pretty good out of the box.. I change it to not listen on all, and only the interfaces I want and only query outbound on interface(s) I need. Also change from transparent mode to static type. I also turn off the automatic ACLs and do my own. Yes, when it comes to recursion performance - unbound is particularly good. When tuned on a dedicated box for load - it can be phenomenal for recursion.

The issue I encounter seems related to others who have tried to run inline mode without netmap support; traffic passes for a brief period of time and then all traffic flow stops.

@boobletins Ideally I would like to solve both of the issues, but the WAN latency is a higher priority. I think they are interrelated, but I have no idea which is causing the other. dmesg | grep interrupt igb0: Using MSIX interrupts with 5 vectors igb1: Using MSIX interrupts with 5 vectors igb0: Using MSIX interrupts with 5 vectors igb1: Using MSIX interrupts with 5 vectors igb0: Using MSIX interrupts with 5 vectors igb1: Using MSIX interrupts with 5 vectors vmstat -i interrupt total rate irq1: atkbd0 6 0 irq9: acpi0 2 0 irq16: ehci0 3845256 1 irq23: ehci1 1831351 1 cpu0:timer 2673498411 1035 cpu1:timer 377015655 146 cpu3:timer 376025919 146 cpu2:timer 375885908 146 irq264: isci0 1 0 irq266: igb0:que 0 186663825 72 irq267: igb0:que 1 39564243 15 irq268: igb0:que 2 46355532 18 irq269: igb0:que 3 49144499 19 irq270: igb0:link 2 0 irq271: igb1:que 0 285667733 111 irq272: igb1:que 1 67109876 26 irq273: igb1:que 2 43993156 17 irq274: igb1:que 3 62085685 24 irq275: igb1:link 8 0 irq276: ahci0 9574415 4 Total 4598261483 1781

If your ISP is pulling shady shenanigans, you can: Get a new ISP that doesn't engage in shenanigans Use a VPN to tunnel past their shenanigans /shenanigans

@tsmalmbe The confusion stems from the somewhat primitive way the plugin has to handle blocking. The blocking plugin is actually written as a Snort logging output plugin, and it gets a copy of every alert that is triggered. Unfortunately, the rule "action" is not part of the alert data that is sent to the plugin. So it cannot know if the alert it was copied on was from an alert action rule, a drop action rule or a pass action rule. So it has to treat every alert notice it receives as a "block" or "drop" action. So in your case, the alert is actually just a notification, but the blocking plugin does not know that. So it has to assume the alert is something it needs to block.

Yes, you can specify SSL/TLS settings One limitation I've run into is that you cannot easily send the same logs to multiple destinations directly from Filebeat. You have to either run multiple instances on the firewall or duplex it from eg a central Logstash service to other locations. It has load balancing built-in, but not duplexing.

Great thanks. I certainly understand the ramifications! However my network is designed into segments, for example there is a DMZ, this has an internal addressing scheme. If this zone started poking around other internal zones it would mean there is a breach so I'd want it blocked.

@tsmalmbe said in Snort: Two firewalls, missing a lot of rules although similar configuration/setup (Solved): This was it. What a simple solution for once. Glad you got it sorted out. Snort or Suricata and RAM disks are not good matches. I always recommend no RAM disk when running either of those two packages.

@nambi said in Snort Blocking too much.: @nogbadthebad said in Snort Blocking too much.: Create a VPN, IPsec or OpenVPN, don't allow access through the firewall so you can view your CCTV cameras. If Snort is blocking too much don't set Block Offenders and leave it running for a week or two, then decide what rules to switch off before enabling blocking. Thank You I currently have a VPN for this access but was hoping to leave my mail server and CCTV access open. Read up on how to use Snort and how to use Suppression Lists. Google is your friend for that. Lot's of tutorials out there on how to do that. For your mail server and CCTV systems, look at what rules are alerting (and thus blocking). Determine if they in fact represent false positives in your environment. If so, you can suppress those rules using three different techniques. You can suppress the alert entirely for any IP address, you can suppress the alert when the destination IP address is a specific host or subnet, or you can suppress the alert when the source IP address is a specific host or subnet. There are also suppress (also called thresholding) options for only alerting after a specific number of alerts in a given time period have occurred. In short, there are many options for tuning an IDS/IPS like Snort or Suricata. Google "thresholding and suppression" for Snort. An IDS/IPS is not a package you install and then walk away from and expect it to work without any hassles. Every IDS/IPS requires tuning by an experienced network security admin using knowledge about the unique network environment being protected by the system.

@bmeeks Then I'll just wait. We just started rolling out the 2.4.4 updates to our managed routers when 2.4.4_1 came out. We're holding off on upgrading to it until we finish testing in our office (after the first of the year). Maybe by that time you'll have the 4.1.0 update out and we can just roll with that. Thanks!

@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