[SR-Users] Detecting calls with missing ACK (Lazy SIP scanners)

[Marrold]

I've been doing some experimentation with t_any_timeout()
and t_branch_timeout(), and I've observed they return true if either the
initial invite receives no response, or if the 200 OK is not acknowledged
by the UAC.

Is there any way of differentiating between these scenarios?

Thanks


On Wed, Apr 6, 2016 at 12:57 AM, Marrold <kamailio at marrold.co.uk> wrote:

> Hi Charles,
>
> I can confirm that t_any_timeout(), and t_branch_timeout() return true
> when these un-ACKd transactions occur.
>
> I just needed to make sure that I set a failure route, in my reply route.
>
> Thanks for the tip.
>
> On Tue, Apr 5, 2016 at 1:56 PM, Charles Chance <
> charles.chance at sipcentric.com> wrote:
>
>> Hi,
>>
>> You should probably check out TM docs - specifically failure route (
>> http://kamailio.org/docs/modules/stable/modules/tm.html#tm.f.t_on_failure)
>> and t_is_expired (
>> http://kamailio.org/docs/modules/stable/modules/tm.html#tm.f.t_is_expired
>> ).
>>
>> From there you can do what you like.
>>
>> Cheers,
>>
>> Charles
>> On 5 Apr 2016 1:22 p.m., "Marrold" <kamailio at marrold.co.uk> wrote:
>>
>>> I am interested in 'fingerprinting' various SIP scanner attacks and
>>> using them to intelligently block attacks, rather than just blindly black
>>> listing any SIP message to a honey pot.
>>>
>>> Additionally I think it would be wise to detect these missing ACKs
>>> and/or incomplete transactions from a legitimately mis-configured or
>>> malfunctioning end point, to help protect the core network from needless
>>> re-transmissions.
>>>
>>> Having checked the Asterisk logs, this is what I'm looking to block if a
>>> certain threshold is exceeded-
>>>
>>> [2016-04-05 13:10:52] WARNING[2010] chan_sip.c: Retransmission timeout
>>> reached on transmission eff430b8c1b6d21c2058049f41a7ec57 for seqno 1
>>> (Critical Response)
>>>
>>> Thanks
>>>
>>>
>>> On Tue, Apr 5, 2016 at 1:14 PM, Daniel Tryba <d.tryba at pocos.nl> wrote:
>>>
>>>> On Tue, Apr 05, 2016 at 12:09:29AM +0100, Marrold wrote:
>>>> > I have been running a couple of Asterisk honey pots to get a better
>>>> > understanding of the tools and methods potential hackers are using to
>>>> > exploit SIP servers.
>>>> >
>>>> > I have observed many attacks from the 'sipcli' user agent that don't
>>>> send
>>>> > ACKs.
>>>> [...]
>>>> > Please could anyone point me in the right direction to detect these
>>>> non
>>>> > completed calls with a missing ACK in Kamailio? I am unsure on the
>>>> > terminology I should be using to search the online documentation.
>>>>
>>>> Why do you care? The attacker doesn't care about receiving SIP messages,
>>>> they are only interested in initiating a call to a target, if the target
>>>> gets dialled you will be abused, by either an other source with a fully
>>>> function SIP stack or just something that might be spoofed.
>>>>
>>>> What I do is blacklist addresses that send any SIP messages to my
>>>> honeypots, might be dangerous since with UDP anything can be spoofed (so
>>>> better make sure you have a whitelist and there is no connection between
>>>> the honeypots and your client facing SIP platform)
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
>> Birmingham Science Park, Birmingham B7 4BB.
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160410/6e452ff9/attachment.html>