asterisk users - Sep 2019 - Security AccountID unknown - PJSIP

Hi list,

I would like to now what is the sense of such type of entry in security.log

[2019-09-27 15:12:24] SECURITY[26964] res_security_log.c: 
SecurityEvent="ChallengeSent",EventTV="2019-09-27T15:12:24.181+0200",Severity="Informational",Servic
e="PJSIP",EventVersion="1",AccountID="<unknown>",
SessionID="56b0ca9-d967a90d16411209-a1b0fae1 at
188.165.222.17",LocalAddress="IPV4/UDP/<MyAddress>/5060",
RemoteAddress="IPV4/UDP/<attackerIP>/5213",Challenge=""

We have a lot of such tries coming from IPs not allowed and fail2ban 
fail to ban them because of SecurityEvent not treated and Severity 
Informational.

We add a fail2ban filter to ban those IPs which is OK on our side but 
also means that attacker knows that account is not existing.

Any comment appreciate

Best Regards

-- 
Daniel

On Fri, Sep 27, 2019, at 11:31 AM, Administrator TOOTAI
wrote:
> Hi list,
> 
> I would like to now what is the sense of such type of entry in security.log
> 
> [2019-09-27 15:12:24] SECURITY[26964] res_security_log.c: 
>
SecurityEvent="ChallengeSent",EventTV="2019-09-27T15:12:24.181+0200",Severity="Informational",Servic
>
e="PJSIP",EventVersion="1",AccountID="<unknown>",
> SessionID="56b0ca9-d967a90d16411209-a1b0fae1 at
188.165.222.17",LocalAddress="IPV4/UDP/<MyAddress>/5060",
>
RemoteAddress="IPV4/UDP/<attackerIP>/5213",Challenge=""
> 
> We have a lot of such tries coming from IPs not allowed and fail2ban 
> fail to ban them because of SecurityEvent not treated and Severity 
> Informational.
> 
> We add a fail2ban filter to ban those IPs which is OK on our side but 
> also means that attacker knows that account is not existing.
> 
> Any comment appreciate
SIP uses a challenge/response mechanism for authentication. The above indicates
that a challenge was sent. The remote side is under no obligation to retry with
authentication and may choose not to. If they did and failed another message
would occur.

-- 
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

Le 30/09/2019 à 11:45, Joshua C. Colp a écrit :
> On Fri, Sep 27, 2019, at 11:31 AM, Administrator TOOTAI wrote:
>> Hi list,
>>
>> I would like to now what is the sense of such type of entry in
security.log
>>
>> [2019-09-27 15:12:24] SECURITY[26964] res_security_log.c:
>>
SecurityEvent="ChallengeSent",EventTV="2019-09-27T15:12:24.181+0200",Severity="Informational",Servic
>>
e="PJSIP",EventVersion="1",AccountID="<unknown>",
>> SessionID="56b0ca9-d967a90d16411209-a1b0fae1 at
188.165.222.17",LocalAddress="IPV4/UDP/<MyAddress>/5060",
>>
RemoteAddress="IPV4/UDP/<attackerIP>/5213",Challenge=""
>>
>> We have a lot of such tries coming from IPs not allowed and fail2ban
>> fail to ban them because of SecurityEvent not treated and Severity
>> Informational.
>>
>> We add a fail2ban filter to ban those IPs which is OK on our side but
>> also means that attacker knows that account is not existing.
>>
>> Any comment appreciate
> 
> SIP uses a challenge/response mechanism for authentication. The above
indicates that a challenge was sent. The remote side is under no obligation to
retry with authentication and may choose not to. If they did and failed another
message would occur.
 From security logs 26/09/2019 before we add our fail2ban rule:

EventTV="2019-09-26T14:32:06.516+0200",RemoteAddress="IPV4/UDP/66.117.9.138/52488"

EventTV="2019-09-26T14:32:45.748+0200",RemoteAddress="IPV4/UDP/66.117.9.138/57808"

EventTV="2019-09-26T14:33:25.300+0200",RemoteAddress="IPV4/UDP/66.117.9.138/63211"

EventTV="2019-09-26T14:34:04.527+0200",RemoteAddress="IPV4/UDP/66.117.9.138/51988"

In 2 minutes, the same IP address. We count 28862 tries from 11/09/2019 
to 26/09/2019 coming *ONLY* from this IP address :(, average being 80 
tries/hours.

If I understand you, there is no check between 2 authentication tries 
coming from the same IP address which doesn't reply to a challenge ?

Thanks for your support

-- 
Daniel