asterisk users - Sep 2019 - Security AccountID unknown - PJSIP

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

On Mon, Sep 30, 2019, at 10:52 AM, Administrator TOOTAI
wrote:
> 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 ?
There is not. Asterisk doesn't keep track of such things.

-- 
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 à 15:58, Joshua C. Colp a écrit :
> On Mon, Sep 30, 2019, at 10:52 AM, Administrator TOOTAI wrote:
>> 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
?
> 
> There is not. Asterisk doesn't keep track of such things.
> 
OK, thanks
-- 
Daniel