| 00:18.27 | *** join/#asterisk TandyUK (~admin@TandyUK/staff/James) |
| 00:34.50 | *** part/#asterisk kharwell (kharwell@nat/digium/x-usudchstjnyeycws) |
| 00:41.05 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 01:24.06 | *** join/#asterisk infobot (ibot@rikers.org) |
| 01:24.06 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.18.4 (2017/12/13), Standard: 15.1.4 (2017/12/13); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
| 01:40.36 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 01:46.18 | *** join/#asterisk Perlon (minimalist@2a03:b0c0:0:1010::36:1) |
| 01:47.50 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:e866:955e:b53d:4291) |
| 02:08.14 | *** join/#asterisk rangotail (~rangotail@unaffiliated/rangotail) |
| 02:09.15 | *** join/#asterisk SoBlindWolf (~SoBlindWo@go.pcshost.co) |
| 02:38.30 | *** join/#asterisk s-mutin (~s-mutin@85.234.114.134) |
| 02:41.04 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 02:57.08 | *** join/#asterisk robink (~quassel@unaffilated/robink) |
| 03:21.05 | *** join/#asterisk overyander (~me@209.141.208.197) |
| 03:23.53 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 03:55.33 | *** join/#asterisk robinak (~quassel@unaffilated/robink) |
| 04:38.39 | *** join/#asterisk justdave (~dave@unaffiliated/justdave) |
| 04:54.37 | *** join/#asterisk paulgrmn_ (~paulgrmn@184.75.214.86) |
| 05:05.09 | *** join/#asterisk nafg (uid214603@gateway/web/irccloud.com/x-dvqwwmjboheywyec) |
| 05:53.27 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 06:20.36 | *** join/#asterisk evilman_work (~evilman@87.244.6.228) |
| 08:12.19 | *** join/#asterisk tehgooch (~tehgooch@unaffiliated/tehgooch) |
| 08:25.23 | *** join/#asterisk pchero_work (~pchero@109.70.54.56) |
| 09:06.57 | *** join/#asterisk Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 09:07.18 | *** join/#asterisk DanB (~DanB@clt-195.192.205.166.ip-anschluss.net) |
| 09:31.49 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
| 09:33.57 | *** join/#asterisk DanB (~DanB@clt-195.192.205.166.ip-anschluss.net) |
| 09:47.20 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 11:08.37 | *** join/#asterisk skirmisha (~skirmisha@213.16.62.70) |
| 11:08.41 | skirmisha | hi guys |
| 11:08.44 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 11:08.50 | skirmisha | can someone give me quick tip |
| 11:09.10 | skirmisha | in context i have several ext to dial... |
| 11:10.00 | skirmisha | is there a way to define global hangup for all of them when i have them in the list like exten => 100,1,Dial, exten => 200,1 Dial etc...? |
| 11:10.15 | skirmisha | i don't want to do hangup for each separately |
| 11:10.19 | skirmisha | but one for all |
| 11:16.12 | skirmisha | guys anyone here? |
| 11:18.30 | *** join/#asterisk catphish (~charlie@unaffiliated/catphish) |
| 11:18.30 | skirmisha | if i have priority 1 for each ext and then i do regexp with priority 2 will that match the next? |
| 11:19.15 | sibiria | don't quote me on it, but no, i don't think there's a way to define a global hangup context |
| 11:19.59 | sibiria | possibly via a hangup handler, though |
| 11:21.53 | sibiria | if i recall correctly you can specify a context for handlers, meaning you should be able to define a global one as long as you push that handler to every channel you create - but i have no experience with this, so i could be wrong |
| 11:23.53 | sibiria | oh, i may have misunderstood you - were you asking about having one and the same hangup flow for every extension in ONE context? |
| 11:24.05 | skirmisha | yes |
| 11:24.16 | sibiria | because that's how it works by default. you define -one- hangup for the context |
| 11:24.21 | sibiria | not one per extension set |
| 11:24.31 | skirmisha | correct |
| 11:24.34 | skirmisha | https://wiki.asterisk.org/wiki/display/AST/Contexts%2C+Extensions%2C+and+Priorities |
| 11:24.37 | sibiria | you don't need to define several |
| 11:24.39 | skirmisha | just saw it here |
| 11:24.59 | skirmisha | i did exten => _X.,n,Hangup() |
| 11:25.15 | skirmisha | It may not be immediately intuitive, but the "_.!" extension with the "n" priority will be executed after any of the preceding lines are executed. |
| 11:25.40 | *** join/#asterisk lankanmon (~LKNnet@CPE64777dd7e053-CM64777dd7e050.cpe.net.cable.rogers.com) |
| 11:28.18 | skirmisha | i have bunch of ext in the context, but want to define one single hangup for all of them |
| 11:28.29 | sibiria | as i said, that's how it works by default |
| 11:28.53 | skirmisha | yes, but matching is different |
| 11:29.03 | sibiria | whenever that context is hung up, you will end up in the 'h' extension for that context |
| 11:29.30 | skirmisha | because ext are like _100, _200, _300 etc... then i have final _X. which should be executed after that priority 2 |
| 11:30.02 | sibiria | and what's the problem? at the end of the entire context, just define your 'h' extension set |
| 11:30.16 | *** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff) |
| 11:30.34 | sibiria | it doesn't matter *where* in your context you will hang up, you will still be sent to that one 'h' extension on Hangup |
| 11:31.22 | sibiria | and if you don't want to specify Hangup everywhere, you can make use of auto fallthrough to end up in 'h' |
| 11:31.39 | sibiria | (some caveats apply) |
| 11:31.44 | skirmisha | i am not defining exten => h, but rather exten =< _X. |
| 11:32.26 | sibiria | i think there's a language barrier here. |
| 11:32.44 | skirmisha | ok let me explain it again |
| 11:33.38 | skirmisha | instead to have exten => 100,1, Dial then exten => 100,2, Hangup i want to make it exten => 100,1 Dial...exten => 200,1, Dial...last exten => X.,2, Hangup |
| 11:34.06 | skirmisha | will hangup be executed after first dial to whatever ext number? |
| 11:35.39 | sibiria | in that case, with the '2' prio there, i'm not really sure. but it's easily tested using a simple flow |
| 11:35.53 | sibiria | without thinking too much about it, i would make use of auto fallthrough |
| 11:36.33 | sibiria | when the dial plan for this or that extension comes to the end, asterisk will automatically send you to the most appropriate extension - if the call was considered connected, it will be hung up meaning you will end up in 'h' |
| 11:36.44 | sibiria | without having to specify a Hangup in some extension |
| 11:38.38 | skirmisha | the h ext does not allow me to modify hangup cause |
| 11:38.46 | skirmisha | tested already |
| 11:39.35 | sibiria | hangupcase is a built-in function. you can't write to it |
| 11:39.41 | skirmisha | ext h is just to execute the code after hangup |
| 11:39.52 | skirmisha | yes you can modify it |
| 11:39.54 | sibiria | hangupcause* |
| 11:40.24 | skirmisha | using ISDN values of it |
| 11:48.30 | *** join/#asterisk GoldenBear (~GoldenBea@hwsrv-209636.hostwindsdns.com) |
| 11:58.44 | EmleyMoor | I have a problem registering an Android Zoiper to my Asterisk box via IAX. The problem is basically that the phone uses the public IPv4 address of the Asterisk box, but the Asterisk box responds from its private address. There is no intervening router. Is there any way I can stop IAX working on the private address? (I don't actually need it to) |
| 11:59.50 | sibiria | skirmisha, https://pastebin.com/raw/nx7VujTU works fine |
| 11:59.57 | sibiria | with the ! matching |
| 12:00.02 | sibiria | ah, they left |
| 12:06.16 | catphish | am i right in thinking that all dns in pjsip is blocking? i'm considering how to resolve problems with DNS causing it to hang |
| 12:07.33 | EmleyMoor | Looks like I may well have fixed it with a bindaddr... |
| 12:09.52 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 12:11.31 | *** join/#asterisk mahafyi (~chatzilla@106.201.133.209) |
| 12:11.37 | sibiria | catphish: resolving a host has to be blocking, there's no way around it. the bigger question is perhaps if pjsip can handle dial plans in parallel |
| 12:11.55 | sibiria | instead of taking tasks in a FIFO manner |
| 12:12.34 | sibiria | asterisks threads a lot by default. it shouldn't be a problem if one channel is stalling |
| 12:13.52 | catphish | sibiria: i actually don't actually know what the thread model is like, but it's definitely the case that if enough channels are stalled on DNS, no other SIP packets are processes |
| 12:14.30 | sibiria | have you tried putting "the most common hosts" in your local hosts file to guarantee fast lookup to see if that confirms the problem? |
| 12:14.54 | catphish | sibiria: yes, and it does |
| 12:15.03 | sibiria | sounds like you're onto the problem then |
| 12:16.01 | catphish | sibiria: the problem that we had specifically was that one of our peers had a dns name somewhere in their SIP packets, asterisk was trying to resolve it, and hanging (because the authoritative DNS for the domain was offline) |
| 12:16.45 | catphish | immediately returning an NXDOMAIN for that domain resolves the problem, but it made me worry about the wider DoS implication |
| 12:17.07 | sibiria | yeah that definitely sounds like an attack vector |
| 12:17.25 | catphish | if someone accidentally (or worse deliberately) puts a bad domain name into sip requests, it can trivially take down pjsip |
| 12:18.11 | catphish | i don't know the threading model, but i do know that dns lookups block a thread, and it doesn't take many before it runs out (at least in my config) |
| 12:20.39 | catphish | i'm not really sure what the solution would be, maybe an async resolved in pjsip, but that's quite a complication, or a way to prevent unnecessary lookups, but i'm not sure this can be avoided while still allowing things like sip redirects |
| 12:21.39 | sibiria | a quick look through the pjsip settings doesn't reveal any immediate ways to configure the behavior, not even a timeout setting. it sure seems like a very easy problem to attack by just flooding with doctored hosts |
| 12:21.51 | sibiria | there's some limit to exactly how large threadpool you want to use, too |
| 12:21.56 | sibiria | not really a solution |
| 12:23.46 | catphish | i wonder if pjsip does have an async resolver in it, there's some google hits for those words |
| 12:24.08 | catphish | but i don't know enough about it to comment further |
| 12:27.20 | catphish | i do know is that when a major UK SIP provider accidentally started sending SIP responses with a non-existent domain in them, it caused at least 2 people's asterisk installations to stall at regular intervals, unfortunately while i understand the problem, i lack the skill to solve it, issue documented here: https://issues.asterisk.org/jira/browse/ASTERISK-27242 and I believe this was cased by the same issue https://issues.asterisk.org/jira/brow |
| 12:27.20 | catphish | se/ASTERISK-27247 |
| 12:29.27 | catphish | another more concise report, this time with an answer: https://issues.asterisk.org/jira/browse/ASTERISK-20317 |
| 12:31.06 | catphish | in fact, searching the issue tracker for "dns" reveals quite a few people talking about DNS lookups hanging chan_sip, where there's no thread pool to mitigate the problem |
| 12:32.14 | catphish | thanks anyway sibiria :) |
| 12:36.32 | sibiria | maybe easier to try control and mitigare this in the system's resolver. good luck |
| 12:38.36 | *** join/#asterisk eschmidbauer (~eschmidba@unaffiliated/eschmidbauer) |
| 12:38.54 | file | PJSIP DNS is async |
| 12:38.55 | eschmidbauer | good morning. are there asterisk debian 9 packages available? |
| 12:41.04 | catphish | file: really? that's pretty interesting then, i wonder why issues were occurring then |
| 12:41.12 | catphish | also good news |
| 12:41.20 | file | there is a case where it can still do a blocking DNS query |
| 12:41.32 | file | which is if you are using realtime with hostnames in identify configuration |
| 12:41.39 | sibiria | eschmidbauer: yes, asterisk is in the native debian repo |
| 12:41.50 | sibiria | 13.14 currently unless my memory is off |
| 12:41.57 | catphish | i don't really use realtime any more |
| 12:46.12 | eschmidbauer | oh nice. |
| 12:47.24 | eschmidbauer | im going to migrate from 1.6.X version... probably before pjsip was implemented... is chan sip still avail in 13.14 ? will there be a lot of "gotchas" migrating? |
| 12:47.51 | sibiria | eschmidbauer: it's still available |
| 12:48.06 | sibiria | i personally spent a bit of time getting into pjsip after using chan_sip |
| 12:48.17 | sibiria | and i didn't really have any advanced configuration going |
| 12:48.51 | sibiria | if it's worth the time is up to you - chan_sip still works |
| 12:49.11 | sibiria | it's just not getting the same amount of attention these days |
| 12:49.15 | eschmidbauer | ok cool |
| 12:49.26 | eschmidbauer | im sure i'll be back w more questions after the actual migration |
| 12:49.53 | catphish | i migrated to 13 last year, and made the decision it was worth moving to pjsip at the same time, i'd recommend doing so |
| 12:52.53 | *** join/#asterisk SoBlindWolf (~SoBlindWo@go.pcshost.co) |
| 12:55.08 | *** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff) |
| 13:05.56 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 13:13.01 | Kobaz | anyone know any carriers that have https fax (via audiocodes fax ata) other than vitelity ? |
| 13:33.44 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-157-202.satx.res.rr.com) |
| 13:38.28 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |
| 13:42.31 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 14:07.49 | Kobaz | heh, migrate from 1.6 |
| 14:07.51 | Kobaz | we're on 1.8 |
| 14:08.07 | Kobaz | i had to move a customer back to 1.8 from 11 yesterday due to timing issues in chan_sip |
| 14:08.21 | Kobaz | actually that's two customers i had to move to 1.8 from 11 this week |
| 14:09.37 | *** join/#asterisk nighty- (~nighty@s229123.ppp.asahi-net.or.jp) |
| 14:12.16 | [TK]D-Fender | meanwhile we're at * 15 |
| 14:12.25 | [TK]D-Fender | #antideluvian |
| 14:12.45 | Kobaz | right |
| 14:13.03 | Kobaz | that's like when pbxinaflash or whatever it was, was on 1.2 and 1.6 was out |
| 14:13.19 | Kobaz | i reaaaaly want to migrate to 15 badly |
| 14:13.38 | Kobaz | i need to add so much to my testing suite to make sure stuff wont break catistrophicly |
| 14:13.52 | Kobaz | i had *though* that 1.8 -> 11 would be a fairly clean move |
| 14:14.02 | Kobaz | but there's just subtle differences that cause problems |
| 14:14.27 | Kobaz | if you have straight up extensions.conf... phone A calls phone B and goes to voicemail |
| 14:14.35 | Kobaz | sure, just drop in the latest asterisk whenever possible, you're probably fine |
| 14:15.15 | Kobaz | but when you have an entire platform, AGI, AMI, and tracking of transfers and masquerades and all that shenanigans, it's not so pretty to do upgrades |
| 14:17.09 | Samot | 8:12:59 AM K<Kobaz> anyone know any carriers that have https fax (via audiocodes fax ata) other than vitelity ? <-- There's no such thing has a AudioCodes "FAX" ATA. |
| 14:17.16 | Kobaz | yes there is |
| 14:17.21 | Samot | They use the MP-202 which is just an ATA. |
| 14:17.27 | Kobaz | http://faxata.com/ |
| 14:17.30 | Kobaz | right |
| 14:17.41 | Kobaz | it's an ata that does t38 to a proxy |
| 14:17.54 | Kobaz | https to the far-end, which then dumps it to a real fax machine |
| 14:18.06 | Samot | It's an ATA |
| 14:18.09 | Kobaz | right |
| 14:18.16 | Kobaz | with HTTPS for faxing transport |
| 14:18.17 | Samot | You know that a Cisco SPA1x2 does this too? |
| 14:18.24 | Kobaz | No, i did not |
| 14:18.29 | Samot | It's TLS with t.38 support |
| 14:18.32 | Samot | It's not special |
| 14:18.34 | Kobaz | this is why I'm asking questions |
| 14:18.35 | Samot | It's a common option. |
| 14:18.54 | Kobaz | i really never got into faxing |
| 14:19.05 | Samot | 1) It will require the provider to support TLS. |
| 14:19.08 | Kobaz | other than plugging a fax into an FXS and it mostly works |
| 14:19.16 | Kobaz | and when it doesn't.. it's bad |
| 14:19.37 | Kobaz | good to know that the audiocodes isn't anything special |
| 14:19.52 | Kobaz | from the "papers" it sounds like they invented a new protocol |
| 14:19.58 | Samot | No. |
| 14:20.04 | Kobaz | If it's t.38 the whole way, that makes more sense |
| 14:20.05 | Samot | It's SIP over TLS |
| 14:20.09 | Samot | With t.38 support. |
| 14:20.24 | Samot | T.38 is just an encapsulation method. |
| 14:20.28 | Kobaz | right |
| 14:20.31 | Kobaz | soooo, knowing that... back to the origial question |
| 14:20.43 | Samot | First the provider needs to support TLS |
| 14:20.50 | Samot | Second they need to support T.38 |
| 14:20.51 | Kobaz | with modification.... what providers have a nifty fax portal, and do TLS t.38 |
| 14:21.13 | Kobaz | business partner of mine does vitelity vfax for everything |
| 14:21.13 | Samot | You're going to have to do research on that. |
| 14:21.19 | Kobaz | but, meh, their setup is a bit, meh |
| 14:21.41 | Kobaz | Samot: that's what I'm doing... research via community participation |
| 14:21.57 | Samot | What you are looking for is specific. |
| 14:22.04 | Kobaz | right |
| 14:22.09 | Samot | It would require people to have specifically asked for that service from their carrier. |
| 14:22.14 | Samot | Not all carriers do this |
| 14:22.17 | Kobaz | right |
| 14:22.26 | Samot | Not all carriers that support T.38/TLS have digital FAX platforms |
| 14:22.32 | Samot | The platform, itself, is a feature. |
| 14:22.35 | Kobaz | which is why if someone else was here, one of the 190 other people idling here... used a fax portal, they might chime in here |
| 14:23.16 | Kobaz | i'm not sure why we're arguing over the merits of polling #asterisk to see if someone used something similar... i think it's a proper venue for the question... people ask about ITSP's all the time |
| 14:23.28 | Samot | Digital FAX Platforms are more specific. |
| 14:23.35 | Samot | Because they generally don't involve Asterisk |
| 14:23.52 | Samot | And not all support "FAX Gateways" with their service. |
| 14:23.56 | Kobaz | right |
| 14:23.57 | Kobaz | of course |
| 14:24.06 | Kobaz | i'm not making any assumptions to that effect |
| 14:24.17 | Samot | Well RingCentral has a Digital FAX platform.. |
| 14:24.24 | Samot | No analog device support. |
| 14:24.34 | Kobaz | good to know |
| 14:24.49 | Samot | Digital FAX is generally a stand alone service |
| 14:24.55 | Kobaz | right |
| 14:24.57 | Kobaz | i know all this |
| 14:25.02 | Samot | Or a bundled service for Hosted Voice. |
| 14:25.21 | Samot | You may have to look at Digital FAX providers. |
| 14:25.36 | Samot | Those are ones that generally have their own platform because it's the only thing they do. |
| 14:25.44 | Kobaz | yeah |
| 14:26.25 | Kobaz | who knows, after i finish 2017 projects, we may just develop our own |
| 14:27.29 | Kobaz | i've thought about that for a while |
| 14:27.43 | Kobaz | i wrote a proof of concept store and forward with asterisk 11 using t.38 over the summer |
| 14:28.10 | Kobaz | it wouldn't be that much more of a chore to throw a gui on it and then progam t.38 atas to send out |
| 14:28.42 | *** join/#asterisk jkroon (~jkroon@165.16.204.170) |
| 14:32.08 | Samot | Well a Digital FAX platform generally has Fax to Email and Email to Fax |
| 14:32.16 | Kobaz | yeah |
| 14:32.31 | Kobaz | among other things |
| 14:32.31 | Samot | So you would need some sort of email server running SMTP with POP/IMAP |
| 14:32.43 | Samot | Need to be able to take attachments and process them |
| 14:32.46 | Kobaz | yeap |
| 14:32.56 | Kobaz | we already run email internally |
| 14:33.01 | Kobaz | wouldn't be a big deal |
| 14:33.02 | Samot | OK. |
| 14:33.09 | Samot | So now you need to process incoming email. |
| 14:33.14 | Kobaz | right |
| 14:33.15 | Samot | Tear it apart.. |
| 14:33.23 | Kobaz | yeah i have support for all that |
| 14:33.24 | Samot | Convert the attachments and then stream them out |
| 14:33.27 | Samot | OK. |
| 14:33.36 | Kobaz | we already do email processing for system alerts and whatnot |
| 14:33.43 | Kobaz | send attachments, receive attachments |
| 14:33.54 | Kobaz | it's really just putting a different spin on what we already have |
| 14:54.56 | *** join/#asterisk kharwell (kharwell@nat/digium/x-ndfdkoplzgaiddac) |
| 14:54.56 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:02.32 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:02.32 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 15:07.56 | *** join/#asterisk IzzyG (~IzzyG@108.41.159.2) |
| 15:16.34 | *** join/#asterisk IzzyG (~IzzyG@108.41.159.2) |
| 15:22.36 | tehgooch | I think snom's redirection service may be compromised somehow. Some Chinese and Italian IPs accessed our provisioning server and immediately downloaded config files for phones that were in the redirection service. Soon after Chinese and Italian IPs were registered to those extensions and making international calls. |
| 15:23.21 | tehgooch | Still investigating the issue at this point, but that's what it seems like at face value. |
| 15:24.45 | *** join/#asterisk bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 15:24.46 | *** mode/#asterisk [+o bford] by ChanServ |
| 15:25.19 | Kobaz | tehgooch: ACLs |
| 15:25.33 | Kobaz | tehgooch: for customers on static ips, it's an easy thing to do |
| 15:25.48 | tehgooch | Unfortunately almost none of our customers have static IPs. |
| 15:26.09 | tehgooch | I have been pushing to get them on them, but apparently that is a waste of money. |
| 15:26.12 | *** part/#asterisk catphish (~charlie@unaffiliated/catphish) |
| 15:26.27 | Kobaz | for dynamic it's a bit more complicated |
| 15:26.54 | Kobaz | we maintain whitelists based on succssful registrations, and then lock it down after the customer is initially set up |
| 15:27.14 | Kobaz | we have at least one phone in the office set up with an idle url, which is basically a form of port knocking |
| 15:27.19 | *** join/#asterisk zaf (~zaf@104.254.192.70) |
| 15:27.39 | Kobaz | so it refreshes a system status page which continually checks the ip and sees if it needs to get added to the whitelist |
| 15:27.56 | Kobaz | and then dynamically adjusts the ACLs |
| 15:27.58 | tehgooch | Kobaz, all good ideas, but unfortunately we don't have time to implement them currently. :( |
| 15:28.17 | Kobaz | so everyone in china and russia could download all the configs they want |
| 15:28.52 | tehgooch | yep, i've reported the risks, but it's been deemed to be lower priority |
| 15:29.07 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-bfhuuzqebnzbplah) |
| 15:29.08 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 15:29.21 | Kobaz | a business partner of mine who has another company... one of his customers was getting pwned almost every week |
| 15:29.27 | Kobaz | change provision passwords, change sip credentials |
| 15:29.34 | Kobaz | a few days later the phone's making high rate calls |
| 15:29.45 | Kobaz | i helped him block all the high rate destinations and set channel limits |
| 15:29.51 | tehgooch | Honestly it hasn't been an issue up until now, so maybe this will change upper management's mind. |
| 15:30.06 | Kobaz | but there's something living on the customer network that's actually logging into the polycoms and grabbing credentials from phone's directly |
| 15:30.58 | tehgooch | Welp I have to get ready to go into the office. Luckily I was awake and noticed the alerts. |
| 15:32.37 | Kobaz | apparently that's a thing... did a ton of research to find that one |
| 15:32.59 | Kobaz | malware will force a polycom to downgrade the firmware back to a version that shows credentials in plain |
| 15:33.17 | Kobaz | and then it grabs the login and starts making calls |
| 15:34.00 | *** join/#asterisk alejandrozf (c9ebb376@gateway/web/freenode/ip.201.235.179.118) |
| 15:37.16 | Samot | SNOM's redirection server is probably not compromised. |
| 15:37.22 | IzzyG | kobaz: haveyou seen such malware? where would it live? on a PC? or on a Polycom Phone ? |
| 15:37.31 | Samot | Since those services go "Oh this MAC belongs to X and should go here" |
| 15:37.34 | Kobaz | IzzyG: on a pc |
| 15:38.21 | Samot | IzzyG: The only way to force a firmware change is either via the GUI of the phone or the config files the phone uses. |
| 15:38.38 | Samot | So if it's on the PC I'm not sure how that would impact the phone. |
| 15:38.57 | Samot | Unless the PC was compromised, they figured out what IP the phone was on and then got to the phone GUI. |
| 15:39.12 | Kobaz | right, i'm talking about compromised machines |
| 15:39.13 | IzzyG | i have not heard of such malware in the past. in our deployments, majority of the time the phones are on a different network then the PC's.. |
| 15:39.33 | Kobaz | rogue dhcp... etc... you can do all kinds of crap to steal credentials |
| 15:39.33 | Samot | Kobaz: That's a serious compromise. |
| 15:39.49 | *** part/#asterisk alejandrozf (c9ebb376@gateway/web/freenode/ip.201.235.179.118) |
| 15:39.52 | Samot | Because they are now getting the phone's IP and GUI somehow? |
| 15:40.03 | Samot | By having a PC compromised. |
| 15:40.06 | Kobaz | Samot: that's SUPER easy on a flat network |
| 15:40.06 | Kobaz | right |
| 15:40.17 | Kobaz | nmap will show you ip phones within seconds |
| 15:40.19 | Samot | How do they access the phone? |
| 15:40.28 | Samot | Through the PC? |
| 15:40.34 | Samot | Through the network? |
| 15:40.38 | Kobaz | rogue dhcp, phone reboots, grabs new firmware |
| 15:40.48 | Samot | From? |
| 15:40.51 | Kobaz | "new" ie "old" |
| 15:40.53 | Samot | That's now how those phones work. |
| 15:41.01 | Samot | not |
| 15:41.11 | Kobaz | depends on the phones |
| 15:41.28 | Samot | OK. So via the Polycom GUI.. |
| 15:41.35 | Samot | You must first select where you want to get the firmware from.. |
| 15:41.39 | Samot | Then it makes a request |
| 15:41.44 | Kobaz | right |
| 15:41.47 | Samot | Shows you a list of firmware to choose from. |
| 15:41.55 | Samot | So how is a rogue DHCP server forcing this? |
| 15:42.01 | Kobaz | pushing new provisioning |
| 15:42.06 | Samot | HOW? |
| 15:42.13 | Kobaz | umm... option 66 |
| 15:42.17 | Kobaz | like everyone else |
| 15:42.20 | Samot | OK. |
| 15:42.23 | Samot | So they got into a PC |
| 15:42.30 | Samot | Then got into the DHCP server. |
| 15:42.39 | Kobaz | not necessarily 'the' dhcp server |
| 15:42.45 | Kobaz | hence, rogue |
| 15:42.50 | *** join/#asterisk pkx2 (~pkx@unaffiliated/pkx) |
| 15:43.04 | Kobaz | a flat, unmanaged network, is *very* succeptable to all kinds of attacks like this |
| 15:45.17 | Kobaz | if you have the bareist of minimum management, ie, dhcp snooping. Voice vlans. Most of this goes away |
| 15:45.17 | *** join/#asterisk salviadud (~salviadud@201.163.226.6) |
| 15:45.19 | Samot | OK. |
| 15:45.37 | Samot | So somehow people never noticed their phones reboot and their layouts looking completely different. |
| 15:46.24 | Kobaz | i know you're paying devils advocate, but end-users are generally ill-prepared to notice anything |
| 15:46.34 | Kobaz | most setups are 'standard' |
| 15:46.48 | Kobaz | out of the box sip.cfg, and the phone looks like any other phone |
| 15:47.13 | Kobaz | you may customize the heck out of your setups, but not everyone does |
| 15:48.29 | Samot | 10:30:04 AM K<Kobaz> but there's something living on the customer network that's actually logging into the polycoms and grabbing credentials from phone's directly <-- For this statement to be true it would not be "Option 66" or a "Rogue DHCP" they are logging into the phone. Which is what my questioning was based on. |
| 15:48.50 | Samot | Which then begs the question "Did they change the default user/admin passwords?" |
| 15:49.04 | Samot | Because you said provisioning passwords and SIP creds were changed.. |
| 15:49.14 | Kobaz | right |
| 15:49.18 | Samot | Nothing about the phones actual security... |
| 15:50.32 | Kobaz | i don't recall that detail of the incident... it may have been default admin credentials |
| 15:53.27 | Kobaz | i don't know how exactly what/where/when/why of the stealing credentials |
| 15:53.52 | Kobaz | but i'm throwing out items that are directly related and likly avenues for the attack |
| 15:54.15 | Kobaz | basically putting in a new router, re-imaging local pcs and changing EVERY password was what finally resolved the issue |
| 15:54.26 | Kobaz | SOMETHING was compromised on the local network |
| 15:54.42 | Kobaz | at that point, very little on the lan was trustworthy |
| 16:02.05 | *** join/#asterisk bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 16:02.05 | *** mode/#asterisk [+o bford] by adams.freenode.net |
| 16:45.23 | *** join/#asterisk tafa2 (~tafa2@t.ldn.dsrtnet.com) |
| 16:50.42 | *** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff) |
| 17:32.43 | *** join/#asterisk pchero (~pchero@109.70.54.56) |
| 17:33.52 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
| 17:45.08 | *** join/#asterisk Hyper_Eye (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
| 17:47.57 | *** join/#asterisk Penguin (~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net) |
| 17:52.37 | *** join/#asterisk Demon_VoIP (~demon@109.60.222.253) |
| 17:54.28 | *** join/#asterisk paulgrmn_ (~paulgrmn@184.75.214.86) |
| 17:54.39 | Demon_VoIP | asterisk 15.1.4. pjsip_realtime. Error: res_pjsip_outbound_registration.c: Invalid outbound proxy URI 'lr' specified on outbound registration |
| 17:54.56 | Demon_VoIP | value, for example: sip:195.239.174.100;lr What's wrong? |
| 17:55.44 | Demon_VoIP | and the same: config_options.c: Error parsing contact=transport=TLS at line 0 of |
| 17:56.46 | *** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff) |
| 17:57.55 | *** join/#asterisk mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 17:58.14 | Demon_VoIP | file wrote it is correct value: https://community.asterisk.org/t/pjsip-anonymous-endpoint-dialing-via-proxy/65857/7 |
| 17:58.32 | file | you need a \ in frnt |
| 17:58.33 | file | er front |
| 17:58.40 | Demon_VoIP | it is realtime |
| 17:58.45 | Demon_VoIP | not config file |
| 17:59.00 | file | do you have ^3B in front? |
| 17:59.02 | Demon_VoIP | config file i use \;lr of course |
| 17:59.32 | Demon_VoIP | file, do i need write \; in db field value (realtime)? |
| 17:59.43 | file | in realtime you put ^3Blr |
| 18:00.00 | Demon_VoIP | thanks. i'll try |
| 18:00.41 | Demon_VoIP | i test realtime to avoid hangs :( But.. i afraid it'will not help me |
| 18:02.02 | Demon_VoIP | i guess the reason of hangs is pjsip reload (offten). But... My first try of realtime hanged task processors after 10 secs |
| 18:05.05 | *** join/#asterisk sekil (~sekil@cable-89-216-223-209.dynamic.sbb.rs) |
| 18:08.45 | *** join/#asterisk miralin (~Thunderbi@81.177.59.227) |
| 18:10.43 | *** join/#asterisk Penguin (~xwQ5kwYl6@our.systems.are.full.of.penguins.at.penguinsystems.net) |
| 18:17.10 | *** join/#asterisk sekil (~sekil@cable-89-216-223-209.dynamic.sbb.rs) |
| 18:18.53 | *** join/#asterisk jamesaxl (~James_Axl@109.172.62.242) |
| 18:31.21 | *** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff) |
| 18:52.45 | Demon_VoIP | realtime doesn't live :( It hangs task processors during 10 secs after start. three tries, three hangs. No hop. |
| 18:59.34 | Demon_VoIP | file, I and thousands of users of my free service with the hope of closing ASTERISK-26806. I am ready to try the fixes because there is nothing to lose. |
| 19:02.04 | *** join/#asterisk evil_gordita (robert@70.188.41.127) |
| 19:03.38 | file | I'm working on it in my spare time. When im confident I'll put it up. |
| 19:03.51 | file | No guarantee it will help your usage. |
| 19:04.28 | Demon_VoIP | I'm afraid that won't help. But I hope |
| 19:18.39 | *** join/#asterisk robink (~quassel@unaffilated/robink) |
| 19:24.00 | file | I uploaded the 13 patch. |
| 19:30.15 | *** join/#asterisk kasanop (uid270352@gateway/web/irccloud.com/x-avsqzcycagynuqzd) |
| 19:34.08 | Demon_VoIP | file, asterisk 13? I am using 15. Are they compatible? |
| 19:34.36 | file | I doubt it |
| 19:35.38 | Demon_VoIP | So, I'm willing to test, but apparently can't do |
| 19:36.53 | Demon_VoIP | And judging by the size of the patch, it is not so simple to port my powers. |
| 19:44.05 | file | it's a complete rewrite of OPTIONS support. |
| 19:49.57 | cresl1n | sings the OPTIONS song |
| 20:02.11 | *** join/#asterisk startledmarmot (~startledm@cpe-75-82-221-87.socal.res.rr.com) |
| 20:41.25 | *** join/#asterisk wonderworld (~ww@ip-88-152-174-32.hsi03.unitymediagroup.de) |
| 20:42.20 | wonderworld | i have got an extension that sometimes dials a local extension. will the local extension inherit the variables i set in the original extension? |
| 20:51.32 | *** join/#asterisk dar123 (~dar@2602:306:bcbf:e750:f541:3441:df1a:82ff) |
| 21:43.53 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
| 21:53.37 | *** join/#asterisk retentiveboy (~retentive@c-73-82-30-193.hsd1.ga.comcast.net) |
| 22:13.06 | *** join/#asterisk retentiveboy (~retentive@c-73-82-30-193.hsd1.ga.comcast.net) |
| 22:14.04 | *** join/#asterisk saint_ (~saint_@unaffiliated/saint-/x-0540772) |