10.4. Software Maintenance and HardeningA 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.
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:
10.4.1. Hardening VoIP ServersAn 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:
10.4.2. Project 10.2. Harden a SoftPBX10.4.2.1 What you need for this project:
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.
10.4.2.2 Remove unnecessary softwareThat 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 => 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. 10.4.2.3 Clean up xinetdxinetd 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. 10.4.2.4 Kill shell access for daemon usersIf 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 10.4.2.5 Optimize the local firewall on the softPBXIn 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:
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. 10.4.2.6 Check for security risks in the dial-planIt'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 FirewallsIf 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 setupThe 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 threats10.4.3.1 Building a DMZThere 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:
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
Now, let's assume IP phone 10.1.1.103 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:
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:
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. |