| macVoIP.com the web home of Ted Wallingford |
|
 |
|
Build a Killer Telephony Server
Excerpted from my book VoIP Hacks (O'Reilly Media) Using any old PC with Linux is great way to experiment and learn about 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. Then there are the 2000-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 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, which humans have come to expect 100% reliability from over many decades, a dilapidated hodgepodge 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. This means following a principled philosophy of stability, high availability, and compatibility. The Three Things that Matter Most in Telephony When building server for an enterprise telephone system, there are three areas of focus to keep in mind. I put them in my personal order of importance, from most important to third-most: Stability High-availability Compatibility To provide the utmost stability, a server's environment must be kept at a cool-room temperature of 65 to 75 degrees F. 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. Creating high availability Building in compatibility Size and Select a Voice Server 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 - 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 PSTN, you'll need at least a 2.0 GHz Pentium IV or equivalent with a 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 G.729 are the biggest processor hogs of all. If you've 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 discussed in chapter 4) handle codec-processing tasks in order to preserve capacity on the softPBX. Select an OS and Harden It o The more optional packages you install, the less room you'll have for things like voicemail and log files, both of which are important in the world of telephony, right? Once Fedora Core is up and running, you're ready to start hardening. Though I've geared this towards an Asterisk server, it is principally accurate for any softPBX. Why not use Windows for a phone server? Well, as it turns out, Windows doesn't support nearly the selection of free, high-quality telephony software like Asterisk, sipX, Open H.323, and other open-source, server-side stuff. It also turns out that Windows itself comes towing a rather pricey license fee. So I figured I'd stick to what you can download from the Net without breaking the bank. The less money you spend on licensing fees, the more you can spend on other parts of your telephony solution. There are two basic aspects of the softPBX that need examination to harden a server: the software that's installed, and the software that's running. As far as hardening the software that's installed but not running, or not needed, the course of action is quite simple: remove it. Remove unnecessary software 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. Clean up xinetd 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 TCP/IP listeners, reducing the likelihood of an attacker discovering a vulnerability. So, if you don't need telnet, TFTP, talk, and finger, then, for goodness sake, disable them. The fewer services that have listening ports, the more secure your server will be. In order 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 UDP port access needed by each one. Table 7-1 lists the important protocols and their respective ports. VoIP Protocol Port Numbers
So, if you are using SIP, you need to permit inbound SIP signaling on UDP ports 5060 and 5061. 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 only RTP, IAX, and SIP traffic can be accepted by the server, while 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. |
|
|
|
(C) 2003 - 2006 Ted Wallingford
|