All,
thanks for the suggestions.
APIBAN looks fine but still there is the risk of packets from an unknown IP
to hit the server.
So I was thinking in patching the parser code to log the src IP in case of
error but when I tested sending an invalid message against latest kamailio
I got this in the logs:
2024-10-25T07:30:56.968878+09:00 lab225012
/usr/local/src/git/kamailio-5.8/kamailio[1404214]: ERROR: <core>
[core/parser/msg_parser.c:791]: parse_msg(): ERROR: parse_msg:
message=<NOTIFY sip:305@172.23.112.144 SIP/2.0#012#012Via: SIP/2.0/UDP
172.23.3.5:5060;branch=z9hG4bK7b359876#012From: "no_callerid" <
sip:no_callerid@172.23.3.5>;tag=as78a85cfe#012To:
<sip:305@172.23.112.144>#012Contact:
<sip:no_callerid@172.23.3.5>#012Call-ID:
015118886c22a1a45cb8833b41abf969(a)172.23.3.5#012CSeq: 102
NOTIFY#012User-Agent: Asterisk PBX#012Max-Forwards: 70#012Event:
check-sync#012Content-Length: 0#012>
2024-10-25T07:30:56.970881+09:00 lab225012
/usr/local/src/git/kamailio-5.8/kamailio[1404214]: ERROR: <core>
[core/receive.c:378]: receive_msg(): core parsing of SIP message failed (
10.0.0.1:57005/1)
So the function parse_msg itself will not log the src IP but the subsequent
ERROR log line from function receive_msg will have it (ip 10.0.0.1) and
will also include the port (57005).
So nothing needs to be done as fail2ban can get the ip with the proper
filter definition.
However there is at least one other scenario.
I removed the header Call-ID from a valid SIP message and when I sent it I
got just this:
2024-10-25T07:41:16.825827+09:00 lab225012
/usr/local/src/git/kamailio-5.8/kamailio[1404217]: ERROR: <core>
[core/receive.c:450]: receive_msg(): required headers not found in request
So I could not get the src IP. So am thinking in patching this.
However, meanwhile it seems I can handle this kind of situation generically
by using:
https://www.kamailio.org/docs/modules/devel/modules/nosip.html