[asterisk-users] Deleting extension makes it usable?
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 ANSWERED00: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" ;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
Re: [asterisk-users] Deleting extension makes it usable?
On 08/06/10 14:50, J 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 ANSWERED00: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";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 Hi Were you using RealTime and/or allowing realtime caching? If so it is possible that the user/peer is still in the realtime cache even though the sip extension has been deleted from the DB Open the console and execute the following sip prune realtime 3799 If you get a response of pruned then that was the problem, if you get a response of not found then it's back to the drawing board Ish -- Ishfaq Malik Software Developer PackNet Ltd Office: 0161 660 3062 -- _ -- 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
Re: [asterisk-users] Deleting extension makes it usable?
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" >;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 _ 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 3...@whatever-context and see what turns up. murf On Tue, Jun 8, 2010 at 7:50 AM, J 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 ANSWERED00: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" > >;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
Re: [asterisk-users] Deleting extension makes it usable?
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 1-2. 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 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" > >;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 _ 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 3...@whatever-context and see what turns up. > > murf > > > > > > On Tue, Jun 8, 2010 at 7:50 AM, J 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 ANSWERED00: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" >> >;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 >>
Re: [asterisk-users] Deleting extension makes it usable?
Hi J, When I used FreePBX, I faced these situations occasionally. It is normal to see these entries in your CDR when hackers are trying to misuse your system. There doesn't need to be a real extension for it to appear it in the CDR. Based on what SIP URI the hacker sends, the CDR will display some entry in the 'src' field. In your case it is 3799 because the hacker or his software knows that once it was successful from this particular extension. Eventually you may see 3780, 3781 all the way up. The 'dst' s is the destination context in which FreePBX is dumping these SIP inbound calls. You can see in the CDR, in table 'dcontext'. If in the General Settings of FreePBX you have setup 'Allow Anonymous SIP Calls = no', which is the default, then this is the [from-sip-external] context, otherwise it is [from-trunk] context. Don't allow anonymous SIP calls and keep it 'no'. The hacker is trying to register on your system and hearing the no service message followed by the congestion tone. Having said this all, look into Fail2Ban. That would had blocked this hacker already at your kernel level at least. Zeeshan A Zakaria -- Sent from my Android phone with K-9 Mail. On 2010-06-08 9:59 AM, "J" 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 ANSWERED00: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" >;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 -- _ -- 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
Re: [asterisk-users] Deleting extension makes it usable?
Thank you all very much for your replies. I've gone ahead and made a
few tweaks that might help, including disabling anonymous inbound SIP
calls. I also exhaustively grepped /etc/asterisk for 3799, and there
are absolutely no occurances of it. The files do not include files in
any other directories, either.
However, upon deleting the extension, I still see entries in the call
log. Initially I thought these were actual calls, but is it possible
instead these are failed calls/attempts by this person? I ask after
poking around more in MySQL and seeing entries like the ones at the
bottom of this email. This seems to be in line with what Zeeshan said
("lastapp: Congestion"), but I'd like to confirm that's really the
case. If so, it sounds like I just need to block this person's IP so
he doesn't waste my valuable logging space!
Thank you again for your help,
J
*** 39607. row ***
calldate: 2010-06-08 13:14:26
clid: "asterisk" <3799>
src: 3799
dst: s
dcontext: from-sip-external
channel: SIP/206.205.124.247-09d71088
dstchannel:
lastapp: Congestion
lastdata: 5
duration: 12
billsec: 12
disposition: ANSWERED
amaflags: 3
accountcode:
uniqueid: 1276017266.1300
userfield:
*** 39608. row ***
calldate: 2010-06-08 13:14:38
clid: "asterisk" <3799>
src: 3799
dst: s
dcontext: from-sip-external
channel: SIP/206.205.124.247-09d0da80
dstchannel:
lastapp: Congestion
lastdata: 5
duration: 12
billsec: 12
disposition: ANSWERED
amaflags: 3
accountcode:
uniqueid: 1276017278.1301
userfield:
39608 rows in set (0.08 sec)
On Tue, Jun 8, 2010 at 11:44 AM, Zeeshan Zakaria wrote:
> Hi J,
>
> When I used FreePBX, I faced these situations occasionally. It is normal to
> see these entries in your CDR when hackers are trying to misuse your system.
> There doesn't need to be a real extension for it to appear it in the CDR.
> Based on what SIP URI the hacker sends, the CDR will display some entry in
> the 'src' field. In your case it is 3799 because the hacker or his software
> knows that once it was successful from this particular extension. Eventually
> you may see 3780, 3781 all the way up.
>
> The 'dst' s is the destination context in which FreePBX is dumping these SIP
> inbound calls. You can see in the CDR, in table 'dcontext'. If in the
> General Settings of FreePBX you have setup 'Allow Anonymous SIP Calls = no',
> which is the default, then this is the [from-sip-external] context,
> otherwise it is [from-trunk] context. Don't allow anonymous SIP calls and
> keep it 'no'. The hacker is trying to register on your system and hearing
> the no service message followed by the congestion tone.
>
> Having said this all, look into Fail2Ban. That would had blocked this hacker
> already at your kernel level at least.
>
> Zeeshan A Zakaria
>
> --
> Sent from my Android phone with K-9 Mail.
>
> On 2010-06-08 9:59 AM, "J" 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" ;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.a
Re: [asterisk-users] Deleting extension makes it usable?
See your extensions.conf for context [from-sip-external] and it'll all make
sense.
Install and configure Fail2Ban, search for instructions on voip-info.org and
make your life easier.
Zeeshan A Zakaria
--
www.ilovetovoip.com
On 2010-06-08 1:44 PM, "J" wrote:
Thank you all very much for your replies. I've gone ahead and made a
few tweaks that might help, including disabling anonymous inbound SIP
calls. I also exhaustively grepped /etc/asterisk for 3799, and there
are absolutely no occurances of it. The files do not include files in
any other directories, either.
However, upon deleting the extension, I still see entries in the call
log. Initially I thought these were actual calls, but is it possible
instead these are failed calls/attempts by this person? I ask after
poking around more in MySQL and seeing entries like the ones at the
bottom of this email. This seems to be in line with what Zeeshan said
("lastapp: Congestion"), but I'd like to confirm that's really the
case. If so, it sounds like I just need to block this person's IP so
he doesn't waste my valuable logging space!
Thank you again for your help,
J
*** 39607. row ***
calldate: 2010-06-08 13:14:26
clid: "asterisk" <3799>
src: 3799
dst: s
dcontext: from-sip-external
channel: SIP/206.205.124.247-09d71088
dstchannel:
lastapp: Congestion
lastdata: 5
duration: 12
billsec: 12
disposition: ANSWERED
amaflags: 3
accountcode:
uniqueid: 1276017266.1300
userfield:
*** 39608. row ***
calldate: 2010-06-08 13:14:38
clid: "asterisk" <3799>
src: 3799
dst: s
dcontext: from-sip-external
channel: SIP/206.205.124.247-09d0da80
dstchannel:
lastapp: Congestion
lastdata: 5
duration: 12
billsec: 12
disposition: ANSWERED
amaflags: 3
accountcode:
uniqueid: 1276017278.1301
userfield:
39608 rows in set (0.08 sec)
On Tue, Jun 8, 2010 at 11:44 AM, Zeeshan Zakaria wrote:
> Hi J,
>
> When I us...
--
Justin Maurer | System Administrator
2ergo – Digital leaders in a mobile world
+1 (703) 879 3413
--
_
-- Bandwidth and Colocation Pr...
--
_
-- 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
