Re: [Freeswitch-users] Your Security Best Practices
What carriers are you using that utilize re-INVITEs? -- Kristian Kielhofner http://blog.krisk.org ------------------------------ *From*: freeswitch-users-bounces@lists.freeswitch.org < freeswitch-users-bounces@lists.freeswitch.org> *To*: freeswitch-users@lists.freeswitch.org < freeswitch-users@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.
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. 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. On Tue, Jun 15, 2010 at 2:56 PM, Kristian Kielhofner <kris@kriskinc.com>wrote:
What carriers are you using that utilize re-INVITEs?
-- Kristian Kielhofner http://blog.krisk.org
------------------------------ *From*: freeswitch-users-bounces@lists.freeswitch.org < freeswitch-users-bounces@lists.freeswitch.org> *To*: freeswitch-users@lists.freeswitch.org < freeswitch-users@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.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
We have bypass media. /b On Jun 15, 2010, at 4:01 PM, Code Ghar wrote:
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.
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.
I believe it is nice to say as well that most small transit carriers see the bypass media as a commercial threat since they will disclose in part of the packet to which IP address they are actually terminating the call to. I've been through this with lots of carriers that do nothing but LCR dips and transit. JM On Tue, Jun 15, 2010 at 6:11 PM, Brian West <brian@freeswitch.org> wrote:
We have bypass media.
/b
On Jun 15, 2010, at 4:01 PM, Code Ghar wrote:
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.
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.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
This is what is wrong with this industry. You have every Tom, Dick and Harry setting up Asterisk and FreeSWITCH boxes without an ounce of clue what the heck to do. Then you have mom and pop shops that provide really sub par services by routing media all over the globe when not needed. This results in software such as Asterisk or FreeSWITCH getting a bad name when the media goes to hell because TomDickHarry's voip service he runs on his cable modem went out because it rained outside. So to summarize, either do it right or go home. /b On Jun 15, 2010, at 4:47 PM, João Mesquita wrote:
I believe it is nice to say as well that most small transit carriers see the bypass media as a commercial threat since they will disclose in part of the packet to which IP address they are actually terminating the call to.
I've been through this with lots of carriers that do nothing but LCR dips and transit.
JM
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! 2010/6/15 João Mesquita <jmesquita@freeswitch.org>
I believe it is nice to say as well that most small transit carriers see the bypass media as a commercial threat since they will disclose in part of the packet to which IP address they are actually terminating the call to.
I've been through this with lots of carriers that do nothing but LCR dips and transit.
JM
On Tue, Jun 15, 2010 at 6:11 PM, Brian West <brian@freeswitch.org> wrote:
We have bypass media.
/b
On Jun 15, 2010, at 4:01 PM, Code Ghar wrote:
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.
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.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
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@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@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
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
On Thu, Jun 17, 2010 at 3:53 PM, Brian West <brian@freeswitch.org> 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?
FYI, there are soft phones out there that FAIL at this: wxCommunicator GoldMine CRM Softphone (Front Range Solutions) These two phones do not support the concept of "auth username" - they ASSUME that the username is the auth username. Naughty naughty. -MC
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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Thu, Jun 17, 2010 at 4:13 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
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.
I don't know that I agree with such an extreme view. Better to give them an example of a locked-down config than to let them flounder on their own and possibly make something horrible. That being said, anyone using FS in the enterprise *SHOULD* consult a security professional to make sure that everything on their LAN/WAN is up to snuff. -MC
Give them a non-working example. And provide a comment on almost every line why this will not work. Let the customers exercise their brain first. You don't need dumb customers, am I right? You'll see a good outcome. Sorry, but I can't resist. It's my daily work to get rid of unwanted customers. "Unwanted Customers" doesn't sound good in any language. But it's a reality... On Thursday 17 June 2010, Michael Collins wrote:
On Thu, Jun 17, 2010 at 4:13 PM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org>wrote:
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.
I don't know that I agree with such an extreme view. Better to give them an example of a locked-down config than to let them flounder on their own and possibly make something horrible. That being said, anyone using FS in the enterprise *SHOULD* consult a security professional to make sure that everything on their LAN/WAN is up to snuff.
-MC
On Thu, Jun 17, 2010 at 3:31 PM, Code Ghar <codeghar@gmail.com> 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?
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
"... 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.
This I don't know. Is it handled down in Sofia? Brian or Tony could tell us.
"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?
I'm sure you could use a combination of ACLs and 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.
I cringe at the thought of doing *ANY* kind of authentication based on incoming caller ID...
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?
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. 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. I invite others to chime in. Also, I've started an informal security best practices page on the wiki: http://wiki.freeswitch.org/wiki/Security_bp Everyone put your thoughts up and we'll formalize it at a later time. -MC
On Tue, Jun 15, 2010 at 4:59 PM, Anthony Minessale < anthony.minessale@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@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (7)
-
Anthony Minessale
-
Brian West
-
Code Ghar
-
João Mesquita
-
Kristian Kielhofner
-
Michael Collins
-
Sergey Okhapkin