[VOIPSEC] How to test VoIP Security

Tue Nov 15 08:43:38 CST 2005

There are some testing tools for VoIP that you can utilize for example:
SiVus 
SIPBOMBER 
SIPP
sipsak
These tools are focus in SIP Based Signaling VoIP Services. 
I hope helps you

Regards 
Geneiatakis Dimitris 

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Voipsec-request at voipsa.org
Sent: Tuesday, November 15, 2005 3:53 PM
To: Voipsec at voipsa.org
Subject: Voipsec Digest, Vol 11, Issue 20

Send Voipsec mailing list submissions to
	Voipsec at voipsa.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
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..."

Today's Topics:

   1. Re: How to test VoIP security (Saverio Niccolini)
   2. Re: IPv6 and the demise (or not) of NAT (was	Re:
Interactive
      Connectivity Establishment (ICE)) (Randell Jesup)
   3. Re: How to test VoIP security (steven rivera)
   4. Re: IPv6 and the demise (or not) of NAT (was	Re:Interactive
      Connectivity Establishment (ICE)) (Christopher A. Martin)
   5. Re: Interactive Connectivity Establishment (ICE) (Olivier GRALL)
   6. Re: How to test VoIP security (Mark Teicher)

----------------------------------------------------------------------

Message: 1
Date: Tue, 15 Nov 2005 13:08:22 +0100
From: "Saverio Niccolini" <Saverio.Niccolini at netlab.nec.de>
Subject: Re: [VOIPSEC] How to test VoIP security
To: "Floris Jan Schepel" <fjschepel at hmc-heerema.com>,
	<voipsec at voipsa.org>
Message-ID: <D977208E3F96C0409B876B141CE9E8262B248E at venus.office>
Content-Type: text/plain;	charset="us-ascii"

Hi Floris,

I think you should look for solutions performing:
"security auditing"

Security auditing is:
Examination of system wide security to determine system vulnerability.
Security auditing does not attempt to break into the network illegally,
rather it tries to find areas of vulnerability.
It uses a variety of automated software tools, performing routine tests
and checks adapting dynamically to the System Under Test (SUT)

Is this what you meant? If yes, there is not really a methodology to be
defined here or something you can find on books, but there are a lot of
companies offering products... :-) You can also think of building your
own for example using open source stuff...

Hope this helps...

Regards,
Saverio

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Floris Jan Schepel
> Sent: Tuesday, November 15, 2005 11:47 AM
> To: voipsec at voipsa.org
> Subject: [VOIPSEC] How to test VoIP security
> 
> Dear experts,
> 
> I am a IT student at TI Mon3aan, in the Netherlands, whit a work 
> placement at Heerema.
> My study here is to find out, how to secure VoIP.
> Heerema will work whit a Cisco Avaya solution. A Cisco network, whit 
> Catalyst 4506, 3560, and 2950 switches.
> The VoIP environment will be Avaya, like the 8700 media servers, G650 
> Media gateways direct to ISDN, and Avaya
> IPphones.(H.323)
> 
> On a lot of sites, there are explanations how to secure a VoIP 
> environment, but none of this sites, tell me how to test a VoIP 
> environment. I am looking for a tool or a appliance, with I can test 
> and log the security of this VoIP network. I like to use this tool or 
> appliance on a test network.
> 
> I'ts not the purpose to knock (DoS) or Hack the VoIP network down. I 
> have Google'd a lot and, checked the email list, but I have failed to 
> find something usefull. I also have read a lot of VoIP books, like: 
> "Switching to VoIP", and Carrier grade Voice over IP" but none of them

> gives me information of what I am looking for.
> 
> I hope, that you can help me, testing this VoIP environment without 
> harming it.
> 
> 
> Thanks for you help,
> Floris
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 

------------------------------

Message: 2
Date: 15 Nov 2005 07:36:10 -0500
From: Randell Jesup <rjesup at wgate.com>
Subject: Re: [VOIPSEC] IPv6 and the demise (or not) of NAT (was	Re:
	Interactive Connectivity Establishment (ICE))
To: Simon Horne <s.horne at packetizer.com>
Cc: Voipsec at voipsa.org
Message-ID: <ybuk6fa5br9.fsf at jesup.eng.tvol.net.jesup.eng.tvol.net>
Content-Type: text/plain; charset=us-ascii

Simon Horne <s.horne at packetizer.com> writes:
>>         Another big problem with UPnP is the double-nat problem.
>>Put a device behind two UPnP NATs and you can't open a port through
both.
>>With STUN/etc, you can open ports through any number of NATs.
>
>Except if one of those NAT's is symmetric (which is 90% of all routers 
>are) then it maybe broke.

        Oh, a lot lower than 90% for home router/nat/firewalls (and it
used to be 90% not-symmetric).  Though it is unfortunately increasing.

--
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS
team rjesup at wgate.com

------------------------------

Message: 3
Date: Tue, 15 Nov 2005 07:40:12 -0500
From: steven rivera <steven.rivera at mci.com>
Subject: Re: [VOIPSEC] How to test VoIP security
To: 'Floris Jan Schepel' <fjschepel at hmc-heerema.com>,
	voipsec at voipsa.org
Message-ID: <0IPZ00J3DXV12J at dgismtp04.mcilink.com>
Content-Type: text/plain; charset=us-ascii

Floris

VOIP Security is the delicate balance between accessibility and
security.
Below is a list (no particle order) of what I have done for such VoIP
security audits is the following. I hope you find this useful.

- View the VOIP system with associated telephones as a host on your
network.
Doing this allows you to treat the VoIP phone like you would any other
end
device on your network and thus test for the vulnerabilities the same
way
using similar tools
- You would be surprised as to the ease and simplicity of older
vulnerabilities like "smurf" attacks that are affecting VOIP Phones
- pen-tests end devices - bring the end device into a lab environment
- VoIP Network architecture - the question is: converge or not to
converge
voice and data? - the more disparate they are the better for security,
although separate means more expensive and an additional layer of
complexity.
- The connectivity across the two networks can be a point of weakness
and
often little thought is put into the architecture of it
- review the protocols, gateways and proxies closely
- Ensure that firewalls that are VOIP aware are being used and are
configured properly - SIP operates from outside connection initiation
this
can open up a gaping hole to the network
- Other concerns that should be considered are eavesdropping / tapping
and
sniffing of the voice traffic
- There are simple protocol analyzers like the "Vomit" tool that can be
used
to sniff out voice traffic from network traffic. It's a freeware tool
readily available from the internet
- evaluate the integration with voicemail this is often a weak point
that
the requirement of ease of use outweighs security concerns.

I hope this helps. I think that when a company chooses to bring the
voice
traffic onto a data network it should be protected the same way, with
the
same security countermeasures as the data. Often what I am seeing is
that
most who do not view VoIP in that way may be opening themselves up for
huge
security breeches. 

Sincerely,

Steven Rivera
Information Security Specialist
Southern New England Commercial Accounts
MCI - Rye Brook, NY
914-312-2197 Office
325-2197 VNET
914-960-9117 Cell

View our Managed Security Services Video:
http://global.mci.com/external/us/cyber_security.rm

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Floris Jan Schepel
Sent: Tuesday, November 15, 2005 5:47 AM
To: voipsec at voipsa.org
Subject: [VOIPSEC] How to test VoIP security

Dear experts,

I am a IT student at TI Mon3aan, in the Netherlands, whit a work
placement
at Heerema.
My study here is to find out, how to secure VoIP.
Heerema will work whit a Cisco Avaya solution. A Cisco network, whit
Catalyst 4506, 3560, and 2950 switches.
The VoIP environment will be Avaya, like the 8700 media servers, G650
Media
gateways direct to ISDN, and Avaya IPphones.(H.323)

On a lot of sites, there are explanations how to secure a VoIP
environment,
but none of this sites, tell me how to test a VoIP environment. I am
looking
for a tool or a appliance, with I can test and log the security of this
VoIP
network. I like to use this tool or appliance on a test network.

I'ts not the purpose to knock (DoS) or Hack the VoIP network down. I
have
Google'd a lot and, checked the email list, but I have failed to find
something usefull. I also have read a lot of VoIP books, like:
"Switching to
VoIP", and Carrier grade Voice over IP" but none of them gives me
information of what I am looking for.

I hope, that you can help me, testing this VoIP environment without
harming
it.

Thanks for you help,
Floris

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

______________________________________________________________________
This e-mail has been scanned by MCI Managed Email Content Service, using
Skeptic technology powered by MessageLabs. For more information on
MCI's
Managed Email Content Service, visit http://www.mci.com.
______________________________________________________________________

______________________________________________________________________
This e-mail has been scanned by MCI Managed Email Content Service, using
Skeptic(tm) technology powered by MessageLabs. For more information on
MCI's Managed Email Content Service, visit http://www.mci.com.
______________________________________________________________________

------------------------------

Message: 4
Date: Tue, 15 Nov 2005 07:22:33 -0600
From: "Christopher A. Martin" <chris at InfraVAST.com>
Subject: Re: [VOIPSEC] IPv6 and the demise (or not) of NAT (was
	Re:Interactive Connectivity Establishment (ICE))
To: "Hallam-Baker, Phillip" <pbaker at verisign.com>
Cc: Voipsec at voipsa.org
Message-ID: <4379E119.90205 at InfraVAST.com>
Content-Type: text/plain; charset="iso-8859-1"

On the other hand the alternative to such stringent controls is to 
"trust" the end point/users. This is not a good alternative either in a 
network that needs to employ security measures to protect business.

I shot a quick MIDCOM poke earlier, but this is also my biggest concern 
about MIDCOM, trust is being placed in the endpoint to open "holes" by 
telling the controller what to do. The good thing about MIDCOM enabled 
devices is that if deployed they are presumably under the same 
administrative domain and protective measures as the endpoints (I 
wouldnt allow an endpoint that does not fall under this scenario).

Also, STUN/TURN/ICE/UPNP provide an additional network overhead chatter 
maintaining all of the connections, which depending on the number of 
hosts using it hinders scalability. These protocols are all limitted to 
home networks and soho at that point.

This all basically goes back to the right tool for the job. There is a 
place for everything, based on what is acceptable to the entity as well 
as what type of scale is required. The question is, what liability is 
also going to befall those who deploy insecure methodologies..when the 
time comes I am certain that there will be a sort of reverse fallout if 
someone is burned using a VoIP client on one of these networks or if the

network is used as an amplifier due to its insecure rollout.

Babbling completed,
Chris

Hallam-Baker, Phillip wrote:

>There is a moral here.
>
>Try to enforce security by refusing to provide needed functionality in
a safe fashion only leads to someone else providing it insecurely.
>
>My firewall gives me an all or nothing choice... Control individual
ports by micromanagement or throw it all open... Not a good choice.
>
> -----Original Message-----
>From: 	Robert Moskowitz [mailto:rgm at icsalabs.com]
>Sent:	Mon Nov 14 16:02:06 2005
>To:	Voipsec at voipsa.org
>Subject:	Re: [VOIPSEC] IPv6 and the demise (or not) of NAT (was
Re:Interactive Connectivity Establishment (ICE))
>
>At 03:03 PM 11/14/2005, Simon Horne wrote:
>
>  
>
>>At 05:52 AM 15/11/2005, Bipin_Mistry at 3com.com wrote:
>>So I agree with you Phillip.  There should be a standard way of
telling
>>the Firewall which ports it needs to open and close and not rely on
>>session border controllers.
>>
>>There is, it is called UPnP IGD or Universal Plug 'n Play (Internet
Gateway
>>Device) refer www.upnp.org and most home/small office routers now
support it.
>>
>>
>>The biggest problem is that it potentially adds a security risk to the
>>network, other malicious programs running on the LAN can open ports up
as
>>they wish, there is no security to filter which programs can us it .
For
>>this reason a lot of people are very hesitant to turn it on in their
routers.
>>    
>>
>
>Other security risks as well.
>
>As you imply, Malcode on a PC can take advantage of PnP to set up all 
>sorts of covert channels.
>
>I have seen some rather nasty uses of PnP in attacks on physical 
>security.  I hope we don't punt on this one.
>
>
>Robert Moskowitz
>Senior Technical Director
>ICSA Labs, a division of Cybertrust, Inc.
>W:      248-968-9809
>F:      248-968-2824
>VoIP:   248-291-0713
>E:      rgm at icsalabs.com
>
>There's no limit to what can be accomplished if it doesn't matter who 
>gets the credit
>
>
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>  
>

------------------------------

Message: 5
Date: Tue, 15 Nov 2005 14:34:40 +0100
From: Olivier GRALL <olivier.grall at neotip.com>
Subject: Re: [VOIPSEC] Interactive Connectivity Establishment (ICE)
To: Dan Wing <dwing at cisco.com>
Cc: Voipsec at voipsa.org
Message-ID: <4379E3F0.2050004 at neotip.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Sorry for my not very clear sentence, I will try to explain what I 
wanted to say.

This is the call flow of  ICE-05:

          Agent A          TURN,STUN Servers          Agent B
             |(1) Gather Addresses |                     |
             |-------------------->|                     |
             |(2) Offer            |                     |
             |------------------------------------------>|
             |                     |(3) Gather Addresses |
             |                     |<--------------------|
             |(4) Answer           |                     |
             |<------------------------------------------|
             |(5) Media            |                     |
             |<------------------------------------------|
             |(6) Media            |                     |
             |------------------------------------------>|
             |(7) STUN Checks      |                     |
             |<------------------------------------------|
             |(8) STUN Checks      |                     |
             |------------------------------------------>|
             |(7) Offer            |                     |
             |------------------------------------------>|
             |(8) Answer           |                     |
             |<------------------------------------------|
             |(9) Media            |                     |
             |<------------------------------------------|
             |(10) Media           |                     |
             |------------------------------------------>|

                                 Figure 1

No problem for me about early media : a terminal can send RTP/RTCP 
packets as soon as it knows where to send it.

The problem is call establishment. In the case of agent A can receive 
media at the first try, if agent B doesn't validate this try agent A 
receives media. A new SDP offer/answer is done. The media channels are 
cut for agent A. Then new channels are established right. So agent A 
will see its video session broken for a short period (maybe just 1 sec).

But for video communications, it is not very clean to see that.

So yes, for me the problem comes from RE-INVITE because an user doesn't 
expect cuts. I think RE-INVITE can be used to forward a call for 
example. There is a reason why it is no more in the call flow of ICE-06,

isn't there ?

Regards,

Olivier GRALL
R&D Engineer 	*NeoTIP** S.A.*
4, rue Louis de Broglie
22300 Lannion
France
olivier.grall at neotip.com <mailto:olivier.grall at neotip.com> 	+33 (0)2
96 
48 66 94

Dan Wing a ?crit :

>>Thanks a lot for this information. I think I saw this 
>>behaviour on ICE-05 at least on the first call flow. I had a 
>>quick look on the new version ICE-06, the call flow seems to 
>>be really better. A very bad thing was to send media packets 
>>before a new SDP negociation.
>>    
>>
>
>I don't understand your last sentence.  Are you saying it is
undesirable to
>send early media, or are you saying ICE doesn't allow you to send early
>media, or are you saying it's undesirable to send a new offer
(re-Invite in
>SIP)?
>
>  
>
>>This could involve in large 
>>cuts in the call establishment especially if there is video.
>>
>>New call flow:
>>
>>          Agent A          TURN,STUN Servers          Agent B
>>             |(1) Gather Addresses |                     |
>>             |-------------------->|                     |
>>             |(2) Offer            |                     |
>>             |------------------------------------------>|
>>             |                     |(3) Gather Addresses |
>>             |                     |<--------------------|
>>             |(4) Answer           |                     |
>>             |<------------------------------------------|
>>             |(5) STUN Check       |                     |
>>             |<------------------------------------------|
>>             |(6) STUN Check       |                     |
>>             |------------------------------------------>|
>>             |(7) Offer            |                     |
>>             |------------------------------------------>|
>>             |(8) Answer           |                     |
>>             |<------------------------------------------|
>>             |(9) Media            |                     |
>>             |<------------------------------------------|
>>             |(10) Media           |                     |
>>             |------------------------------------------>|
>>
>>
>>                                 Figure 1
>>
>>The call establishment may be long if it's not the first 
>>address which is good but the third one.  There are timeouts 
>>on STUN checks I think. 
>>    
>>
>
>If the answerer ("Agent B" in the above flow) wants to send media
before the
>ICE state machine completes, it can send media.  Of course, if the ICE
state
>machine hasn't completed the answerer might not pick a viable path to
send
>media until the ICE state machine completes.  But if it selects any
path
>that received a STUN Response (message 6 in the above flow), the
answerer
>will at least know that path works, even if it might not happen to be
the
>best path or the path that is selected in the re-Invite.
>
>...
>  
>
>>I'm sure that NAT problems will still be alive with IPv6 
>>because it permits masking of  network topology. It makes 
>>part of security requirements for a company.
>>    
>>
>
>draft-ietf-v6ops-nap-02.txt might be the ticket.
>
>-d
>
>  
>

------------------------------

Message: 6
Date: Tue, 15 Nov 2005 08:52:37 -0500 (GMT-05:00)
From: Mark Teicher <mht3 at earthlink.net>
Subject: Re: [VOIPSEC] How to test VoIP security
To: steven rivera <steven.rivera at mci.com>, 	'Floris Jan Schepel'
	<fjschepel at hmc-heerema.com>, voipsec at voipsa.org
Message-ID:

<13856418.1132062758275.JavaMail.root at elwamui-norfolk.atl.sa.earthlink.n
et>

Content-Type: text/plain; charset=ISO-8859-1

>> Oh Boy, I was just waiting for someone to breach this topic again.  

-----Original Message-----
From: steven rivera <steven.rivera at mci.com>
Sent: Nov 15, 2005 7:40 AM
To: 'Floris Jan Schepel' <fjschepel at hmc-heerema.com>, voipsec at voipsa.org
Subject: Re: [VOIPSEC] How to test VoIP security

Floris