[asterisk-bugs] [JIRA] (ASTERISK-29230) pjsip: Asterisk goes crazy and massively spams logfile if registration can't be send

[Michael Maier (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253313#comment-253313 ] 

Michael Maier commented on ASTERISK-29230:
------------------------------------------

Yes, I'm pretty sure as tcpkill needs the local port - this port is changed after the old connection is dropped and the new connection is started.
That's how tcpkill is started:
{code}
tcpkill -i eth0 port 48067
{code}
48067 is the local port of the actual tls tcp connection to the ISP's server. After the new connection is built up, the local port changes - therefore, tcpkill doesn't work any more (even if you don't switch it off - one time I forgot it to switch off - the few RST-packages sent by tcpkill had no effect any more after there was a new connection with a new local port). Besides that, in the logfile of asterisk, you get only one time the connection reset info, e.g.:
{code}
[2021-01-07 06:59:03] DEBUG[4178] res_pjsip/pjsip_transport_events.c: Reliable transport 'tlsc0x7fdfe02f0388' state:DISCONNECTED
[2021-01-07 06:59:03] DEBUG[4178] res_pjsip/pjsip_transport_events.c: Reliable transport 'tlsc0x7fdfe02f0388' state:SHUTDOWN
...
[2021-01-07 06:59:21] DEBUG[8015] res_pjsip/pjsip_transport_events.c: Reliable transport 'tlsc0x7faf882eff68' state:CONNECTED
{code}

Regarding last changes - I have to take a look at my old logs. I fear, this problem isn't new ... .

> pjsip: Asterisk goes crazy and massively spams logfile if registration can't be send
> ------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29230
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29230
>             Project: Asterisk
>          Issue Type: Security
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 18.1.0
>         Environment: CentOS 7, x86_64
>            Reporter: Michael Maier
>            Assignee: Michael Maier
>            Severity: Blocker
>              Labels: fax, patch
>         Attachments: easybeltrace.png, forced-tcp-kill.tar.gz, no-abort.patch.tar.gz, obr_abort.patch
>
>
> If registration is impossible because of an error sending a packet, asterisk goes crazy and spams the log with > 6740(!) identical entries during 2 seconds like this one (-> no mediasec involved!):
> [2020-12-29 22:34:09] ERROR[4871] res_pjsip_outbound_registration.c: easybellPJSIP: Failed send registration to server 'sip:secure.sip.easybell.de' from client 'sip:[number]@secure.sip.easybell.de'
> There is a warning at the beginning of the spam attack:
> [2020-12-29 22:34:09] WARNING[3661] taskprocessor.c: The 'pjsip/outreg/easybellPJSIP-00000069' task processor queue reached 500 scheduled tasks.
> Another problem was at this time: The reRegistration started 14s too early (can't see any reason why)!  The first package seen in the pcap maps to the end of the timeline of the spam entries, means:
> - 6740 spam entries
> - first package seen in the pcap trace (written by asterisk)
> The account is a standard account, configured using tcp/tls.
> I consider this problem as a security problem, because it has the ability to kill a machine completely, depending on the machine's resources and the duration of the problem and the affected numbers in parallel (I could see the same problem some time later affecting 2(!) other numbers in parallel, but it luckily ended after about 0.1 seconds).



--
This message was sent by Atlassian JIRA
(v6.2#6252)