Messages

Am, almost, sorry.

But what is the news? Apparmor or SELINUX is default. Even in the CIS Benchmarks (Hardening Guidelines) its standard.
Furthermore this is not a Linux forum. OPNsense is built on UNIX.

Also this is not an IDS or even not an IPS....

At least, to give you some useful information: Check AIDE...

Hi,

found this thread after creating mine.

Seems I have a similar issue. Suricata logs ignoring rotation settings – RAM disk filling up

[Note:]

Hi everyone,

I'm running OPNsense on an NVMe SSD and have intentionally enabled the RAM disk option to minimize write operations to the disk. Since my setup runs 24/7, reducing unnecessary disk writes is important to prolong the SSD's lifespan.

To support this, I've enabled the RAM disk under System → Settings → Miscellaneous and configured logging under
Services → Intrusion Detection → Administration → Logging

Enable syslog alerts - Unchecked
Enable eve syslog output - Checked
Enable eve syslog output - Daily
Save logs - 1

Note: The logs of the FW are usually forwarded via syslog(UDP) to my SIEM


Despite these settings, Suricata continues to generate suricata_YYYYMMDD.log files in /var/log/suricata/, often reaching hundreds of MB in just a few days. These logs are not rotated or deleted, and they accumulate until the RAM disk is full.

Code Select Expand

root@xxx:/var/log/suricata # ls -lisah
total 115555
  28     1 drwx------   2 root wheel  1.4K Nov  4 08:01 .
   2     2 drwxr-xr-x  17 root wheel  1.8K Nov  4 03:01 ..
4320  1284 -rw-r-----   1 root wheel  1.3M Nov  4 08:49 eve.json
3970  4340 -rw-r-----   1 root wheel  4.2M Nov  4 00:00 eve.json.0
4456     0 lrwxr-x---   1 root wheel   39B Nov  4 08:01 latest.log -> /var/log/suricata/suricata_20251104.log
4319  1416 -rw-r-----   1 root wheel  1.4M Nov  4 08:49 stats.log
3969  3852 -rw-r-----   1 root wheel  3.8M Nov  4 00:00 stats.log.0
3619  3848 -rw-r-----   1 root wheel  3.8M Nov  3 00:00 stats.log.1
3269  3840 -rw-r-----   1 root wheel  3.7M Nov  2 00:00 stats.log.2
2919  3788 -rw-r-----   1 root wheel  3.7M Nov  1 00:00 stats.log.3
2569  3700 -rw-r-----   1 root wheel  3.6M Oct 31 00:00 stats.log.4
2218  3664 -rw-r-----   1 root wheel  3.6M Oct 30 00:00 stats.log.5
1866  3632 -rw-r-----   1 root wheel  3.5M Oct 29 00:00 stats.log.6
 558  1592 -rwx------   1 root wheel  1.6M Oct 25 00:00 suricata_20251024.log
 807 11384 -rw-------   1 root wheel   11M Oct 25 23:55 suricata_20251025.log
1158 11160 -rw-------   1 root wheel   11M Oct 26 23:59 suricata_20251026.log
1523 12652 -rw-------   1 root wheel   12M Oct 28 00:00 suricata_20251027.log
1874  9248 -rw-------   1 root wheel  9.0M Oct 29 00:00 suricata_20251028.log
2222  7644 -rw-------   1 root wheel  7.5M Oct 29 23:59 suricata_20251029.log
2577 10564 -rw-------   1 root wheel   10M Oct 31 00:00 suricata_20251030.log
2926  5636 -rw-------   1 root wheel  5.5M Nov  1 00:00 suricata_20251031.log
3276  3116 -rw-------   1 root wheel  3.0M Nov  2 00:00 suricata_20251101.log
3626  3216 -rw-------   1 root wheel  3.1M Nov  3 00:00 suricata_20251102.log
3974  4600 -rw-------   1 root wheel  4.5M Nov  3 23:58 suricata_20251103.log
4326  1376 -rw-------   1 root wheel  1.3M Nov  4 08:49 suricata_20251104.log

This already filled up /var/log, which resides in RAM – defeating the purpose of reducing disk wear and causing stability issues or log loss.

Expected behavior: With "Save logs: 1" and daily rotation, I would expect Suricata to keep only the most recent log (or just eve.json if syslog is enabled), and delete old ones automatically.

Questiosn:
Is this a known bug or expected behavior?
How can I disable or limit Suricata's suricata_*.log files reliably?
Is there an official way to only keep eve.json (for remote logging like to my SIEM) and avoid these legacy-style logs?
Do I need to manually patch suricata.yaml every time?

Any advice or official workaround would be greatly appreciated. Thanks!

Cheers,

fb

Du solltest am Ruckus-ICX-Stack das IGMP-Snooping im VLAN 9 deaktivieren oder die Multicast-Adresse 224.0.0.18 statisch zulassen, damit CARP-Ankündigungen zwischen den OPNsense-Knoten sauber durchkommen.

Das Problem liegt mit hoher Wahrscheinlichkeit daran, dass die Fritte oder der Switch die CARP-Multicasts bzw. ARP-Updates nicht korrekt weiterleiten, weshalb die Fritte die virtuelle IP (192.168.9.1) nicht zuverlässig der aktiven Firewall zuordnet.


Falls vorhanden, würde ich ggf. mal ein TAP dazwischen hängen und mit Wireshark anschauen.

Wenn da vorher ein PA Cluster hing, frage ich mich so echt und wirklich, warum zur Hölle eine Fritte? Das sind zwei Welten. Den ganzen VOIP Rotz, so meine Spekulation, bekommt man auch anders hin.

Ich hab hier keinen Cluster Betrieb, aber hatte nur Ärger mit der 7590. Von daher läuft hier nun ein Vigor 166. Beste Investition in meinen Kupferlink und besonders meine Nerven^


@Patrick: Ruckus ist nen klassischer Switch Hersteller. Ehemals Brocade. Ich hatte damit aber auch noch keine Berührungspunkte im DC

schalte mal nat reflection ein.

auf proxmox


dig @gw_dns_ip lalelu.com

sollte das nicht funktionieren mit dem korrekten FQDN, dann mehr infos geben. kA ob Du noch blocklists o.Ä installiert hast...

wenn ich mich nicht ganz falsch erinnere, lauscht die FW auf allen interfaces für http und ssh... das sollte man einstellen.

Auch bedenken, selbst wenn auf Interface igx* das mgmt lauscht, ohne floating rule können auch andere netze darauf zugreifen. ein wenig anders, als andere enterprise FWs, die nur das mgmt subnetz erlauben.

MTU und MSS anpassen. Notfalla iperf nutzen um die besten werte zu ermitteln.

Gut überlegen ob tun oder tap benötigt wird.

Außerdem hat openvpn einen massiven overhead. Nicht vergleichbar mit wireguard. Auch die Encryption settings haben einen Einfluß auf den throughput.

Sorry, ich habe nicht alles gelesen.


ping, traceroute(mtr), und nmap sollten dein Freund sein. Zudem das loggin einschalten.

Ohne alles gelesen zu haben, wundere ich mich,das WAN auf vlan9 sein soll... aber nun denn.


Im weiteren. FTP active oder passive? Ich gehe davon auf, dass der ftp server auch wirklich lauscht auf dem interface und die verbindung aus demselben subnetz funktioniert?

Hi,


I just verified it. In my case the floating rule is not needed. As the LAN rule will cover it. Tbh I was wondering why the floating rule is recommended, due to the flow from the origin is allowed on the GW itself, it will pass through the FW.

Q: Why is the floating rule in this case recommended?

I have a strange behavior what makes me really wonder....


So..... I tried to use the physical interface and gave it a mgmt ip. Like meyergru mentioned.

1. VIP removed
2. physical interface = UP. BLOCK bogon & private networks = enabled.
3. set IP x.x.x.2/30
4. have the NAT rule outbound. Limited to tcp 443 and only the .1 from my Workstation
5. Disabled the floating rule out of curiousity
=> I still can reach the Modem from my Workstation. My assumption is, as LAN can go everywhere, I do not need the floating rule at all.

Note: The Workstation is in my LAN. LAN is trusted zone and everything outgoing is allowed.


Ideas?

@meyergru

Bin ich da der einzige?

Ja...

Just to add something to this.

Many users  have to setup a vlan for pppoe to their ISP. In my case it's vlan 7 and its my WAN interface. The hardware interface is usually not not assigned and not up.

That means: If you follow this Tutorial, it won't work, as it would bind the VIP to VLAN 7. Therefore the connection will obviously fail. As the modem does not have its mgmt encapsulated in vlan 7.

To fix it:

1. Interface - Assignments: Add the physical device. For instance igc3. Give a name like "modem-mgmt" and hit save.
2. Under interfaces, choose the new interface "modem-mgmt" and enable the interface. You can select block private and bogon as well. No need to add an IP Address or anything else.
3. create the VIP as usual, pointing to that Interface.
4. create the NAT rule with the same interface.
5. create the flowting rule.

Notes: Due to security concerns, it makes absolutely sense to allow really only what is needed. (e.g TCP, HTTPS) For both rule and nat. And you might want to limit it to your workstation for later configuration. From my perspective there is no need to open the whole LAN subnet, or allow protocols and ports which are unneccesary.


Thanks @bucky2780 for your HowTo

I am sorry,but I dont think so.

It makes a huge difference. sometimes with a minor release you fix vulnerabilities, correct me if I am mistaken. But surely if this happens, users want to get notified about that.

So for instance if you fix a CVSS 10/10. I really don't think that you would release a major version. So it's would be usually a minor or even a fix _(whatever)

@franco

as plain as simple. getting notifyied if a new version comes out. What ever it is.

In fact "https://github.com/opnsense/core/commit/dbeed6fb7" did not help at all.

root@xxx:/var/log # configctl firmware changelog latest
25.7.3
root@xxx:/var/log # /usr/local/bin/check_opnsense_update.sh
NO_UPDATE: Current version: 25.7.3_7

so the commit was not helpful at all....