[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