We're starting to see customers who get random arbitrary ringing caused by a random connection attempt from the internet. Most of our customers have Cisco routers with full-cone NAT, so it's easy to do that. We don't reinvite handsets, we proxy the media, so we've considered using restricted NAT instead. If we can figure out how, we can't find any documentation on how to do it, and don't have a response to our Cisco TAC case on it yet. But I figured I'd ask if others have come up with better solutions. I know there are a few authentication options in the phones themselves, but they seem to vary greatly by vendor and even by model. I like to do things as simply and system-wide as possible. We primarily sell Grandstream, and we support Cisco/Linksys SPA as well as Polycom IP series (not VVX). We're an Asterisk-based hosted service provider.
I was getting ghost ringing into my Polycom because my router sensibly remaps phone:5060 to WAN_IP:5060. My solution was to switch to SIP TCP. On 11/20/2015 03:14 PM, Carlos Alvarez wrote:
We're starting to see customers who get random arbitrary ringing caused by a random connection attempt from the internet. Most of our customers have Cisco routers with full-cone NAT, so it's easy to do that. We don't reinvite handsets, we proxy the media, so we've considered using restricted NAT instead. If we can figure out how, we can't find any documentation on how to do it, and don't have a response to our Cisco TAC case on it yet.
But I figured I'd ask if others have come up with better solutions. I know there are a few authentication options in the phones themselves, but they seem to vary greatly by vendor and even by model. I like to do things as simply and system-wide as possible. We primarily sell Grandstream, and we support Cisco/Linksys SPA as well as Polycom IP series (not VVX).
We're an Asterisk-based hosted service provider.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
That said, it is baffling to me that phones accept INVITEs unchallenged from anywhere but $REGISTRAR_IP/$OUTBOUND_PROXY_IP. -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
That's the default for all the handsets, I believe. There are various options such as "accept only from proxy" or "only from registrar," but like I said it varies so it could be more challenging to employ that. Also in our limited testing it seems like it may not have had the intended effect. Possibly because NAT hides the original IP, but I don't know that for sure. Most phones also have an option to force auth for incoming invites, which we have not tested yet. On Fri, Nov 20, 2015 at 1:21 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
That said, it is baffling to me that phones accept INVITEs unchallenged from anywhere but $REGISTRAR_IP/$OUTBOUND_PROXY_IP.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 11/20/2015 03:23 PM, Carlos Alvarez wrote:
That's the default for all the handsets, I believe. There are various options such as "accept only from proxy" or "only from registrar," but like I said it varies so it could be more challenging to employ that. Also in our limited testing it seems like it may not have had the intended effect. Possibly because NAT hides the original IP, but I don't know that for sure.
Any properly standards-compliant registrar will send a Request URI on incoming INVITEs that is equivalent to the Contact binding provided by the phone originally. It can choose to send that INVITE to a network and transport-layer destination that is different to the network and transport-reachability in the contact provided by the handset, i.e. for far-end NAT traversal, but the integrity of the RURI should not be compromised.
Most phones also have an option to force auth for incoming invites, which we have not tested yet.
I don't think you want that. SIP servers and registrars will certainly definitely expect the registrant to trust them. You can certainly configure Asterisk per se to answer 401/407 challenges from the phone with digest credentials, but that's not a very simple or interchangeable solution. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
On Nov 20, 2015, at 3:27 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
On 11/20/2015 03:23 PM, Carlos Alvarez wrote:
That's the default for all the handsets, I believe. There are various options such as "accept only from proxy" or "only from registrar," but like I said it varies so it could be more challenging to employ that. Also in our limited testing it seems like it may not have had the intended effect. Possibly because NAT hides the original IP, but I don't know that for sure.
Any properly standards-compliant registrar will send a Request URI on incoming INVITEs that is equivalent to the Contact binding provided by the phone originally. It can choose to send that INVITE to a network and transport-layer destination that is different to the network and transport-reachability in the contact provided by the handset, i.e. for far-end NAT traversal, but the integrity of the RURI should not be compromised.
Most phones also have an option to force auth for incoming invites, which we have not tested yet.
I don't think you want that. SIP servers and registrars will certainly definitely expect the registrant to trust them. You can certainly configure Asterisk per se to answer 401/407 challenges from the phone with digest credentials, but that's not a very simple or interchangeable solution.
Broadworks handles the 401 UNAUTHORIZED with nonce fine from a Polycom. It will resend the INVITE with the authentication credentials
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Fri, Nov 20, 2015 at 12:21 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
That said, it is baffling to me that phones accept INVITEs unchallenged from anywhere but $REGISTRAR_IP/$OUTBOUND_PROXY_IP.
^This. Challenge to INVITE should mitigate scanners, and challenge to BYE should mitigate that particular targeted attack. The problem remains that your endpoints receive and process those packets, leaving them vulnerable still to other attacks. Sharing my experience: with our own managed hardware we can use ACLs both in the firewall and/or the SIP proxy/ALG/B2BUA/whatever; when all messaging is relayed through your known proxy then there is no reason to accept SIP globally. With customer provided routers your mileage will vary. Consumer grade devices can be helped sometimes by toggling the SIP ALG from its current setting, whether that's On or Off. For some devices our only recourse has been to suggest the customer change the NAT policy to something more restrictive, knowing it might break other services, or consider a firmware upgrade or downgrade to a version that provides the needed security, or replace the device with something more cooperative. Higher classes of hardware may have sufficient SIP features (ALG, transparent proxy, etc.) to lock down the REGISTER dialog NAT mappings while leaving the non-SIP mappings full-cone/unrestricted. How this can be done on Brand C routers falls outside of my own experience. It's also worth checking if the affected devices have their own options for only accepting requests from the registration domain or other configured proxy, in cases when the router cannot help and you don't want to use nonce challenges. Regards, Calvin Ellison Voice Services Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- voxox.com 9276 Scranton Rd, Suite 200 San Diego, CA 92121 On Fri, Nov 20, 2015 at 12:21 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
That said, it is baffling to me that phones accept INVITEs unchallenged from anywhere but $REGISTRAR_IP/$OUTBOUND_PROXY_IP.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 11/20/2015 04:09 PM, Calvin Ellison wrote:
challenge to BYE should mitigate that particular targeted attack.
Spoofed sequential (in-dialog) requests strike me as less of a concern than initial requests, since, in order for the BYE to match an existing dialog in the phone's UAS, the attacker would have to spoof a valid From & To-tag, Call-ID, CSeq, etc. -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
We've never seen evidence of issues other than just making phones ring. I assume it's some script kiddies trying to find an open SIP proxy. The routers in use are owned by our ISP partner and managed by them. Typical mid-grade routers like a 1900 series. I'm not aware of an ability to filter SIP as an application with those, though I've been pretty removed from Cisco hands-on for some time. Filtering based on port would not help us. On Fri, Nov 20, 2015 at 2:13 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
On 11/20/2015 04:09 PM, Calvin Ellison wrote:
challenge to BYE should mitigate that particular targeted attack.
Spoofed sequential (in-dialog) requests strike me as less of a concern than initial requests, since, in order for the BYE to match an existing dialog in the phone's UAS, the attacker would have to spoof a valid From & To-tag, Call-ID, CSeq, etc.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
These routers use a range of high ports, nothing is on 5060. It seems that they are scanning, and when they get something, repeatedly attack it. Because our enterprise customers are all on a couple of subnets, they may have keyed into "this range is full of SIP devices" and keep hitting them. On Fri, Nov 20, 2015 at 1:19 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
I was getting ghost ringing into my Polycom because my router sensibly remaps phone:5060 to WAN_IP:5060. My solution was to switch to SIP TCP.
On 11/20/2015 03:14 PM, Carlos Alvarez wrote:
We're starting to see customers who get random arbitrary ringing caused
by a random connection attempt from the internet. Most of our customers have Cisco routers with full-cone NAT, so it's easy to do that. We don't reinvite handsets, we proxy the media, so we've considered using restricted NAT instead. If we can figure out how, we can't find any documentation on how to do it, and don't have a response to our Cisco TAC case on it yet.
But I figured I'd ask if others have come up with better solutions. I know there are a few authentication options in the phones themselves, but they seem to vary greatly by vendor and even by model. I like to do things as simply and system-wide as possible. We primarily sell Grandstream, and we support Cisco/Linksys SPA as well as Polycom IP series (not VVX).
We're an Asterisk-based hosted service provider.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
There is a setting in the Polycom config so it will only accept INVITES from the IP it has registered to. You can also configure it to authenticate all INVITES. To match to IP address of the registered line voIpProt.SIP.requestValidation.x.method=?source" voIpProt.SIP.requestValidation.x.request=?INVITE? To require authentication of the registered line. voIpProt.SIP.requestValidation.x.method=?digest" voIpProt.SIP.requestValidation.x.request=?INVITE? ? Matthew Crocker President - Crocker Communications, Inc. Managing Partner - Crocker Telecommunications, LLC E: matthew at corp.crocker.com E: matthew at crocker.com
On Nov 20, 2015, at 3:19 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
I was getting ghost ringing into my Polycom because my router sensibly remaps phone:5060 to WAN_IP:5060. My solution was to switch to SIP TCP.
On 11/20/2015 03:14 PM, Carlos Alvarez wrote:
We're starting to see customers who get random arbitrary ringing caused by a random connection attempt from the internet. Most of our customers have Cisco routers with full-cone NAT, so it's easy to do that. We don't reinvite handsets, we proxy the media, so we've considered using restricted NAT instead. If we can figure out how, we can't find any documentation on how to do it, and don't have a response to our Cisco TAC case on it yet.
But I figured I'd ask if others have come up with better solutions. I know there are a few authentication options in the phones themselves, but they seem to vary greatly by vendor and even by model. I like to do things as simply and system-wide as possible. We primarily sell Grandstream, and we support Cisco/Linksys SPA as well as Polycom IP series (not VVX).
We're an Asterisk-based hosted service provider.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 11/20/2015 12:14 PM, Carlos Alvarez wrote:
We're starting to see customers who get random arbitrary ringing caused by a random connection attempt from the internet. Most of our customers have Cisco routers with full-cone NAT, so it's easy to do that. We don't reinvite handsets, we proxy the media, so we've considered using restricted NAT instead. If we can figure out how, we can't find any documentation on how to do it, and don't have a response to our Cisco TAC case on it yet.
But I figured I'd ask if others have come up with better solutions. I know there are a few authentication options in the phones themselves, but they seem to vary greatly by vendor and even by model. I like to do things as simply and system-wide as possible. We primarily sell Grandstream, and we support Cisco/Linksys SPA as well as Polycom IP series (not VVX).
We're an Asterisk-based hosted service provider.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
This may be dependent upon the Cisco router in question, but when we deploy routers we always set the ACL to only allow SIP communications from our SBC. - When customers provide their own, we recommend the same settings. -- Robert Johnson BendTel, Inc. (541)389-4020 Central Oregon's Own Telephone and Internet Service Provider http://bendtel.com/about/
We have a Calix ONT in our lab that is ?on the internet? for its voice VLAN. It gets rogue INVITES and rings constantly (every 5-10 seconds). Makes for a nice honeypot, source IPs go right into the ACL on the firewall ? Matthew Crocker President - Crocker Communications, Inc. Managing Partner - Crocker Telecommunications, LLC E: matthew at corp.crocker.com E: matthew at crocker.com
On Nov 20, 2015, at 3:35 PM, Robert Johnson <robert.j at bendtel.com> wrote:
On 11/20/2015 12:14 PM, Carlos Alvarez wrote:
We're starting to see customers who get random arbitrary ringing caused by a random connection attempt from the internet. Most of our customers have Cisco routers with full-cone NAT, so it's easy to do that. We don't reinvite handsets, we proxy the media, so we've considered using restricted NAT instead. If we can figure out how, we can't find any documentation on how to do it, and don't have a response to our Cisco TAC case on it yet.
But I figured I'd ask if others have come up with better solutions. I know there are a few authentication options in the phones themselves, but they seem to vary greatly by vendor and even by model. I like to do things as simply and system-wide as possible. We primarily sell Grandstream, and we support Cisco/Linksys SPA as well as Polycom IP series (not VVX).
We're an Asterisk-based hosted service provider.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
This may be dependent upon the Cisco router in question, but when we deploy routers we always set the ACL to only allow SIP communications from our SBC. - When customers provide their own, we recommend the same settings.
-- Robert Johnson BendTel, Inc. (541)389-4020 Central Oregon's Own Telephone and Internet Service Provider http://bendtel.com/about/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Are you employing application layer filtering, or are you simply blocking port 5060? We're not being hit on 5060, but random high ports. And we need to allow internet access so features on the phone display that are outside our network will continue to work. On Fri, Nov 20, 2015 at 1:35 PM, Robert Johnson <robert.j at bendtel.com> wrote:
On 11/20/2015 12:14 PM, Carlos Alvarez wrote:
We're starting to see customers who get random arbitrary ringing caused by a random connection attempt from the internet. Most of our customers have Cisco routers with full-cone NAT, so it's easy to do that. We don't reinvite handsets, we proxy the media, so we've considered using restricted NAT instead. If we can figure out how, we can't find any documentation on how to do it, and don't have a response to our Cisco TAC case on it yet.
But I figured I'd ask if others have come up with better solutions. I know there are a few authentication options in the phones themselves, but they seem to vary greatly by vendor and even by model. I like to do things as simply and system-wide as possible. We primarily sell Grandstream, and we support Cisco/Linksys SPA as well as Polycom IP series (not VVX).
We're an Asterisk-based hosted service provider.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
This may be dependent upon the Cisco router in question, but when we deploy routers we always set the ACL to only allow SIP communications from our SBC. - When customers provide their own, we recommend the same settings.
-- Robert Johnson BendTel, Inc. (541)389-4020 Central Oregon's Own Telephone and Internet Service Provider http://bendtel.com/about/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
We dealt with this years ago. The solution was 2 fold: 1: Stop using port 5060. Pick some other port for your phones to listen on locally. Do the same thing on your access-edge SBC's (this will also pay dividends in ALG avoidance). 2: Find the CPE option to restrict inbound to only the registered proxy. As mentioned before this might be different for each device make but it is unquestionably the best solution. On 11/20/2015 12:14 PM, Carlos Alvarez wrote:
We're starting to see customers who get random arbitrary ringing caused by a random connection attempt from the internet. Most of our customers have Cisco routers with full-cone NAT, so it's easy to do that. We don't reinvite handsets, we proxy the media, so we've considered using restricted NAT instead. If we can figure out how, we can't find any documentation on how to do it, and don't have a response to our Cisco TAC case on it yet.
But I figured I'd ask if others have come up with better solutions. I know there are a few authentication options in the phones themselves, but they seem to vary greatly by vendor and even by model. I like to do things as simply and system-wide as possible. We primarily sell Grandstream, and we support Cisco/Linksys SPA as well as Polycom IP series (not VVX).
We're an Asterisk-based hosted service provider.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 20/11/15 22:57, Ryan Delgrosso wrote:
1: Stop using port 5060. Pick some other port for your phones to listen on locally. Do the same thing on your access-edge SBC's (this will also pay dividends in ALG avoidance). 2: Find the CPE option to restrict inbound to only the registered proxy. As mentioned before this might be different for each device make but it is unquestionably the best solution.
3. Some phones (like snom) expect invites with a line=xxxxx in the first line. No line ID, no ringing. INVITE sip:5060 at 192.168.2.174:35778;line=3vosp6yi SIP/2.0 -- Tim Bray tim at kooky.org | +44 7966 479015 | http://www.kooky.org Huddersfield, UK
participants (7)
-
abalashov＠evaristesys.com -
caalvarez＠gmail.com -
calvin.ellison＠voxox.com -
matthew＠corp.crocker.com -
robert.j＠bendtel.com -
ryandelgrosso＠gmail.com -
tim＠kooky.org