@Bob-Dig said in Problems with Suricata in pfSense on Proxmox running inline mode: Hyper-V doesn't use vtnet so sure, it won't run. I didn't mean to imply Hyper-V supported vtnet. Only mentioned Hyper-V because a number of other issues have been surfaced there by users attempting to run pfSense. My point was that these two hypervisors (Hyper-V and Proxmox) tend to show up most often when someone posts with a pfSense issue in a virtual environment. I notice much fewer issues posted when virtualizing pfSense in a VMware environment.

@Antibiotic I have not used the subscriber rules. I would only enable rules for the things you are protecting, for example web server rules. I do not think it would hurt to have overlapping rules, other than extra CPU time processing the packet twice.

@johnpoz yes it is, however it was not in the Talos Cisco IP list yet. I submitted a request to add that specific IP. That link you sent me has a IP list with a lot of them except it was missing that one address.

@mcury Obrigado, vou tentar criar apenas para a porta que estou sofrendo mesmo. Quanto ao DNS, eu realmente tenho um servidor DNS, que responde na porta 53. Quando alguém digita um endereço que esta no meu servidor, é consultado no registroBR que após isso joga para meu servidor certo? Isso nao estabeleceria uma conexão? A pergunta foi meio de curioso haha Sobre o Synproxy, achei bem interessante, se tiver alguma experiência sobre o uso, lhe agradeço. Vou fazer todos os testes amanhã: Pelo que vi na documentação: " Sinproxy Esta opção faz com que pf faça proxy de conexões TCP de entrada. As conexões TCP começam com um handshake de três vias. O primeiro pacote de uma conexão TCP é um SYN da origem, que provoca uma resposta SYN ACK do destino e, em seguida, um ACK de retorno da origem para completar o handshake. Normalmente, o host atrás do firewall cuidará disso sozinho, mas o estado synproxy faz com que o firewall conclua esse handshake. Isso ajuda a proteger contra um tipo de ataque de negação de serviço, as inundações SYN. Normalmente, isso só é usado com regras em interfaces WAN. Atualmente, esse tipo de ataque é melhor tratado no nível do sistema operacional alvo, já que todo sistema operacional moderno inclui recursos para lidar com isso por conta própria. Como o firewall não pode saber quais extensões TCP o host back-end suporta, ao usar o estado synproxy, ele anuncia que não há extensões TCP suportadas. Isso significa que as conexões criadas usando o estado synproxy não usarão dimensionamento de janela, SACK, nem carimbos de data/hora, o que levará a uma redução significativa no desempenho na maioria dos casos. Esta opção pode ser útil ao abrir portas TCP para hosts que não lidam bem com abusos de rede, onde o desempenho superior não é uma preocupação."

Okay. I think i understand. I thank you for your answers. I will try other ways to keep the malicious out.

@bmeeks I have Snort running on my local LAN. This is actually a durp moment. I had assigned a static IP to my local desktop because I was accessing a new managed switch I purchased to set the switch up for my network. I forgot to switch the desktop IP back. So while I was saying nothing existed at 192.168.3.2 it was actually the machine I was using to access everything. So False alarm.

Install the Suricata package and then from a command-line shell prompt in pfSense issue this command: suricata -V Post back here what that command shows. It should simply print the current binary version, but it might throw an error if there is an issue with your install. Also, have you looked under LOGS VIEW in the Suricata GUI and then selected your configured interface and the suricata.log file to see what shows there? Suricata very rarely refuses to start without printing a pretty good explanation of why. The only exception to this rule is if the actual install of the package fails to properly update some shared dependent libraries. But if that is the case, executing the CLI command I suggested above will show that.

@vmillan69 said in paquete snort 4.1.6_17 no se ven las alertas: since the last update of snort 4.1.6_17 for pfsense in aws version 23.09.1 I do not test Snort for compatibility with AWS installs as I have no way of doing that. If you use it on AWS, then you are on your own. But if it worked previously, I can tell you that nothing changed with the last update that had anything to do with alerting. So, I don't believe the Snort update is the only cause of your issue.

@cjca said in Suricata 7.0.4_1 and Snort 4.1.6_17 package update Release Notes: @bmeeks i am Carlos help please You have given me nothing to tell me what your problem is. It's the same as saying "I get in my car, but it won't go" . How can I help you unless you give me some information? What is the content of the suricata.log? Are there any Suricata related messages logged in the pfSense system log?

@xokia said in Alerts not being blocked: @xokia I think I may know what's going on. These are ageing out of the block list I had it set to 3 hrs. I increased it to 12 hrs That was going to be my first question: what interval has been set for "clear blocked hosts"? When an IP has not seen any additional traffic during the interval set for clearing blocked hosts, then the cron task will remove that IP from the snort2c pf table.

@PiotrIr Thanks for your post and thanks for everyone who replied. Helped me tremendously diagnosing my network performance issues. Performance stats gave me the root cause. I had the "SCADA Preprocessors" (I have no reason to) cause a massive decrease in speed. ...

What you desire is not really possible with Legacy Mode Blocking as it currently operates. It uses a pf table to implement the blocking. That table is created when pfSense initializes or reloads the firewall filter. IP addresses are added to the table, and because the table is the SOURCE and DESTINATION target of some built-in pfSense firewall rules, those IP addresses get blocked when inserted into the snort2c table. There is currently no sense of which interface those block rules apply to. They are global as you surmised. Implementing such a feature would be quite programming intensive as it would require a number of changes both in pfSense itself as well as the IDS/IPS packages.

The "352" is not a line number in the active rules file in this case. Instead, it is alerting you to an error in the Lua scripting for your OpenAppID rules. Something is wrong in OpenAppID, not in the ET Open ruleset. And remember that the Snort binary will always FAIL TO START when it encounters any type of error parsing the supplied rules. This is just the way it was engineered. Suricata will print errors, skip the offending rule, and keep loading the things that are okay. Snort will NOT do that. When it encounters any kind of error, it exits.

@bmeeks You are right. I have "zero" experience with managing an IPS. I really didn't understand what you meant before till I read your post about passlists. I was able to create a custom rule that pass DNS query to my specific domain. Thanks.

@bmeeks I really appreciate your help with answer my questions yesterday. Had to change a few backend services to listen on port 80 or another custom port (if its docker) that still sends data in the clear; in my case port 5100 So to answer anyone else's questions that stumble upon this post. Have Suricata listen in on the backend communications where the servers are located and make sure that backend communication is in clear text and not https. Some folks like to enable https on the backend as well but then you hurt your IDS chances of scanning payloads and alerting. As of now netmap only works on physical interfaces - no vlans. no trunking. I ended up breaking traffic flow to my DMZ segment yesterday due to netmap errors.

This appears to be an extraordinarily out-of-date system! You need to update both pfSense itself and then after that the Snort package. Current versions are 2.7.2 for pfSense and 4.1.6_17 for the Snort package. You are so far behind that pfSense cannot even read the new upgrade info to realize it is outdated. As for Snort, package versions are locked to the pfSense version they were compiled with. Snort in that pfSense branch is years out of date and will never be updated. The current underlying Snort binary version is 2.9.20 and the rules for Snort are locked to the binary version. It's possible the 2.9.9.0 rules package has been deprecated by the Snort team. In your case, the best course of action would be to backup the config, save it offline, then download and install the 2.7.2 CE version of pfSense. After installation, you can try importing the old config backup. Edit: I logged into the Snort VRT site and the rules archive for 2.9.9.0 has been removed. The oldest file there now is 2.9.11 while the current version is 2.9.20. Because rules versions are locked to the binary version, you can only use Snort VRT rules packages that match your binary version. Thus you will have to update both pfSense and Snort to their latest versions if you wish to continue using the package with updated rules.

A new package version (7.0.4_1) has been posted that contains the fix for this problem.

@bmeeks You are correct, I apologize. There were no red blocks in the alerts tab. I wrote that late last night. I will post the log tonight.

@nasheayahu said in Enabled Snort and Suricata Disabled?: @bmeeks said in Enabled Snort and Suricata Disabled?: What version of the Suricata package is installed on your system? [image: 1711426596717-screenshot_20240325_221429.png] Is there another way to verify the version installed? Also, note, I'm running pfSense with Suricate 7.0.4 in a virtual lab on a openSUSE Leap 15.5 Host Server, and its running fine, and no widget crashes. Hmm. That is the most recent version. The error is caused by a blank line in the alerts.log file for the interface. I've never deteremined how the blank line happens, but one theory is maybe during log rotation. You can do either of these to fix the Dashboard Widget problem: Open the file /var/log/suricata/suricata_xxxxx/alerts.log in an editor and find and remove any blank lines in the file. The xxxxx part of the directory path will be the physical interface name and a UUID identifying the specific Suricata interface. Go to the ALERTS tab and click the icon to clear out all alerts. That will erase the file and Suricata will start a new empty file.