Page 1 of 1
Notifications sent to API, instead of mail
Posted: 20 Jul 2020, 17:35
by dandju20
Hello,
I was wondering if it would be possible to send lfd notifications like: login notification, suspicious process,... to an REST API endpoint/server, instead of sending them by email? In case of an email system failure, emails are not sent, but sending them to another (monitoring) system over eg. Https (to an API) would be a good alternative.
There seems to be an option to execute a script, but only when an IP got blocked?
If there is a way please let me know.
Thanks
Daniel
Re: Notifications sent to API, instead of mail
Posted: 14 Oct 2020, 13:01
by pluggi
I would also be interested in this option too.
Re: Notifications sent to API, instead of mail
Posted: 22 Apr 2021, 21:13
by idratis3
And this could make further customisation of the notifications possible, or use other channels as mail (opens the way for integration in a custum dashboard, or IFTTT, Zapier, SLACK, etc....
Re: Notifications sent to API, instead of mail
Posted: 12 Jan 2022, 16:02
by danfbach
This would be an excellent addition - perhaps you could allow csf to assume the current cpanel slack configuration? (if that's even possible?) That'd be pretty cool.
Re: Notifications sent to API, instead of mail
Posted: 13 Jan 2022, 09:04
by marcele
Just a note that CSF already supports this. Take a look at the BLOCK_REPORT option in /etc/csf/csf.conf. It's pretty easy to write a custom report script to log everything to an API.
Re: Notifications sent to API, instead of mail
Posted: 14 Jan 2022, 12:45
by idratis3
An example of use is here :
Perl :
https://gist.github.com/Bsebring/f3dd52 ... b681961a2d
Python :
https://gist.github.com/Bsebring/afcd0a ... 7ded2e9368
"# This file was written as an executable to be used in the auto report function
# of csf and lfd. By replacing $YOUR_API_KEY below with your abuseipdb api key,
# allows you to use this code to integrate your csf system with abuseipdb.com"
Re: Notifications sent to API, instead of mail
Posted: 14 Jan 2022, 13:01
by idratis3
From the readme.txt about "Block Reporting" on 2022-01-14
1/ Security : "It runs under the root account, so great care should be exercised with regard to security of the BLOCK_REPORT script"
2/ The arguments :
-----)
lfd can run an external script when it performs and IP address block following
for example a login failure. This is done by setting the configuration variable
BLOCK_REPORT to a script that must be executable. The following parameters are
passed the the script as arguments:
ARG 1 = IP Address # The IP address or CIDR being blocked
ARG 2 = ports # Port, comma separated list or * for all ports
ARG 3 = permanent # 0=temporary block, 1=permanent block
ARG 4 = inout # Direction of block: in, out or inout
ARG 5 = timeout # If a temporary block, TTL in seconds, otherwise 0
ARG 6 = message # Message containing reason for block
ARG 7 = logs # The logs lines that triggered the block (will contain
# line feeds between each log line)
ARG 8 = trigger # The configuration settings triggered
lfd launches the BLOCK_REPORT in a forked process which terminates after 10
seconds if not completed by then. It runs under the root account, so great care
should be exercised with regard to security of the BLOCK_REPORT script.
To also run an external script when a temporary block is unblocked by lfd.
UNBLOCK_REPORT can be the full path of the external script which must be
executable. The following parameters are passed the the script as arguments:
ARG 1 = IP Address # The IP address or CIDR being blocked
ARG 2 = port* # Port, there could be multiple unblocks for each IP
[*] If a port was specified in the initial block.
(-----