On Tue, Nov 12, 2013 at 6:05 PM, Hiers, David <David.Hiers at adp.com> wrote:

Maybe someone is spoofing your SBC IP address?

I can't see what useful info would be gained from such spoofing, but enough of these could DOS you pretty hard.

I would suggest capturing packets towards the devices experiencing it, behind the NAT device, using Wireshark ----- I would wonder first if either the NAT/ACL isn't working as designed; or traffic is coming from a SIP ALG / inside the NAT; spoofing the SBC's source IP seems terribly unlikely. I think it's more likely, there's an unexpected way the Polycom is being contacted, such as a proxy service on a router. Then there is that matter of; "Does your NAT device verify the foreign IP address of reverse traffic like a full stateful firewall would, or does it just check the destination port number on an incoming packet, and immediately translate to internal IP based on the destination port number and forward to the internal device?" In the latter case, the internal device might be contacted on port 5060 from other internet hosts scanning the ephemeral port range; if that 5060 from the internal device has recently been used as a source port from the Polycom contacting the SBC. So a full packet capture from the network with the handsets, could give you a better idea, of what you are seeing.

David

-- -JH

Hi all, I'm the original author of SIPVicious and released the tools to help other security professionals and netops etc to test their own systems. Needless to say, the tools are abused. The reason why you're getting these calls is that someone is probably using svwar.py (part of the toolset) on your phones. Another contributing factor is that the Polycom is probably ringing when any INVITE message it sent to it rather than validating the IP address and/or the target SIP address. Yet another potential factor is that the phones are using STUN or something like that if they are behind NAT, to keep the port open and I'd guess that the router just opens the port (UDP/5060) to any outside IP. The persons causing your phone to ring are a misguided bunch and get nothing out of getting your phone to ring (as far as I know). They are typically looking for PBX servers and SIP gateways (especially ones with an FX0) that will either relay their calls or (in the case of a PBX / SIP registrar) allow them to enumerate extensions via an INVITE brute force. Normally no spoofing of the SBC IP address is required in this case. The solutions that Keith Croxford (for the Polycom config) gave should help address this issue. The point is that the source of the call should be validated and matched to a whitelist. Other mitigations may involve changing the source port on the phones (which doesn't really solve the issue) and switching to SIP TCP instead of UDP (since this wouldn't require the port to be forwarded). Both solutions might not really address the issue but rather try to fix the symptoms. I had put a blog post on this topic: http://blog.sipvicious.org/2012/12/if-sipvicious-gives-you-ring.html Feel free to contact me off-list to discuss further, Sandro Gauci Penetration tester and security researcher Email: sandro at enablesecurity.com Web: http://enablesecurity.com/ PGP: 8028 D017 2207 1786 6403 CD45 2B02 CBFE 9549 3C0C On Wed, Nov 13, 2013 at 4:43 AM, Jay Hennigan <jay at west.net> wrote:

On 11/12/13 6:40 PM, Jimmy Hess wrote:

...

I would suggest capturing packets towards the devices experiencing it, behind the NAT device, using Wireshark ----- I would wonder first if either the NAT/ACL isn't working as designed; or traffic is coming from a SIP ALG / inside the NAT; spoofing the SBC's source IP seems terribly unlikely.

I think it's more likely, there's an unexpected way the Polycom is being contacted, such as a proxy service on a router.

Good idea, but these are typically remote customer sites and any individual phone maybe gets one of these ghost calls per day or two, so implementation is kind of tough.

...

Then there is that matter of; "Does your NAT device verify the foreign IP address of reverse traffic like a full stateful firewall would, or does it just check the destination port number on an incoming packet, and immediately translate to internal IP based on the destination port number and forward to the internal device?"

In the latter case, the internal device might be contacted on port 5060 from other internet hosts scanning the ephemeral port range; if that 5060 from the internal device has recently been used as a source port from the Polycom contacting the SBC.

That's kind of what I was thinking but we're also seeing it from behind an Adtran IAD with a SIP ACL that permits only our SBCs.

...

So a full packet capture from the network with the handsets, could give you a better idea, of what you are seeing.

Absolutely agreed. The Polycom XML code mentioned earlier looks promising as well.

The curious thing is that this is suddenly happening within the past two days on installations that have been trouble-free for months.

-- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

On 11/12/13 4:06 PM, Keith Croxford wrote:

Try this - * Polycom -*

Add this to your config file. This will cause the phone to respond with a '400 bad request' unless the INVITE comes from the registrar.

voIpProt.SIP.requestValidation.1.request="INVITE" voIpProt.SIP.requestValidation.1.method="source"

We will test this in the lab. Also suggested by Mauricio Lizano with the caveat that it could break things.

*Adtran (Only applies to the local SIP stack (voice users, trunks etc) ) *

Add an ACL, which only lists your proxy/SBC IPs

ip access-list standard my-proxy remark MY IP SPACE permit x.x.x.x y.y.y.y log

!Apply the ACL as a sip access-class ip sip access-class my-proxy in

This has already been done. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV