[OpenSIPS-Users] Could I build a "SIP firewall" with OpenSIPS?

[Dan Ballance]

Thank you so much for this Anca! I hugely appreciate your input on this :)

dan

On 14 April 2011 11:25, Anca Vamanu <anca at opensips.org> wrote:

>  Hi Dan,
>
>
>
> On 04/13/2011 05:43 PM, Dan Ballance wrote:
>
> Hi there,
>
>  I am investigating OpenSIPS for use in my company's VOIP network.
> I'm wondering if I could get a little advice on a design I am considering?
>
>  The problem:
>
>  We currently have a VOIP network built around a propriety SIP proxy which
> we are discovering appears to have a number of security weaknesses. The most
> significant of these is it's inability to tear down calls in progress once a
> user's balance has hit zero and having no ability to limit the channels that
> a user has open. This could potentially cripple our business due to the
> losses we are experiencing from fraud.
>
>
> You can use opensips for implementing the firewall that you require, but
> your solution is not complete. I will explain bellow why.
>
>  A very early draft of my solution:
>
>  I have noticed the OpenSIPS module userblacklist (
> http://www.opensips.org/html/docs/modules/1.6.x/userblacklist.html ) and
> believe that this could solve our problems. I have other code running
> elsewhere on our network which is able to identify fraudulent calls - I just
> need a way of killing said calls and stopping the fraud in progress. It
> seems with this module I could call a web service on the OpenSIPS server,
> add and remove SIP uris from the blacklist database table and then call the
> module MI function via XML-RPC to update the list and cut off the call. (At
> least I am hoping it could do this - can the blacklist block calls in
> progress?)
>
> The userblacklist module can be used to deny future calls from a fraudulent
> account. Just that you have to also provide the prefix for the destination
> that you want to block. So, from your external application you can add
> record with the account and prefixes in the *userblacklist* table and call
> the MI command 'reload_blacklist' to let opensips know that the list was
> been updated.
> But you can not use it to stop ongoing calls. For this you need the *
> dialog* module, you can tell it to stop an ongoing call by sending the MI
> command dlg_end_dlg(
> http://www.opensips.org/html/docs/modules/devel/dialog.html#id294808).
> Note that you have to call *dlg_list* 'callid' (
> http://www.opensips.org/html/docs/modules/devel/dialog.html#id294675)
> before to get the info required by *dlg_end_dlg* command.
>
>
>  Assuming the userblacklist module will do what I hope, I have a question
> about how to slot the OpenSIPS server into our network. In an ideal world, I
> would run the OpenSIPS server in stateless mode so that is scales well, and
> do nothing more with the SIP traffic apart from forward on non-blocked calls
> to our existing propriety SIP proxy and block banned SIP uris from
> progressing any further.
>
>  The main question I have is can the userblacklist module be run in
> stateless mode and is it possible for OpenSIPS to forward on traffic to
> another SIP proxy for registration. In effect I guess I am trying to build
> some kind of SIP firewall out of OpenSIPS but I don't know if this is
> possible. Any advice / constructive criticism from the knowledgeable people
> on this list would be massively appreciated!
>
>  If you use the dialog module - then you will have to have opensips
> running in statefull mode (dialog aware in fact).
>
>  Sincerely,
>
>  Dan.
>
>  (If it's okay I will keep my surname and company name anonymous due to
> the public nature of this list and the fraud problems that we have been
> experiencing.)
>
>  Regards,
>
> --
> Anca Vamanu
> OpenSIPS Developer
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110414/5bf1e4f7/attachment-0001.htm>