FW: problem in voip environment
Reposting...first attempt didn't seem to make it onto the list.
------
Loic-
It sounds like both the PC and IP phone are in the same subnet/VLAN. If
they are, you will always be able to ping the phone from the PC because
they are on the same logical wire.
Suggestions:
1a.) Verify the IP phone is on the telephony VLAN (VLAN y).
This can be verified by pressing '#ADDR' on Avaya IP phones and hitting
'#' until the phone displays the VLAN it's configured to use. If it's
not configured to use the correct VLAN (y) it may be defaulting to
port/native VLAN (x). In this case, I'd recommend checking that the
DHCP scope and option 176 are setup correctly (if using DHCP). For more
information about the DHCP option 176 see the Avaya LAN Administrators
guide:
http://support.avaya.com/elmodocs2/4600/233507_2_1.pdf
1b.) Verify the PC is on the data VLAN (VLAN x).
This can be verified by analyzing the IP address of the PC vs. IP
address of the phone. BTW - The IP Addresses in your post indicates
that the PC and the phone are on the same subnet. Did you mean
10.10.10.0/24 for the phone and 10.10.11.0/24 for the PC?
2.) Verify there is no Layer 3 device that will bridge the
telephony and data VLANs. Layer 3 devices are typical in most customer
networks and naturally allow data to bridge from one VLAN to another.
If you want to isolate connectivity between telephony and data, you can:
- Provide a separate network that serves only telephony. This
means additional equipment costs. In addition, PCs can no longer plug
into the phones which may mean substantial wiring costs because each
desk needs two CAT5 drops (one for the phone and one for the PC).
- Utilize firewalls and/or router ACLs to prohibit any data
traffic from touching telephony devices.
Sincerely,
-John Walton, CISSP
CSAG Lead Security Engineer
Avaya, Inc.
-Michael Kloberdans
R&D Network Engineer
Avaya, Inc.
----
The Avaya Product Security Support Team (PSST) would like to develop a
relationship with our customers and the public to encourage them to
forward vulnerabilities to us. Please send information regarding any
discovered security problems with Avaya products to
securityalerts[at]avaya.com. I, or someone on the PSST, will do our
best to respond.
The PSST handles externally received reports of security vulnerabilities
as well as internally discovered security problems. We also handle
customer security incidents and provide escalation support for Avaya
Global Services and the Avaya Enterprise Security Practice.
---
-----Original Message-----
From: Pasquiet Loic (M.) [mailto:Loic.Pasquiet@xxxxxxxxxxxxxxxx]
Sent: Saturday, September 11, 2004 2:54 PM
To: bugtraq@xxxxxxxxxxxxxxxxx
Subject: problem in voip environment
1. Topic
Security issues have been identified that allows an attacker to
compromise ip phones.
2. Description
We are testing voip solutions and here's what we've found :
take a layer 2 switch, here, an avaya cajun switch like P33xT or
P334T-ML (layer 2).
configure 2 ports like it's recommended in voip, like this :
a vlan id x on port 1 and a vlan-static-bindig id y for telephony (x is
the pvid is or native vlan or default vlan) a vlan id x on port 2 and a
vlan-static-bindig id y for telephony we are in mode access so ports are
not 802.1q or in trunk mode ...
plug an ip phone on port 1 in 10.10.10.10/24 plug a PC on port 2 in
10.10.10.11/24 (the pc doesn't tag his frames) (if you plug the PC
behind another ip phone, the result is the same)
try to ping the ip phone ... it's ok.
You can now easily flood all ip phones on the same switch or the entire
stack !
3. Affected products
Avaya Cajun P33xT , P33xT-ML and more ?
4.Solution
Actually in the product house for Avaya.
With other switch, we know that you can bypass this hole by activate a
'untagpvidonly' command on the ports 1 et 2 or something equivalent
according to constructors ...
In trunk mode or in full 802.1q mode, we can do the 'same' thing by
simply tagging frames from your PC.
So, you are in telephony vlan ...
We are also interesting in deployment experience and the response about
fully tagging ports or not ...
thanks,
loic