- VoiceOps - lists.voiceops.org

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

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

Feb. 21, 2014

On Fri, 21 Feb 2014, D'Arcy J.M. Cain wrote: > > Second field, one can set up a triggering mechanism. > > (Pseudo code) > > > > if [ number == 2125551212 ] > > then > > do something (send_email || generate_phonecall > > done > > fi > > Not sure what you mean here. If the IP is already blocked then what > are we checking? Blocking an IP will ONLY block the attacker from doing malice from that host. If by chance someone made it onto one of your machines, you could set a trigger that says: Hey if you see an account trying to dial this KNOWN_TO_BE_BAD number that is listed, send me an e-mail, or lookup what OTHER IP is now trying to call that number and block them too. > Not sure about this. What if I want to weight the reports based on who > submitted them. There may be members that I completely trust and would > block based on their report. For others I may want to see multiple > reports before I block. I don't disagree however, I am taking my malware analysis and DFIR experience here. The reason (IMHO) we companies still get compromised six ways from Sunday is, many don't share data for various reasons: 1) they don't want the public/others to know "they've been had," 2) data submitted may be relevant to an ongoing law enforcement related investigation 3) good old fashioned chest thumping. Chest thumping. I have seen many companies take the approach that attacker data is some holy grail. "We were the first and only to see this!" All the while others could have been given a green light on an attack source. > What about non-free email? It seems to me that a tighter vetting > process is needed. I wouldn't accept any email that was not attached > to an actual VoIP provider. I realize that that takes more work though. There are VoIP providers, ITSPs, Carriers, but you're leaving out the small businesses, and smaller non carrier like shops who can also disclose attack sources. > I am not totally opposed to the idea. Not sure how useful it might > be. What sort of attacks are you thinking about? I already block IPs > based on failures to register and no one can dial without being > registered. It's all automatic. I am thinking the whole gamut of attacks. Registrations, actual calls, anything related to VoIP. Web based exploit of a PBX. Anything that is relevant to IP PBX telephony systems. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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

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

Feb. 21, 2014

Because none of us want to deal with fraud, and many of us have fought it, are fighting it, and eventually (like it or not) will come across it. I am proposing starting up a NON PUBLIC, TRUSTED mailing list. The purpose of the list would be to share information on attacks, numbers, dialed, and so forth. The reasoning for it not being public, would be obvious, avoid letting a threat actor know they have been flagged. The theory behind this list, would be to aggregate KNOWN fradulent destinations for the purposes of creating some form of blacklist, or triggering mechanism. For example, suppose I had a break in, where calls went to 2125551212. On the list I would send an email stating: x.x.x.x (IP) | 2125551212 | DATE | CHECKSUM First field is obvious, you'd want to block this address. Second field, one can set up a triggering mechanism. (Pseudo code) if [ number == 2125551212 ] then do something (send_email || generate_phonecall done fi The date, is for historical purposes, and the checksum would be a variable of which system saw what. For those who have seen my VABL list http://www.infiltrated.net/vabl.txt It would look EXACTLY like that. So for anyone who'd care to share, without disclosing WHO shared the information, there would be a mechanism to hide your identity (company info, etc..) The other reason for it being a NON public list, would be a matter of trust in the sense that, I would NOT allow any freemail (Gmail, Hotmail, etc) to be used, in order to minimize any false positives. The last thing I would want is for someone to maliciously submit data against a competitor. (make sense?) I am willing to start, and maintain such list, however, I'd need to know whether or not a) others are willing to share attack data (which will be sanitized) b) other businesses and peers would find the data useful. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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

CNAM on toll free?
by gfreeman＠sungevity.com Feb. 14, 2014

Feb. 14, 2014

Hi, folks, Can toll-free numbers have CNAM registrations? We're hoping to have it say something other than "TOLL-FREE CALLER", but our vendor says that toll-free CNAMs can't change. thanks, Graham Freeman gfreeman at sungevity.com

3 2