[Freeswitch-users] Your Security Best Practices

[Kristian Kielhofner]

 What carriers are you using that utilize re-INVITEs?


--
Kristian Kielhofner
http://blog.krisk.org

------------------------------
 *From*: freeswitch-users-bounces at lists.freeswitch.org <
freeswitch-users-bounces at lists.freeswitch.org>
*To*: freeswitch-users at lists.freeswitch.org <
freeswitch-users at lists.freeswitch.org>
*Sent*: Tue Jun 15 14:37:02 2010
*Subject*: [Freeswitch-users] Your Security Best Practices

Recently I have seen many attempts to break in to VoIP switches I work with.
So I thought this might be a good time to discuss everyone's security best
practices. If you could relate them to how you implemented them in
FreeSWITCH, it would give us beginners good ideas on how to follow the
principle of "security first". Let me start off the discussion with some
practices we use and have seen in carriers we deal with.

Since we only do carrier-to-carrier stuff, it is easy to restrict the IPs
where we accept traffic from. This is done using either a dedicated firewall
(we use Cisco and pfSense) or host-based (since we use Linux, iptables it
is). We restrict ingress traffic on port 5060 (SIP) to trusted sources only.
Since a lot of carriers are starting to use re-invites and most do not
provide ranges of media IPs they will use, we leave open all UDP ports used
by our servers for RTP, usually between 10,000 and 50,000. In this
situation, how well does FreeSWITCH cope with attacks? For example, if RTP
ports are 10,000 to 20,000, does FS recognize invalid RTP packets and knows
how to deal with them?

Another scenario is user registration of softphones or ATAs, etc. A practice
we use in our lab environment (we will soon be putting servers in
production) is to use lengthy passwords, at least 15 characters, mixing
alpha-numeric characters. We also do not use 4-digit extensions (default in
FS) but use 6-digit. It wasn't started as a security measure but turned out
that many attackers we saw usually try 4-digit extensions. So we are safer
today (maybe not so in the future when attackers wise up). How do you manage
your users, extensions, registrations, etc., from a security aspect?

In the same context, we recently saw a flood of invalid user registration
requests, at close to 60-80 requests per second, for a sustained period of
less than a minute. One proprietary solution we use was unable to handle
this flood of requests and dropped 70% of its call before the attacks
stopped and it was able to recover. Let's say we use top-of-the-line servers
to run FS, maybe two quad-cores with 16GB memory, then should it increase
the ability of FS to deal with such unwanted floods? I assume FS is
configured with default settings. The real question is: does throwing
hardware at the problem solve the issue for FS? And even if it does, is
there anything we can do at the FS level to allow it to handle even more
flooded traffic on its own, without relying on superior hardware?

Then come Man in the Middle attacks. So far I haven't seen a real push in
the industry to mitigate these. One common practice is to use prefixes to
identify traffic from a source. For example, we can use 999912125550000
where 9999 identifies us to the egress gateway and the rest is the number to
call. Of course, since signaling is in plain text someone can analyze this
data and then start using the same prefix to send traffic to our egress
gateway/carrier. They believe the traffic is from us and charge us for the
calls.

A second option is to use SIPS but I haven't seen it being used at all. Of
course, now we are talking about using TCP instead of UDP, bringing its own
advantages and disadvantages.

A third option I am starting to see if the use of IPSec tunnels for
signaling and RTP is exchanged outside of the tunnel. This works well for
carrier-to-carrier traffic but cannot be deployed widely cost-effectively if
you do home user to service provider traffic.

If you have dealt with any one or all of these scenarios, or have come
across others, please share your experiences and solutions with all of us.
Of course, if you can also advise how to implement your security best
practices in FS it would be just wonderful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100615/e32bba13/attachment-0001.html