Cisco CUBE SIP listen issue

[Dieselboy]

I have a Cisco 2901 router with 3 interfaces:
0/0 is in VRF 2 and connects to the upstream ISP
0/2 is in VRF 2 and is facing the ASA firewalls WAN interface

0/1 is in the global VRF and runs the voip services CUBE.

ports 0/0 comes in from the internet and is a /30. The inbound ACL on this interface denies all traffic to the IPs configured on 0/0 and 0/2. But I permit traffic to the rest of the /28 which is configured on the 0/2 interface (so that our public IPs are reachable via the ASA firewalls).

I saw an attacker sending our CUBE sip invites yesterday and I could not immediately understand how they were making it to the CUBE, since all traffic is DENIED to the router on the public interfaces 0/0 and 0/2.
To mitigate, I first configured the SIP process to bind to 0/1. This resolved the issue but did not explain it.

Looking into this again today, I understand this:
- without sip binding, sip listens on *:5060 which means all interfaces
- although the ACL denies traffic to the router IPs (in VRF 2) I need to permit any source to the /28 block so that the router sends the traffic to our ASAs

The way point 2 should work is this:
- router has a packet destined for another IP in the /28
- port 0/2 has an IP in this range so it sends an ARP out of 0/2
- ASA responds to the ARP
- router forwards the packet to the ASA MAC

However, during this attack, the attacker was spoofing the source and destination IP of an address which is not in use by the ASA. So, it appears that this process was occuring instead:
- router has a packet destined for another IP in the /28
- port 0/2 has an IP in this range so it sends an ARP out of 0/2
- no response to ARP as IP not in use

So at this point, my expectation is that the router would drop the packet because it cannot be forwarded. But it appears that the packet is being processed by the sip process listening on *:5060 even though the destination IP is not configured on the router at all.

Working with Cisco on this. In hindsight I will now bind sip to the correct interface always in future:

Code Select Expand

voice service voip
sip
  bind control source-interface GigabitEthernet0/1
  bind media source-interface GigabitEthernet0/1

[Dieselboy]

Confirmed with packet capture. Router receives a packet desined for an IP which is not in use, so the router does not receive an ARP reply. Instead of dropping the traffic, the router sends it to the sip process. The desintation IP of the packet is not configured on the router and is not in use elsewhere in our network.

I tried to mitigate this using a static route for the /28 block with high AD going to null0, and configure static host routes pointing to the ASA for each used IP but because the router has an interface in that range, it's "locally connected" and therefore the static routes don't do anything.

Only other thing I can think of is to reconfigure the WAN of the ASA and the LAN facing internet port of the router to use a private ip address, and use NAT for everything on the ASA.

Waiting on Cisco.

[deanwebb]

Wow, that's pretty wild stuff.

[Dieselboy]

I also confirmed the router is listening on the subnet address and processing sip messages to the subnet ID. For example, router is configured with x.x.x.177/28 which is the first usable IP but router is picking up invites to x.x.x.176 and responding to them.

Still waiting for Cisco's update

[Dieselboy]

Cisco TAC advised that the router running sip does not care about the layer 3 destination IP address.

Doesn't seem right to me. So basically any SIP packets that are to traverse (route) through a router with SIP enabled, will be picked up and processed by the router; even though the router is not using the IP address in the destination IP field of the packet.

So without sip being bound to one interface, we have this socket:

Code Select Expand

-------------- SIP Transport Layer Listen Sockets ---------------
  Conn-Id               Local-Address
===========    =============================
   0            [0.0.0.0]:5060:


Normally, 0.0.0.0 would mean any interface on the device (any ip on the device). However TAC are saying thats not the case here.

[deanwebb]

Cisco TAC advised that the router running sip does not care about the layer 3 destination IP address.

Doesn't seem right to me. So basically any SIP packets that are to traverse (route) through a router with SIP enabled, will be picked up and processed by the router; even though the router is not using the IP address in the destination IP field of the packet.

So without sip being bound to one interface, we have this socket:

Code Select Expand

-------------- SIP Transport Layer Listen Sockets ---------------
  Conn-Id               Local-Address
===========    =============================
   0            [0.0.0.0]:5060:


Normally, 0.0.0.0 would mean any interface on the device (any ip on the device). However TAC are saying thats not the case here.

[Dieselboy]

First, the IP I confirmed is actually not a host ID it's the broadcast ID of the subnet. Think I got mixed up between .181 and .191 with .191 being the broadcast ID, I am not sure right now. So I went back to check the captures and logs again and confirmed that it's just those 2 IPs which are the subnet ID and the broadcast ID. There are other logs but for this issue, just those two destination IPs.

So, with that, the router will not try to route the broadcast destination address to the LAN via ARP; so I was incorrect in that part.

That leads me on to the next. Someone informed me that the router will listen on the subnet and broadcast IDs. I was sort of aware regarding the broadcast (I've sent pings to broadcasts before to get devices to reply) but was not aware about subnet ID. So it appears that the router picking up the sip invites for the broadcast and subnet IDs may actually be normal.

I have updated the ACLs to block traffic to the router network and broadcast IDs / IPs in addition to the routers hosts addresses. I'll be sure to do this as part of normal config going forward. One to take note of if you did not know already; or may be you knew but did not join the dots (like I did).