Suricata can use a lot of RAM, but it usually does not give it back too readily. So, I'm a bit puzzled that you say the Dashboard shows 10% of RAM in use. I would expect that to be quite a bit higher -- and even more so with evidence of swap usage. You can increase the size of swap space, but when your box resorts to using any swap space your performance is totally in the toilet at that point. Swap is super slow. Using swap means there is not enough active RAM to hold everything that is executing, so areas of RAM associated with currently sleeping processes is written out to disk. Then, when the current process sleeps, its data is written out to disk and the previously written data is read back in to RAM for use by the former sleeping process when it becomes active. This is a highly inefficient (and very slow) process for multitasking and your performance tanks. So you almost never want to use swap.

For home usage you should split services; SquidGuard with Blacklists Blocks much more then I was expecting Snort with an Oink Code free Several books from Amazon are available to get in closer touch with it. pfBlocker-NG with I-Blocklist for ~10 € a year You might be really good sorted with many of them In short if you sort the things to do over more then one pfSense packet, often you will be getting a better service out for you or your company it self's! If you where reading something about IDS/IPS it makes more sense to come back and ask this or that function, about a problem and more points. You may think it is not really that books are outdated, old and whatever, but for getting an overview how it works and more makes you then also install only one rules, edit it and see for three month how many false positives you got and then you will starting the second rule once more for let us say three month and so on. What is the right mode for you, what is the most attacks you may be confronted with, what you want to secure and why. You may be also setting up Squid & SquidGuard as caching proxy in front of your LAN and lightSquid as an reserve proxy in front of your DMZ with the servers to get a better "not in contact directly with the internet" state of your network. Setting up public IPs directly on pfsense is one more point. Security is not one point and all is fine for you and IDS/IPS is not a set it up and forget it service. Book: (Amazon) IDS: Intrusion Detection (Trace search in the net) ~5 € Install TCPDump or WireShark and collect data and packets from your network, learn what is written in this packets, what are the meaning of the numbers and and and ....... Books: (Amazon) Network Intrusion Detection Snort 2.0 Intrusion Detection Snort Primer: A FAQ Based Introduction Managing Security with Snort and IDS Tools Then after you know this you will be setting up ids/ips and you only insert one rule after one rule and editing them that they match to you network and your situation. After you got a problem, @bmeeks might be better able to help you, without making an ids/ips basic course with you.

No, that feature is not available. One problem with implementing it is literal horizontal space on the web page. There is a finite amount of "width" available. So some compromises are needed to fit everything within the table without resorting to scrolling horizontally forever to see something. There has also not been a large demand for that feature. To the best of my recollection, you are the second user to ask about it in the history of the package.

@bmeeks yep thats what i thought. Thank you sir

@bmeeks Great description, well detailed. It's what I suspected. I compared the block.log and alert.log against the eve.json output and the relevant alerts matched what I found in alert/block.log.

Problem solved. Updated proxmox, chose iommu and threw 2 wan ports through iommu (igb). [image: 1662627505580-fe0d765e-0a81-41c8-aee9-9fc4f8d40280-image.png] [image: 1662627722397-5422af3e-d633-453d-a354-9ea9eb035fc3-image.png] root@pve:~# pveversion -v proxmox-ve: 7.2-1 (running kernel: 5.15.39-4-pve) pve-manager: 7.2-7 (running version: 7.2-7/d0dd0e85) pve-kernel-5.15: 7.2-9 pve-kernel-helper: 7.2-9 pve-kernel-5.13: 7.1-9 pve-kernel-5.11: 7.0-10 pve-kernel-5.4: 6.4-15 pve-kernel-5.15.39-4-pve: 5.15.39-4 pve-kernel-5.15.35-2-pve: 5.15.35-5 pve-kernel-5.15.35-1-pve: 5.15.35-3 pve-kernel-5.15.30-2-pve: 5.15.30-3 pve-kernel-5.13.19-6-pve: 5.13.19-15 pve-kernel-5.13.19-5-pve: 5.13.19-13 pve-kernel-5.13.19-4-pve: 5.13.19-9 pve-kernel-5.13.19-2-pve: 5.13.19-4 pve-kernel-5.13.19-1-pve: 5.13.19-3 pve-kernel-5.11.22-7-pve: 5.11.22-12 pve-kernel-5.11.22-5-pve: 5.11.22-10 pve-kernel-5.4.174-2-pve: 5.4.174-2 pve-kernel-5.4.166-1-pve: 5.4.166-1 pve-kernel-5.4.157-1-pve: 5.4.157-1 pve-kernel-5.4.143-1-pve: 5.4.143-1 pve-kernel-5.4.140-1-pve: 5.4.140-1 pve-kernel-5.4.106-1-pve: 5.4.106-1 ceph-fuse: 14.2.21-1 corosync: 3.1.5-pve2 criu: 3.15-1+pve-1 glusterfs-client: 9.2-1 ifupdown: residual config ifupdown2: 3.1.0-1+pmx3 ksm-control-daemon: 1.4-1 libjs-extjs: 7.0.0-1 libknet1: 1.24-pve1 libproxmox-acme-perl: 1.4.2 libproxmox-backup-qemu0: 1.3.1-1 libpve-access-control: 7.2-4 libpve-apiclient-perl: 3.2-1 libpve-common-perl: 7.2-2 libpve-guest-common-perl: 4.1-2 libpve-http-server-perl: 4.1-3 libpve-storage-perl: 7.2-8 libqb0: 1.0.5-1 libspice-server1: 0.14.3-2.1 lvm2: 2.03.11-2.1 lxc-pve: 5.0.0-3 lxcfs: 4.0.12-pve1 novnc-pve: 1.3.0-3 openvswitch-switch: 2.15.0+ds1-2+deb11u1 proxmox-backup-client: 2.2.5-1 proxmox-backup-file-restore: 2.2.5-1 proxmox-mini-journalreader: 1.3-1 proxmox-widget-toolkit: 3.5.1 pve-cluster: 7.2-2 pve-container: 4.2-2 pve-docs: 7.2-2 pve-edk2-firmware: 3.20220526-1 pve-firewall: 4.2-5 pve-firmware: 3.5-1 pve-ha-manager: 3.4.0 pve-i18n: 2.7-2 pve-qemu-kvm: 7.0.0-2 pve-xtermjs: 4.16.0-1 qemu-server: 7.2-4 smartmontools: 7.2-pve3 spiceterm: 3.2-2 swtpm: 0.7.1~bpo11+1 vncterm: 1.7-1 zfsutils-linux: 2.1.5-pve1

@bmeeks I can definitely attest to the fact that those JSON logs rack up very quickly. Bzip2 was the top running process on my box for some time. So instead of logging locally, it might just be better to SPAN the port and send to my security onion or graylog - basically something that can make sense of the data. Thanks for your input on this. I was really curious if the function could be written but not right now.

@jonathan_figueroa said in How serious should I take "invalid chunk size" and "double decoding attack" alerts?: Hello friend, I am in the same position. I have implemented pfsense in my organization. Snort is giving me the same alerts and blocks with Facebook and Whatsapp. I have disabled those blocks and alerts from the X however hours later it is blocking me again or showing alerts sometimes from the same IP or the IP block corresponding to 157.240.0.0/16. In my passlist I have put that IP block so that it does not consider it but it keeps giving me the same error. Did you manage to solve this kind of situations in any way? Translated with www.DeepL.com/Translator (free version) When you add addresses to a Pass List you must then do two other things to have the change seen by the running Snort process. First, you must assign the Pass List to the interface by going to the INTERFACE SETTINGS tab, scrolling down to the Pass List drop-down, and selecting the proper list. Then save the change. Second, you must then restart Snort on the interface because the Pass List file is only read and processed once during Snort startup. It is not dynamically processed. If you disable a rule or suppress an alert using the icons on the ALERTS tab, those changes are dynamic. When you click the icon, Snort is sent a SIGHUP signal that causes it to reload the rules and the assigned suppression list. I strongly recommend disabling ALL the HTTP_INSPECT rules as they result in a lot of false positive triggers with modern web traffic. For alerts from other rules, you will need to examine each alerting rule and determine if it represents a false positive or not. That unique skill is what makes one a good IPS/IDS admin. Doing it well requires training and experience.

@cool_corona said in Suricata dont block Torrents: @bmeeks But I dont see options to update to newer revisions like _4 You stated you are running pfSense 2.5.2. As has been stated here on the forums many times, once pfSense is updated, the package tree for the former version is frozen and receives no further updates. So 2.5.2 pfSense will never receive any of the Suricata updates that 2.6.0 CE and 22.05 pfSense Plus will get (until they are no longer the current release). And once 2.6.0 is updated by a newer release, then its package tree will also be frozen at whatever version it has on the day of the update. There is a separate directory of packages for each pfSense version. But only the current pfSense version tree is updated and recompiled against the new baseline pfSense version. Any older versions are frozen and get no further updates. And you can't install packages compiled for the newer (current) pfSense version on an older version as that is highly likely to break your installation due to the dependent library versions being different. So while you may have a reason for staying on pfSense 2.5.2, the downside that comes with that choice is you can't see- nor install- any of the updated packages in the Ports tree.

@bmeeks i did hping3 -S --flood -p 80 192.168.12.5 that's sir i added it on hping3

@vidorado said in Snort ignoring passlist: @bmeeks said in Snort ignoring passlist: then restart Snort on the affected interface. In my case this was the problem. I had updated the passlist and it was already assigned to the interface, even the IP list showing with "View List" button next to the dropdown was ok. But it keeped blocking the new IPs added to the passlist until I restarted the snort interface. Remember that the Snort package consists of two distinct parts. There is an underlying binary executable that runs as a service, and there is the PHP-driven GUI that generates the configuration files needed by the binary. When you make changes to Snort's configuration, those changes are written to one of the few text configuration files read by the binary. But the binary only reads those files once during startup. So any changes require restarting the binary so it can "see" the new configuration. The only exception to this is loading new rules. The binary can be signaled via SIGHUP to reload its rules file, but that is all. Other changes require a restart. When you "view a Pass List" in the GUI, all it is doing is reading the content of the Pass List text file and displaying it for you. If the text file has been rewritten, but the binary not restarted, then what the binary is using will not match what the GUI is showing.

@michmoor: So these are the alerts from the scan? If you are using Inline IPS Mode, then the rule is set to ALERT only according to the screenshot. If using Legacy Blocking Mode, then most likely your LAN and DMZ are both in the default Pass List and won't be blocked. The default Pass List includes all locally-attached networks on the firewall (except the WAN).

There is nothing to do unless you want to modify the Snort section of the config.xml file on the firewall and stuff the custom rules in there as Baee64 encoded text. The package always rewrites its configuration files from scratch each time the binary is started or restarted. Any customizations you make at the OS level are overwritten as you observed. The package is not designed for CLI interoperability. It has a GUI interface. If you want a pure CLI interoperable Snort installation, then abandon the pfSense GUI package and install the binary Snort package and do all the configuration by hand via the command-line.

Run the following from the pfSense command line:- logger -h 172.16.2.10 -P 514 TEST 172.16.2.10 < syslog server 514 < syslog server port Do the times match ?

@batre said in snort ignoring VIP adresses: @bmeeks it add the ip and alert to the supress list, but there are endless different alerts, so that doesnt work something like that im looking for : suppress ip XXX.XXX.XXX.XXX That mode of operation is not available. Suppression is a per-rule thing. You can suppress by source or destination IP, but only for a given GID:SID rule signature. So if your VIP is triggering many different rules, you will have to suppress it in each triggered rule. Another option you can explore is creating a custom PASS rule that includes just that VIP (or VIP collection if it is several). PASS rules are evaluated first, and any traffic matching a PASS rule bypasses the rest of the rule signatures. So be careful if you choose to try a PASS rule. Make it too encompassing and you will completely neuter Snort.