Showing posts with label PBX Systems. Show all posts
Showing posts with label PBX Systems. Show all posts

Monday

PBX Features | Traditional PBX Systems


PBX systems provide a plethora of features typically offered by a telephone provider, such as call waiting, three-way calling, conference calling, voicemail, additional call appearances, and many other routing features. Some vendors count 600 or more separate features among their capabilities, far more than is offered by any carrier on a central office switch as subscriber services. But often overlooked in this list are those used for access control. The PBX is effectively the firewall to the PSTN and because voice access has per-minute and geographic costs associated with each call, this aspect of PBX capability should be a critical consideration for product selection, configuration, and ongoing operations. Yet at the same time, the data security community is rarely concerned with this characteristic because it’s not a ppure data security issue, yet even in a VoIP system there will be PSTN connectivity; why gamble with this?

Say a company has 200 employees, each with a phone on their desk. Without a PBX, each employee would require their own pair of copper wires from the CO, each with their own phone number that routes to their desk. However, it’s a safe bet that not all 200 employees will be on the phone all the time, and it’s likely that most of those calls will be to other employees. This is where a PBX really pays off. A business or campus will need many fewer lines from the Local Exchange Carrier (LEC); in the previous example, the company might require only 40 outside lines, routing those calls onto the PSTN trunk lines as necessary on a per call basis. They also could rent 200 Direct Inward Dial (DID) numbers from the LEC, which terminate though those trunk lines. The PBX will then route the inbound call based upon which DID number was dialed to reach it.

The appeal of a PBX system is obvious to not only businesses and campuses but also attackers, who have taken an increased interest in them as well, since most PBX systems can support trunk-to-trunk transfer (i.e., dial-out again from the PBX after coming in on another line). PBX security often is overlooked by enterprises until a big phone bill arrives, and oftentimes the hackers have no challenge at all when settings are never changed from the manufacturers default. Try a Google search for “default password” and a PBX vendor and you’ll see just how easy this information can be to obtain. It is important to note that because PBX vendors typically have provided detailed instructions on how to secure the PBX, the remaining security responsibility lies completely on the operator of the PBX system, and any toll charges that may be obtained by fraud are left to be paid by the PBX owner. Attackers who have compromised a PBX system may set up their own private conference room, a “party-line” where they may hang out and exchange illicit information on your dime.

Other features can be a double-edged sword as well. Many PBX systems also provide a call-monitoring feature for managers to supervise their agents (or to record calls). You know those recordings that go, “Your call may be monitored for quality assurance and training purposes”? Well, if you’re not careful, they might also be monitored for humorous or larcenous purposes. And it may not be just calls to your call center that get monitored; if your monitoring system wasn’t properly designed or an intruder gets access to PBX administration at a high enough level, any call can be monitored.


The bottom line when it comes to PBX features is that you need to read the associated security recommendations carefully. Some vendors have assembled detailed security guides for addressing toll fraud and feature access that are well over 100 pages, and you would be wise to find out what kind of documentation exists. And don’t forget to back up your PBX regularly so that you don’t lose the security policy you create! More critically, if a VoIP vendor does not have these kinds of capabilities, you would be wise to find out what can be done to reduce exposure to toll fraud. In some cases, the lack of feature-functionality in many VoIP solutions is a blessing because it reduces the opportunities for security-affecting misconfiguration. Yet at best this is a temporary benefit since VoIP solutions are becoming more sophisticated each and every year.

Notes from the Underground…—Toll Fraud

Attackers have discovered a myriad of ways to make all the long distance calls they want from your PBX system, leaving you with the hefty collect-call charges, Here are a few:
  • Even with good security elsewhere, a caller can ask to transfer to extension to 9011 on a system where dialing 9 goes to an outside line and 011 is the international direct dial access code. Make sure your employees (particularly those that answer many external calls) know about this ruse and consider using your PBX’s trace feature to track down the source of such calls (you can even have the call transferred to your security department as part of the trace feature).

  • Attackers can read the same manuals online that your systems administrators can, and the smart ones will figure out how to get around the obvious restrictions, For instance, if trunk access codes aren’t restricted, it really won’t matter how well you’ve locked out other dial restrictions. And just because you don’t use your local trunks for long distance doesn’t mean an attacker won’t.

  • Adding support for IP softphones or WiFi phones to a PBX means that a softphone or wireless phone could be used by a remote attacker who can get onto your IP network (by wire or wireless) for toll fraud or other nefarious purposes, In this case, defense of your IP network overall is what will minimize exposure to the PBX, but it’s important that the PBX not weaken overall IP security (by allowing WEP-based security on wireless networks shared by voice and data, for instance).

Wednesday

PBX Trunks | Traditional PBX Systems


A trunk is a special kind of line that connects two telephone switches. If one of the two switches is the PBX, the other could be a local or long-distance switch for PSTN access, in which case we would call these local trunks or long-distance trunks, respectively (though it’s worth pointing out that even if you don’t have dedicated long-distance trunks you likely are able to get long distance services through local trunks). On the other hand, if the other end of the trunk is another privately owned PBX, we would call these private trunks or tie lines, even if they happen to be routed through the PSTN (since the telephone numbers they can reach can only be dialed from within the private network). There are also trunks that can act like both types through the use of Centrex or something called a Virtual Private Network (VPN—but it’s not the remote access VPN you may be familiar with from the data world— this VPN is created by a carrier to let you keep a private dial plan across many sites on the same trunks that you use for regular PSTN access).

Some say trunks are so named because in the old days, Ma Bell saw fit to use thick, lead-covered cables to connect the switches. These cables resembled an elephant’s trunk. Others claim the word’s origin is derived from the way the local loop network resembles the branches of a tree, with the trunks having similarity to…well, a tree trunk. Regardless, trunks are the main lines of the communications system, and the only case where a trunk is not connecting to a switch is when an adjunct server is involved (like a voice messaging server, an Automatic Call Distribution (ACD) server, an Interactive Voice Response (IVR) system, or similar system). In some cases, these servers may use station emulation instead of trunking, so you’ll need to verify what actually is being used.

Trunks can be analog, digital, or VoIP-based,just like station lines. Analog trunks can be as simple as a regular 2-wire POTS line to the local CO switch, or a 4-wire analog E&M trunk that provides improved signaling response (less glare). Channelized digital T1 trunks come in two main flavors. The first and oldest type of T1 can have 24 channels of 64 kilobit per second voice with robbed-bit signaling (signaling bits are stolen from the voice stream in a way that’s not noticeable to the ear). This type of T1 sends much less signaling data but cannot be used with 64 kbps switched data because of the robbed bits used for signaling, but can pass 56kbps switched data. ISDN T1 trunks have 23 channels of voice (bearer, or B channels) and a separate 64 kbps channel for signaling (the data, or D channel) that can support ISDN User Part (ISUP) messages, including Automatic Number Identification, which allows calling and called number information to be sent (although it can be spoofed. In Europe and internationally, the E1 is the typical digital interface, with an ISDN BRI carrying 30 bearer channels (30B+D) as opposed to the 23 channels supported by ISDN over T1 (23B+D).

VoIP trunks also come in various flavors, including H.323, SIP, and proprietary protocols like Inter-Asterisk eXchange (IAX). In some cases, IP-enabled PBX systems also use gateway control protocols with VoIP trunks, such as Simple Gateway Control Protocol (SGCP), H.248/Megaco/Media Gateway Control Protocol (MGCP), Skinny Gateway Control Protocol. One of the difficult problems with VoIP trunks, however, is feature transparency between vendors. ISUP/Q.931 or its private line equivalent (QSIG) has the most complete feature interworking capability, and standards for mapping these onto H.323 and SIP exist, but these are not evenly supported by PBX vendors at this point. Robust, reliable inter-working between different PBX vendors over VoIP is not easy to find today (and is still a challenge over private tie lines).

Saturday

PBX Lines | Traditional PBX Systems


In telephony, a line (or station line) connects endpoint equipment (digital terminals, analog phones, fax machines, modems, or even an IP phone through an IP network) to the PBX (or central office) for switching. An analog line is the private equivalent of a local loop or loop transmission facility.
Note 
A PBX is more likely than your phone company to support ground start phones and trunks on analog interfaces. Your phone at home seizes control of the line by using loop start, which involves shorting the two ends of the line together to activate the circuit. Ground start sends one of the leads to ground (typically ring) to seize the line, which is much less likely to cause glare (a condition that arises when both sides on a line or trunk simultaneously seize control of the line).

Typically, a PBX supports analog lines (and trunks) through a line card with 8, 12, 16, 24, or more lines per card, which are then wired to a patch panel for interconnection through a structured cabling system to the analog phone or device. Most of the security concerns around analog lines center on how well protected the equipment and cabling systems are from eavesdropping and tampering. Ground start loops will make theft of service less likely because a special phone is required, but otherwise the same basic rules for protecting a PSTN line from tampering apply.

Of course, line is also a generic term that may apply to power lines providing electricity to homes and businesses. But when we talk about an analog telephone line, we are talking specifically about the two wires involved: the tip (the first wire in a pair of phone wires, connected to the + side of the battery at the central office or PBX; it is named tip because it was the at the tip of an operator’s plug) and the ring (connected to the − side of the switch battery and named because it was connected to the slip ring around the jack). Any equipment that works with Plain Old Telephone Service (POTS) lines will work with a PBX analog line configured for loop start. From a PBX, an analog line will nearly always be 2-wire although 4-wire lines with Earth & Magnet (E&M, sometimes also called Ear and Mouth) interfaces are supported from the same card for analog trunks.
Tip 
If you’ve ever taken a peek behind the phone jacks that litter the walls of your home, you are likely to see two (or three) pairs of wires, one Green/Red, the next Yellow /Black, then White/Blue, but for our purposes only the first pair is important. The Green wire, referred to as the Tip, is the positively charged terminal. The Red terminal, the Ring, is the neutral, which completes the circuit, enabling electrical signals to flow freely. Note that newer homes may use a more recent color scheme that is also used for Ethernet cabling. The first pair is White/Blue, then White/Orange, then White/Green and finally White/Brown. This scheme is what you’re most likely to see in structured cabling systems within buildings.

Analog PBX systems supported only analog lines, but with the introduction of digital switching, a new class of line was developed: the digital line. In most PBX systems, a proprietary format for digital line signaling (and media) was created that requires the use of digital phones manufactured by that vendor. Some vendors, however, also support Integrated Services Digital Network (ISDN) standard phones directly (or through the PSTN) via the ITU-standardized ISDN BRI. Most proprietary digital formats use a 2-wire system with 8wire plugs and jacks, although some are 4-wire systems. ISDN uses a 2-wire system from the CO switch, but is 8-wire to the interface used by a phone terminal, so the actual number of wires used will depend on several factors (such as whether the phone has a built-in NT-1 interface). Also, many proprietary switch features will not be supported on ISDN phones, particularly when the phone is manufactured by a different vendor. And even within a vendor product line, you may discover that newer features are supported only on newer phones or phone firmware. In any case, digital lines for proprietary digital terminals typically are supported by digital line cards with 8, 12, 16, 24, or more lines per card, and ISDN lines for ISDN phones are supported by either ISDN trunk cards or special ISDN BRI line cards, which may come in several flavors depending on the ISDN BRI type.

In the case of the modern hybrid PBX or IP-PBX, there is an equivalent concept for IP lines to IP phones, but unlike analog or digital lines the IP line isn’t necessarily tied down to a single electrical interface on the PBX. In fact, the PBX can use multiple Ethernet ports to support an IP line, and IP phones can fail over to multiple IP-enabled PBX systems. The first IP line support built into most PBX systems leveraged the H.323 suite of protocols or proprietary protocols like Cisco “skinny,” but almost all new development on PBX systems today uses Session Initiation Protocol (SIP). The bottom line is that the concept of an IP line exists in virtually every VoIP system out there, and understanding how the line concept is expressed in a specific VoIP system will give you an important handle with which to analyze its architecture and security.

This flexibility and versatility are a huge advantage to VoIP, but it does come at a price. Because the phones are now sharing infrastructure and bandwidth with other devices (and perhaps the entire data network), quality-of-service (QoS) guarantees for packet loss, latency (how long each packet takes to arrive from the phone to the PBX), and jitter (variability of latency across packets in a stream) now become the responsibility of the party providing the network infrastructure. Additional vectors for Denial-of-Service attacks on IP lines (either to the phone or the PBX) and Man-In-The-Middle (MITM) attacks must be considered. In my experience, the resulting loss of accountability from a single organization or vendor to multiple entities rarely is included in planning (or ROI calculations) for VoIP deployments.

Tuesday

PBX Systems Management and Administration: Administration Sequence

After the system is installed, the system administrator must enter the translation data into the system memory via the SAT. Translation data is taken from survey sheets and previous system records and provides a blueprint of what needs to be programmed into the system configuration. When entering the translation data into the system, the system administrator should periodically save the translations on tape. This creates a nonvolatile copy of the translation already entered into the system. If a power outage or system failure occurs, the translation data saved on the tape will not have to be entered again.

PBX system features should be entered into the switch in an ordered manner. The following is the recommended order in which data should be entered into the system:

  1. Login and password (change password, if necessary)

  2. Dial plan

  3. Feature access codes (FACs)

  4. System features (class of service and class of restriction)

  5. Console parameters

  6. Attendant consoles

  7. System parameters

  8. Voice terminals

  9. Data modules

  10. Network connection channels

  11. Bridged line assignments

  12. Group assignment (hunt groups, call coverage, pickup groups, etc.)

  13. Trunk groups

  14. Paging/code call zone assignments

  15. ARS table

Before the customer database data is programmed into the system, the system administrator should review the system hardware configuration to assess the available port circuit interface boards and design layout. Many administration interface screens will require the administrator to input a port or slot identifier. A port or slot is an address that describes the physical location of the installed equipped. Port addresses consist of cabinet, port carrier, card slot, and port circuit card termination identifiers. Each hardware component has a multidigit identifier, and the combination of the hardware component identifiers is the port address.

Dial plan and FACs must be administered before voice terminals, hunt groups, pickup groups, coverage groups, and attendant consoles can be administered. Default values for the dial plan can be changed if they do not meet customer requirements. A standard dialing plan usually supports four- or five-digit extension numbers, but some customers may require more extension digits for system subscribers. For example, a seven-digit dial plan may be required for multisystem intelligent transparent private network configurations. Default FACs can also be changed, but the number of digits assigned to the FAC must agree with that of the dial plan.

The dial plan is used by the system to interpret dialed digits and know how many digits are expected for different call types, such as intercom calls or trunk calls. An important element of the dial plan is the first-digit table. The first digit dialed by a station user may have any one of the following codes: attendant, dial trunk access, extensions, feature access, and miscellaneous (used when more than one code begins with the same digit and requires a second-digit dial table).

Regarding first-digit dialing, North American station users are accustomed to dialing 9 for dial trunk access and 0 to reach an attendant console. In most of Western Europe, the first-digit dial trunk access code is 0, which usually proves confusing to American tourists. Many station users do not understand that access codes are programmable by system administrators, although most systems use the default values programmed by the manufacturer, such as 9 for trunk access in North America.

Miscellaneous codes are usually required when there might be a problem interpreting the first dialed digit. For example, when local 911 emergency services were first introduced, major PBX problems occurred. PBX systems that were programmed to recognize 9 as the first-digit dial trunk access code did not recognize the second dialed digit, 1, as a valid area or exchange code. System administrators were forced to reprogram their first digit tables to interpret a 911 call. Similarly, the revised North American Dialing Plan (NADP) introduced in the mid-1990s forced a reprogramming of the dial plan because trunk calls outside of the local area code required dialing a 1 before an area code for interpretation by local central office switches, and digit restrictions for the second area code digit (previously 0 or 1) were modified. Continuing changes in PSTN dialing requirements require constant updates of PBX dial plans.

Once the dial plan and FACs have been assigned, the system administrator can add voice terminals to the system. A variety of programming commands simplifies the configuration process. For example, the duplicate command can add the same types of voice terminals, instead of repetitive programming of similar information. The terminal extension number, location, type, and user name are entered on the display form with labeled blank fields. For an IP-PBX system, IP voice terminals require similar data entry for the voice station display screen, but also require entry of IP addresses, MAC addresses, and voice codec information. IP addresses are usually assigned by a DHCP server but can be manually administered. QoS programming for IP voice terminals is the responsibility of the LAN administrator, as is performance monitoring of IP telephony metrics, such as call delay and packet loss.

A common misconception is that IP-PBX systems don’t require traditional MAC administration because IP voice terminals can be initialized via a DHCP server or physically moved to different LAN connector outlets without administration programming. Despite these capabilities, subscriber and voice terminal parameters must be input for all IP peripherals. With regard to moves, IP-PBX system IP voice terminals require similar data entry for the voice station display screen, but also require the entry of IP addresses, MAC addresses, and voice codec information. IP addresses are usually assigned by a DHCP server but can be manually administered. All PBX systems support a customer station rearrangement feature that allows the movement of digital telephones between telecommunications outlets without administration intervention, exactly like an IP terminal.

Attendant consoles must be added one at a time, and for reliability, attendant consoles should not be assigned to the same circuit pack. Data modules can be assigned after voice terminal administration. Some data modules must be added during voice terminal administration if the voice terminal has a data module. Other data modules can be added separately.

Network connection channels are used to provide switched data access for the following features and functions:

  • CDR

  • SATs

  • Remote SATs

  • Property management system (PMS) link

  • PMS log printer

  • Journal printer

  • Recorded announcements

  • System printer

Group assignments can be programmed after voice terminals are added. The following groups can be administered:

  • Abbreviated dialing (system, group, enhanced)

  • Hunt groups

  • Call coverage answer groups

  • Pickup groups

  • Intercom groups

  • Terminating extension groups

  • Trunk groups

The ARS tables support network access to the PSTN and private networks. Trunk groups must be programmed to ARS. Access to private network facilities include the following network interface types:

  • DS1 interface

  • TTTN

  • Private tandem network

  • ISDN PRI

  • VPN

Related Posts with Thumbnails

Link Exchange