i have noticed lots of these kind of attacks in my syslog:
/var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/parse_cseq.c:95]: parse_cseq(): ERROR: CSeq EoL expected /var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/parse_cseq.c:98]: parse_cseq(): ERROR: parse_cseq: bad cseq /var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/msg_parser.c:161]: get_hdr_field(): ERROR: get_hdr_field: bad cseq
in order to be able to fail2ban the attacker, source ip address should appear in syslog message.
is there a way to catch sip request syntax errors in config file so that appropriate syslog message could be generated?
-- juha
On 8/21/13 12:53 PM, Juha Heinanen wrote:
i have noticed lots of these kind of attacks in my syslog:
/var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/parse_cseq.c:95]: parse_cseq(): ERROR: CSeq EoL expected /var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/parse_cseq.c:98]: parse_cseq(): ERROR: parse_cseq: bad cseq /var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/msg_parser.c:161]: get_hdr_field(): ERROR: get_hdr_field: bad cseq
in order to be able to fail2ban the attacker, source ip address should appear in syslog message.
is there a way to catch sip request syntax errors in config file so that appropriate syslog message could be generated?
We can add an event_route for it as well as print the src ip in the log message for quick fix (this one can be backported easy).
Cheers, Daniel
Actually nothing needs to be done in kamailio core. I's a simple scripting logic.
if(!sanity_check("whatever_you wan't_check")) { xlog("L_INFO","Malformed message from $proto:$si:$sp\n$mb\n"); break; }
On Thursday 22 August 2013 00:07:56 Daniel-Constantin Mierla wrote:
On 8/21/13 12:53 PM, Juha Heinanen wrote:
i have noticed lots of these kind of attacks in my syslog:
/var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/parse_cseq.c:95]: parse_cseq(): ERROR: CSeq EoL expected /var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/parse_cseq.c:98]: parse_cseq(): ERROR: parse_cseq: bad cseq /var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/msg_parser.c:161]: get_hdr_field(): ERROR: get_hdr_field: bad cseq
in order to be able to fail2ban the attacker, source ip address should appear in syslog message.
is there a way to catch sip request syntax errors in config file so that appropriate syslog message could be generated?
We can add an event_route for it as well as print the src ip in the log message for quick fix (this one can be backported easy).
Cheers, Daniel
The problem is that in some cases, it doesn't get to execute the config file at all. The core does some basic parsing to detect the type of message (request or reply) and looks for mandatory headers (CSeq is one of them). When its a failure in this process, the config file is not executed, because the message is invalid and the afferent internal structure cannot be filled properly.
Cheers, Daniel
On 8/22/13 12:18 AM, Sergey Okhapkin wrote:
Actually nothing needs to be done in kamailio core. I's a simple scripting logic.
if(!sanity_check("whatever_you wan't_check")) { xlog("L_INFO","Malformed message from $proto:$si:$sp\n$mb\n"); break; }
On Thursday 22 August 2013 00:07:56 Daniel-Constantin Mierla wrote:
On 8/21/13 12:53 PM, Juha Heinanen wrote:
i have noticed lots of these kind of attacks in my syslog:
/var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/parse_cseq.c:95]: parse_cseq(): ERROR: CSeq EoL expected /var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/parse_cseq.c:98]: parse_cseq(): ERROR: parse_cseq: bad cseq /var/log/syslog.1:Aug 21 04:23:46 host /usr/sbin/sip-proxy[13490]: ERROR: <core> [parser/msg_parser.c:161]: get_hdr_field(): ERROR: get_hdr_field: bad cseq
in order to be able to fail2ban the attacker, source ip address should appear in syslog message.
is there a way to catch sip request syntax errors in config file so that appropriate syslog message could be generated?
We can add an event_route for it as well as print the src ip in the log message for quick fix (this one can be backported easy).
Cheers, Daniel
Sergey Okhapkin writes:
Actually nothing needs to be done in kamailio core. I's a simple scripting logic.
if(!sanity_check("whatever_you wan't_check")) { xlog("L_INFO","Malformed message from $proto:$si:$sp\n$mb\n"); break; }
in this attack, my sanity_check call was not executed, i.e., config script was not executed.
-- juha
Daniel-Constantin Mierla writes:
We can add an event_route for it as well as print the src ip in the log message for quick fix (this one can be backported easy).
thanks for the quick fix. please backport to 4.0. for the next release, event_route would be nice to have so that the error message could be customized.
-- juha
On 8/22/13 7:11 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
We can add an event_route for it as well as print the src ip in the log message for quick fix (this one can be backported easy).
thanks for the quick fix. please backport to 4.0. for the next release, event_route would be nice to have so that the error message could be customized.
I backported the patch for the log message and now I pushed a patch that executes event_route[core:receive-parse-error] in such case as well, allowing for config interaction. Can you give it a test, I had no time to do it so far and have to go for a while. Otherwise I will do it sometimes soon.
Cheers, Daniel
Daniel-Constantin Mierla writes:
I backported the patch for the log message and now I pushed a patch that executes event_route[core:receive-parse-error] in such case as well, allowing for config interaction. Can you give it a test, I had no time to do it so far and have to go for a while. Otherwise I will do it sometimes soon.
daniel,
i tried with sipp by leaving out linefeed from request line:
INVITE sip:[service]@test.tutpro.com:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
and event_route:
event_route[core:receive-parse-error] { # Handle message with core syntax error
xlog("L_NOTICE", "Request from <$var(src_ip)> has invalid core syntax\n"); }
was NOT executed:
Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: INFO: <core> [parser/parse_fline.c:229]: parse_first_line(): ERROR:parse_first_line: bad request first line Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: INFO: <core> [parser/parse_fline.c:231]: parse_first_line(): ERROR: at line 0 char 42: Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: INFO: <core> [parser/parse_fline.c:237]: parse_first_line(): ERROR: parsed so far: INVITE sip:jh@test.tutpro.com:5060 SIP/2.0 Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: INFO: <core> [parser/parse_fline.c:242]: parse_first_line(): ERROR:parse_first_line: bad message Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: ERROR: <core> [parser/msg_parser.c:705]: parse_msg(): ERROR: parse_msg: message=<INVITE sip:jh@test.tutpro.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.98.102.10:5062;branch=z9hG4bK-3799-1-0#015#012From: sipp sip:sipp@192.98.102.10:5062;tag=3799SIPpTag001#015#012To: sut sip:jh@test.tutpro.com#015#012Call-ID: 1-3799@192.98.102.10#015#012CSeq: 1 INVITE#015#012Contact: sip:sipp@192.98.102.10:5062#015#012Max-Forwards: 70#015#012Subject: Performance Test#015#012Content-Type: application/sdp#015#012Content-Length: 137#015#012#015#012v=0#015#012o=user1 53655765 2353687637 IN IP4 192.98.102.10#015#012s=-#015#012c=IN IP4 192.98.102.10#015#012t=0 0#015#012m=audio 6000 RTP/AVP 0#015#012a=rtpmap:0 PCMU/8000#015#012> Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: ERROR: <core> [receive.c:148]: receive_msg(): core parsing of SIP message failed (192.98.102.10:5062/1)
after the last line, i would expect that event route is executed:
if (parse_msg(buf,len, msg)!=0){ LOG(cfg_get(core, core_cfg, corelog), "core parsing of SIP message failed (%s:%d/%d)\n", ip_addr2a(&msg->rcv.src_ip), (int)msg->rcv.src_port, (int)msg->rcv.proto); sr_core_ert_run(msg, SR_CORE_ERT_RECEIVE_PARSE_ERROR); goto error02; }
but it is not.
also, as you see in above, a syntax error produced awfully lot of messages to syslog, which is good for attacker. is it possible to turn some of them to debugs (e.g. the one that prints the whole message)?
-- juha
Hope I caught it and fixed now in master.
Regarding the verbosity, debug can be lowered, as one option that can be done now.
The second is to update the code so these log messages are printed to corelog level and change this value in config to be higher than debug:
http://www.kamailio.org/wiki/cookbooks/devel/core#corelog
Cheers, Daniel
On 8/22/13 2:39 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I backported the patch for the log message and now I pushed a patch that executes event_route[core:receive-parse-error] in such case as well, allowing for config interaction. Can you give it a test, I had no time to do it so far and have to go for a while. Otherwise I will do it sometimes soon.
daniel,
i tried with sipp by leaving out linefeed from request line:
INVITE sip:[service]@test.tutpro.com:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
and event_route:
event_route[core:receive-parse-error] { # Handle message with core syntax error
xlog("L_NOTICE", "Request from <$var(src_ip)> has invalid core syntax\n");
}
was NOT executed:
Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: INFO: <core> [parser/parse_fline.c:229]: parse_first_line(): ERROR:parse_first_line: bad request first line Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: INFO: <core> [parser/parse_fline.c:231]: parse_first_line(): ERROR: at line 0 char 42: Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: INFO: <core> [parser/parse_fline.c:237]: parse_first_line(): ERROR: parsed so far: INVITE sip:jh@test.tutpro.com:5060 SIP/2.0 Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: INFO: <core> [parser/parse_fline.c:242]: parse_first_line(): ERROR:parse_first_line: bad message Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: ERROR: <core> [parser/msg_parser.c:705]: parse_msg(): ERROR: parse_msg: message=<INVITE sip:jh@test.tutpro.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.98.102.10:5062;branch=z9hG4bK-3799-1-0#015#012From: sipp sip:sipp@192.98.102.10:5062;tag=3799SIPpTag001#015#012To: sut sip:jh@test.tutpro.com#015#012Call-ID: 1-3799@192.98.102.10#015#012CSeq: 1 INVITE#015#012Contact: sip:sipp@192.98.102.10:5062#015#012Max-Forwards: 70#015#012Subject: Performance Test#015#012Content-Type: application/sdp#015#012Content-Length: 137#015#012#015#012v=0#015#012o=user1 53655765 2353687637 IN IP4 192.98.102.10#015#012s=-#015#012c=IN IP4 192.98.102.10#015#012t=0 0#015#012m=audio 6000 RTP/AVP 0#015#012a=rtpmap:0 PCMU/8000#015#012> Aug 22 15:32:40 siika /usr/sbin/sip-proxy[3428]: ERROR: <core> [receive.c:148]: receive_msg(): core parsing of SIP message failed (192.98.102.10:5062/1)
after the last line, i would expect that event route is executed:
if (parse_msg(buf,len, msg)!=0){ LOG(cfg_get(core, core_cfg, corelog), "core parsing of SIP message failed (%s:%d/%d)\n", ip_addr2a(&msg->rcv.src_ip), (int)msg->rcv.src_port, (int)msg->rcv.proto); sr_core_ert_run(msg, SR_CORE_ERT_RECEIVE_PARSE_ERROR); goto error02; }
but it is not.
also, as you see in above, a syntax error produced awfully lot of messages to syslog, which is good for attacker. is it possible to turn some of them to debugs (e.g. the one that prints the whole message)?
-- juha
Daniel-Constantin Mierla writes:
Hope I caught it and fixed now in master.
i tried, but still no luck:
Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: INFO: <core> [parser/parse_fline.c:229]: parse_first_line(): ERROR:parse_first_line: bad request first line Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: INFO: <core> [parser/parse_fline.c:231]: parse_first_line(): ERROR: at line 0 char 42: Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: INFO: <core> [parser/parse_fline.c:237]: parse_first_line(): ERROR: parsed so far: INVITE sip:jh@test.tutpro.com:5060 SIP/2.0 Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: INFO: <core> [parser/parse_fline.c:242]: parse_first_line(): ERROR:parse_first_line: bad message Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: ERROR: <core> [parser/msg_parser.c:705]: parse_msg(): ERROR: parse_msg: message=<INVITE sip:jh@test.tutpro.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.98.102.10:5062;branch=z9hG4bK-21827-1-0#015#012From: sipp sip:sipp@192.98.102.10:5062;tag=21827SIPpTag001#015#012To: sut sip:jh@test.tutpro.com#015#012Call-ID: 1-21827@192.98.102.10#015#012CSeq: 1 INVITE#015#012Contact: sip:sipp@192.98.102.10:5062#015#012Max-Forwards: 70#015#012Subject: Performance Test#015#012Content-Type: application/sdp#015#012Content-Length: 137#015#012#015#012v=0#015#012o=user1 53655765 2353687637 IN IP4 192.98.102.10#015#012s=-#015#012c=IN IP4 192.98.102.10#015#012t=0 0#015#012m=audio 6000 RTP/AVP 0#015#012a=rtpmap:0 PCMU/8000#015#012> Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: ERROR: <core> [receive.c:148]: receive_msg(): core parsing of SIP message failed (192.98.102.10:5062/1)
Regarding the verbosity, debug can be lowered, as one option that can be done now.
in parser/parse_fline.c, i would like to make the first three L_DBG and change the last to L_ERR:
LOG(L_INFO, "ERROR:parse_first_line: bad %s first line\n", (fl->type==SIP_REPLY)?"reply(status)":"request");
LOG(L_INFO, "ERROR: at line 0 char %d: \n", offset ); prn=pkg_malloc( offset ); if (prn) { for (t=0; t<offset; t++) if (*(buffer+t)) *(prn+t)=*(buffer+t); else *(prn+t)='°'; LOG(L_INFO, "ERROR: parsed so far: %.*s\n", offset, ZSW(prn) ); pkg_free( prn ); }; error1: fl->type=SIP_INVALID; LOG(L_INFO, "ERROR:parse_first_line: bad message\n"); /* skip line */ nl=eat_line(buffer,len); return nl;
The second is to update the code so these log messages are printed to corelog level and change this value in config to be higher than debug:
thanks for the pointer. setting corelog=3 would get rid of the log message that prints whole message.
-- juha
On 8/22/13 5:24 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Hope I caught it and fixed now in master.
i tried, but still no luck:
Indeed, the efective execution of the actions was missing.
I will comment over the rest of proposed changes once I will check the sources.
Cheers, Daniel
Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: INFO: <core> [parser/parse_fline.c:229]: parse_first_line(): ERROR:parse_first_line: bad request first line Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: INFO: <core> [parser/parse_fline.c:231]: parse_first_line(): ERROR: at line 0 char 42: Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: INFO: <core> [parser/parse_fline.c:237]: parse_first_line(): ERROR: parsed so far: INVITE sip:jh@test.tutpro.com:5060 SIP/2.0 Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: INFO: <core> [parser/parse_fline.c:242]: parse_first_line(): ERROR:parse_first_line: bad message Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: ERROR: <core> [parser/msg_parser.c:705]: parse_msg(): ERROR: parse_msg: message=<INVITE sip:jh@test.tutpro.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.98.102.10:5062;branch=z9hG4bK-21827-1-0#015#012From: sipp sip:sipp@192.98.102.10:5062;tag=21827SIPpTag001#015#012To: sut sip:jh@test.tutpro.com#015#012Call-ID: 1-21827@192.98.102.10#015#012CSeq: 1 INVITE#015#012Contact: sip:sipp@192.98.102.10:5062#015#012Max-Forwards: 70#015#012Subject: Performance Test#015#012Content-Type: application/sdp#015#012Content-Length: 137#015#012#015#012v=0#015#012o=user1 53655765 2353687637 IN IP4 192.98.102.10#015#012s=-#015#012c=IN IP4 192.98.102.10#015#012t=0 0#015#012m=audio 6000 RTP/AVP 0#015#012a=rtpmap:0 PCMU/8000#015#012> Aug 22 18:15:18 siika /usr/sbin/sip-proxy[21745]: ERROR: <core> [receive.c:148]: receive_msg(): core parsing of SIP message failed (192.98.102.10:5062/1)
Regarding the verbosity, debug can be lowered, as one option that can be done now.
in parser/parse_fline.c, i would like to make the first three L_DBG and change the last to L_ERR:
LOG(L_INFO, "ERROR:parse_first_line: bad %s first line\n", (fl->type==SIP_REPLY)?"reply(status)":"request");
LOG(L_INFO, "ERROR: at line 0 char %d: \n", offset ); prn=pkg_malloc( offset ); if (prn) { for (t=0; t<offset; t++) if (*(buffer+t)) *(prn+t)=*(buffer+t); else *(prn+t)='°'; LOG(L_INFO, "ERROR: parsed so far: %.*s\n", offset, ZSW(prn) ); pkg_free( prn ); }; error1: fl->type=SIP_INVALID; LOG(L_INFO, "ERROR:parse_first_line: bad message\n"); /* skip line */ nl=eat_line(buffer,len); return nl;
The second is to update the code so these log messages are printed to corelog level and change this value in config to be higher than debug:
thanks for the pointer. setting corelog=3 would get rid of the log message that prints whole message.
-- juha
Daniel-Constantin Mierla writes:
I will comment over the rest of proposed changes once I will check the sources.
i guess you have been too busy to check this:
in parser/parse_fline.c, i would like to make the first three L_DBG and change the last to L_ERR:
LOG(L_INFO, "ERROR:parse_first_line: bad %s first line\n", (fl->type==SIP_REPLY)?"reply(status)":"request");
LOG(L_INFO, "ERROR: at line 0 char %d: \n", offset ); prn=pkg_malloc( offset ); if (prn) { for (t=0; t<offset; t++) if (*(buffer+t)) *(prn+t)=*(buffer+t); else *(prn+t)='°'; LOG(L_INFO, "ERROR: parsed so far: %.*s\n", offset, ZSW(prn) ); pkg_free( prn ); }; error1: fl->type=SIP_INVALID; LOG(L_INFO, "ERROR:parse_first_line: bad message\n"); /* skip line */ nl=eat_line(buffer,len); return nl;
one error level message should be enough about the same issue. the first two are clearly debug related.
-- juha
I thought I replied to this, but actually I couldn't find it, maybe I just had the intention to do it and then got distristracted by something else -- thanks for the reminder.
The proposed changes are fine with me, they can be committed.
Daniel
On 8/29/13 2:53 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I will comment over the rest of proposed changes once I will check the sources.
i guess you have been too busy to check this:
in parser/parse_fline.c, i would like to make the first three L_DBG and change the last to L_ERR:
LOG(L_INFO, "ERROR:parse_first_line: bad %s first line\n", (fl->type==SIP_REPLY)?"reply(status)":"request");
LOG(L_INFO, "ERROR: at line 0 char %d: \n", offset ); prn=pkg_malloc( offset ); if (prn) { for (t=0; t<offset; t++) if (*(buffer+t)) *(prn+t)=*(buffer+t); else *(prn+t)='°'; LOG(L_INFO, "ERROR: parsed so far: %.*s\n", offset, ZSW(prn) ); pkg_free( prn ); }; error1: fl->type=SIP_INVALID; LOG(L_INFO, "ERROR:parse_first_line: bad message\n"); /* skip line */ nl=eat_line(buffer,len); return nl;
one error level message should be enough about the same issue. the first two are clearly debug related.
-- juha