September 2010 - VoiceOps - lists.voiceops.org

VoIP Abuse Project
by ldardini＠gmail.com Sept. 21, 2010

Sept. 21, 2010

2010/9/20 VoIP Abuse Project <voipabuse at infiltrated.net> > Leandro Dardini wrote: > > Hello, > > I find a blacklist too heavy to manage and unable to catch the fast > > emerging bruteforcers. As freelancer I suggest to my clients (all on > > Linux with Asterisk) the install of the fail2ban software. > > > > The working of fail2ban software is really simple: it reads the > > messages generated by the application and if one user try to > > authenticate with wrong credentials more than X times in the unit of > > time, then triggers an insert into iptables to not get more packets > > from him for a long time (adjustable). > > > > Leandro > > Understood on fail2ban however, I can use fail2ban against you and have > your own servers block their upstream. Fail2Ban "fails" when you're in a > managed PBX arena and your clients are connecting from all over the > place. When you have thousands of customers and some are connecting from > all over the place, fiddling with Softphones, settings in Snom, Polycom, > etc., you will quickly learn that Fail2Ban outright fails. > > While a blacklist CAN be cumbersome, this isn't like spam where there > are millions of hosts attempting this per day. At maximum, I've seen > about 15-20 hosts attacking one PBX. It will take me about 20-30 minutes > to whip up a python or shell script to parse them out and upload them. I > already have my honeypot writing to DB, all I have to do is re-write to > gzip and send the full logs. > > The hard part is writing an informative email someone will likely never > read (abuse departments). Last thing I want to hear is "you're not > playing fair" when their clients complain. > > -- > > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT > > "It takes 20 years to build a reputation and five minutes to > ruin it. If you think about that, you'll do things > differently." - Warren Buffett > > 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E > > I am sorry, but I really don't understand how fail2ban can be used against me. The only drawback of fail2ban is when inside a large private organization using NAT and exiting on Internet with a single (or small pool of) IP, some evil colleagues can send a bunch of wrong REGISTER requests and trigger fail2ban to filter the IP preventing legitimate users from within the same organization to access your service. This can happen once, then the good sysadmin of the organization will snoop the traffic and catch the evil colleagues. Leandro

7 8

VoIP Abuse Project
by sil＠infiltrated.net Sept. 20, 2010

Sept. 20, 2010

Finally getting fed up with the bruteforcers so I decided to "out" upstreams and netblocks. Stay tuned. Maybe a VoIP based blacklist? Work in progress http://www.infiltrated.net/voipabuse/ -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E

7 9

local calling database
by eric.fort＠gmail.com Sept. 16, 2010

Sept. 16, 2010

if you click delete on the results page ti offers an information removal option and claims that all data is from publicly available sources. If the last part is true they must have some great sources somewhere as up to date as it seems to be. at presently I'm watching a port from verizon wireless to Level3 rather closely. I'll be checking that to see how long it takes for the record at tnid.org to change and I'm careful not to get into any public databases. > > Eric fort > > > On Thu, Sep 16, 2010 at 8:33 AM, Darren Schreiber <d at d-man.org> wrote: > >> Wow, where does this pull from? Highly accurate in my cursory testing. >> Would love to tie an API to this... >> >> Brandon Buckner <BrandonB at netins.com> wrote: >> >> >> FWIW, I checked one we ported last Thursday and it is correct. >> >> ---- >> Brandon Buckner >> Switching Technician / VoIP Admin >> Iowa Network Services >> 515-830-0440 opt 1 >> brandonb at netins.com >> >> >> >> -----Original Message----- >> From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] >> On Behalf Of Frank Bulk - iName.com >> Sent: Thursday, September 16, 2010 4:40 AM >> To: 'Jared Geiger'; VoiceOps >> Subject: Re: [VoiceOps] local calling database >> >> I just checked a friend who ported his landline to wireless last week >> Friday >> and the info there is incorrect...do you think they're dipping live? >> >> Frank >> >> -----Original Message----- >> From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org >> ] >> On Behalf Of Jared Geiger >> Sent: Monday, September 13, 2010 2:34 PM >> To: VoiceOps >> Subject: Re: [VoiceOps] local calling database >> >> For current ( I haven't found a mistake yet ) porting information. >> Check out http://tnid.org/ >> >> >> _______________________________________________ >> VoiceOps mailing list >> VoiceOps at voiceops.org >> https://puck.nether.net/mailman/listinfo/voiceops >> >> _______________________________________________ >> VoiceOps mailing list >> VoiceOps at voiceops.org >> https://puck.nether.net/mailman/listinfo/voiceops >> > >

1 0

IP outage - XO?
by ujjval＠simplesignal.com Sept. 16, 2010

Sept. 16, 2010

We are seeing some weird behavior and our Data center people are telling us that XO is having nationwide outages... Are you guys seeing something similar?

6 5

local calling database
by d＠d-man.org Sept. 16, 2010

Sept. 16, 2010

Wow, where does this pull from? Highly accurate in my cursory testing. Would love to tie an API to this... Brandon Buckner <BrandonB at netins.com> wrote: FWIW, I checked one we ported last Thursday and it is correct. ---- Brandon Buckner Switching Technician / VoIP Admin Iowa Network Services 515-830-0440 opt 1 brandonb at netins.com -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Frank Bulk - iName.com Sent: Thursday, September 16, 2010 4:40 AM To: 'Jared Geiger'; VoiceOps Subject: Re: [VoiceOps] local calling database I just checked a friend who ported his landline to wireless last week Friday and the info there is incorrect...do you think they're dipping live? Frank -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jared Geiger Sent: Monday, September 13, 2010 2:34 PM To: VoiceOps Subject: Re: [VoiceOps] local calling database For current ( I haven't found a mistake yet ) porting information. Check out http://tnid.org/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

1 0

local calling database
by tensai＠zmonkey.org Sept. 16, 2010

Sept. 16, 2010

Currently I'm using some Perl scripts tied to localcallingguide.com's XML API to build a local calling database, and that seems to be working great, but in the spirit of due diligence I'm looking for feedback about other local calling databases out there, both free and commercial. On or off list replies appreciated. Corey

13 18

MiNET protocol plugin for Wireshark/Ethereal
by russell＠rustlesolutions.ca Sept. 15, 2010

Sept. 15, 2010

This may be a far fetched question in this mailing list. Does anyone have a copy or know where to acquire a copy of the Mitel MiNET protocol decoder for Ethereal or Wireshark? I've attempted to get it through Mitel but they will not release it unless you're a customer. I'm using Natural Convergence Silhouette (the company no longer exists) plainly speaking is a fork of the Mitel ICP-3300 which runs the MiNET protocol to customer terminal equipment and SIP/MGCP on the back end. Thanks

2 1

local calling database
by abalashov＠evaristesys.com Sept. 14, 2010

Sept. 14, 2010

Troy, The site seems to have some degree of lead generation and/or marketing features such as entreatments to purchase numbers, and my guess is that is the monetisation strategy. Can't possibly say if it's working. One does not have to query NPAC directly, of course. There are VeriSign and other STP operators that will resell you this service as well, as will numerous folks who offer SIP interfaces to TCAP LNP queries like Broadvox and SourceComm. It is entirely possible they get the dips on relatively good terms from one of those sources compared to what we expect, due to volume. But yes, at the end of the day not going broke is a requirement. I take it as granted that entities like VeriSign and Sourcecomm and Broadvox do quite a lot of short-term caching, TOS be damned. A bigger question for me is how they are able to offer LNP info relatively free and clear to anyone who wants it, even if they are not carriers per se. Neustar NDA requirements are not friendly to such actors and require a lot of paperwork for anyone wanting more or less direct NPAC access. How someone buying dip access from Neustar (at some level) is able to pass it along to third parties without propogating the myriad of NPAC territorial NDAs is a complete mystery to me. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Sep 13, 2010, at 4:26 PM, Troy Davis <troy at yort.com> wrote: > > > On Mon, Sep 13, 2010 at 11:43 AM, Chris Boyd > <cboyd at gizmopartners.com> wrote: > > On Sep 13, 2010, at 11:10 AM, Troy Davis wrote: > > > Yeah, it's very NANPA-centric right now. We wanted to pick a set > of information we knew would be complete enough to be useful. > > How is the carrier information determined? I've tried a few > numbers, and the city/state infor was correct, but the carrier > information was incorrect. The numbers were reported as the carrier > that originally provisioned service, not the current carrier after > porting. > > Still a pretty useful tool. > > The carrier info is all at 1,000 or 10,000 number granularity > depending on the allocation size. The reason LNP isn't there is > that I don't know of a way to do it without a per-query fee. > > Someone else pointed out tnID, which seems to be doing free LNP > dips. I'm not sure how they're making enough money from paid > reverse lookups to cover the query fee, especially with the > restrictions on caching that most (all?) LNP providers have. But > it's great if the economics work and it's sustainable. > > Anyone with SS7 access want to allow digits to perform and cache > free LNP dips? Happy to expose that for free too, with a client > rate-limit and your name on the result page as having sponsored it. > Assuming there's no restriction on caching, the cached data could be > reused for months. Since this isn't meant to be used for routing, > being 3-6 months behind would be fine. > > Troy > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops

3 2

Outsourced TN Porting and CNAM DB assistance
by nvermeer＠rgts.com Sept. 13, 2010

Sept. 13, 2010

Hi all, Does anyone here have an outsourcing company or consulting group they can recommend to help us with some porting and CNAM issues? We're having some pains with the VZ LEC wholesale group and we'd like some assistance getting some processes straightened out. Regards, Nick Nicholas Vermeer Manager, Engineering (ph) +1.212.282.2512 (fax) +1.212.282.2668 (email) nvermeer at rgts.com<mailto:nvermeer at rgts.com> Rockefeller Group Technology Solutions, Inc. 1221 Avenue of the Americas New York, NY 10020-1095

1 0

as5350 incoming calls failing which have blocked callerid
by blair＠fx.net.nz Sept. 10, 2010

Sept. 10, 2010

Hi Guys, Have just upgraded one of our PSTN gateways from an old as5300 to a new as5350xm. Have run into an issue whereby incoming calls from PSTN which have callerID blocked won't complete, and just seem to get dropped on the floor. I get the following debug output when I make a call from callerid blocked number to the gateway - seems odd because the only references I can find to this error message are for outgoing calls.. Of note is the Plan / type which are Unknown, and the drop cause. Cause i = 0x809C - Invalid number format (incomplete number) 00124: Aug 26 19:24:54.621 NZST: ISDN Se3/0:15 Q931: RX <- SETUP pd = 8 callref = 0x01FF Sending Complete Bearer Capability i = 0x9090A3 Standard = CCITT Transfer Capability = 3.1kHz Audio Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA18381 Preferred, Channel 1 Progress Ind i = 0x8283 - Origination address is non-ISDN Date/Time i = 0x0A081A1318 Date (dd-mm-yr) = 10-08-26 Time (hr:mnt:sec) = 19:24:52 Signal i = 0x40 - Alerting on - pattern 0 Calling Party Number i = 0x00A3, N/A Plan:Unknown, Type:Unknown Called Party Number i = 0x80, '4987770' Plan:Unknown, Type:Unknown 000125: Aug 26 19:24:54.621 NZST: ISDN Se3/0:15 Q931: Received SETUP callref = 0x81FF callID = 0x0017 switch = primary-net5 interface = User 000126: Aug 26 19:24:54.621 NZST: ISDN Se3/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x81FF Cause i = 0x809C - Invalid number format (incomplete number) 000127: Aug 26 19:25:04.058 NZST: %CALLTRKR-6-CALL_RECORD: ct_hndl=25, service=None, origin=Answer, category=SyncData, DS0 slot/port/ds1/chan=3/0/0/0, called=4987770, calling=(n/a), resource slot/port=(n/a)/(n/a), userid=(n/a), ip=0.0.0.0, account id=(n/a), setup=08/26/2010 19:24:53, conn=0.00, phys=0.00, service=0.00, authen=0.00, init-rx/tx b-rate=0/0, rx/tx chars=0/0, charged units=0, time=0.01, disc subsys=ISDN, disc code=0x1C, disc text=Invalid number format (incomplete number), sig type=Unknwn Anyone run into this kind of thing before and have any ideas how I might configure the box so that these calls complete? Cheers, Blair

2 4