[VOIPSEC] VoIP Blocking Filter w/Ettercap

Tue Jul 19 21:29:31 CDT 2005

At least auto qos, that would work well to rate limit.

Port security - it is in the smartports template - helps with macof attacks.

VACL to not allow TCP traffic intra voice vlan.

I have also below my comments back to Michael off line who had some great
points, and depending on the security policy of the company, some but not
all of the attacks might work.

****************************
I walk into a lobby of a building or sit down at any cube that has a phone.
I unplug the phone and plug in my laptop.

THS - you did what? Ah, even the "lobby ambassadors" in my building would be
calling security on you. :)

"Ok, well I've got 802.1x, which will challenge you to authenticate before
allowing you on the VLAN"

I'll ignore the request and turn on a sniffer. Within 30 seconds or so, I'll
see a CDP message from the switch that includes the VVID (which is the Voice
VLAN number). Turning off CDP would break all other phones, as this is the
primary method for learning this information. Once I've got this, I open up
Terminal on my Powerbook :) and type:

THS - We are assuming that they are using CDP and a voice vlan on that
section of the network, which I do not think that I would do if I ran that
network. Just like a PC kiosk, it would be in it's own vlan with nothing
next to it. And, come on, if they had that little security, couldn't you
just read the voice vlan off of the phone settings, because I am assuming
they would not have turned that feature off either :)

At this point I can set this interface to use DHCP, and unless you've hard
coded each phone's MAC address into your DHCP server, I'll get an IP and the
address of the TFTP server (which is almost always the CallManager server
itself). The .cnf file on the server is the configuration file for the
phone, and of course, TFTP contains no mechanism for authentication, so I
can easily download this file.

THS- On a phone in a lobby, I just might hard code that MAC in, or better
yet, put a static in and have no DHCP with the settings page turned off. The
tftp server can be the call manager, but depending on the deployment, it
does not have to be. If you were worried about security, I would think you
would move it off the call manager.

Now I'm on the Voice VLAN and I've got a valid IP address and the IP address
of the CallManager server. Again, this is assuming you've followed the SAFE
blueprints to the letter. This is not on some unprotected network. Sadly,
everything in this e-mail could be done even at Cisco HQ. This can still be
done even if you throw a bunch of other things that the SAFE papers don't
even talk about.

1. Denial of Service. At what point in call setup would a phone on the same
VLAN *not* ring if I tried to perform a call setup from my computer to it?
What device could stop me from doing this to all phones on the VLAN? None.
Can the phone itself realize that I'm not a valid endpoint on the network or
that I'm not registered with the CallManager? 

THS - there is no reason for any other phone to be layer 2 adjacent to that
phone, but lets say there is other phones. I have and would but a VACL in
that would not allow any TCP traffic in the vlan. No phone ever communicates
with another phone using TCP. That would mean that you would not be able to
send TCP connections to the phone, which would mean no call setup.

Nope. Doesn't care much. What would stop me from spamming registration
messages to a gateway or to the CM itself?

THS - You could spam, I can not stop that, but I can turn on even the auto
qos feature and allow only X amount of traffic through. If you send more
then that traffic it would get dropped. It would be hard to overrun a device
with lets say 36k of signaling from that port. Also, I would have an ACL
that would not allow any TCP traffic to the gateway, only RTP to the gateway
that you could talk to, you should not send TCP to the gateway in my world.

2. Phone Spoofing. I can register with the CallManager as an existing
configured telephone or softphone simply by using the MAC address of the
desired target. This is the only item used for authentication. Not the real
MAC address on the packets, mind you, simply as an identifier within the
payload. Easily spoofed. Once this is done, I will have calling permissions
and access rights the same as the target, as well as the ability to get his
calls.

THS - with the hard phones in 4.x, you have a Certificate Trust List (CLT)
file that would not allow you to register with the call manager. If you were
running a softphone you still would not be able to register with the call
manager unless the call manager had auto registration on. If you tried to be
a softphone with a hard phone mac, that might be possible, I will have to
think about it for a bit.

4. Attacking the CallManager. Especially if the CM is on the same segment as
the phones, it is generally true that there are few filters between Voice
VLANs and CM servers (which run Windows 2000). 

THS - On the same segment? Man, the SRND (cisco's term for a design guide)
would tell you to never do that. Always make sure that your call manager is
at least one layer 3 hope away. But, you would be able to get to the call
manager, qos, acls, csa, hardened os, those are the layers that a company
would have to use to protect itself.
****************************

Hope that helps, ciao,

Troy Sherman
JAG 1024
Cisco Systems Inc.
Phone   408.902.3091
Cell    408.887.9516
Pager   800.365.4578

-----Original Message-----
From: Maness, Drew [mailto:Drew.Maness at disney.com] 
Sent: Tuesday, July 19, 2005 8:37 AM
To: Troy Sherman; Michael Todd
Cc: Voipsec at voipsa.org; Credland, Jim
Subject: RE: [VOIPSEC] VoIP Blocking Filter w/Ettercap

I wanted to capture this conversation into the beginnings of a Best
Practice.

Technology Summarization for Cisco VOIP

Layer 2 (Access Layer) Best Practices
VLAN Segregation between Voice and Data networks
DHCP Snooping
Dynamic ARP Inspection (DAI)
IP Source Guard
CDP Verify

Did I miss anything?

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Troy Sherman
Sent: Monday, July 18, 2005 6:57 PM
To: 'Michael Todd'
Cc: Voipsec at voipsa.org; 'Credland, Jim'
Subject: RE: [VOIPSEC] VoIP Blocking Filter w/Ettercap

 In line but shorter.....

Troy Sherman
JAG 1024
Cisco Systems Inc.
Phone   408.902.3091
Cell    408.887.9516
Pager   800.365.4578

MT - This is not true. I have performed this on all manner of  
switches and IOS versions. Can you please specify why a "newer"  
switch would block this?

THS - Some switches now look at CDP (I know, but more difficult, do not
remember the IOS versions) to make sure that they are seeing a CDP
packet
from the phone before they allow traffic on that voice vlan. It is baby
steps until some newer features come out in the future. The best one off
the
top of my head is on the CatOS on the 6k (8.3.(4) I think), it uses a
command called CDP verify to check this, otherwise traffic is blocked.

MT - You are correct that MITM options are definitely limited once  
DAI is enabled. I would also suggest DHCP anti-spoofing measures on  
top of the arp spoofing measures. I really am just trying to point  
out that there are no options for switch level authentication of VoIP  
endpoints. My other concern is that nowhere in the Cisco SAFE  
blueprint for IP Telephony are these recommended, and many network  
administrators do not configure these features. I believe that  
Arpwatch is recommended, but these would only log arp changes, not  
block them.

THS - This confuses me, do you mean a rouge DHCP server? If so, you have
to
have dhcp snooping turned on to make DAI work. When you turn on dhcp
snooping you get 3 things, no port can reply to a dhcp broadcast, you
build
the dhcp snooping binding table for DAI and IP source guard, and the
dhcp
request CHADDER field is checked to make sure that the mac address in
the
dhcp requests matches the mac address in the cam table of the switch.
Unless
you have IP source guard with port security, but that is not really a
enterprise feature because of the requirement of the option 82 field in
the
dhcp request.

THS - and yes, they are not in SAFE, I did not write SAFE :). I can tell
you
that data is data in my world and most of the things we have talked
about
are the same for email and even ssh/ssl, and how many companies encrypt
all
the email that they send. If I were going to be a bad guy, I would much
rather read someone's email then listen to the voice. I have talked to
companies that have turned all this security on and more for their voice
network (which is data) and yet have done nothing to protect the "other"
data on their network, which is strange to me. A good security policy,
layers, monitoring, all those things are what it takes to make a secure
network. I have found that most attacks are internal, and that most
attacks
are allowed because of mis configuration, that is one reason for things
like
smartports and such.

MT - For anyone interested, THS has a good presentation on these  
attacks at http://www.cisco.com/networkers/nw04/presos/docs/SEC-2002.pdf

THS - googled me eh? :)

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