| Get this Security+ CertiGuide for your own computer. |
Click Here!
Use coupon code "certiguide" to save 20%!
(Expires 2004/12/31) |
|
| Also available: 300-question Security+ practice test! |
| Get It Here! |
|
|
3.1.7 Telecom / PBX (Private Branch Exchange)
(Page 2 of 2)
Security issues with Telecom / PBX
The same type of vulnerabilities
faced by an organization’s data network are also faced by its telephone
network, including theft of service (through long distance toll fraud),
compromise of data privacy or integrity, unauthorized access to privileged
functions, denial of service, and opportunities for reconnaissance by
an attacker interested in patterns of calls by one or more users280.
An example of the risks faced by
PBX’s is a situation in which an attacker gained access to a hospital’s
PBX, and then for the next two years, periodically blocked calls to
and from the hospital, connected internal staff to outside numbers they
did not intend to contact, and placed bogus emergency calls that appeared
to come front the hospital itself. 281
Common pitfalls to watch for, in
terms of the security of your traditional PBX include:
- Default passwords on manufacturer-installed accounts
(information on these can be found in the PBX switch documentation or
from your vendor – you can be sure that potential intruders know
what they are);
- Features that can be accessed via the phone system,
such as voicemail or switch reconfiguration functions (typically, the
password security on these features is not significant, and can be defeated
by brute force);
- Leaving a modem connected to the remote maintenance
port, even when you do not know of any scheduled maintenance that will
require it, leaves open a path into the system for anyone who wants
to try to use it;
- Software updates sent from the switch vendor
to the system administrator – which may have been intercepted and
tampered with before the system administrator received them (ideally,
your vendor would send the update as a digitally-signed message to guard
against undetected tampering);
- Hard copy of configuration information, possibly
listing passwords and critical configuration details, being acquired
by unauthorized personnel (“dumpster diving” can reveal this,
and other, proprietary information).
Social Engineering and PBX security
should be monitored.
 PBX = The Forgotten Hole
A telephone network faces security concerns similar to a data network, including unauthorized use, compromise of data privacy or integrity and denial of service.
Specific actions to take, to secure a PBX, include changing all default passwords, not leaving modems connected to PBX maintenance ports, restricting administrative activities that can be performed with just phone access (and strong passwords, the user ID’s with administrative access), and watching out for social engineering attempts to gain information about the company’s phone system.
|
![[spacer]](1p.gif)  Computer Telephony Integration (CTI)
Recently, PBX’s incorporating Computer and Telephony functionality have become popular, some sticking to their traditional physical line “switching” routes, and others incorporating VoIP (voice over IP functionality)282. Many of these systems, such as the Altigen283 communications server runs on Windows 2000 and other widely-available operating systems, integrating telephony with applications like SQL Server and Microsoft Exchange to perform functions like “screen pops” (popping up customer information, looked up from the incoming caller ID information, on a service rep’s screen) or “call routing” (sending a call to an available tech support representative with the appropriate skills, based on the type of trouble call). Both these new computer telephony solutions and traditional PBX’s may be network-enabled, to allow console access and transfer of PBX-collected information like Call Detail Records (CDR’s) to another computer, perhaps for billing purposes.
If you’re using one of these systems, and it is connected to your LAN, be aware that anyone breaking into your LAN may also eventually gain access to your communications server. So, the standard precautions, of setting extremely strong passwords, monitoring the server for configuration changes, following up on unusual logins, etc., apply. When your communications server runs on a widely available OS, also add automated virus checking to your list of security measures..
|
 Securing Voice Mail
Does your telephone system provide off-site access to voicemail? Does the system require that users choose access codes of a certain length, or can users get by with a blank access code? Do you educate your users to choose codes more difficult to guess than “1111”, “9999” and “1234”? What about access codes that enable access to administrative features remotely? If your phone system supports this, have you changed the default access code for it?
|
__________________
280. http://www.local6.com/orlpn/news/stories/news-188235220030110-120116.html
281. Kuhn, Richard, “Security for Private Branch Exchange Systems”
282. http://www.securityfocus.com/infocus/1767
283. http://www.altigen.com/
| If you find CertiGuide.com useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from StudyExam4Less.com. (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support! |
|
|
Home -
Table Of Contents - Contact Us
CertiGuide for Security+ (http://www.CertiGuide.com/secplus/) on CertiGuide.com
Version 1.0 - Version Date: November 15, 2004
Adapted with permission from a work created by Tcat Houser et al.
CertiGuide.com Version © Copyright 2004 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.
|
