[asterisk-users] Deleting extension makes it usable?

Tue Jun 8 10:15:28 CDT 2010

Since you mentioned FreePBX, unfortunately, it's not only the GUI that
drives the system and it can be that at some point someone planted
the extension in one of your .conf or other file if they had access to SSH
or some other way.

Going back to occurrence in sip.conf as mentioned, of course
FreePBX regenerates sip.conf every time and you can't tamper with it  but
sip_custom.conf or any other file can be called to just create
an extension in the non-GUI section and it will still work and not show up
in FreePBX GUI.

Recreating the extension probably over-wrote that or maybe supersedes that
and hence the failed authentication attempts.

If you can live with no SIP from outside, temporarily block any incoming on
5060 and 10000-20000.

To find the extension occurances in the .conf files, try this:

=> Delete the extension from FreePBX first and then:
cd /etc/asterisk
grep -o "3799" *.*

However, I think it's also possible to have the 3799 created in a totally
different directory in your server as long as it has the right
asterisk.asterisk permissions and it can be called by an #include from
sip_custom.conf. So, check that file out extensively.

-Bruce

On Tue, Jun 8, 2010 at 10:56 AM, Steve Murphy <murf at parsetree.com> wrote:

> I hope I'm correct, I don't have time to verify every bit of this,
> but....
>
> The message
>
> [Jun  7 17:04:16] NOTICE[7422] chan_sip.c: Failed to authenticate user
> "asterisk" <sip:3799 at 206.205.124.247 <sip%3A3799 at 206.205.124.247>
> >;tag=as23bacb61
>
> indicates the user "asterisk". Do you have a sip account for "asterisk"?
>
> Why it would take 14 seconds and an ANSWERED dial for an unathenticated
> use is something to investigate!
>
> As to the more general question of how 3799 could be unexpectedly matched
> in the dialplan, I would respond that there are several possibilities...
>
> One is, Is the account with the weak
> pword removed from sip.conf? The 3799 account? Because, it looks like
> SIP/206.20... (you abbreviated here in the CDR you listed) is where
> the call is originating.
>
> b. Did you *really* get rid of all 3799 occurrences in the dialplan? What
> patterns
> do you have in the dialplan that might match 3799, after the explicit 3799
> is removed?
> Any _XXXX type patterns included or in the context in question?
>
> c. I uncovered a pattern matching bug, and reported it in bug
> https://issues.asterisk.org/view.php?id=17366
> where unexpected patterns are matched. Sorry, I haven't had time to correct
> it myself, it's probably
> a simple 1-line fix, but oh, what it might take to figure out what the line
> should say, and where it is!
>
> d. "s" is the "start" extension, and an incoming call will tend to get
> routed into an "s" extension.
>
> You can quickly determine (b) or (c), by going to the CLI, and saying
> "dialplan show 3799 at whatever-context and see what turns up.
>
> murf
>
>
>
>
>
> On Tue, Jun 8, 2010 at 7:50 AM, J <jmaurer at 2ergo.com> wrote:
>
>> I'm fairly new to FreePBX/Asterisk/Trixbox, but have Googled myself
>> into submission here, so any assistance is appreciated.
>>
>> We had a user with a weak SIP secret recently that allowed it to be
>> used by an outside user. The extension was 3799. I could see the
>> intruder's calls (including the destination phone numbers) in the
>> trixbox call report log. Because the extension was no longer used, I
>> went ahead and deleted it, thinking that would solve the problem. I
>> also discovered approximately the same time that the Asterisk Call
>> Manager port was open to the outside world, which has since been
>> closed. The web interface, ssh, etc. have never been exposed to the
>> outside world. Since taking these actions, I restarted the asterisk
>> server.
>>
>> Now, here's the issue. I don't think deleting the extension helped.
>> Now I see entries like this in the reports log:
>>
>> Calldate  Channel Source Clid Dst Disposition Duration
>> 1.      2010-06-07 16:47:38     SIP/206.20...   3799    "asterisk"
>> <3799>       s       ANSWERED        00:14
>>
>> The "Dst" field being "s", where it used to be the phone number being
>> dialed. How is this extension able to be used even after it has been
>> deleted?
>>
>> Strangely, what I've done to keep the user out in the mean time is
>> re-created the 3799 extension with a better secret. This results in
>> log entries like the following:
>>
>> [Jun  7 17:04:16] NOTICE[7422] chan_sip.c: Failed to authenticate user
>> "asterisk" <sip:3799 at 206.205.124.247 <sip%3A3799 at 206.205.124.247>
>> >;tag=as23bacb61
>>
>> Why can sip:3799 connect and make calls when the extension doesn't
>> exist? Is this person somehow using a "user" account? I've checked
>> both /etc/asterisk and the MySQL tables and am not coming up with
>> much. What does it mean that their destination is "s", not a phone
>> number?
>>
>> Thanks for any assistance!
>> J
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>               http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
>
>
> --
> Steve Murphy
> ParseTree Corp
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100608/0146228b/attachment.htm 