[Serusers] partially restrict access
Jiri Kuthan
jiri at iptel.org
Fri Nov 14 03:23:51 CET 2003
I use almost identical scripts with following diffs:
- after authentication check, I also check for group membership;
the rationale is that not every authenticated user has the privilege
to call anywhere
if (uri =~ "sip:0[1-9][0-9]+ at .*") { /* one zero ... local calls */
if(!is_user_in("credentials", "local")) {
sl_send_reply("403", "no permission for local calls...");
break;
};
# the same for long-distance
} else if (uri =~ "sip:00[1-9][0-9]+ at .*") { /* two zeros ... LD ...
- to verify that someones doesn't try to misue record-route processing
logic with preloaded routes to bypass the proxy, I do the following check
in rr-processing:
if (loose_route()) {
# check if someone has not introduced a pre-loaded INVITE -- if so,
# verify caller's privileges before accepting rr-ing
if ((method=="INVITE" || method=="ACK" || method=="CANCEL")
&& uri =~ "sip:[+0-9]+ at GW_ADDRESS") {
route(3); # Forward to PSTN gateway (that's where all the ACL checks
# are executed
} else {
append_hf("P-hint: rr-enforced\r\n");
# account all BYEs
if (method=="BYE") setflag(1);
route(1); # Generic forward
};
break;
};
- you may wish to apply 'consume_credentials' to make the messages
to gateway less fat (just an esthetical option)
- I apply the checks only to INVITEs and not for subsequent requests, such as BYE.
What can happen otherewise is that a gateway calls to IP, the call is answered
in some other domain (daniel at medina.home), the BYE will come from the other domain,
the request-uri-based logic will challenge it and the BYE will fail (no digest
credentials for caller from the other domain)
(cont. bellow)
At 09:25 PM 11/13/2003, Daniel Medina wrote:
> We're configuring ser to allow any calls made to local extensions go to
>the local PBX, but restrict 10-digit calls via the gateway from
>non-registered users. This is the config.
>
>if (uri=~"^sip:(.+@)?mydomain.edu") {
> if (method=="REGISTER") {
> log(1, "REGISTER received\n");
> if (!www_authorize("mydomain.edu", "subscriber")) {
> www_challenge("mydomain.edu", "0");
> break;
> };
> save("location");
> break;
>};
>
># 5-digit local call
>if (uri=~"^sip:[0-9]{5}@mydomain.edu") {
> rewritehostport("CISCO_GW:5060");
> log(1,"5 digit local call");
> route(2);
> break;
>};
>
># 10 Digit dialing with outside line (93 +1 +number)
>if (uri=~"^sip:931[0-9]{10}@mydomain.edu") {
> if(!(src_ip=="CISCO_GW") &
> !(proxy_authorize("mydomain.edu","subscriber"))) {
> proxy_challenge("mydomain.edu", "1");
> break;
> } else {
> rewritehostport("CISCO_GW:5060");
> log(1,"Outside line")
> route(2);
> break;
> };
>};
>
> I've seen other configs posted which appeared to be more strict than
>this, specifically they would only allow registered users to may calls,
>and not accept calls from anonymous sources to local numbers.
>
> This above appears to work, sort of. While it doesn't allow anonymous
>callers to register, I think it's also not allowing them a chance to
>authenticate.
I don't understand the objective here -- authentication of anonymous users
is not what you would like to do, is it? (I mean it is kind of mutualy
exclusive)
> The logs say
>
>ERROR: forward_msg: no 2nd via found in reply
> (repeated a few times)
>Outside line
> (Indicating that the caller actually passed)
>route[2]:SIP-to-PSTN call routed
>ERROR: reply cannot be parsed
Well, unless I see message dumps I assume that it happens what your
log tell: someone sends a reply to proxy server with only one via
header field in it, or other defect. (Other situatation when this may
happen is when SER acts as a UAC, like if it generates local CANCELs,
and replies come back after the transaction state is already gone.)
-jiri
More information about the sr-users
mailing list