StatusMAIL Issue

Hi.

I have detected a problem with the StatusMAIL Addon. I will explain it.

On some IPFires, not all, if the “Intrusion Prevention System - Alerts” option is checked, the process is blocked and no mail is sent. The only solution is to uncheck this option to make it work. Logically, it does not add this section to the report.

Some screenshots:


Statusmail goes to 100%. You have to kill the process.

[root@bs /]# /usr/local/bin/statusmail Test
(6) Starting log and status email processing
(7) Initialising plugin system_status_ps.pm
(7) Initialising plugin services_mail.pm
(7) Initialising plugin services_ups_apc.pm
(7) Initialising plugin services_intrusion_prevention_system.pm
(7) Initialising plugin system_ssh.pm
(7) Initialising plugin network_firewall.pm
(7) Initialising plugin hardware_media_space.pm
(7) Initialising plugin system_status_services.pm
(7) Initialising plugin system_internet.pm
(7) Initialising plugin services_clamav.pm
(7) Initialising plugin services_ipblacklist_update.pm
Use of uninitialized value $params{"subsection"} in hash element at /usr/local/bin/statusmail line 382.
Use of uninitialized value $params{"subsection"} in hash element at /usr/local/bin/statusmail line 382.
Use of uninitialized value $params{"subsection"} in hash element at /usr/local/bin/statusmail line 382.
(7) Initialising plugin services_ids_update.pm
(7) Initialising plugin graphs.pm
(7) Initialising plugin system_kernel.pm
(7) Initialising plugin services_urlfilter.pm
(7) Initialising plugin system_pakfire.pm
(6) Executing status mail schedule Test
(7) Process item Graph :: Hardware Graphs :: Load Graph

(process:7030): Pango-WARNING **: error opening config file '/root/.config/pango/pangorc': Permission denied

(7) Process item Graph :: Network :: firewallhits

(process:7031): Pango-WARNING **: error opening config file '/root/.config/pango/pangorc': Permission denied

(7) Process item Graph :: Network :: tun0

(process:7037): Pango-WARNING **: error opening config file '/root/.config/pango/pangorc': Permission denied

(7) Process item Graph :: System :: CPU Graph

(process:7038): Pango-WARNING **: error opening config file '/root/.config/pango/pangorc': Permission denied

(7) Process item Network :: Firewall :: Country - green0
(7) Process item Network :: Firewall :: Country - red0
(7) Process item Network :: Firewall :: IP address - green0
(7) Process item Network :: Firewall :: IP address - red0
(7) Process item Network :: Firewall :: Port - green0
(7) Process item Network :: Firewall :: Port - red0
(7) Process item Network :: Firewall :: Reason - green0
(7) Process item Network :: Firewall :: Reason - red0
(7) Process item Services :: Intrusion Prevention System :: Alerts

He stays at this point for hours and hours. You have to stop the process with Ctrl + C.

[root@bs statusmail]# ./test_plugin.pl plugins/services_intrusion_prevention_system.pm
Select Message format from the following options: html, text: html
Select Period covered by report from the following options: hours, days, weeks, months: weeks
Select weeks covered by report (1..365):1
Select Maximum lines per item (1..1000):10
Add item Servicios : Sistema de Detección de Intrusiones : Alerts ?
Select Prioridad minima (1..4):4

You launch this process and the same thing happens, it does not give any error but it stays here fried.

In “/var/log/httpd/error_log” appears this:

Use of uninitialized value $params{"subsection"} in hash element at /usr/local/bin/statusmail line 382.

TimF @timf , what data do you need to see the problem?.

BR.

OK.

I don’t think that the uninitialised variable is relevant - it’s because Statusmail is trying to get some information on a subsystem you’re not using.

The error with pango is something related to the text on the graphs. I don’t know why you’re getting the error - I don’t - but if the graphs are being generated OK, I’m not going to worry about it at this point.

The lock up on the Intrusion Prevention System :: Alerts is probably due to something causing the code there not detecting the end of the log file correctly. I can’t see anything wrong with the code at the moment, but I’ll have a closer look. I have seen something like it before in the more complicated code for reading the general message log - in that case there were circumstances were the rotation of the log files would cause the loop reading the file not to terminate, but to go back to the beginning.

Unfortunately, I don’t think there’s any information that you could give me that’ll help me sort it out. I’ll have a close look at the code and try to find the error.

I’ve had a close look at the code, and I still can’t see where the error is. Can you try running it again using test_plugin.pl and see if it still behaves the same way. Also what’s the result of ls -l /var/log/suricata?

Hi @timf.

Thanks for the reply. It seems that now in my IPFire (before it failed and the captures is from him) it works correctly. Perhaps over time the problem you may have has been solved or has been solved with the update with the 154 test.

It is very strange.

In any case, if it fails again, I will send you the information you ask for.

Greetings and thank you very much.