[cisco-voip] Phone Fraud H.323

[David Zhars]

Hey Ryan,

The telco said these POTS lines (four of them) were being used to dial
Jamaica.  The router has 4 FXO ports.  For some reason, they were leaving
the fourth line alone, though the telco felt that wouldn't last long.
The router only has an internal non-routable IP addy.
Only processes H.323 (but does allow telnet and SNMP)
I don't know what PSTN egress means.  Sorry!

On Sun, Sep 11, 2016 at 11:49 AM, Ryan Huff <ryanhuff at outlook.com> wrote:

> Hi David,
>
>
>
>    - Did the telco say that the calls were originated from your POTS
>    trunks or were they responding to customer complaints that one of your
>    numbers had been reported to them for fraud ... etc?
>    - Does this router have a public Internet facing interface?
>    - Does this router process any other signaling protocols besides H.323?
>    - You mentioned having Unity / Unity Connections ... are you allowing
>    PSTN egress from Unity Connections / have you verified the restriction
>    tables are correct?
>
> There are a number of things you could do on either side (UCM / Gateway).
> To cover the gap for the interim, I would at least deal with the specific
> called numbers that the telco gave you. In UCM, you could create specific
> route patterns in the egress path that do not route the match. On the
> gateway, you could use voice translation rules to try and reject the call
> attempt or translate the number to something the carrier won't route. You
> could also create specific dial-peers for the called numbers that do not
> route to anything.
>
>
> This reminds me of a time I had this issue (and I was a bit less mature);
> I created dial-peers on the CUBE that matched the 'bad' called numbers and
> I routed them back into CCM->CTIRp->CUC and had a small sample of Rick
> Astley's, "Never Gonna Give You Up" playing as the opening greeting to a
> System Call Handler .... ahhh the younger days ....
>
>
> ANYWAYS ....
>
>
> I would say, in my experience, this sort of thing typically comes from the
> outside in. In cases where CUBE has a public Internet facing interface,
> usually someone finds something open on CUBE, sends some signaling that
> matches a dial-peer and off it goes. In this case you'd want to look at
> some outside ACLs or putting a firewall between the public Internet and the
> CUBE. If your CUBE does not face the Internet or is on a private network
> like MPLS ... that is much less likely to be the case and you want to start
> looking elsewhere on the network.
>
>
> I have seen bot dialers/Probers like 'SIPVicious
> <http://blog.sipvicious.org/>' (Cisco even has an advisory about it
> <https://tools.cisco.com/security/center/viewAlert.x?alertId=33141>) be
> able to access CUBE from the inside while installed on an infected PC.
> Granted, this tool is for SIP, but similar tools exist for h.323.
>
>
> Thanks,
>
> Ryan
>
> ------------------------------
> *From:* cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of
> David Zhars <dzhars at gmail.com>
> *Sent:* Sunday, September 11, 2016 9:37 AM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] Phone Fraud H.323
>
> So yesterday I was alerted by our landline company that some of our phone
> numbers that come in POTS on an H323 router, we being used for phone
> fraud.  I am wondering how this happens with an H323 router (I am familiar
> with someone hacking Unity and setting up actions to route to Jamaica once
> someone leaves a voicemail or similar).
>
> The odd part is that these numbers are almost NEVER used for calling out,
> unless the user presses a 7 for an outbound line (versus an 8 which puts
> the call out on ISDN).
>
> I found a link on how to disable OffNet calling in UCM, but should I
> instead look at securing the H323 router?  Or does the call blocking rule
> need to be done in UCM?
>
> Thanks for any enlightenment you can provide.
>
> PS- Client is in USA, call fraud to Jamaica which does not require a
> country code, so harder to block.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160912/1cfe5b70/attachment.html>