Hack88.Build a Killer Telephony Server
Hack 88. Build a Killer Telephony Server
Using any old PC with Linux is great way to experiment and learn about Internet Protocol (IP)-based telephony, but to implement a production server, you'll need some slightly bigger iron, and you'll need it hardened. In my travels as a networking consultant, I get to visit a lot of enterprise data centers. These range from meager, stuffy, 100-degree closets crammed with desktop PCs that accidentally became servers, surrounded by a spaghetti pile of crummy cabling, to the 2,000-square-foot, raised-floor, uncomfortably cool server rooms with halon fire-prevention systems and row after row of racks filled with quad-processor servers. When I have an opportunity to work in a modern, decked-out environment, I'm thankful that I'm not crammed in an undersized, overheated closet searching in vain for a free port on an incorrectly labeled Ethernet switch where I can plug in my PowerBook. It never ceases to amaze me just how little some folks seem to care about the environmental state of their critical data and communications equipment. As long as things keep running, I suppose they aren't likely to balk at the sorry state of their servers. But with a critical application like telephony, from which humans have come to expect 100% reliability over many decades, a dilapidated hodge podge of PC equipment sitting under a leaky roof just isn't going to work. A desktop-gone-server isn't going to cut it either. Fortunately, you're about to find out how to build a voice server right. This means selecting the right PC or commercial telephone PBX chassis, connecting it to the right components, choosing the right operating system, and hardening it. And that means following a principled philosophy of stability, high availability, and compatibility. 7.2.1. The Three Things That Matter Most in TelephonyWhen building a server for an enterprise telephone system, you should keep three areas of focus in mind. Here they are, in my order of importance:
7.2.1.1. Creating stability.To provide the utmost stability, a server's environment must be kept cool, with a room temperature of 65 to 75 degrees Fahrenheit. It should be kept dry (duh) and connected to a protected power source with a battery backup. Large environments should consider a backup power generator with an automatic transfer switch. The switches and routers that provide connectivity to the server should be on protected power, too. The server should also be well hardened against potential denial-of-service attacks, which you'll do shortly. 7.2.1.2. Creating high availability.To assure that the server is always available and that its voice services aren't affected by internal hardware failures like failed disk drives and power supplies, you should design redundancy into each server. A RAID 5 disk array with four or more hard disks provides a "hot spare" so that you can swap out a failed drive without having to shut down the server (you can also consider building a server with no hard disks [Hack #95]). Redundant power supplies allow the same hot-swap ability in case a power supply bites the dust. There are other techniques for high-availability, too, like clustering. 7.2.1.3. Building in compatibility.If you want to future-proof your voice server, don't bother building it on software that doesn't support the open standards needed to make it interoperable with other servers. Specifically, your software needs to support SIP and Real-time Transport Protocol (RTP). This means sticking with a highly compatible VoIP platform like Asterisk or sipX, or carefully evaluating a commercial solution. 7.2.2. Size and Select a Voice ServerIf you've chosen a commercial softPBX like the Avaya Media Server or Cisco CallManager, you're pretty much pinned to the sizing guidelines provided by the manufacturer. When you build it yourselfon Linux or BSDyou've got total control over scalability. With that said, there's really no hard and fast rule for determining how much processor power your server needs. I've run small workgroup (5- to 10-user) Asterisk servers on Pentium II machines. A large workgroup with hundreds of phones connected would certainly need a much beefier computer. VoIP can be a very light load on a PC, or an immense one. If you have five SIP phones connected to a single Asterisk server, all using the simplest codec (uLaw), a Linux server with a slower processor (Pentium II or newer) and 256 MB of RAM is probably just fine. But if you have 50 SIP phones using three or four different codecs and attaching to the Public Switched Telephone Network (PSTN), you'll need at least a 2 GHz Pentium 4 or equivalent with 1 GB of RAM. SIP-to-SIP calls are much less processor-intensive than SIP-to-Zaptel calls. Conference calls are more processor-intensive than normal two-party calls, and bandwidth-preserving codecs like the G.729 are the biggest processor hogs of all. If you have a great need to support highly compressed codecs on a lot of phones, and you'll be attaching your Asterisk server to the PSTN or to legacy phones using Zaptel, you'll need more speed, more RAM, and then more speed again. To relieve the burden on a softPBX, try offloading processor-intensive tasks to dedicated hardware. Try to maintain an all-SIP, all-uLaw environment on your softPBX. Let off-board equipment like SIP-to-PSTN gateways (such as the Clipcomm [Hack #43]) handle codec-processing tasks to preserve capacity on the softPBX. 7.2.3. Select an OS and Harden ItIf you're building a Linux voice server, there's not much point using an older Linux distribution. So get a recent revision of Fedora Core, burn it to CD-ROMs (four of them), and install it, keeping a few things in mind about all of those optional software packages the installer will prompt you about:
Once Fedora Core is up and running, you're ready to start hardening. Though I've geared this discussion toward an Asterisk server, it is principally accurate for any softPBX.
When hardening a server, you need to examine two basic aspects of the soft-PBX: the software that's installed and the software that's running. In terms of hardening the software that's installed but not running or not needed, the course of action is quite simple: remove it. 7.2.3.1. Remove unnecessary software.That means getting rid of Bind if you're not using it, removing Apache if it isn't needed, and unloading MySQL if you've no need for it. Just because the software isn't running doesn't mean you can't use it to facilitate a sophisticated security exploit, so remove it altogether if you don't absolutely need it. Since we're dealing with Asterisk, you can disable a number of modules to reduce the risk of security exploits. Asterisk provides modules for all kinds of signaling protocols and telephony applications, and you might not need them all. Use the noload directive in /etc/modules.conf to specify those that you'd like to disable: noload => pbx_kdeconsole.so noload => chan_modem.so In this case, the two modules being disabled are the KDE log console module, which provides a graphical console for the KDE desktop environment, and the modem module, which is used for ISDN connectivity with Asterisk. Keeping unnecessary modules from loading also conserves memory on the server. 7.2.3.2. Clean up xinetd.xinetd is Fedora's catchall daemon for Telnet, finger, and a number of other Unix network applications. (It's the successor to inetd.) Its configuration files, in /etc/xinetd.d, are used to enable or disable support for a long list of network-access services. Use this configuration directory to disable all but those that you absolutely need. Here's the contents of a file in this directory, /etc/xinetd.d/imap, controlling the imap daemon: service imap { disable = yes socket_type = stream wait = no user = root server = /usr/sbin/imapd log_on_success += HOST DURATION log_on_failure += HOST } This particular service is disabled, per the disable = yes line. Check all the files in this folder for the disable=yes line, or, if you prefer, you can altogether remove the config files for the services you don't need. The idea is to eliminate unnecessary Transmission Control Protocol/Internet Protocol (TCP/IP) listeners, reducing the likelihood of an attacker discovering vulnerability. So, if you don't need Telnet, the Trivial File Transfer Protocol (TFTP), talk, and finger, for goodness sake, disable them. The fewer services that have listening ports, the more secure your server will be. 7.2.3.3. Optimize the local firewall on the softPBX.To build a local firewall policy on the softPBX server, you'll need to identify which VoIP protocols you're using and plan a policy based on the kind of TCP and User Datagram Protocol (UDP) port access needed by each one. Table 7-1 lists the important protocols and their respective ports.
So, if you are using SIP, you need to permit inbound SIP signaling on UDP ports 5060 and 5061. Consider the following iptables policy commands: iptables P INPUT j DROP iptables A INPUT p UDP -dport 5060-5061 j ACCEPT iptables A INPUT p UDP --dport 5036 j ACCEPT iptables A INPUT p UDP -dport 5004 j ACCEPT iptables P OUTPUT j ACCEPT This set of iptables commands manipulates the kernel's firewall such that the server can accept only RTP, Inter-Asterisk Exchange (IAX), and SIP traffic; all outbound traffic (OUTPUT chain) is permitted. This policy is based only on UDP port numbers. If incoming traffic isn't on ports 5060, 5061, 5036, or 5004, it is dropped. A truly hardened server would restrict outbound traffic, too. For more information about securing VoIP, refer to Switching to VoIP (O'Reilly). |
EAN: 2147483647
Pages: 156