13

Securing Open Source Enterprise VoIP Christian Stredicke/snom

Embed Size (px)

Citation preview

Page 1: Securing Open Source Enterprise VoIP Christian Stredicke/snom
Page 2: Securing Open Source Enterprise VoIP Christian Stredicke/snom

Securing Open Source Enterprise VoIPChristian Stredicke/snom

Page 3: Securing Open Source Enterprise VoIP Christian Stredicke/snom

September 10-12, 2007 • Los Angeles Convention Center • Los Angeles, California

www.ITEXPO.com

3

SIP is the ketchup of the burger

Finally the VoIP industry is splitting up into layers: SIP is the ketchup that makes it a tasty combination

Hosting

Consulting

ITSP

Hard Phones

SIP PBX

The Past:Everything is

provided (more or less) by one large

company

The Future: Specialized vendors offering excellent products in a specific area

Problem: Products are getting very complex and it is hard to stay

competitive

ATA

SBC

SoftPhones

IVR

Page 4: Securing Open Source Enterprise VoIP Christian Stredicke/snom

September 10-12, 2007 • Los Angeles Convention Center • Los Angeles, California

www.ITEXPO.com

4

Selling Security

• There is probably no company without firewall any more

– Security for Email and Web is a must have today– Administrators who don‘t understand that are jobless

• Offer two contracts– One where you make the customer responsible for all

security breaks (system without security)– Another one where they just waive your liability (system

with security)

• They will pick the contract that includes security

Page 5: Securing Open Source Enterprise VoIP Christian Stredicke/snom

September 10-12, 2007 • Los Angeles Convention Center • Los Angeles, California

www.ITEXPO.com

5

The Evolution of VoIP Privacy

“We got transfer working”

Use SRTP (but no TLS)

VPNTLS + SRTP

Page 6: Securing Open Source Enterprise VoIP Christian Stredicke/snom

September 10-12, 2007 • Los Angeles Convention Center • Los Angeles, California

www.ITEXPO.com

6

How to listen to VoIP calls*

Ethernet Switch

The LAN is the problem!

Tools:• www.oxit.it• arp-sk - ARP Swiss

Army Knife Tool• arp-scan• …

ARP

* If you are just using plain SIP

The PC puts itself into the communication stream by pretending to have same MAC address as the phone (PC are pretty fast these days and respond faster than VoIP phones)

Page 7: Securing Open Source Enterprise VoIP Christian Stredicke/snom

September 10-12, 2007 • Los Angeles Convention Center • Los Angeles, California

www.ITEXPO.com

7

SRTP scrambles the voice

EthernetHeader IP UDP RTP Codec Ethernet

Checksum

MACEthernetHeader IP UDP RTP Codec Ethernet

Checksum

AES “Counter”X

• The AES Counter is used for XOR the audio data• The MAC is a hash over the codec content and makes sure

that only the one who knows the counter value can generate the packet

• With every packet, the counter is pseudorandomly incremented

• The key is to negotiate the initial counter value securely

Page 8: Securing Open Source Enterprise VoIP Christian Stredicke/snom

September 10-12, 2007 • Los Angeles Convention Center • Los Angeles, California

www.ITEXPO.com

8

Key Exchange Algorithms (so far)

Sig.Conf.

ForkingMedia before

Answer

Shared-key conf.

PKI? RekeyBid-down protectio

n

MIKEY-PSK No No Yes Yes No* Yes Yes

MIKEY-RSA No No Yes Yes Yes Yes Yes

MIKEY-DH No No No No Yes Yes Yes

MIKEY-DHHMAC

No No No No No* Yes Yes

MIKEY-RSA-R No Yes No Yes Yes Yes Yes

SDES Yes Yes* No Yes No Yes* No

SDES-EM Yes Yes* Yes Yes No Yes No

EKT Yes* Yes* Yes Yes No Yes *

SDP-DH No No No No No No No

ZRTP No Yes Yes No No Yes Yes

DTLS No Yes Yes No No Yes Yes

Source: Dan Wing, Overview of SIP Media Security Options, March 21, 2006 (IETF 65)

Page 9: Securing Open Source Enterprise VoIP Christian Stredicke/snom

September 10-12, 2007 • Los Angeles Convention Center • Los Angeles, California

www.ITEXPO.com

9

How TLS works

• Known from other protocols (https, secure SMTP, …)• Looks like TCP from the application point of view• Uses strong cryptographical methods (RSA, DH)• How can you trust the other side?

– Certificates– Must be issued by someone that you trust– Preset list or load the root certificate

• Problem: – Requires at the very least TCP support (most PBXs don't have this

today)– Problems for embedded devices (OpenSSL takes several MB)

Page 10: Securing Open Source Enterprise VoIP Christian Stredicke/snom

September 10-12, 2007 • Los Angeles Convention Center • Los Angeles, California

www.ITEXPO.com

10

Is VPN the solution?

• Very well established• Secure• Latest generations address latency

– UDP or GRE

• Nice side effects:– No more NAT problems– VPN servers are widely available (OpenVPN)– No more port-playing with national carriers

• Problems:– Media Relay through the central VPN node– Setup is not as easy as TLS

Page 11: Securing Open Source Enterprise VoIP Christian Stredicke/snom

September 10-12, 2007 • Los Angeles Convention Center • Los Angeles, California

www.ITEXPO.com

11

DoS is becoming a pain

• Brute force attacks:– ping –f (start is several times)– Downloading of emails (LOL)– Just don‘t hang up (ENUM)

• Bad software– INVITE of Death (DoS LOL)– Accepting INVITE without any kind of authentication

“If you have Gigabit Ethernet, make sure you can process one million

ping packets per second”

Page 12: Securing Open Source Enterprise VoIP Christian Stredicke/snom

September 10-12, 2007 • Los Angeles Convention Center • Los Angeles, California

www.ITEXPO.com

12

Simple Steps to Increase Security

• Put your VoIP network into a VLAN– Give higher priority bits for that LAN– Have a mini-SBC between the LANs– Limit bandwidth on trunk level

• Set the expectations right– Making phone calls over the public Internet has no QoS– Seriously consider PSTN termination

• Think about upgrade paths• Backup

Page 13: Securing Open Source Enterprise VoIP Christian Stredicke/snom

September 10-12, 2007 • Los Angeles Convention Center • Los Angeles, California

www.ITEXPO.com

13

The Bottom Line

• You must address privacy in the enterprise• TLS and SRTP are a good solution• VPN is even better as is solves NAT as well• Think pessimistic about bandwidth utilization