Path: utzoo!utgpu!watserv1!watmath!att!att!tut.cis.ohio-state.edu!ucsd!ucselx!bionet!hayes.ims.alaska.edu!accuvax.nwu.edu!nucsrl!telecom-request From: gutierrez@noc.arc.nasa.gov (Robert Michael Gutierrez) Newsgroups: comp.dcom.telecom Subject: Re: Mysterious LD Fraud Message-ID: <14303@accuvax.nwu.edu> Date: 4 Nov 90 03:17:12 GMT Sender: news@accuvax.nwu.edu Reply-To: Robert Michael Gutierrez Organization: NASA Science Internet - Network Operations Center Lines: 74 Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 10, Issue 788, Message 3 of 10 BRUCE@ccavax.camb.com (Barton F. Bruce) writes an article in which he is attempting to trace some fraudulent calls coming from his lines. The PBX is programmed to dial out on AT&T's SDN network (10732) [I will explain the use of 10732 below]. > Their NET&T bill showed MCI calls on their LDN. Curiously, that new > LDN, though defaulting to 10732, is not in AT&Ts SDN database, so will > default to vanilla AT&T service. Virtually all their other trunks, > including oneway outgoing HOBIC trunks, give their own WTN as the ANI > number. There are two trunks that do give a former LTN (their new LTN > is a 8000 that they prefer to list rather than the old one that was > quite nondistinctive) rather than their actual WTN, but none of these > old numbers are involved in the MCI calls. [BTW ... is this a chain hotel??? That would explain how they can get/afford AT&T SDN.] In another article, somebody offers that a drop hasn't been disconnected, either out of the frame (C.O.) or a B-box down the line (one of those telco pedistals you see on some street corners). To be exact: Marc Kaufman (kaufman@Neon.stanford.edu) writes: >My guess (based on an actual occurrance with my residence line) is >that your line is bridged to another drop pair in one of the phone >company's cable termination boxes... This could be true, but with common ground-start trunks, it would be hard for the person with a standard 2500 set (or similiar Korean equivalents) to get dial tone out of it. I have myself experienced a multi-drop dialtone, when I was 14 and had just moved to another apartment. I picked up the handset and somebody was talking on it! The other party was none too happy to hear somebody "tapping" into their line, and was going to "call the police" about it. I knew better (being telephone aware by that time) and just waited for somebody on the frame to discover the pair was crossed when we got our own dialtone. Back to the original article: > There is NO WAY anyone could have routed calls 10222, and even if they > had, they would have shown up on the SMDR log. Also the trunks are in > a rotary hunt group outgoing that always picks another trunk on > successive calls. The chance of anyone getting even a few, let alone > all these calls, onto THE ONE TRUNK that ANIs as xxx.8000 is > impossible from behind the PBX. I know I'm going to sound like your mother :-), or your security admin (do you have a security administrator???), but you better make damn sure that nobody has set up a class of service that direct accesses a trunk, and bypasses the SMDR (ie: non-logging). Print out the configuration, DON'T just look at it on the console. Take it to your desk, and with a pencil/pen, mark off all the confirmed configurations for ALL classes and ALL extensions. Sounds tedious, well, it is, but a good admin will cover every angle before pointing fingers. Remember what you mom said, "It's not nice to point," especially when you're wrong... Oh, also one other thing. *All* large PBX's have direct trunk access (I seem to remember Rolm's was **7X, N.T.'s was 72XX, etc). This is an often overlooked class of service, and always a very DANGEROUS one. With direct trunk access, a user can punch one of these up, take the switch out of the line (usually with a #), and the trunk then belongs to them, with no monitoring or logging whatsoever. This class of service has always been the most ignored, and 3-4 large companies I've worked with have proven this ignorance. This class should be looked at *BOTH* globally and on the extension level. Robert Michael Gutierrez NASA Science Internet Office - Network Operations Center. Ames Research Center, Moffett Field, California. USA.