February 2014 - VoiceOps - lists.voiceops.org

Maintenance for Performance Technologies SEGway
by scott＠socket.net May 17, 2017

May 17, 2017

We have been using a set of PTI SEGway x201s with point code emulation for a number of years now. We also have an unlicensed spare in stock. The maintenance contract renewals are due and the two quotes I've received are quite high. I know of at least one other company that has chosen to drop the vendor maintenance and take care of that in-house. I would like to hear from anyone that is currently using SEGways and find out what they chose to do for maintenance. I would also be very interested to hear of any bad experiences from chosing the in-house option. Thanks. Scott Stratman Network Facilities Manager SOCKET 573-999-4376 scott at socket.net 1-800-SOCKET-3 www.socket.net

3 2

Fraud
by John＠InteleChoice.us Feb. 26, 2014

Feb. 26, 2014

I am new to your site. I was looking in the Archives and saw in November 2013 there were some of you who experienced fraud. We had a an Avaya IP Office customers system who got hit pretty bad. The customer is treating the fraudulent calls like credit card fraud and not taking any responsibility. Does anyone have any advice on how to persuade the customer take this issue seriously? His bill was racked up pretty good. Strangely and coincidentally Avaya came out with a security bulletin the end of December 2013 on this same issue. I tried to contact Avaya with no response. It seems as though someone has built a sniffer for the Avaya IP Offices and gleaning their registrations.

11 12

Fraud
by mylists＠battleop.com Feb. 25, 2014

Feb. 25, 2014

I'm pretty sure it would ruffle some feathers around here if I sent that list out into the public domain. I can tell you that we basically go thought the rate deck and filter anyone that's above X amount per minute and then throw in countries where customer's hacked PBX's send calls to. It's not the most scientific method but it's the most complaint free method. Richey From: John Curry [mailto:telecom7 at gmail.com] Sent: Monday, February 24, 2014 4:21 PM To: 'My List Account'; voiceops at voiceops.org Subject: RE: [VoiceOps] Fraud Would you mind sharing your hi toll rate destination dial plan? From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of My List Account Sent: Monday, February 24, 2014 1:48 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Fraud Maybe I am missing something here but why does the carrier that delivers the fraudulent traffic to the Telco that's in on the fraud pay the Telco that's in on the fraud for the calls that are delivered to their network? Seems pretty simple, if you cut off their revenue stream they won't have a reason to continue. I guess we all know there is no incentive for them to stop this practice because it's a big cash cow for everyone except for the poor end user who is left holding the bag. Our default dial plan won't let you dial these destinations so we don't have a real issue with this abusive traffic. Most of our customers who use international go with one of our filtered dial plans that let them dial most of the world except for known fraudulent and high toll rate destinations. Richey From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Saturday, February 22, 2014 11:48 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Fraud In most cases you will lose this customer. They don't see this as their responsibility (i.e. the credit card fraud defense) but the reality is their equipment was compromised due to their negligence. If the customer is reasonable offer them your cost on the damages so its just a passthrough. Otherwise you can take them to court or just send them to collections. BTW while many will advocate fraud detection and mitigation systems here, its been my experience (we wrote our own fraud system that out-performs our upstream carriers by hours) that if you detect fraud on a customer like this, and shut it down in minutes, and mitigate what could have been thousands of dollars in damage due to their mis-configured systems, reducing it to just tens or hundreds they will often still fight that amount and deny responsibility. The fraud system protects you, and by extension the customer, but the customers don't see it that way. -Ryan On 02/19/2014 02:09 PM, John Curry wrote: I am new to your site. I was looking in the Archives and saw in November 2013 there were some of you who experienced fraud. We had a an Avaya IP Office customers system who got hit pretty bad. The customer is treating the fraudulent calls like credit card fraud and not taking any responsibility. Does anyone have any advice on how to persuade the customer take this issue seriously? His bill was racked up pretty good. Strangely and coincidentally Avaya came out with a security bulletin the end of December 2013 on this same issue. I tried to contact Avaya with no response. It seems as though someone has built a sniffer for the Avaya IP Offices and gleaning their registrations. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

2 1

VoIP passive monitoring appliances or software - any recommendations?
by ml＠knight-networks.com Feb. 24, 2014

Feb. 24, 2014

$DAY_JOB is at a national ISP/NSP where we resell VoIP services. We do peering with the VoIP carrier at one of our remote POP's. We are looking for a better way to be able to monitor the handoff of those calls to our carrier over that peering link. We have quite a bit of instrumentation within our walled garden to tell us about call quality. We can monitor our QOS policies to ensure packets aren't being dropped by intermediate routers. If the customer uses our routers to terminate their SIP session, we can pull call quality stats from those routers as well. We can also use our own office telephones to make and receive test telephone calls, and we can of course run Wireshark captures from the switches to which those phones are connected. However, we can't say for certain that the customer's RTP traffic actually made it on the wire connecting us to the VoIP provider, nor can we say that the traffic is being transmitted and received properly. The peering link is connected to a Cisco 12k router on our side, so there is no way (afaik) to mirror the port, as on a switch. For the moment, I am envisioning that we'll need to deploy a server running Wireshark to the remote POP. It will need two network interfaces; one connected to a management network, the other a capture interface. The capture interface will connect to a network tap, and the network tap connected in-line between our router and the patch panel. Wireshark is probably adequate for what we need. But I'm wondering if there is any software or an appliance that would do the job better. Given the usual details - calling number, called number, date and time - we want to be able to quickly inspect traffic and dig into the details of the stream. Do we see any missing packets from the media stream? What is the MOS score of a particular call? Do we see any missing packets coming from us? Any missing packets from the provider? Alerting on bad call quality would be a nice-to-have addition. Any recommendation would be appreciated. Thanks in advance. -Brian Knight

11 13

Fraud
by John＠InteleChoice.us Feb. 24, 2014

Feb. 24, 2014

Would you mind sharing your hi toll rate destination dial plan? From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of My List Account Sent: Monday, February 24, 2014 1:48 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Fraud Maybe I am missing something here but why does the carrier that delivers the fraudulent traffic to the Telco that's in on the fraud pay the Telco that's in on the fraud for the calls that are delivered to their network? Seems pretty simple, if you cut off their revenue stream they won't have a reason to continue. I guess we all know there is no incentive for them to stop this practice because it's a big cash cow for everyone except for the poor end user who is left holding the bag. Our default dial plan won't let you dial these destinations so we don't have a real issue with this abusive traffic. Most of our customers who use international go with one of our filtered dial plans that let them dial most of the world except for known fraudulent and high toll rate destinations. Richey From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Saturday, February 22, 2014 11:48 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Fraud In most cases you will lose this customer. They don't see this as their responsibility (i.e. the credit card fraud defense) but the reality is their equipment was compromised due to their negligence. If the customer is reasonable offer them your cost on the damages so its just a passthrough. Otherwise you can take them to court or just send them to collections. BTW while many will advocate fraud detection and mitigation systems here, its been my experience (we wrote our own fraud system that out-performs our upstream carriers by hours) that if you detect fraud on a customer like this, and shut it down in minutes, and mitigate what could have been thousands of dollars in damage due to their mis-configured systems, reducing it to just tens or hundreds they will often still fight that amount and deny responsibility. The fraud system protects you, and by extension the customer, but the customers don't see it that way. -Ryan On 02/19/2014 02:09 PM, John Curry wrote: I am new to your site. I was looking in the Archives and saw in November 2013 there were some of you who experienced fraud. We had a an Avaya IP Office customers system who got hit pretty bad. The customer is treating the fraudulent calls like credit card fraud and not taking any responsibility. Does anyone have any advice on how to persuade the customer take this issue seriously? His bill was racked up pretty good. Strangely and coincidentally Avaya came out with a security bulletin the end of December 2013 on this same issue. I tried to contact Avaya with no response. It seems as though someone has built a sniffer for the Avaya IP Offices and gleaning their registrations. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

1 0

[VOIPSEC] Tackling VoIP fraud, new idea
by David.Hiers＠adp.com Feb. 24, 2014

Feb. 24, 2014

The key is vetting the participants. Even the feds have a hard time with that... David -----Original Message----- From: Voipsec [mailto:voipsec-bounces at voipsa.org] On Behalf Of Mark Collier Sent: Friday, February 21, 2014 12:44 To: J. Oquendo Cc: voiceops at voiceops.org; voipsec at voipsa.org; Peter Beckman Subject: Re: [VOIPSEC] [VoiceOps] Tackling VoIP fraud, new idea I like the idea of the list and will participate Mark D. Collier Chief Technology Officer/VP Engineering Securelogix Corporation 13750 San Pedro San Antonio, Texas 78232 (210) 863-9001 www.SecureLogix.com www.voipsecurityblog.com > On Feb 21, 2014, at 12:23 PM, "J. Oquendo" <sil at infiltrated.net> wrote: > >> On Fri, 21 Feb 2014, Sergey Kolesnichenko wrote: >> >> Why dont't you want to speak about tactics here openly? >> > > Common sense. This is a public list, and there is no way for me to > determine the intentions of anyone who is a subscriber to the list. It > is a KNOWN fact, that criminals subscribe to security mailing lists > such as Bugtraq, Full Disclosure and others. Not for the sake of > lending a helping hand, but for other means. Much similar to malware > authors who run their malware through VirusTotal to see if anything is > going to detect it. > > On a private list, there is the accountability factor to equate. > Someone subscribed using a corporate email address. > Therefore SOME form of vetting took place. > > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM > > "Where ignorance is our master, there is no possibility of real peace" > - Dalai Lama > > 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF > > _______________________________________________ > Voipsec mailing list > Voipsec at voipsa.org > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org _______________________________________________ Voipsec mailing list Voipsec at voipsa.org http://voipsa.org/mailman/listinfo/voipsec_voipsa.org This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

7 9

Voice DDOS ?
by ivan.kovacevic＠startelecom.ca Feb. 24, 2014

Feb. 24, 2014

Hi Folks, We are seeing something strange coming across our network. A disconnected client TFN is receiving 30,000+ calls per hour (all failing). The ANIs being used are dummy ANIs 17029983416 (no answer) and 16469820093 (recording saying "no routes found"). This is not affecting our network, although it's causing the upstream provider a bit of grief. Not sure why someone would do this.... We are about to remove the CICs at the sms800 level, but just wondering if anyone has come across something similar? Thanks, Ivan

4 5

[VOIPSEC] Tackling VoIP fraud, new idea
by beckman＠angryox.com Feb. 21, 2014

Feb. 21, 2014

I don't mind, but some believe that letting the fraudsters in on our techniques allows them to have more information in order to circumvent our roadblocks. If there was a private list, technical implementations could be spoken of without tipping our hand in public forums for fraudsters to counter. Beckman On Fri, 21 Feb 2014, Sergey Kolesnichenko wrote: > Why dont't you want to speak about tactics here openly? > > > 2014-02-21 19:51 GMT+02:00 Peter Beckman <beckman at angryox.com>: > >> Email sucks for this. I don't want to read an email about something hours >> or days after the issue is happening and have to do something manually to >> protect my infrastructure. >> >> This seems like something that should be an API in which trusted people can >> access. >> >> But then you have concerns about trust of the data. Do I trust your >> reasoning for an IP block? Do I even get to see your evidence? >> >> Honestly I don't need a list or an API to block stuff. >> >> HOWEVER, if this can become a private discussion list to talk about >> methods, techniques and tactics that we can all implement in order to >> prevent telecom/SIP/VoIP fraud on our own, THAT I'd be interested in. >> >> Beckman >> >> >> >> On Fri, 21 Feb 2014, J. Oquendo wrote: >> >> On Fri, 21 Feb 2014, Sergey Kolesnichenko wrote: >>> >>> One more mailing list? :-) I'm sure it is a bad idea. I'm working for a >>>> company to protect it from VoIP related attacks, but you will never have >>>> gurantess that I will not be using the data in a private list to attack >>>> someone as a private individual :-) it is a security hole in a private >>>> list >>>> about VoIP security... >>>> >>>> >>> I disagree with it being a bad idea. There is never any >>> guarantees in life. The purpose for a private list, is it >>> protects COMPANIES data. There is a trust mechanism in the >>> sense that should/if/when someone wants to contest data, >>> I can go back based on checksum to determine WHO submitted >>> what. I HIGHLY doubt, someone would throw away their >>> reputation, and or damage company reputation by submitting >>> falsified data. >>> >>> >>> -- >>> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ >>> J. Oquendo >>> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM >>> >>> "Where ignorance is our master, there is no possibility of >>> real peace" - Dalai Lama >>> >>> 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF >>> _______________________________________________ >>> VoiceOps mailing list >>> VoiceOps at voiceops.org >>> https://puck.nether.net/mailman/listinfo/voiceops >>> >>> >> ------------------------------------------------------------ >> --------------- >> Peter Beckman Internet Guy >> beckman at angryox.com >> http://www.angryox.com/ >> ------------------------------------------------------------ >> --------------- >> > _______________________________________________ > Voipsec mailing list > Voipsec at voipsa.org > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

1 0

[VOIPSEC] Tackling VoIP fraud, new idea
by sil＠infiltrated.net Feb. 21, 2014

Feb. 21, 2014

On Fri, 21 Feb 2014, Sergey Kolesnichenko wrote: > Why dont't you want to speak about tactics here openly? > Common sense. This is a public list, and there is no way for me to determine the intentions of anyone who is a subscriber to the list. It is a KNOWN fact, that criminals subscribe to security mailing lists such as Bugtraq, Full Disclosure and others. Not for the sake of lending a helping hand, but for other means. Much similar to malware authors who run their malware through VirusTotal to see if anything is going to detect it. On a private list, there is the accountability factor to equate. Someone subscribed using a corporate email address. Therefore SOME form of vetting took place. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF

1 0

[VOIPSEC] Tackling VoIP fraud, new idea
by sil＠infiltrated.net Feb. 21, 2014

Feb. 21, 2014

On Fri, 21 Feb 2014, Sergey Kolesnichenko wrote: > One more mailing list? :-) I'm sure it is a bad idea. I'm working for a > company to protect it from VoIP related attacks, but you will never have > gurantess that I will not be using the data in a private list to attack > someone as a private individual :-) it is a security hole in a private list > about VoIP security... > I disagree with it being a bad idea. There is never any guarantees in life. The purpose for a private list, is it protects COMPANIES data. There is a trust mechanism in the sense that should/if/when someone wants to contest data, I can go back based on checksum to determine WHO submitted what. I HIGHLY doubt, someone would throw away their reputation, and or damage company reputation by submitting falsified data. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF

2 1