<br><br><div class="gmail_quote">On Thu, Jun 17, 2010 at 3:31 PM, Code Ghar <span dir="ltr"><<a href="mailto:codeghar@gmail.com">codeghar@gmail.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;">
I was reading up on some security advice and came across an article from Digium (<a href="http://blogs.digium.com/2009/03/28/sip-security/" target="_blank">http://blogs.digium.com/2009/03/28/sip-security/</a>). A few points that stood out for me were:<br>
<br>"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?<br>
</blockquote><div><br>Use fail2ban or some other mechanism. If someone is sending mass numbers of SUBSCRIBEs then you should be handling that the same way you handle all brute-force attacks - at the firewall. Although you should definitely not make hacking your VoIP system easy, you should also keep in mind that external security is an absolute must. Use the layered approach<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>"... 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.<br>
</blockquote><div>This I don't know. Is it handled down in Sofia? Brian or Tony could tell us.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>"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?<br>
</blockquote><div>I'm sure you could use a combination of ACLs and mod_limit.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>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.<br>
</blockquote><div>I cringe at the thought of doing *ANY* kind of authentication based on incoming caller ID...<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>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?<br>
</blockquote><div>I think this is where mod_cleo comes in. :P Seriously, you probably should treat inbound calls as untrusted regardless of where they're from, at least until you've done some level of verification. A PIN code isn't hyper-secure, but it is better than nothing. <br>
<br>You can't prevent all of these attacks. The best you can hope to do is to make the attacks as difficult as reasonably possible without irritating your paying customers. <br><br>I invite others to chime in. Also, I've started an informal security best practices page on the wiki:<br>
<br><a href="http://wiki.freeswitch.org/wiki/Security_bp">http://wiki.freeswitch.org/wiki/Security_bp</a><br><br>Everyone put your thoughts up and we'll formalize it at a later time.<br>-MC<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><br><br><br><div class="gmail_quote">On Tue, Jun 15, 2010 at 4:59 PM, Anthony Minessale <span dir="ltr"><<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@gmail.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;">
We have some parameters to disable some commonly abused features in a carrier env.<div><br></div><div>in the sofia profile</div><div><br></div><div>set manage-presence to false</div><div><br></div><div>If you are not providing registration or client transfers disable them completely</div>
<div>set disable-transfer to true</div><div>set disable-register to true</div><div><br></div><div><br></div><div>And register for ClueCon where someone will probably give a talk on VoIP security!</div><div><br></div><br>
<div>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><div class="im"><br>ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
</div>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</a><br><br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:+19193869900<br>
</div>
<br></blockquote></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>