EDIT: I just noticed that you are explicitly allowing SIP traffic in your WAN from a single range, and denying everything else. We'd really need SIP and H323 debugs running during an occurrence to say for sure where it came from, and what occurred. If you're blocking all other traffic except 5060 from 184.108.40.206, then the fraud either came in another interface than the one 104 is applied inbound on, or the fraud came from that 'trusted' IP.
The easiest thing for you is to take advantage of our toll fraud enhancement in 15.1(2)T, so that you only allow VoIP calls from those known source IPs which you trust for calls:
Or like you mentioned, just deny all SIP traffic from the Internet, if you don't have a SIP ITSP.
I'm going to leave my original post below for others' future reference, but it isn't as relevant for you as I thought.
I'm copying a write-up I did for a previous person. I briefly editied it, but it should explain this in detail for you. It really boils down to making sure you don't allow unwanted traffic in from an untrusted source. This is a basic network design mentality, and carries over to voice:
By default, before CSCsb25337, any router listens for SIP and H.323 connections as long as the router is voice capable. This is by design. With the fix for CSCsb25337 (most recent code), we only listen on that VoIP protocol if you have a dial-peer configured for that protocol. As soon as you have a SIP peer (like for CUE), the SIP listener will run on all interfaces. Hence, if you don't restrict VoIP traffic inbound on your interfaces with public IP addresses, you can run into toll fraud. You should follow security best practices and only allow traffic which you trust in from untrusted sources.
To prevent future call fraud, you should do one of the following things (placed in descending order of recommendation): -Place a firewall between your CME/voice router and the Internet, that will not trust voice control traffic inbound from the Internet towards the voice router. Because of the dialer interface, this may not be a probably solution for you.
-Place an access-list inbound on the public interface that only permits specific traffic. The implicit deny in the access-list will block other traffic, preventing attacks. This is recommended, as you have full control of what traffic you want to allow into your network from the Internet. For instance, say I only want to trust traffic from google (220.127.116.11) inbound:
int Dialer1 ip access-group 101 in
!This access-list would allow any traffic from Google, and block everything else with an implicit deny statement. access-list 101 permit ip host 18.104.22.168 any
-Place an access-list inbound on the public interface to at least block SIP and H.323 traffic. This would leave the router still vulnerable to other Internet attacks, as all other ports that are listening on the router are left open:
int ip access-group 101 in
!This access-list would only block voice traffic (H.323, SCCP, MGCP, SIP). access-list 101 deny tcp any any eq access-list 101 deny udp any any eq 2427 access-list 101 deny tcp any any eq 2428 access-list 101 deny tcp any any range 1718 1720 access-list 101 deny tcp any any eq 1731 access-list 101 deny tcp any any eq 2000 access-list 101 deny tcp any any eq 5060 access-list 101 deny udp any any eq 5060 access-list 101 permit ip any any
You can also check out this link; we changed some behavior in recent code which will make it easier for you if you are willing to upgrade. On new code, we reject VoIP calls from any source not explicitly defined in the config: https://supportforums.cisco.com/docs/DOC-12228
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...