Messages

You can enable remote logging on syslog-ng like this:

create a file /usr/local/etc/syslog-ng.conf.d/remote.conf with this:

Code Select Expand


source s_network {
    network(
        ip("192.168.1.1")
        transport("udp")
    );
};

destination d_syslog {
file("/var/log/syslog-ng/messages_${HOST}"); };

log { source(s_network); destination(d_syslog); };


# Create the directory
mkdir /var/log/syslog-ng

Stop syslog-ng
pkill -f /usr/local/sbin/syslog-ng

Start syslog-ng
/usr/local/sbin/syslog-ng -f /usr/local/etc/syslog-ng.conf -p /var/run/syslog-ng.pid

If you have a malicious client it can hammer your drive, and too much activity will bog you down.

After discussing on the maltrail page it appears the bug is with the python3 module for capturing traffic which is why it leaks based on traffic.

Reverting to python2.7 does not have this issue, I have confirmed this, and documented some of the steps below, I may have left some out but that is what I did:

# install ports tool not recommended for prod environments, I am just a home user that likes to cause trouble for himself.
opnsense-code ports tools
# Install python 2.7
cd /usr/ports/lang/python27
python2.7 -m ensurepip
# do not upgrade pip beyond version 21, it will break
pip2.7 install --upgrade "pip < 21.0"
# make sqlite 3 you need to set flavor to py27
cd /usr/ports/databases/py-sqlite3
make FLAVOR=py27 clean install
pip2.7 install sqlite3

# test if you have evrything you need from cli
python2.7 /usr/local/share/maltrail/sensor.py

If everything works you can update the rc file/usr/local/etc/rc.d/opnsense-maltrailsensor to change the command to use python 2.7
command_args="-f -P /var/run/maltrailsensor.pid python2.7 /usr/local/share/maltrail/sensor.py"

Thank you for chiming in, at least I know it is not my doing. I see the same pattern I think it may be traffic driven, I also see the same thing with Suricata eventually becoming unresponsive and that is when it becomes noticeable.
I am going to check on the maltrail issues and ask the devs what could be driving up the memory.

Looks like memory leak is not fixed today again the sensors were using several gigs of ram each, I am going to try to reproduce the issue on different environment, if anyone else is seeing the men leak please chime in.

I was having the same issue, I am now on 21.7.1 and issue still happens.

it has been stable for the past couple of hours after I did the following:

1. Set a maximum buffer size value on the admin UI for the sensor by default it takes 10% of available mem.
2. Cloned the latest maltrail from upstream and using that (kept my config file)

I too had issues with maltrail sensor.py was running out of memory, it seems to be working now.
This is what I did to fix it:
1. I set a maximum memory size for the sensor using admin ui
2. I also upgraded from github maltrail and replaced everything but the config.

I think the first step could have been the fix, just setting the limit, but the latest version has also newer rules and code changes.

Thank you all for the work into this project, I wanted to share the following.

I was having constant issues with maltrail sensor on the last releases, it was starving my box and causing swap and hangs.
I have a 16GB box with 4 cores ( 4 sensors get started )

I saw another reddit post few days ago and someone mentioned the upgrade would fix this as we would get maltrail 0.35

However the upgrade did not fix it for me.

I did the following and it seems to be running stable for the past couple of hours:
1. Set a max memory value for sensor of 900 MB by default it is supposed to use up to 10% of free mem
2. I used git pull to update the maltrail version in place to 0.36 ( I needed only to update the lists but it seems there were code changes too so I pulled in all changes, and kept my config)

I think the 1. st change is likely what fixed it, but if you continue having issues you can try and clone 0.36 and keep your conf file.