Hi,
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.
At this stage I'm not sure what they're trying to achieve, whether it's a successful call to one of their test numbers, or maybe they will brute force anything that returns a 401 later, or maybe they're waiting for a 18X response.
Below are three typical scenarios-
------ INVITE ------ > <--- 100 Trying --- <----- 200 OK ----- <----- 200 OK ----- <----- 200 OK ----- ( No ACK)
------ INVITE ------ > <-------- 503 -------- <-------- 503 -------- <-------- 503 -------- ( No ACK)
------ INVITE ------ > <-------- 401 -------- <-------- 401 -------- <-------- 401 -------- ( No ACK)
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.
Thanks
I am assuming you're adding Record-Route to your initial INVITEs?
If so, in the case of the answered call, it might be a defective UA that doesn't follow Record-Route for in-dialog messages (which include e2e ACK).
In the case of the negative replies, a scanner might not waste additional resources sending a formally requisite ACK. It'll just move on to the next target, and leave you holding the bag on the unacknowledged failed transaction.
-- Alex
Thanks for the speedy response as always.
The current scenarios are taken from Asterisk only, Kamailio is not yet in front of it - so no record route headers.
I imagine the ACKs aren't being sent due to it being a waste of resources as you suggest, but I'm interested in detecting these in Kamailio so I can add them to a block list if they exceed a certain limit.
On Tue, Apr 5, 2016 at 12:12 AM, Alex Balashov abalashov@evaristesys.com wrote:
I am assuming you're adding Record-Route to your initial INVITEs?
If so, in the case of the answered call, it might be a defective UA that doesn't follow Record-Route for in-dialog messages (which include e2e ACK).
In the case of the negative replies, a scanner might not waste additional resources sending a formally requisite ACK. It'll just move on to the next target, and leave you holding the bag on the unacknowledged failed transaction.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC 1447 Peachtree Street NE, Suite 700 Atlanta, GA 30309 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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)
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 10/04/16 21:57, Marrold wrote:
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?
If Kamailio matches the 200ok for transaction, then it should not give true for a timeout check. But maybe there is a mismatch also in kamailio if the 200ok is sent to caller but it is no ACK sent back. In such case, a sip network trace will be useful to investigate what happens there.
Cheers, Daniel
Hi,
On 06/04/16 01:57, Marrold wrote: Hi Charles,
I can confirm that t_any_timeout(), and t_branch_timeout() return true when these un-ACKd transactions occur.
by un-ACKed, do you mean they didn't receive any response or they didn't receive the ACK following a response to an INVITE?
I mean specifically the response to an INVITE was not ACK'd
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?
If Kamailio matches the 200ok for transaction, then it should not give
true for a timeout check. But maybe there is a mismatch also in kamailio if the 200ok is sent to caller but it is no > ACK sent back. In such case, a sip network trace will be useful to investigate what happens there.
In this scenario a 200ok is sent to the caller, but no ACK is sent back. This appears to return true for timeout checks. I will grab a SIP trace.
As a side note / update I figure I can potentially add a flag / AVP when a response and / or ACK is received and figure out the cause of the timeout from there.
Thanks for your assistance.
On Tue, Apr 12, 2016 at 7:57 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
On 10/04/16 21:57, Marrold wrote:
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?
If Kamailio matches the 200ok for transaction, then it should not give true for a timeout check. But maybe there is a mismatch also in kamailio if the 200ok is sent to caller but it is no ACK sent back. In such case, a sip network trace will be useful to investigate what happens there.
Cheers, Daniel
-- Daniel-Constantin Mierlahttp://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 12/04/16 17:33, Marrold wrote:
Hi,
On 06/04/16 01:57, Marrold wrote: Hi Charles,
I can confirm that t_any_timeout(), and t_branch_timeout() return true when these un-ACKd transactions occur.
by un-ACKed, do you mean they didn't receive any response or they didn't receive the ACK following a response to an INVITE?
I mean specifically the response to an INVITE was not ACK'd
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?
If Kamailio matches the 200ok for transaction, then it should not give true for a timeout
check. But maybe there is a mismatch also in kamailio if the 200ok is sent to caller but it is no > ACK sent back. In such case, a sip network trace will be useful to investigate what happens there.
In this scenario a 200ok is sent to the caller, but no ACK is sent back. This appears to return true for timeout checks. I will grab a SIP trace.
As a side note / update I figure I can potentially add a flag / AVP when a response and / or ACK is received and figure out the cause of the timeout from there.
You can also run with debug=3 in kamailio config to get more log messages in syslog. If there are too many, then use debugger module and set debug level to 3 only for tm module, then you should see if tm is matching the 200ok to a transaction.
Cheers, Daniel
Hello
On 06/04/16 01:57, Marrold wrote:
Hi Charles,
I can confirm that t_any_timeout(), and t_branch_timeout() return true when these un-ACKd transactions occur.
by un-ACKed, do you mean they didn't receive any response or they didn't receive the ACK following a response to an INVITE?
Cheers, Daniel
-
Alex Balashov -
Charles Chance -
Daniel Tryba -
Daniel-Constantin Mierla -
Marrold