19 May
2005
19 May
'05
5:38 p.m.
On Thursday 19 May 2005 07:49 am, Jan Janak wrote:
On 02-05-2005 19:00, Michael Ulitskiy wrote:
Thanks Jan and everyone else who replied.
I got it. Just wanted to point out again that I believe it would be to everyone
best to make it more clear in documentation.
Michael
Hello,
I'm trying to comprehend loose routing concept and I have
a question that concerns me.
As far as I understand loose routing says that if there're Route
headers in a message it should be forwarded according to the URIs
set in Route headers.
I thought that this is true only within a dialog, but RFC3261 (part 16.6) says:
"Requests establishing a dialog may contain a preloaded Route header field."
Also SER manual says: " the failure not to include loose routing in your scripts
may lead to infinite loops. Make sure that you include the following script
fragment immediately after request sanity checks" and provide the following
piece of code:
if (loose_route()) {
t_relay();
break;
};
which as far as I understand unconditionally forwards message if Route header
is present.
So I'm wondering what about security?
Your concerns are correct. Loose routing and especially pre-loaded
route sets can become security issue. Moreover, when loose routing is
being used, then the SIP message can be forwarded to the URI from the
2nd Route header field -- but all security-related check in SER
usually check the Request-URI (which is the contact of the remote
party in this case).
You should put all the access control checks also before
t_relay in the loose_route condition. This will ensure that the
caller has permissions to place calls to the URI in the Request-URI,
nothing less nothing more.
This is not yet enough (as you corrently point out in the text below)
and because it is not possible to check the real IP and port of the
next hop after all changes have been done by SER (and it is complex
becuase it can involve DNS queries to resolve SRV/A records), you would
need to deploy some screening on the gateway side too.
The gateway should check if the request is coming from the IP and port
of the trusted proxy server and in addition to that it should verify
that the Request-URI contains the IP (not hostname) and port that belongs
to the gateway. The Request-URI test is important because an attacker could
create a fake DNS record that will resolve to the IP of your gateway
and this way he could bypass access control checks on the proxy. If
the request-uri of the message contains the IP of the gateway then you
know that the proxy server did all the access control checks because
it knew it was forwarding to the gateway. Requests containing another
IP or any hostname in the Request-URI should be rejected by the
gateway.
If the gateway does not support such screening then you could put
another SER instance with very simple configuration (that would just
perform the checks, no loose routing) in front of it. The simpler the
better in this case.
Some people on the list also suggested putting a "magic cookie" into
the Request-URI which will only be known to the SIP Proxy and gateway.
The proxy server would only put the cookie into the Request-URI if it
successfuly performed all the security checks and if it knows that it
is forwarding to the gateway. The gateway would reject any request
that does not contain the magic cookie.
Jan. If I follow
this guidelines how I would
shield my PSTN gateway if anyone can construct message and
pre-load it with URI of my gateway and all my proxies must honor it.
For example I have a PSTN gateway on ip address 10.1.1.5 and proxy
on 10.1.1.10 that supposed to interface outside world.
So I guess if someone construct a message like this:
INVITE sip:12345@somewhere.com SIP/2.0
...
Route: <sip:12345@10.1.1.5;lr>
my proxy will forward it to PSTN gateway and it will make outbound call.
Is this true? Please enlighten me on this.
Thank you,
Michael
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers