[Freeswitch-users] Your Security Best Practices

[Sergey Okhapkin]

The security related problems were discussed on almost every soft switch 
mailing lists I'm watching. And the outcome was (in plain English which 
Americans do not understand) - never provide working configuration samples in 
the softswitch distribution :-( Let the end user build the configuration.

On Thursday 17 June 2010, Brian West wrote:
> You really should try FreeSWICH and understand the security.  In the end
>  its YOUR job to secure it... not ours.  I can't stop someone from setting
>  up FreeSWITCH in an insecure way.  Just like you can't stop someone from
>  setting up a CGI script that owns your box.
> 
> On Jun 17, 2010, at 5:31 PM, Code Ghar wrote:
> > 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?
> 
> How about you set the AUTH username different then the username and then
>  have a password too?
> 
> > "... 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.
> 
> All bad requests get a 403.  All requests good or bad get a 401 then a 403
>  if invalid.  No indications at all that the username is valid.
> 
> > "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?
> 
> Mod_limit.
> 
> > 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.
> 
> Never a good idea to use caller id as auth.
> 
> > 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?
> 
> NO.
> 
> /b
> 
> 
> 
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>