Section 10.3. Access Control
10.3. Access ControlThe biggest headache in building secure networks is often access control. It is by permitting access that rich applications are delivered in the network; it is by restricting access that those applications are made more secure. Unfortunately, just as in the outside, analog world, limiting access in the name of security can result in a poor experience or a lasting resentment by users. Consider the security checkpoints at airports: very thorough, very time-consuming , and, possibly, a very big inconvenience. But the point of an airport security checkpoint is the same as an access control policy on your VoIP network: allow only the right people inthat is, people with a boarding pass and a clean X-ray scan. Likewise, if an access attempt that isn't authorized or is possibly damaging is made into the IP network, stop it immediately.
There are many layers to the access control paradigmcredentials, origin and destination, timing, and physical presence controls. One or all of these may be taken into account when your network decides whether to let somebody have access to a registrar, a directory lookup, a media channel, or any data at all. 10.3.1. Credentials and AuthenticationAccess control credentials are special pieces of secret information that entitle a user, or a software process, access to the network. This may be a password, an encrypted string, or some other secret key that authenticates the user or software process, allowing it to use a resource. On a SIP phone, this might be the registration password required in order to gain access to a proxy on the VoIP network, without which making phone calls would be far more difficult. It might even be a public key cryptographic relationship between two call-management servers. It could be the key that is used to encrypt a VPN tunnel between two remote VoIP networks. Credentials are used all over a secure VoIP network. Credentials and authentication are the best way to prevent anonymous abuse of a properly functioning system, VoIP included. They also provide a digital signature that authenticates billing transactions associated with the use of a voice system. Regulatory agencies can require service providers and subscribers to recognize digital signatures during disputes.
It's also important to enforce access control policies on wireless Ethernet segments. This means using WEP keys on wireless devices that access the network by 802.11a/b/g means. Check your wireless IP phone's specs to see if it can be a WEP client. Finally, credentials can be enforced by the endpoint. In a centralized authentication system, IP phones themselves can require a username and password or PIN from prospective callers . This way, users are authenticated before they are able to even get a dial-tone. Cisco, Avaya, and many other vendors ' proprietary solutions support this kind of authentication, though usually through a built-in authentication scheme, as opposed to Active Directory or RADIUS. 10.3.2. Project 10.1. Use MD5 Hash to Secure SIP Passwords10.3.2.1 What you need for this project:
Endpoint authentication helps you prevent somebody from simply plugging an IP phone into your Ethernet switch, directing it to your softPBX, and making phone calls on your network. All softPBX servers support password protection of endpoint access, but some go a step further, hashing the passwords so that they cannot be easily observed by the ill-intentioned. Asterisk allows you use the MD5 algorithm to secure the SIP passwords that are stored in the Asterisk SIP configuration. This prevents clear-text SIP passwords from being the exclusive access control key for SIP endpoints. When the MD5 secret feature is used, Asterisk will require the MD5- hashed password in addition to the common SIP username and password. First, configure a SIP phone to use an MD5 secret. This is accomplished differently on different SIP phone makes. Not all SIP phones have an implicit MD5 setting. On most, it is possible to enter the username, realm, and password and let the phone piece the MD5 secret together. On most IP phones, no additional configuring of the phone is necessary. Next, edit Asterisk's sip.conf configuration file. For each peer that supports MD5 authentication, you can add the md5secret setting, which allows you to store the MD5 hash to compare when the SIP peer is attempting to register or place a call. When entering the MD5 secret into the configuration, you must enter it in its hashed form. The format for SIP MD5 secrets is user:realm:password . So, 3001:asterisk:MaBell would have to be hashed before it was entered and stored in sip.conf . You can hash the string using the md5sum utility, a standard item on most Linux distributions: # echo -n "3001:asterisk:MaBell" md5sum The output of this command is the hash, the part you'd enter for the value of the md5secret option in sip.conf : bece6f2475b3239e877bbd2235332 Use a copy and paste for periodic updates to MD5 secrets. Otherwise, you're sure to be aggravated by data entry mistakes. Alternatively, you could write a shell or Perl script that automates putting MD5 hashes into your sip.conf file. 10.3.2.2 Origin, destination, and timing policiesLike a firewall, access to and from a VoIP network may be restricted due to a policy that takes into account the origin of the access attempt, the destination of a requested resource (such as which subscriber a node is trying to reach), and the timing of the request. There are two ways to restrict access based on origin, destination, and timing: rule-based firewalls and dial-plan configuration. Rule-based firewalls generally have a clause for each rule that states the schedule in which it is enforced. It isn't really practical to use a firewall to restrict access for a particular endpoint, since that endpoint's calls would have to cross the firewall in order to enforce the rules. Instead, firewall devices are great for enforcing source/destination and timing- related rules on entire network segments. For instance, the firewall could permit calls from the Detroit office to the Chicago office only during certain hours of the day or only on weekends. Firewall rules could prohibit the use of remote VoIP users who use a VPN to place calls through the corporate phone systemduring certain times of the day, perhaps.
Firewall rulesets are a form of access control that operate mainly at the network layer and below. Thus, they don't distinguish which codecs are being used, which phone number has been dialed to direct the call, or whether the caller and receiver are using ATAs, IP phones, or softphones. Instead, firewalls are concerned with:
10.3.2.3 Higher-layer access controlIt's the application layerthe dial-planthat can distinguish dialed numbers , signaling protocols, codecs, and so on. These things can be used as access control factors, toobut on the PBX, not the firewall. On the PBX, you might have a dial-plan that is programmed to behave a certain way depending on the origin, destination, or timing of the call. Let's say there's a 24- hour waiting area in a hospital with a courtesy phone that guests can use. But the reception desk that covers this waiting area is staffed only 16 hours a day. It's possible, using some combination of time-sensitive dial-plan rules, to secure this phone against abuse during times when the area isn't being monitored by a receptionist . Almost all PBX systems support this kind of programming. 10.3.2.4 Physical presence policiesOne way to assure proper access security is to have the network verify the indicators that each device present on the VoIP network is permitted to access the network. This could mean accounting for a particular endpoint's MAC hardware address in an access control list that's centrally stored, so that when the endpoint is plugged into an Ethernet switch on the network, the switch knows to grant it access. This technique is quite common with 802.11b/g wireless Ethernet segments. On many wireless access points, the list of authorized MAC addresses is stored in the base station itself. For the ultraparanoid system administrator, some Ethernet switches can be programmed to grant access only to a certain MAC hardware address on a certain port . This could be useful in a shared-facilities or bandwidth-lease environment where multiple tenants use the same Ethernet backbone and individual network ports are restricted to a certain VLAN. 10.3.3. Media EncryptionEncrypting the key piece of authentication infothe endpoint's access passwordis one way to prevent unauthorized access to make and receive calls using an IP phone. But this measure alone doesn't protect calls in progress from being observed and possibly recorded. Once an intruder has access to the softPBX or a critical piece of routing infrastructure, like a firewall, she may be able to store VoIP media streams packet by packet, and piece them together to listen to later. It isn't very hard to figure out which codec the call used and play the call back using a program that supports lots of codecs, like QuickTime or a decent sound file editor. This is a potentially devastating riska true cornucopia for the daring intruder. So, to remove the risk, the media streams to and from IP phones and the softPBX can be encrypted. Encryption of media channels is something the bulk of VoIP vendors don't support, but the need is clear. The prevailing method of sending media streams in an encrypted fashion is via SRTP (Secure Real Time Transport Protocol), a mechanism that must be activated during capabilities negotiation (SDP or H.245). As with any other capability, all endpoints involved in the call must support the same standard of encryption. Few IP phones on the market permit the use of SRTP, though Avaya and Cisco both offer support for media encryption through a proprietary means in some of their IP phones. The Zultys Zip 4x4 is a SIP phone that allows SRTP media encryption. Its documentation says that you can toggle back and forth between encrypted and unencrypted sessions during the same call, presumably using multiple SIP methods and setup exchanges. This would be useful if you had an encrypted call between the two 4x4 phones and you needed to transfer the call to a SIP phone that didn't support media encryption. |
EAN: 2147483647
Pages: 172