@bmeeks said in Can pfSense integrate with another device? (mirrored-port⇄API): packets will leak unless you slow the network traffic down to a trickle and hold packets up on one box while the other box is inspecting them and then sending instructions over some kind of back chan Thanks, this is incredibly informative. Just to be clear, my edge device and firewall is pfSense and it's also the one running Suricata (not inline though). I'm just experimenting with stuff for fun, and sure, anything's going to be super inefficient if it's not within kernel's reach but it must be at least better than diverting back and forth the full stream of data. The big really big enterprise firewall-routers, something like TNSR or these 30-something core ASICs out there usually don't have these features. They do seem like they'd benefit from this approach but that's just speculation of mine, I came here to learn in the first place, I've nothing to teach. Thanks again!

@bmeeks Thanks, I didn't notice that option in interface settings. I did that and now I am monitoring the behavior of Suricata. Cheers

@bmeeks Thank you very much for your attention and help, thanks to this I have been able to carry out my laboratory perfectly. Thank you very much !!!!

@wrightsonm said in Suricata log rotation bug: @bmeeks I would say that your suggestion isn't particularly good design practice. There is already ajax being used on this page - see check_status() function. The start / stop buttons should really get submitted as an ajax request that then updates the icons on the page onc completion rather than submitting the entire page and causing the described problem. Secondly, the issue that the php page is at risk of a type of replay attack that is triggered when refreshing the page, that then causes multiple services to be started is less than ideal. The main php script should really take advantage of the logic contained within $_POST['check'] and use that to determine whether or not to start a new process to prevent the possibility of multiple services being started - i.e. add validation. The code tries, as best it can within the limitations of PHP, to see if another instance is running before starting an instance. The problem is that the only way the code really has to determine if another process is running for the interface is to look for the PID file created in /var/run. Each interface has a randomly generated UUID associated with it at interface creation. That UUID is used to name the PID file, so the code can tell which interfaces have Suricata running, and be able to control them individually. However, it takes some amount of time for Suricata to start and create that PID file. If the user quickly refreshes back-to-back, there is no PID file yet from the first process, and so not seeing an existing PID, it assumes there is no existing process and thus starts a new process. Then you have two. The Ajax section was added a few years ago to improve GUI responsiveness. It works by actually creating a new background PHP process to start the Suricata daemon. The Ajax loop then checks for the existence of the aforementioned PID file to determine whether Suricata is running or not. Prior to that, the GUI just sat there and "spun" with the web page totally unresponsive until the PHP function calls returned. That was not ideal, either. If you have a better solution, please feel free to submit a Pull Request here: https://github.com/pfsense/FreeBSD-ports/tree/devel/security/pfSense-pkg-suricata. User contributions are welcomed.

@bmeeks thanx, it's working fine now...

I opened a separate bug to cover this as it was getting conflated with the PHP issue whoch is a separate (and solvable) problem: https://redmine.pfsense.org/issues/12157 Steve

@fst said in Snort will not start - PFSense 21.05 / FreeBSD 12.2: Thanks again. You're welcome. Sorry for not getting it working! Regards, fireodo

@bmeeks Thanks Bill, I actually had a sneaking suspicion I'd seen it and had it in my to do list to check it so thanks for confirming.

@bmeeks Cool. Again, thanks for all the effort on this!

@gertjan said in ET INFO Outbound RRSIG DNS Query Observed: @stewart said in ET INFO Outbound RRSIG DNS Query Observed: Spectrum uses have PUMA chipsets and fall apart Oh .... that name does ring a bell. Isn't that chipset/modem part of the top ten on badmodens.org (or something like that). Why yes. Yes it is. I believe PUMA chipsets is the sole reason that site exists. @gertjan said in ET INFO Outbound RRSIG DNS Query Observed: @stewart said in ET INFO Outbound RRSIG DNS Query Observed: You can't just say Well ..... Right, I admit : I say so, because it, pfSense, ships in a configuration that works out of the box. They choose this build-in setup because it's probably valid for most of us. And that's valid for me. ( so extra true ^^) I realize that there may be a bit of a language barrier if you're primary language is French. I realize if read a certain way it could be an argumentative statement. It wasn't meant to be so, so please don't take offense. Don't worry, I live in France, so I know that there as as many exceptions as habitants. Still .... using a modem that goes haywire because you throw some off the mill, plain vanilla DNS requests through it makes me wonder : You pay your ISP - or your ISP pays you ? ;) Do you have to use this type of modem ? (I've read somewhere, sometimes that you probably do not have any choice). Residential customers can use an approved modem. Commercial customers must use the ones provided by the ISP. IMHO : a more basic router/firewall a pfSense doesn't exist **. I guess it's even setting that reference right now. What I should have said above : On the Resolver settings page : un check the DNSSEC option, as it it worthless anyway. The "ET INFO Outbound RRSIG DNS Query Observed" log line will go away. @stewart said in ET INFO Outbound RRSIG DNS Query Observed: modem buckles under the weight of simple DNS traffic This intrigues me. Dono what the ratio of "DNS traffic"/"All traffic is". 1 or 2 %, maybe ? I should investigate. It's not the overall amount of bandwidth that's used. It's that DNS throws out a bunch of UDP packets in quick succession when doing the resolving and the modems become unresponsive during that time. ** with probably far to many bells and whistles.

@steveits said in Snort2c Hosts being blocked: @stewart said in Snort2c Hosts being blocked: find the WAN IP as being blocked Your WAN IP should appear if Snort is running on the WAN interface. If you move it to LAN, you'll see LAN IPs, and it won't see/scan traffic that was blocked by the firewall. You misunderstand, I think. I'm not saying that I see the WAN IP in the Alerts (which I do since it's on the WAN). I'm saying I sometimes see the WAN IP in the snort2c block table. In that Suricata actually places the WAN IP on the block list and won't accept any traffic to or from the WAN IP for the duration of the block time. If he's running IDS on the WAN and the WAN IP is getting blocked then it won't accept any traffic at all on the WAN. I'm wondering if that is what he is seeing since he is talking about the snort2c block table and not the Alerts or Block lists.

I want to report that I am working offline with the Suricata developer team looking into this issue, and also the one affecting netmap operation in the Suricata 6.x binary.

@bmeeks said in Suricata-6.0.0_11 Package Update Release Notes: It will show up in the near future. This has been done, once again, we got your usual work... :-) (quality above all else) Thank you Bill, if something is missing we will shout

@bmeeks said in Snort-4.1.4 Update Package Release Notes: Yes, it will be included in the current release (both CE and pfSense+) in the near future. I'm sure the team has been busy with the recent 2.5.2 version going RELEASE, and have not pulled over some package updates. Good to hear! I will drop the Netgate team an email asking them to move Snort-4.1.4 over to 2.5.2. Thank you very much! And also THANK YOU for your work! Nice Weekend, i wish, fireodo

@theonemcdonald tun_wg0: flags=80c1<UP,RUNNING,NOARP,MULTICAST> metric 0 mtu 1500 description: WREGRD options=80000<LINKSTATE> inet 10.128.128.1 netmask 0xffffffff inet6 fd1f:c547:3e98:b32f:: prefixlen 64 groups: wg WireGuard nd6 options=101<PERFORMNUD,NO_DAD> Gave it a local link ipv6 but the issue persists. If I delete the tun_wg0 the issue goes away.

@drewsaur There is the + icon to Suppress a rule for an IP, in the source and destination IP columns, if that helps.

The System Log Facility setting controls "where" the entries are logged. Or more accurately, what "tag" they are given in syslog. So with the default of LOG_AUTH, those alerts are going to be given that tag, so when filtering in pfSense's system log, they will show up that way. The "General" view in pfSense grabs everything (if I recall) regardless of the "tag" it was given when logged. But those other tabs do let you filter by the facility tag.

@hichem said in Snort (4.1.3_5) + SG-3100 (21.05-RELEASE (arm)) = exited on signal 10: @steveits Patch already done 5 days ago, but snort stop after a few minutes. For SuricataI win reinstall it and told you the error. Pay attention to the errors in the log. Signal 11 is a segmentation fault. That was happening from the PHP PCRE engine. The patch referenced earlier in this thread fixes that Signal 11 problem. It does NOT fix the Signal 10 issue. That is caused by opcode choices made by the compiler for the 32-bit ARM processor used in the SG-3100 appliance. There is no easy fix for that. I've explained why in several other threads. If running an IDS/IPS is important to you, then get off of ARM 32-bit hardware and move to either an Intel/AMD platform, or a 64-bit aarch64 platform. The Signal 10 error has been an issue with Snort (and sometimes Suricata) since the release of the 32-bit ARM hardware appliances. I've tried one patch in the past that consists of disabling compiler optimizations by essentially telling the llvm compiler to compile Snort with the debugging flags enabled. That appeared to have worked for a while, especially under FreeBSD-11 (which the 2.4.5 branch of pfSense used). It appears that as of FreeBSD-12 (which the new 2.5.x branch and higher of pfSense is using), that old debugging compiler flag may no longer be effective.