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
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
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
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
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.
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
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
> On Nov 20, 2015, at 3:27 PM, Alex Balashov 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
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) /
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.
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
On Fri, Nov 20, 2015 at 12:21 PM, Alex Balashov
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
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
13 matches
Mail list logo