Hi Michael,
I might have found the reason for the problem or at least I was able to get
suricata-reporter running.
I had a go at reading through the suricata-reporter python code. I found a line
about setting the socket path that said
def socket_path(self):
return self.config.get("DEFAULT", "socket",
fallback="/usr/var/run/suricata/reporter.socket")
so I changed the last line to read /var/run/suricata/reporter.socket instead of
/usr/var...
and after that starting the suricata initscript also started the
suricata-reporter and I could see three processes running now, suricata,
suricata-watcher and suricata-reporter.
Will now test it out with some alerts.
Regards,
Adolf.
On 30/09/2025 12:20, Adolf Belka wrote:
Hi Michael,
On 30/09/2025 11:47, Adolf Belka wrote:
Hi Michael,
On 30/09/2025 11:19, Michael Tremer wrote:
Hallo Adolf,
You can simply remove any files in /var/spool/dma and make sure that there are
no sendmail processes running any more.
Regarding why the reporter is not sending any emails, we might need to dig
deeper.
If you kill the reporter when it is running as usual, you can start it again in
debug mode where it will stay in foreground and will log to the console what it
is doing. Maybe that will tell us a little bit more. Launch it again like this:
suricata-reporter --config=/var/ipfire/suricata/reporter.conf -vvv
I didn't even get to triggering an alert as suricata-reporter didn't even want
to start.
Single line error message
Failed to bind to socket: [Errno 2] No such file or directory
I tried restarting suricata from the cli and got the message that
suricata-reporter was not running from the stop step then after the start step
it said
Starting Intrusion Prevention Reporter...
[ OK ]
/etc/rc.d/init.d/functions: line 534: /var/run/suricata/reporter.pid: No such
file or directory
I found that the /var/run/suricata/ directory did not exist.
I created it and tried restarting suricata again and got
Stopping Intrusion Prevention System...
[ OK ]
Stopping Intrusion Prevention Reporter... Not running.
[ WARN ]
Starting Intrusion Prevention Reporter...
[ OK ]
Starting Intrusion Prevention System...
[ OK ]
But running the status command gave
suricata is running with Process ID(s) 8817.
/usr/bin/suricata-reporter is not running but /var/run/suricata/reporter.pid
exists.
So my creating the suricata directory has allowed the pid to be created but
suricata-reporter hasn't started because it still has the error message about
the socket. So creating the suricata directory in /var/run/ did not solve that
problem.
Regards,
Adolf.
Regards,
Adolf.
If you then trigger an alert, you should see some activity there and hopefully
some problem as well if the email cannot be sent.
Best,
-Michael
On 29 Sep 2025, at 17:50, Adolf Belka <[email protected]> wrote:
Further info on the mailq stuff.
I went to /var/spool/dma/ and read the contents of some of the files there.
Basically they are related to a problem with arpwatch and nothing to do with
suricata-reporter.
I will need to separately try and figure out what is happening to cause those.
There are 13 entries in the dma directory, all with the same date/time and I
checked three different entries and they were all related to arpwatch.
Regards,
Adolf.
On 29/09/2025 18:37, Adolf Belka wrote:
Without any new alerts being triggered by the IPS the dma logs showed more of
those messages about error creating mbox root.
I then triggered some more alerts in IPS and no new dma messages were seen.
I also checked the mailq output before and after triggering the alerts and
there were no additional entries compared to previously.
Regards,
Adolf.
On 29/09/2025 18:10, Adolf Belka wrote:
Hi Michael,
On 29/09/2025 17:44, Michael Tremer wrote:
Hello,
Thanks for testing this. So let’s go through this step by step…
First of all, is the companion daemon running? It is a process called
suricata-reporter.
I couldn't find it. Running ps aux | grep suricata showed suricata-watcher and
suricata but no suricata-reporter.
If so, can you check if the configuration file has emails enabled? It is in
/var/ipfire/suricata/reporter.conf.
Yes there is enabled = true in the [email] section.
And finally, can you run “mailq” to see if the emails have been sent and maybe
have bounced?
Ran that command and got a load of stuff but I don't understand it all all.
Here are just a few that were shown as examples
ID : 1a0794.335a3b40
From :
To : root
--
ID : 1a078b.335a3b40
From :
To : root
--
ID : 1a078a.335a3b40
From :
To : root
--
ID : 1a0789.335a3b40
From :
To : root
--
ID : 1a0788.335a3b40
From :
To : root
--
I am also seeing the following in the dma logs
17:15:00 dma[1a0792.335a3b40]: local delivery deferred: can not create
`/var/mail/root'
17:15:00 dma[1a0792.335a3b40]: error creating mbox `root'
17:15:00 dma[1a078c.335a3b40]: local delivery deferred: can not create
`/var/mail/root'
17:15:00 dma[1a078c.335a3b40]: error creating mbox `root'
17:15:00 dma[1a078a.335a3b40]: local delivery deferred: can not create
`/var/mail/root'
17:15:00 dma[1a078a.335a3b40]: error creating mbox `root'
17:15:00 dma[1a078e.335a3b40]: local delivery deferred: can not create
`/var/mail/root'
17:15:00 dma[1a078e.335a3b40]: error creating mbox `root'
17:15:00 dma[1a078a.335a3b40]: cannot execute /usr/lib/dma-mbox-create: No
such file or directory
17:15:00 dma[1a0788.335a3b40]: local delivery deferred: can not create
`/var/mail/root'
17:15:00 dma[1a0788.335a3b40]: error creating mbox `root'
17:15:00 dma[1a0790.335a3b40]: local delivery deferred: can not create
`/var/mail/root'
17:15:00 dma[1a0790.335a3b40]: error creating mbox `root'
17:15:00 dma[1a0792.335a3b40]: cannot execute /usr/lib/dma-mbox-create: No
such file or directory
17:15:00 dma[1a078c.335a3b40]: cannot execute /usr/lib/dma-mbox-create: No
such file or directory
17:15:00 dma[1a0792.335a3b40]: <root> trying delivery
17:15:00 dma[1a078c.335a3b40]: <root> trying delivery
Regards,
Adolf.
-Michael
On 29 Sep 2025, at 13:58, Adolf Belka <[email protected]> wrote:
Forgot to mention, I pressed the test button on the Mail Service WUI page and
immediately received the test mail message.
I use a mail server I have running on my local network.
Regards,
Adolf.
On 29/09/2025 14:52, Adolf Belka wrote:
Hi All,
I just ran the update for CU198 Testing on my vm systems.
The update itself went fine without any error messages or hiccups.
I then went to test the IPS emailing of alerts.
I used the same sender and recipient email addresses as I have specified on the
Mail Service WUI page.
I set the alert severity to All, Including Informational Alerts.
I then followed the suricata testing process as defined in
https://docs.suricata.io/en/suricata-8.0.1/quickstart.html#alerting
and I ended up with alerts in the IPS-Logs but no email message received.
I checked the System logs for the mail system and there was no message trying
to be sent. I ran the test 7 times, so ended up with 7 messages in the IPS-Logs.
I then checked the IPS system Logs and there was no mention of detecting the
alerts and trying to send an email.
I ran the command tail -f /var/log/messages so I could see any additional log
entries when I triggered the IPS alerts but again nothing was shown when I
triggered the alerts, although the messages did end up in the IPS Logs section.
Regards,
Adolf.
