[Freeswitch-users] Your Security Best Practices

[Code Ghar]

I was reading up on some security advice and came across an article from
Digium (http://blogs.digium.com/2009/03/28/sip-security/). A few points that
stood out for me were:

"Make your SIP usernames different than your extensions". This sounds like
good advice because now an attacker has to guess the user name and password
instead of just a password. The biggest benefit to this is that even if
someone knows the format of your extension numbers, they are not able to use
it for registration credentials. Of course, the issue of DoS using a large
number of simultaneous authentication requests still remains. How can we
deal with this?

"... reject bad authentication requests on valid usernames with the same
rejection information as with invalid usernames ..." How can we do this in
FS? I haven't looked at this yet so maybe FS does such a thing anyways;
advice from your experience and expertise required.

"Allow only one or two calls at a time per SIP entity, where possible." This
is standard practice in prepaid phone card business. They allow only one
simultaneous call and if you try to use the PIN to make another call it's
not allowed. At the application level we may be able to do this in FS but it
reminds me of another scenario. Let's say a user's registration is
compromised. Can we prevent registration with same credentials from two
different locations in FS? For example, one registration attempt is from New
York and the other from Baltimore. This would affect the legitimate user
because they might not be able to register. Does anyone restrict this way
using FS?

Apart from the article mentioned, there are some other issues, one of which
is ANI authentication. A lot of pinless prepaid phone services use your
caller ID to authenticate and authorize a call. you give them your phone
number and when you call from there you can use the service. With VoIP it's
very easy to spoof ANI. I believe the concept of "context" helps a lot here.
Say you know the ANI's you assigned to your registered users. They would be
in the "default" context, for example. Now if an attacker uses the same ANI
but tries not from a registered endpoint but say from one of your carriers.
His context would be "public", for example. This way the combination of ANI
with context can prevent such attacks.

But what if the authorized ANI (say 4145550000) is not from a registered
endpoint but from a cell phone, similar to the pinless services offered
today. In this scenario I think there's not much we can do. If we have given
a user an access number (say 2125550000) provided to us by a DID provider,
say ABC, then whenever someone dials 2125550000 then we get the call only
through ABC, whom we have allowed. But we can't be sure that 4145550000 is
actually 4145550000 and not someone pretending to be them. Has anyone
figured out a way to detect and/or prevent such fraudulent calls? Is it even
possible?




On Tue, Jun 15, 2010 at 4:59 PM, Anthony Minessale <
anthony.minessale at gmail.com> wrote:

> We have some parameters to disable some commonly abused features in a
> carrier env.
>
> in the sofia profile
>
> set manage-presence to false
>
> If you are not providing registration or client transfers disable them
> completely
> set disable-transfer to true
> set disable-register to true
>
>
> And register for ClueCon where someone will probably give a talk on VoIP
> security!
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
> Twitter: http://twitter.com/FreeSWITCH_wire
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:+19193869900
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100617/12c33a84/attachment.html