Summary:	ASTERISK-16565: SIP INVITE
Reporter:	Jonathan M Bradshaw (jonathanmbradshaw)	Labels:
Date Opened:	2010-08-13 09:33:44	Date Closed:	2011-06-07 14:00:32
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) dumpFile-ALL-498092266901-0401.txt ( 1) dumpFile-ALL-498092266901-0945.txt ( 2) dumpFile-ALL-498092266901-2732.txt ( 3) full.21 ( 4) sip.conf-text
Description:	I have a set of logs, network traces etc which *may* illustrate a successful if accidental brute force attack on the ASTERISK SIP channel driver.   perhaps it is B/S but you may want to take a look - best regards Jonathan Additional info (net dumps etc) avail on request * Asterisk 1.6.2.7 built by mockbuild @ x86-03.phx2.fedoraproject.org on a i686 running Linux on 2010-05-05 13:14:21 UTC * Fedora 13 (32bit) 2.6.33.6-147.2.4.fc13.i686.PAE ****** ADDITIONAL INFORMATION ****** In-line trace removed - pabelanger
Comments:	By: Paul Belanger (pabelanger) 2010-08-16 10:03:59 We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt By: Paul Belanger (pabelanger) 2010-08-16 10:21:31 As a follow up, we would need to see your actual sip.conf file, without redacted information.  This will help to reproduce the issue. By: Jonathan M Bradshaw (jonathanmbradshaw) 2010-08-16 14:00:39 per your request a log file has been provided at "full.21" By: Jonathan M Bradshaw (jonathanmbradshaw) 2010-08-16 14:09:41 per your request a SIP config file has been added at "sip.conf-text" NB; - Comments have been removed (all after ';') - Passwords have been replaced with '*' By: Jonathan M Bradshaw (jonathanmbradshaw) 2010-08-16 14:11:19 A network trace for this event is available - best regards jmb By: Russell Bryant (russell) 2010-08-16 14:49:23 It's not clear to me what the problem is here.  What did you see in your logs/traces that indicates to you that there is a problem?  Specifically, what behavior have you observed that appears to be a bug in Asterisk? By: Jonathan M Bradshaw (jonathanmbradshaw) 2010-08-17 06:34:24 In the first place I don't believe that the SIP client is behaving as it should (RFC-3261).  That aside I do not understand the pattern of INVITE traffic in this trace, or in others that I have looked at; I expect the first 401 - UNAUTHORIZED message at 0366, based on my inspection of the RFC this is how the server is expected to provide authentication information so that the client can refine its next connection attempt. Based on my inspection of the network frames the INVITE at 6217 is the same as the previous INVITE and as expected it is 401'ed.  The RFC suggests that in the absence of any credentials the client should have sent 'anonymous' as the username and '' as the secret. I am OK so far but I am surprised that the INVITE at 6917 was successful.  In many respects 6917 is the same as the INVITES at 0365 and 6217 but there are some differences. I note that some of the SIP fields in 6917 have been malformed, the FROM, CONTACT and REMOTE-PARTY-ID have changed as follows; FROM 0365 From: "4980922559017" <sip:4980922559017@78.46.42.74>;tag=as08c7b904 6217 From: "4980922559017" <sip:4980922559017@78.46.42.74>;tag=as42f16889 6917 From: "004980922559017" <sip:004980922559017@78.46.42.74>;tag=as2ed270d5 CONTACT 0365 Contact: <sip:4980922559017@78.46.42.74> 6217 Contact: <sip:4980922559017@78.46.42.74> 6917 Contact: <sip:004980922559017@78.46.42.74> REMOTE-PARTY-ID 0365 Remote-Party-ID: "4980922559017" <sip:4980922559017@78.46.42.74>;privacy=off;screen=no 6217 Remote-Party-ID: "4980922559017" <sip:4980922559017@78.46.42.74>;privacy=off;screen=no 6917 Remote-Party-ID: "004980922559017" <sip:004980922559017@78.46.42.74>;privacy=off;screen=no This is a pattern which I have observed over a number of days, I have seen as many as 5 INVITES 401'ed but when a malformed INVITE is received it is admitted. In this example the change is the addition of '00', in other cases '00' has been replaced by '353' (the country code has been duplicated?). I hope this helps, best regards Jonathan PS : This system was upgraded to 1.6.2.10 before the test above.  Asterisk 1.6.2.10 built by mockbuild @ x86-20.phx2.fedoraproject.org on a i686 running Linux on 2010-08-02 21:14:50 UTC tcpdump, file name 2010-08-16-20-19 0365 INVITE 0366 401 - UNAUTHORIZED 6217 INVITE 6218 401 - UNAUTHORIZED 6917 INVITE 6920 100 - TRYING By: Paul Belanger (pabelanger) 2010-08-17 09:32:21 Set allowguests=no in your sip.conf and retest. By: Jonathan M Bradshaw (jonathanmbradshaw) 2010-08-18 09:31:11 OK guy's, call off the hunt!   I have isolated this issue to the configuration on the SIP server and I apologies for distracting everyone..   by way of an explanation, this is what I see happening; The incoming sip invite is checked against the list of peers (name first) in SIP.CONF and this results in a positive match.. In this example the e.164 pattern in the SIP invite is matched to a peer by the same name which is configured for the LAN (Cisco VoIP Phone on the private network), the credentials don't match and so the INVITE is 401'ed.  At a later stage the SIP client sends a malformed SIP INVITE which has '00' or '353' pretended to the number, this does not match any of the peers in SIP.CONF and is treated as expected.. My mistake, but thanks for your attention nonetheless! By: Paul Belanger (pabelanger) 2010-08-18 10:22:08 Closing, not an issue.