One of the features of sipXecs security is that we have a permissions
system that enforces access controls on dial plans. This is the
foundation of our protections against toll fraud - preventing
unauthorized persons (and especially outside attackers) from making toll
calls through the PSTN from the PBX. Before a call can be made, the
caller is authenticated using SIP authentication, and we verify that the
authenticated identity has the permission required to use the dial plan.
If the caller can't be authenticated (as would be the case for an
outside caller), then there is no permission and so no call.
This feature does have downsides, however, in that it makes some
desirable configurations difficult or impossible. The most frequent
example of this is gateway sharing across federated systems:
If my company has offices in New York and London, each set up as a
separate sipXecs system like this:
PSTN (US) - gateway - pbx (NYC) -SIP- pbx (LON) - gateway - PSTN (UK)
it would be nice for me to be able to configure each system to route
calls through the other when that would result in lower cost calling
(usually called 'toll bypass'). Today, that won't work because the user
administration of the two systems is separate, so they can't
authenticate to the other system (note that in the planned sipXecs 5.0
multi-branch support, it would be possible to have unified user
administration).
Similarly, we now have configurations in which a sipXecs system is being
added to legacy systems using a SIP Trunk through sipXbridge (often to
support small branch off the larger legacy system):
PSTN - gateway - sipXecs - sipXbridge -SIP- PBX - pbx_phone
Again, it would be good to be able to support a phone on the legacy PBX
making a call through the SIP trunk and out the sipXecs gateway.
Note: these configurations could be set up today by turning off
the permission requirements on the gateway dial plans: I
strongly advise that this _never_ be done. If you do it, count
on someday getting a really big phone bill (this is not
theoretical - it has happened on at least one misconfigured
system I know of: the attacker was sophisticated and set up a
high volume operation very quickly).
I'd like to explore solutions to allow these configurations by having
the sipXecs border element (the component that first gets the connection
from the 'other' system) authenticate the connection itself, and tag any
request coming in on that connection as 'privileged' (note: not
'trusted' - I want it to have some implied identity whose permissions
can be checked, not some blanket ability to bypass security).
I think that this requires that both sipXproxy and sipXbridge be able to
act as the 'border element'. The sipXproxy would be used for
connections that are 'full' SIP (as two sipXecs system connected by a
site-to-site rule), and the sipXbridge for connections to legacy systems
in which the intermediation features (such as not forwarding REFER)
created for ITSPs are needed.
In either case, a connection that is configured to be privileged would
attach a signed X-Sipx-Authidentity header (which, incidentally, I'd
like to change to Sipxecs-Authidentity) with the identity configured for
that connection. I _think_ that would prevent any further challenges
and give the call the permissions associated with that identity.
My own preference would be to require that the connection be mutually
authenticated with TLS ('authentication' based on just an IP source
address is notoriously easy to defeat).
Comments?
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
