Section 10.4. Software Maintenance and Hardening

10.4. Software Maintenance and Hardening

A huge problem facing the software industry is unintentional vulnerabilities, or bugs , in software that can lead to security hazards. There are several kinds of faults, but the riskiest ones are those that permit a hacker or Trojan/worm agent to gain privileged access to a system. To deal with these faults, the makers of the softwareeither commercial programmers or the open source communityissue patches that fix them.

Of course, it may take some time to resolve a security bug once it's been identified. Linux and BSD- related bugs tend to be fixed rapidly , while commercial software bugs tend not to be fixed quite as quickly.

If a piece of software on your system is vulnerable because of a bug, it's better to disable that software until a patch can be installed than it is to keep running with the risk of attack!

Even if a patch is issued to resolve a security hole, it still takes the system administrator to apply that patch to the systems in question in order for the security risk to be removed. This can be a time-consuming process. Merely keeping aware of all the security bugs and patches can be a big job. The more complex the systemthe more applications and users it supportsthe more susceptible it is to exploitable bugs.

In order to come close to the elusive "five nines" reliability standard of old-hat voice systems, security bugs must not be allowed to hamper the VoIP network. There are several practical ways to avoid the threat of software security bugs:

  • Avoid the use of VoIP servers without a properly configured firewall between them and the Internet. Firewalls stop most random Trojan and worm traffic. The firewall doesn't have to be a NAT deviceremember that NAT can break SIP, MGCP, and H.323

  • Subscribe to a patch notification newsletter from a reputable source, such as the manufacturer of the software on your VoIP systems. If you use a Windows-based softPBX, get in the security loop at

  • If possible, avoid using software that is frequent targets of Trojan, worm, and virus attacks. Instead, choose software that can be customized and highly hardened , such as Linux. If you're looking for a commercial alternative to a Windows-based PBX, try Avaya's MultiVantage softPBX, which runs on a proprietary build of Linux, or Cisco's CallManager Express, which runs on Cisco IOS embedded in a router. Of course, there's always Asterisk, which runs on Linux, FreeBSD, and Mac OS X.

  • Create a very restrictive access control policy at the network layer to minimize the likelihood of a security compromise (see "Access Control," earlier in this chapter)

  • Keep IP phone firmware up-to-date. In traditional telephony, the phone system was just a PBX that ran, and ran, and ran, without ever having a software patch or a security hiccup. Not so in the world of VoIP; do what you can to keep software well- maintained , up-to-date, and bug-free

  • If your system design calls for a TFTP server, use one that can control access by MAC address. Another approach would be to use a local firewall on the TFTP server to limit access. This way, the TFTP server's exploit risk is lowered . Plus, you don't want a casual user leafing through your files on the TFTP server

  • Don't connect your IP phones to the Internet if all your phone users are in one building and there's no reason to connect them to the Internet. This is a last resort, however, as the goal of every noble VoIP integrator ought to be leveraging the Internet as much as possible

10.4.1. Hardening VoIP Servers

An important aspect of software security is hardening: the act of proactively making your operating system and application software more secure. On a softPBX server, hardening means removing unnecessary services and software agents , so that you have less of a garden of possible security vulnerabilities to worry about.

On Windows servers, this often means removing unneeded services. If Microsoft Internet Information Services isn't needed, shut it down or remove it. That's one less risk. The same is true of Linux systems. Notoriously exploitable software like Apache and BIND should be carefully patched or just removed from the system.

But hardening isn't just disabling or removing software from telephony servers. It also means optimizing the system configuration of every relevant device on the network. On an Asterisk server on Linux, for example, this would mean establishing a very restrictive local firewall policy. That way, only authorized traffic can get into, and out of, the softPBX. This is sort of access control at the host levelthe last line of defense, if you will.

Even if a would-be intruder is sitting three feet away from your softPBX server, he won't be able to break in if it's hardened correctly. Here are some hardening tips that work on Windows and Linux:

  • Remove unnecessary software from each critical system in the VoIP network

  • If possible, move software that is more vulnerable to security compromise onto servers that are separate from high-availability applications like VoIP. This might mean running DNS and softswitch services on different machines

  • Local user accounts and passwords should become disabled after three or four incorrect login attempts

  • Establish local firewall policy on each machine that runs a critical piece of the VoIP network to reduce risky traffic flows

10.4.2. Project 10.2. Harden a SoftPBX What you need for this project:
  • Asterisk running on Red Hat Linux

Though this project is geared toward an Asterisk server, it is principally accurate for any softPBX.

Two basic aspects of the softPBX need examination during hardening: 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.

Production servers shouldn't have Asterisk running as root due to security concerns. Refer to Chapter 3 to set Asterisk up so that it can run as a nonroot user. 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 it can't be used to facilitate a sophisticated security exploit, so remove it altogether if you don't absolutely need it. Use a package-management tool if you're not certain which software is required on your system. Red Hat provides RPM for this purpose. Chances are, you don't need the Gimp, a graphics tool, on a softPBX, so use RPM to remove it.

Since we're dealing with Asterisk, you can disable a number of modules in order to reduce the risk of security exploits. Asterisk provides modules for all kinds of signaling protocols and telephony applications, and you may not need them all. Use the noload directive in modules.conf in order to specify those that you'd like to disable:

 noload =>     noload => 

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. Clean up xinetd

xinetd is Red Hat Linux'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 . It disables the IMAP server from running:

 service imap     {             disable                 = yes             socket_type             = stream             wait                    = no             user                    = root             server                  = /usr/sbin/imapd             log_on_success  += HOST DURATION             log_on_failure  += HOST     } 

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. Kill shell access for daemon users

If you set Asterisk up to run as a nonroot user (see Chapter 3), then you'll need to make sure that user has no shell access. This setting is found in the /etc/passwd file along with the list of users on the system. Change the shell setting for each non-root user that's meant only for running software processes to /bin/ nologin or something that doesn't exist. /bin/bash and /bin/sh are common shells that do exist, and regular user accounts, like root, still need some form of shell access, so don't change those. This way, inadvertently logging on as that user will not result in access to Unix. Here's a snippet from /etc/passwd that contains a number of such users with disabled shells:

 root:x:0:0:root:/root:/bin/bash     bin:x:1:1:bin:/bin:  /sbin/nologin  daemon:x:2:2:daemon:/sbin:  /sbin/nologin  adm:x:3:4:adm:/var/adm:  /sbin/nologin  asterisk:x:8:0:asterisk:/usr/bin:  /sbin/nologin Optimize the local firewall on the softPBX

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:


5060 and 5061 TCP and UDP


2099 TCP and UDP, 2517 TCP and UDP

H.323 Video (H.263)

2979 TCP and UDP


2944 and 2945 TCP and UDP


69 TCP and UDP


5038 TCP


Depends on configuration of capabilities negotiation preferences of the endpoint RTP implementation (most RTP agents use 5000/5001, 5004/5005, 8000/8001, or high-numbered ports).


5036 UDP


3455 TCP and UDP


1756, 1757, 4056, 4057 TCP and UDP (RTSP can vary by session like RTP)

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 so 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. Check for security risks in the dial-plan

It's possible to create a dial-plan that unintentionally allows incoming calls to use the Asterisk server to dial out, possibly placing expensive and resource-consuming outbound calls. Examine the sample configuration for Asterisk to see how its designers recommend separating outbound contexts from inbound ones. Then, make sure your dial-plan separates them, too. Here's part of a dial-plan snippet from /etc/extensions.conf that allows any incoming call to dial out from the server. It's an example of how not to set up your dial-plan:

 [default]     exten => s,1,Answer( )     exten => s,2,GoTo(outbound)     [outbound]     exten => _XXXXXXX,1,Dial(Zap/1/${$EXTEN}) 

Familiarity with dial-plan programming will breed better security, so brush up on your Asterisk commands (or your Cisco IPT commands). Asterisk dial-plan configuration is covered in more detail in Chapter 17.

10.4.3. DMZs and Firewalls

If an Internet-facing server, or bastion host , as they're called, is locally firewalled and properly hardened in its own right, then it should be quite difficult to compromise. But local firewall policy is the last line of defense. The first line of defense is a separate, standalone firewall appliance or server that sits between the bastion host and the Internet, monitoring and filtering traffic. This appliance could even be a router with firewall firmware installed, though in high-availability designs, the firewall and router should be kept separate.

By design, a firewall should sit between the attacker and the server she's attacking, which allows the attacker's actions to be observed and logged. The idea is to make it difficult to go unnoticed when carrying out a malicious access attempt from the outside world. The administrator just has to be paying attention to his firewall's logs.

But threats can come from the inside, toothe private side of the firewall, where all the servers are. Targeted, punitive threats often originate from within one's own organization. Many enterprise networks are set up so that a large group of workstation PCs has no firewall between it and a segment of servers, possibly including VoIP servers; see Figure 10-1. The na ve system administrator believes that an attack attempt is less likely from a workstation PC on this segment because she has greater physical access control, building security, and the likeso attacking from within the enterprise is thought to be harder than hacking from the outsidei.e., "Who would dare attack me from my own network?" But the random outside threat rarely has emotional baggage as motivation, making the inside threat a worrisome issue.

Figure 10-1. A typical small network firewall setup

The truth is, a VoIP network must be protected from both origins of attack. This is where DMZ segments (demilitarized zones) come into play. A DMZ is a network segment, usually Ethernet, that resides between two firewalled routers: one that provides protection from the Internet and another that provides protection from the private network, as in Figure 10-2. Normally, the DMZ is addressed with a publicly routable IP subnet, and is therefore a true part of the Internet. But the firewall between the DMZ and Internet filters blocks certain ports while logging access attempts.

Figure 10-2. A DMZ setup provides protection for the servers from both private and Internet-based threats Building a DMZ

There are many possible approaches to setting up a DMZ segment that are well beyond the scope of VoIP. Suffice it to say that entire books have been written on the subject of firewalls and security, such as Building Secure Servers with Linux (O'Reilly). But there are some common threads among all DMZ setups:

  • One or more firewalled routers restrict traffic into, and often out of, bastion hosts .

  • A DMZ often has limited access to the private network, while the public network (Internet) has no access to the private network

  • The private network often has limited access to both the public network (Internet) and the DMZ (see Figure 10-2)

When critical servers reside in the DMZ, the firewalled interfaces on the routers can enforce a policy of rules that protect them from risky traffic that originates from the Internet or from the private network. Keep in mind, though, that every hop in the VoIP call path adds some lagand with two firewalled routers, you've got two extra hops. As a result, network performance on these two machines is important. Just like any other device in the call path , firewalls and routers must be able to handle the traffic load demanded by your VoIP network (see Figure 10-3).

In Figure 10-3, you can see that a SIP server and DNS server reside in the DMZ. They are firewalled on both the Internet side and the private side of the DMZ. Let's assume that the SIP proxy server in the DMZ is the softPBX for all IP phones on the private segment. This means that all IP phones and SIP clients must register with it in order to become aware of one another's existence.

Figure 10-3. The firewalls in this DMZ setup (A and B) allow traffic to the DNS server and SIP proxy to be firewalled and monitored , whether it comes from a private network or the Internet

Port Scans

A port scan is a systematic process that attempts to identify all of the open ports and available services on a TCP/IP host. Most hackers use port scans to help them identify potential vulnerabilities on a target host. The hacker either wants to exploit them to gain control or deny access, or he wants to identify and fix them. Fortunately, there's a pretty good way of preventing VoIP services from being located through port scans.

Since TCP is connection-oriented, scanning for TCP ports is easy: if a connection is established, the port is considered open and available; if not, the port is closed and unavailable. Secure TCP-based services as well as you can, or disable them so they can't be located with a port scan, especially on mission-critical servers.

But VoIP mainly uses UDP, which is connectionless. In an insecure network, it's possible to identify UDP ports that aren't available by sending them data and then waiting for an ICMP unreachable message. Ports that don't produce such a response within a reasonable time frame are considered open and available. The moral of the story is this: disable ICMP traffic on your firewall, and nobody will be able to tell which UDP ports your VoIP services are using.

Now, let's assume IP phone needs to be able to make and receive calls to and from the PSTN. The firewall rules for both sides of the DMZ must permit all the signaling and call paths required to allow these:

  • In order for the IP phone to communicate with the SIP server, UDP port 5060 and 5061 must be permitted from to and vice versa on firewall B

  • In order for the SIP server to communicate with the PSTN gateway (via SIP), UDP port 5060 and 5061 must be permitted from to and vice versa

  • In order for an RTP call path to exist between the PSTN gateway and the IP phone, no rules need to be set up on the firewall, since both are on the same segment

  • As a matter of course, all hosts accessing services on the DMZ should have the ability to resolve DNS hostnames, and so TCP and UDP port 53, for DNS, should be permitted from and to the DNS server,

At this point, assuming the VoIP network itself is configured to handle the calls via dial-plans and channels, and so on, PSTN subscribers can call the IP phone, and the IP phone can call the PSTN, even though the SIP proxy is on the DMZ. But what was really accomplished through all this was security. Use a similar exercise to identify the additional TCP/IP traffic flows required to support an Internet-based SIP calling application through firewall A:

  • In order to communicate with Internet-based SIP hosts, the SIP proxy at must be able to send and receive SIP traffic (UDP ports 5060 and 5061).

  • In order to provide DNS name resolution for SIP services, the DNS server at must be able to send and receive DNS traffic (TCP and UDP port 53) to and from the Internet.

  • The SIP proxy can already communicate with the IP phone and the PSTN gateway (see earlier step)

The way a DMZ protects its hosts is by putting them behind firewalls, which limits the amount of public Internet traffic they're exposed to. However, if somehow a DMZ host is compromised even with firewalls in place, it can be easily used to launch attacks against neighboring servers on the DMZ. So, computers that sit on the DMZ, called bastion hosts, must be individually hardened. Rather than trust all traffic originating from within the DMZ, the bastion host should have a very restrictive local firewall policy: permit only the traffic that is needed for that host's application, and never assume that traffic is friendly because it's coming from a firewalled segment. Project 10.1 deals with local firewall policy.

Switching to VoIP
Switching to VoIP
ISBN: 0596008686
EAN: 2147483647
Year: 2005
Pages: 172

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: