[VOIPSEC] Thoughts on SIP Service Provider security? (Speaking at SIPNOC tomorrow)

J. Oquendo sil at infiltrated.net
Mon Apr 25 16:26:12 BST 2011


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:
>
> http://voipsa.org/blog/2011/04/25/speaking-at-sipnoc-on-sip-security-what-would-you-like-me-to-say-to-service-providers/
>
> 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?
>
> Thanks,
> Dan

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:

Username $EXTENSION/$DID
Password $VARIATION_OF_A_NUMBER
Registrar

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
of calls.

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.



-- 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
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
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF




More information about the Voipsec mailing list