[VOIPSEC] Voipsec Digest, Vol 75, Issue 5
ngrant at secvoip.com
Tue Apr 26 10:36:49 EDT 2011
I think one of the biggest issues of course is lack of encryption utilized
by network operators. Many are not nudging everyone towards SIP Trunking,
which is nothing more than MPLS for UC. However, they are putting the in
VLANs, saying its secure and going on their merry way. I know this is a
"plain" view of what they are doing, and quite high level. However, they
MUST allow for us to encrypt our SIP (and RTP for that matter).
I see this as being one of many problems, but probably the biggest at the
On 4/26/11 6:00 AM, "voipsec-request at voipsa.org"
<voipsec-request at voipsa.org> wrote:
>Send Voipsec mailing list submissions to
> voipsec at voipsa.org
>To subscribe or unsubscribe via the World Wide Web, visit
>or, via email, send a message with subject or body 'help' to
> voipsec-request at voipsa.org
>You can reach the person managing the list at
> voipsec-owner at voipsa.org
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Voipsec digest..."
> 1. Thoughts on SIP Service Provider security? (Speaking at
> SIPNOC tomorrow) (Dan York)
> 2. Re: Thoughts on SIP Service Provider security? (Speaking at
> SIPNOC tomorrow) (J. Oquendo)
>Date: Mon, 25 Apr 2011 09:58:29 -0400
>From: Dan York <dyork at voxeo.com>
>To: VoIP Sec <voipsec at voipsa.org>
>Subject: [VOIPSEC] Thoughts on SIP Service Provider security?
> (Speaking at SIPNOC tomorrow)
>Message-ID: <3752D359-3085-4C1E-A5EF-417D5FBF270D at voxeo.com>
>Content-Type: text/plain; charset=us-ascii
>As I posted on the VOIPSA blog, I'll be speaking on a panel about
>security tomorrow at the SIPNOC event near DC:
>While I naturally have my own list of topics I'll raise with network
>operators / service providers about the major issues with SIP and
>security (as it pertains to large networks), I'd be curious for any
>feedback you all have. Given that I'm on the panel wearing my VOIPSA
>hat, I'd welcome community input.
>What are the greatest security issues related to SIP that you think
>network operators need to be dealing with right now?
>Dan York, CISSP, Director of Conversations
>Voxeo Corporation http://www.voxeo.com dyork at voxeo.com
>Phone: +1-407-455-5859 skype: danyork sip:dyork at voxeo.com
>Join the Voxeo conversation:
>Twitter: http://twitter.com/voxeo http://twitter.com/danyork
>Date: Mon, 25 Apr 2011 11:26:12 -0400
>From: "J. Oquendo" <sil at infiltrated.net>
>To: Dan York <dyork at voxeo.com>, Voipsec <voipsec at voipsa.org>
>Subject: Re: [VOIPSEC] Thoughts on SIP Service Provider security?
> (Speaking at SIPNOC tomorrow)
>Message-ID: <4DB59294.8020006 at infiltrated.net>
>Content-Type: text/plain; charset=ISO-8859-1
>On 4/25/2011 9:58 AM, Dan York wrote:
>> VOIPSEC readers,
>> As I posted on the VOIPSA blog, I'll be speaking on a panel about
>>security tomorrow at the SIPNOC event near DC:
>> While I naturally have my own list of topics I'll raise with network
>>operators / service providers about the major issues with SIP and
>>security (as it pertains to large networks), I'd be curious for any
>>feedback you all have. Given that I'm on the panel wearing my VOIPSA
>>hat, I'd welcome community input.
>> What are the greatest security issues related to SIP that you think
>>network operators need to be dealing with right now?
>I think what is lacking is a "security framework." "How to design and
>deploy a secure SIP server." This would begin with best practices
>concerning usernames, passwords, port and network security. I think far
>too many individuals have this notion/theory/POV of VoIP as being
>something magical when at the end of the day its no different than e-mail.
>For those of us who have read documentation from various vendors
>regarding building say a typical account, it's always more of the same:
>I tend to make usernames synonymous with say a client name and a MAC
>address. This to me makes things a little more difficult to "bruteforce"
>e.g. client.name.0A0E0A0E0A0E with a password in similar fashion. The
>theory is that someone would have to try a highly targeted attack at a
>PBX. Same goes for passwords: clientnamvariation.macaddress.password It
>is an easy framework to remember once *something* is in place and
>extremely difficult to break.
>When it comes to connectivity, same applies: "Who needs to connect to
>this machine and why... Should it be public if so, is it possible to
>block all and allow in specifics.?" It all begins with the design.
>Finally, logging; possibly the strongest line of defense. What are you
>logging and why. Are you checking your logs constantly, do you get
>reports, do you know who is connecting to your PBXs and why. For
>starters, it allows for proactive defense for those doing scripting.
>Secondly, it allows a provider (especially a service provider) to be
>more proactive and reactive when it comes to troubleshooting. E.g.,
>client fudges up their phone settings, you will be able to see what is
>going on hopefully via realtime alerting.
>Anyhow, there also needs to be a separation between ITSP, trunking
>providers, etc., what applies to say me when I have my ITSP hat on,
>doesn't apply to me when I'm wearing say my Managed PBX provider hat.
>With the ITSP hat on, my concern is traffic getting to where it needs to
>go. Security concerns are shifted to whomever is trunked as they manage
>their own PBXs. With the other hat, I am responsible for who registers,
>how many calls are placed, to where and why.
>Under the second hat, I've been trying to be as proactively vigilant as
>possible. With say my Asterisk machines, I now have international PIN
>dialing, I have "routes to nowhere" for expensive calls as well. E.g.,
>Anything over say 0.25 goes nowhere and I am also sent an alert when
>these calls are made. This allows me to do two things, 1 it allows me to
>see who needs access if its a valid account and 2 it allows me to get
>any alert for anomalies as my normal clients don't place certain types
>Now under the ITSP hat, same applies in a different way. Using my
>NCites, I was able to create a real time alerting system for anomalies.
>What it does: Takes a look at all traffic for the past 10 minutes, sorts
>out and looks for all NON domestic calls. Using a pre-defined baseline,
>it calculates anything 25% over what I deemed normal and creates an
>alert. The alert contains: Number Dialed, IP of the trunk trying to dial
>the number, amount of times tried. So what can I do with it? 1) I can
>have another machine generate an autoblocking rule against "EXTREME"
>anomalies (pre-defined), etc. Was more of a learning experience to me to
>see if I can actually do it:
>(On the Netrake)
>nCite --> script to check for anomalies
>Anomaly found -> run this script
>script --> parse logs, scp them over to another Linux machine
>Log into the Linux machine
>(On the Linux machine via .bashrc)
>"Oh you're logging in... That means I need a specific file from the
>netrake. I will SCP it over, parse out what is necessary, create a fw
>rule, then resend it to the SBC, then exit"
>(On the Netrake)
>nCite --> check if file X exists, if so, this is an immediate fw change
>...run it! otherwise, go to sleep
>Reducing risk... So far I have not had any hiccups (knock on faux wooded
>table here) but to make this all work took a lot of patience, testing
>and systems/security voodoo. Nothing similar existed at the time at
>least not that I'm aware of... Case in point: Standardization. Where is
>it? I say, framework framework framework... Collaboratively.
>SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP
>"It takes 20 years to build a reputation and five minutes to
>ruin it. If you think about that, you'll do things
>differently." - Warren Buffett
>42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF
>Voipsec mailing list
>Voipsec at voipsa.org
>End of Voipsec Digest, Vol 75, Issue 5
More information about the Voipsec