Let me put it this way: of more than 40 carriers I work with, only six have some sort of problem if they see re-invite. Some of the bigger names most people recognize all support re-invite (and some even prefer it): AT&T, Qwest, and Verizon, among others.<br>
<br>Let me clarify when I say re-invite. We are basically talking about keeping yourself in the signaling path but once the call is answered to invite your ingress and egress carriers to use each others' media IP instead of your media IP. This way you don't have to deal with media once call is connected.<br>
<br><br><div class="gmail_quote">On Tue, Jun 15, 2010 at 2:56 PM, Kristian Kielhofner <span dir="ltr"><<a href="mailto:kris@kriskinc.com">kris@kriskinc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><font color="navy" face="Arial" size="2">
What carriers are you using that utilize re-INVITEs?<br>
<br>
<br>--
<br>Kristian Kielhofner
<br><a href="http://blog.krisk.org" target="_blank">http://blog.krisk.org</a></font></div>
<br><div><hr align="center" size="2" width="100%">
<font face="Tahoma" size="2">
<b>From</b>: <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a> <<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>>
<br>
<b>To</b>: <a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a> <<a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a>>
<br><b>Sent</b>: Tue Jun 15 14:37:02 2010<br>
<b>Subject</b>: [Freeswitch-users] Your Security Best Practices
<br></font><br></div><div><div></div><div class="h5">
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.<br>
<br>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?<br>
<br>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?<br>
<br>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?<br>
<br>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.<br>
<br>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.<br><br>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.<br>
<br>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.<br>
</div></div><br>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br>