How To Detect Fake CallerID? (8xx?)

Home » Asterisk Users » How To Detect Fake CallerID? (8xx?)
Asterisk Users 16 Comments

I have a ‘time and attendance’ application. Think janitorial or security kind of thing where an employee goes from location to location.

They’re supposed to ‘clock in’ when they get to a site using a phone at that site to prove they’re there.

Some employees have discovered ‘fake caller ID‘ services can be used to say they’re on site when they are not.

How can I detect a fake CallerID? The INVITE looks the same to me.

If I have the employees call an 8xx number, can I ask my SIP provider to include more headers to show the real ANI? What would that service be called?

16 thoughts on - How To Detect Fake CallerID? (8xx?)

  • If it’s anything like a PRI provider, I’ve been told they only way to get true CID, in those instances, would be to provide a 1-800 number (US) for them to call. Then you’d get correct CID, since you’re paying for both legs of the call.

    I do not know if this holds true for a SIP provider,


  • For dangerous material sites a call back was used. They call in and get a code, the system calls back and asks for the code. Convoluted yes, the call back was all that was really needed to thwart the fraud. A simple RFID pad setup could be built to use low usage GSM plan to tag in the RFID on site. But this is beyond the scope of telephony.

  • There are legitimate reasons for faking an ident. For instance, if you are using multiple services in parallel to connect to the Outside World. While we had such a setup, we arranged with our SIP provider to attach numbers associated with our ISDN-30 line to calls we were making. And if you are providing something like a “transparent call recording” service, you need to lay the ident of the incoming call leg onto the outgoing call.

    Unfortunately, as you’ve discovered, the service can be abused …..

    You can’t. Only the first telephone company through which the call passes can tell for sure where a call is coming from. The next company through whose equipment it is passing can alter it, and nobody downstream be any the wiser.

    Remember, even although it’s now packet-switched and multiple-redundantly-
    routed underneath, the whole telephone network is still basically emulating an old-fashioned, circuit-switched network; where calls get connected from the originator’s local exchange onto a trunk to pass on to another exchange, and all the next exchange downstream knows for sure is which approximate direction it came in from and where it’s going to. Information that would once have been implied by which pair of wires the signal was travelling down, is now sent separately, and subject to modification en passant.

    Not really. You need to backtrack a little and rethink. Caller ID is just not something that you can rely on anymore.

    Presumably your staff carry mobile phones. What about an app that gets the ID
    of the cell tower to which it is connected, and passes it and the SIM number in a HTTP request to a server you control? You’ll obviously need to do some sort of authentication dance, otherwise anyone could just manually craft a URL
    representing any location. (But since it’s your app, you can effectively embed a different key into every copy; so in the worst case, anyone trying anything naughty is only able to spoof one handset. An .apk file is basically a .zip archive; so you should be able to unzip it into a folder structure, use your favourite scripting language to regenerate the keyfile and zip it back up.
    This might even scale.)

  • You have an unusual situation–you suspect caller ID spoofing by a known person.

    Under the Truth in Caller ID Act, FCC rules prohibit any person or entity from transmitting misleading or inaccurate caller ID information with the intent to defraud, cause harm, or wrongly obtain anything of value. Anyone who is illegally spoofing can face penalties of up to $10,000 for each violation.

    Making it clear to your employees that spoofing will result in termination might be enough.

    Requiring employees to have a phone that you can locate would allow you to check from time to time.


    —–Original Message—

  • The problem is that they are supposed to use the ‘site landline’ to confirm presence — not their cell phone with the spoofed CID.

  • Use a callback. So when clocking in/out, they will hear a random 4 digit PIN, like “Enter four, three, six, eight at the callback”. After they hangup, the phone will ring, and then they will have confirm with the 4 digit PIN.

    If they arent in presence: the phone at the site will ring, and the person at site (that isn’t your employee) cannot carelessly just OK it because they haven’t heard the PIN. If they are in presence: the phone at the site will ring, and the employee will be able to enter the PIN they just heard. If they fake the callerID or not at the initial call, does not matter, since you have verified with a callback.

    —–Ursprungligt meddelande—

  • It’s probably not practical to have them answering the client’s telephone!
    At a lot of sites, incoming calls would be handled by auto attendant, diverted to answering service, etc.


    —–Original Message—

  • Since the callback happens immediately after hangning up, the risk of answering a call that isn’t theirs is minimal. For those sites that divert their incoming calls to a PBX or answering machine, you could have some config/database that excepts these sites from callback verification.
    (which means these sites run into risk of fake callerID).

    Another variant could be that they must visit a specific website using a Wifi or computer at the client. You record the IP. Spoofing the IP in a TCP three-way handshake is almost impossible.

    The thing is then to be able to record which IP is the client, but if your services are ordered by the client via some web form, you could have that IP
    be recorded as “client IP” and the employee must check in/check out from that IP.

    This could be used in unison with the phone verification, so the employee can select which fits best for the enviroment.
    (eg, they choose phone verification or web verification)

    —–Ursprungligt meddelande—

  • IPs change. Also, the client may not have ordered the service from the office. They may have bought the service for multiple locations from head office. Too many variables.

    You may have to think about hardware. Some sort of RF device installed at the client with a unique ID. The employee waves his keychain at the device, it connects to your office and sends the employee’s ID and its own. A card reader is another possibility or bar code reader.

    Of course that’s not a phone solution so I guess it is off topic here.

  • Rather than that, if you’re looking for a phone solution – as part of the customer contract, install an IP phone that registers with your system (use a VPN tunnel to your phone system). Think of it like a “red-phone”
    hotline. You own the phone, and you physically install it and it only talks to your system via a SIP registration. That way you can confirm the physical source of the call origination, and you can control what the phone will be able to call (make a to speed dial a base-64 address – something that can’t be dialed with a conventional phone line, block all other outgoing numbers). A nice side effect of this is that you give your employees/contractors a fixed and predictable way of getting in touch with management if there is a problem (just another speed-dial number).

    Keep in mind that without a “Something you are” factor of authentication, people have the escape route of telling their coworker “hey log me in…”. Fingerprint, hand scan, or retina reading are the most common ways to verify the presence of a live person at a fixed point.

    It’s unfortunate that you have this problem, I’ve seen it before though. To paraphrase Jeff Goldbloom’s Dr. Malcom in Jurasic Park: “Life finds a way…”. I have been shocked and amazed at the ingenuity of people to be lazy and cheat or game a system. What you are running into is the same problem we have with websites – if you don’t 100% control the end to end communication and the devices, you can’t trust any data coming into your system!!!

    A common way for security patrol auditing is to install iButtons with a unique 64-bit number and a secure transaction function. A patrol or janitor would have to physically touch the read to the iButton at specified way-points for a read to occur and be logged, and the patrol or janitor turns in the reader after every shift for download and auditing.


  • Yes; but the whole point is that the caller ID from the site landline is no longer reliable enough as evidence, by itself, that somebody is actually there.

    A custom app could read the ID of the cell tower to which it was connected

  • Seems like this is the best idea (challenge-response), a callback. No matter the callerid, you don’t know where the caller is. But if you place a call BACK to the callerid, it’s going to go to the destination. Then you either need the phone to be answered, or the phone to be answered and and the challenge entered.

    Adam Goldberg AGP, LLC

    —–Original Message—

  • As a client, I don’t want service company personnel answering my phone.

    As a service company, I don’t want my clients thinking that I do not trust my employees who are at the client facility.


    —–Original Message—

  • Personally, if I was a client, I would rather have the personell answer the phone than make a outgoing call, if I would choose. If you think of billing and costs. So if a client allows outgoing, I don’t think they have any problems with answering a call immediately following either.

    But I assume the client will be billed for the time the personell works there?
    And thats why you have this “phone verification system”, to avoid discussion about how long the company has been there and unfair bills?

    Then you could have it this way instead:
    1: Give the client (not personell) a PIN code.
    2: The client calls and enters PIN.
    3: The employee gets a SMS/email/push message/paging tone, that he can start working.
    4: When the employee is done, the client calls again, and enter PIN. This will stop billing.
    5: When billing is stopped, the employee gets a SMS/email/push message/paging tone he can stop working.

    This will be rock solid. The employee only needs to check for the SMSes. The SMSes prevent the client from cheating the system to get cheaper service, like claiming to start when client do not, or calling for stop before the employee is finished, because the employee will only work when he get start signal, and will stop working at stop signal.

    Theres no risk that the client will call in and check in/check out when the employee is not there, because that would cause the client to Be billed for rendered services.

    —–Ursprungligt meddelande—

  • I’ve assumed that the client is not present when the cleaners arrive.


    —–Original Message—