Exploiting the Network | Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions

This section goes along with the networking-based attacks we outlined in Chapters 4, 5, and 6.

Attack Application Port Flooding Attacks

Popularity:	9
Simplicity:	8
Impact:	9
Risk Rating:	9

We attempted to exploit the open application ports on the S8300 Media Server and IP phones. The results are covered in the following sections.

Media Server Flooding Attacks

We first attempted to exploit the open application ports on the S8300 Media Server. We judged the results by using the various IP phones to determine whether or not the attack disrupted service.

We used junotcpsynflood and our udpflood tools to test for DoS susceptibility on the TCP and UDP ports on the S8300 Media Server and G350 Media Gateway. For these attacks, our hacker box was connected to the network via eth0. The goal of these attacks was to determine if service to the various IP phones was disrupted. The first four attacks tested operation of the two 4602SW IP phones, while the last four attacks tested operation of the 4610 and 9630 IP phones. The attacks included TCP SYN and UDP flood attacks, before and during active calls.

For test 1, we used junotcpsynflood to target the 1720 signaling port on the S8300 Media Server. This port processes H.323 call control messages. The attack was conducted with no active calls. The actual command was

 ./junotcpsynflood 10.1.14.100 1720

During the attack, service was disrupted. We couldn't make calls with either IP phone. Pressing the speaker button on either phone resulted in the speaker button light illuminating, but no dial tone was issued and calls could not be initiated. A wireshark capture on the hacker box demonstrated the IP phone at 10.1.14.12 was trying to establish a TCP connection to port 1720 on the Communication Manager. Because the IP phones maintain a persistent connection to Communication Manager, this communication was necessary. The Communication Manager did not reply to the TCP SYN ACK from the IP phones. When attempting to ping the Communication Manager (10.1.14.100) from the hacker box while the flood proceeded, the Communication Manager appeared to respond sporadically.

After the attack continued for a couple minutes (in other words tens of millions of TCP SYN packets later), the IP phones went through a restart process. During the restart process, the IP phones displayed the following (the exact sequence of messages on the two IP phones differed slightly):

 Discover 10.1.14.100 Discovering...

When the attack was terminated , the Communication Manager appeared to resume normal operation. Coincident with the attack termination, the IP phones displayed

 Registering .... Undefined Error # to Continue

After pressing #, the following was displayed:

 * to Retry # to Restart

After pressing *, the following was displayed (at this point, the IP phone had registered with the media server):

 1:10pm  5/31/06 211

Calls were then able to be originated and/or terminated in a normal fashion.

For test 2, we again used junotcpsynflood to target the 1720 signaling port on the S8300 Media Server. The attack was conducted with an active call between extensions 211 and 221. The actual command used was

 ./junotcpsynflood 10.1.14.100 1720

Audio quality between the IP phones was fine while the Communication Manager was being attacked . We ended the call by hanging up the handsets. After hanging up, it wasn't possible to make additional calls.

After the attack continued for a couple minutes, the IP phones went through a restart process similar to that described previously. After the attack was terminated, the two IP phones behaved differently:

The IP phone at x211 resumed normal operation.
The IP phone at 221 displayed its Registering .... message and then displayed 221 on the second line. Calls could not be originated from x221 (there as no dial tone) nor terminated to x221. After a few more minutes, the IP phone was rebooted manually (unplugged/plugged). It then resumed normal operation and calls could be completed between the IP phones normally.

For test 3, we used the udpflood tool to target the 1719 signaling port on the S8300 Media Server. This port processes H.323 registration messages. The attack was conducted with no active calls. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.100 4096 1719 100000000

Note	For more information on the udpflood tool, see Chapter 12.

During the attack, service was disrupted. It wasn't possible to make calls with either IP phone. For example, hitting the speaker button produced no dial tone. When the attack was terminated, however, normal telephony service resumed.

For test 4, we again used the udpflood tool to target the 1719 H.323 registration port on the S8300 Media Server. The attack was conducted with an active call between extensions x211 and x221. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.100 4096 1719 100000000

During the attack, the audio of the pre-existing call did not appear to be affected by the flood. When the call ended, the IP phones behaved as in test 3.

Because the S8300 Media Server is housed within the G350 Media Gateway, we do not know if the inability to make calls when the S8300 was under attack was due exclusively to the failure of the S8300. The TCP SYN flood through the front panel eth (Ethernet) LAN port might have also affected media gateway functionality.

For test 5, we again used junotcpsynflood to target the 1720 signaling port on the S8300 Media Server. The attack was conducted with no active calls. The actual command was

 ./junotcpsynflood 10.1.14.100 1720

We pressed the speaker button on x231 (Avaya 4610 at 10.1.14.13) and x251 (Avaya 9630 at 10.1.14.15). The respective speaker light illuminated, but no dial tone was emitted from either phone. Calls could not be completed. After a couple of minutes both phones displayed:

 Discover 10.1.14.100

When the attack was terminated, both phones resumed their standard display symbology. However, the performance from that point differed over several trials. Sometimes the 9630 phone resumed normal operation almost immediately (in other words, when we pressed the speaker button, we heard a dial tone; we called x231 and heard ringing from the earpiece of x251 although x231 did not ring), whereas a couple of minutes were required for the 4610 phone to resume normal operation. On other trials, the behavior was reversed . Regardless, both phones eventually resumed normal operation without requiring user intervention. Occasionally, the phones briefly displayed the following after cessation of the attack:

 Registering ....

For test 6, we again used junotcpsynflood to target the 1720 signaling port on the S8300 Media Server. The attack was conducted with an active call between extensions 231 and 251. The actual command used was

 ./junotcpsynflood 10.1.14.100 1720

Call performance was fine during the attack, although no actions were attempted requiring supervision by the Media Server (for example, transfer). Handsets were then returned to their cradles. The display symbology on both phones continued to show the call was in-progress for a few more seconds (in other words, duration of call kept incrementing). Then both phones displayed:

 Discover 10.1.14.100

The attack was terminated a few moments later. The display symbology on both phones resumed an in-call status (the call duration timers continued to increment). However, the handsets were back in their cradles and the speaker button lights were both out. When the handsets were picked back up from their cradles, audio was still being exchanged. We picked up/returned the handsets to their cradles several times and pressed the respective speaker button several times. We pressed the drop (to drop call) softkey on 9630 and then pressed the drop hardkey on the 4610. The call could not be terminated by any normal means through either phone. We resorted to the <MUTE>RESET# keypad command sequence (reset values: no; restart phone: yes). The phones reset and resumed normal operation. New calls could be connected and terminated in standard fashion.

For test 7, we used the udpflood tool to target the 1719 signaling port on the S8300 Media Server. This port processes H.323 registration messages. The attack was conducted with no active calls. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.100 4096 1719 100000000

During the attack, service was disrupted. It wasn't possible to make calls with either IP phone. For example, pressing the speaker button produced no dial tone. When the attack was terminated, however, normal telephony service resumed.

For test 8, we again used the udpflood tool to target the 1719 H.323 registration port on the S8300 Media Server. The attack was conducted with an active call between extensions x231 and x251. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.100 4096 1719 100000000

During the attack, the audio of the pre-existing call did not appear to be affected by the flood. When the call ended, the IP phones behaved as in test 7.

Table 8-4 summarizes the results of these tests.

Table 8-4: Communication Manager DoS Test Summary
IP Phone	Test No.	Protocol Port	Call Up? Audio OK?	Make Calls?	Response After the Attack Was Over
4602 x211	1	TCP 1720	No N/A	No	The phone restarted and required user response to recover.
4602 x221	1	TCP 1720	No N/A	No	The phone restarted and required user response to recover.
4602 x211	2	TCP 1720	Yes Audio OK	No	The phone did not appear to restart. It was fine after the attack was over.
4602 x221	2	TCP 1720	Yes Audio OK	No	The phone restarted, but would not work without unplugging/plugging the phone.
4602 x211	3	UDP 1719	No N/A	No	The phone was fine after the attack was over. It did not restart.
4602 x221	3	UDP 1719	No N/A	No	The phone was fine after the attack was over. It did not restart.
4602 x211	4	UDP 1719	Yes Audio OK	No	The phone was fine after the attack was over. It did not restart.
4602 x221	4	UDP 1719	Yes Audio OK	No	The phone was fine after the attack was over. It did not restart.
4610 x231	5	TCP 1720	No N/A	No	The phone restarted and did not require a user response. In some tests, this took several minutes.
9630 x251	5	TCP 1720	No N/A	No	The phone restarted and did not require a user response. In some tests, this took several minutes.
4610 x231	6	TCP 1720	Yes Audio OK	No	The phone continued to exchange audio. Could not stop call. Required user response to restart.
9630 x251	6	TCP 1720	Yes Audio OK	No	The phone continued to exchange audio. Could not stop call. Required user response to restart.
4610 x231	7	UDP 1719	No N/A	No	The phone was fine after the attack was over. It did not restart.
9630 x251	7	UDP 1719	No N/A	No	The phone was fine after the attack was over. It did not restart.
4610 x231	8	UDP 1719	Yes Audio OK	No	The phone was fine after the attack was over. It did not restart.
9630 x251	8	UDP 1719	Yes Audio OK	No	The phone was fine after the attack was over. It did not restart.

IP Phone TCP Flooding Attacks

We attempted to exploit the open "application" ports on the IP phones using junotcpsynflood to test for DoS susceptibility on several TCP ports. For these attacks, the hacker box was connected to the network via eth0. For each of the four IP phones, we ran tests with and without active calls.

For test 1, we used junotcpsynflood to attack the Avaya 4602SW IP phone at 10.1.14.10 on port 1518. The attacks were initiated before a call was originated from x221 to x211. This was the actual command used:

 ./junotcpsynflood 10.1.14.10 1518

During the attacks, the IP phone at extension x211 (IP address 10.1.14.10) was frozen. Extension 221 operated normally. When the attacks were terminated, the IP phone at x211 operated normally.

For test 2, we used junotcpsynflood to attack the Avaya 4602SW IP phone at 10.1.14.10 on port 1518. The attacks were initiated after a call was originated from x221 to x211. The actual command used was

 ./junotcpsynflood 10.1.14.10 1518

The audio of the call ceased for each IP phone when x211 came under attack. The audio resumed after the attack was terminated.

A second trial was performed (to a call in-progress before the attack was launched), but this time we hung up the call before the attack was terminated. The phone at x221 behaved normally once we hung up the call, but x211 remained frozen. When the attack was terminated, x211 resumed normal operation.

For test 3, we used junotcpsynflood to attack the second Avaya 4602SW IP phone at 10.1.14.12 on port 1518. The attack was initiated before a call was originated from x221 to x211. The actual command used was

 ./junotcpsynflood 10.1.14.12 1518

During the attacks, x211 behaved normally. Extension x221 was frozen at first, but then it rebooted and displayed

 Finding router ...

After a few more moments, it displayed

 Bad router? * to program

We pressed * whereupon x221 entered the program mode. We then pressed # (OK) to all prompts. Extension 221 then displayed

 Enter Command

At which point, it remained frozen. The attack was terminated. We tried to dial x221 from x211 at which point x211 froze for a while. Eventually, x211 displayed

 Discovering ...

From which it never recovered. Both IP phones had to be rebooted. It isn't clear why extension x211 was affected, though it is likely because the Ethernet switch began sending packets to ports that it should not send to.

For test 4, we used junotcpsynflood to attack the Avaya 4602SW IP phone at 10.1.14.12 on port 1518. The attack was initiated after a call was originated from x221 to x211. The actual command used was

 ./junotcpsynflood 10.1.14.12 1518

For a while during the call, the audio continued to be exchanged between the two phones. Then the targeted phone (x221) began to reboot. It behaved as in test 3. Both IP phones had to be rebooted eventually.

For test 5, we used junotcpsynflood to attack the 4610 phone at x231 (10.1.14.13). The Nmap TCP port scan had shown all ports to be in the filtered status, so we attacked one of the same TCP ports that had been attacked during the Avaya 4602SW phone testing (port 1518). The attack was initiated before a call was originated from x251 to x231. The actual command used was

 ./junotcpsynflood 10.1.14.13 1518

x251 operated normally. We pressed the speaker button on x231, and the speaker light illuminated and the phone briefly emitted a dial tone. After a few moments, another warbling tone was emitted briefly. We attempted to call from x251 to x231. x251 emitted a ringing tone from its earpiece in a normal fashion; however, x231 did not ring. A few moments later, x231 emitted a ring tone briefly. Eventually the speaker light on x231 turned off. x231 responded to some button presses extremely slowly (many seconds to a couple of minutes).

The attack was terminated after approximately eight minutes.

x231 behaved poorly for several minutes following the cessation of the attack, but eventually appeared to resume normal operation (calls could be originated to/from the phone with the usual audio quality) without requiring manual intervention and apparently without the phone automatically rebooting or resetting.

For test 6, we used junotcpsynflood to attack the 4610 phone at x231 (10.1.14.13). The Nmap TCP port scan had shown all ports to be in the filtered status, so we attacked one of the same TCP ports that we had attacked during the Avaya 4602SW phone testing (port 1518). The attack was initiated after a call was originated from x251 to x231. The actual command used was

 ./junotcpsynflood 10.1.14.13 1518

Audio from x231 continued to be emitted at the earpiece of x251 in a normal fashion and with the usual audio quality. No audio from x251 was presented at the earpiece of x231. x231 did not respond to button presses (for example, MUTE). The call duration timer on the x231 display remained frozen at the time of the attack (13 seconds). x251 continued to behave normally.

The attack was terminated after approximately five minutes. Audio began to be presented at the earpiece of x231 almost instantly, and the phone responded to button presses in a normal fashion. The call duration began to increment from the point it had been frozen. The call could be terminated, and new calls could be originated to/from x231 in a normal fashion.

For test 7, we used junotcpsynflood to attack the 9630 phone at x251 (10.1.14.15). The Nmap TCP port scan had shown all ports to be in the filtered status, so we attacked one of the same TCP ports that we had attacked during the Avaya 4602SW phone testing (port 1518). The attack was initiated before a call was originated from x231 to x251. The actual command used was

 ./junotcpsynflood 10.1.14.15 1518

x231 operated normally. x251 showed some signs of occasional life. After several attempts, a call did make it through from x231 to x251 and was answered . At that point, the call could not be hung up at x251. The displayed clock updated occasionally.

The attack was terminated after approximately eight minutes.

x251 performed better than the equivalent test of x231 upon cessation of the attack. x251 appeared to resume normal operation immediately. Calls could be originated to and from the phone in a normal fashion. Audio quality was typical. The displayed clock was off by a couple of minutes for a brief period; however, the display clock resumed the correct time-of-day eventually.

For test 8, we used junotcpsynflood to attack the 9630 phone at x251 (10.1.14.15). The Nmap TCP port scan had shown all ports to be in the filtered status, so we attacked one of the same TCP ports that we had attacked during the Avaya 4602SW phone testing (port 1518). The attack was initiated after a call was originated from x231 to x251. The actual command used was

 ./junotcpsynflood 10.1.14.15 1518

Audio continued to be presented at both phone earpieces in a normal fashion and with the usual audio quality. x251 responded to button presses extremely slowly, and the call duration timer presented to the x251 display updated extremely slowly (a second every couple of minutes). x231 continued to behave normally.

The attack was terminated after approximately five minutes. x251 responded normally to button presses almost immediately. The call duration timer began to increment normally, but remained five minutes behind. The call could be terminated, and new calls could be originated to and from x231 in a normal fashion.

Table 8-5 summarizes the results of these tests.

Table 8-5: IP Phone TCP Flood Test Summary
IP Phone	Test No.	Call Up? Audio OK?	Make Calls?	Response After the Attack Was Over
4602 x211	1	No N/A	No	The phone was fine after the attack was over.
4602 x211	2	Yes No Audio	No	The phone was fine after the attack was over.
4602 x221	3	No	No	The phone restarted and did not require a user response. For some tests, x211 failed as well.
4602 x221	4	Yes No Audio	No	The phone restarted and did not require a user response. For some tests, x211 failed as well.
4610 x231	5	No	No	The phone behaved poorly for a few minutes, but eventually recovered.
4610 x231	6	Yes No Audio	No	The phone was fine after the attack was over.
9630 x231	7	No	No	The phone was fine after the attack was over.
9630 x231	8	Yes Audio OK	No	The phone behaved poorly for a few minutes, but eventually recovered.

For the next set of attacks, we used the udpflood tool to attack the Avaya 4602SW IP phone at 10.1.14.12 on port 1025. For test 1, we used the udpflood tool to attack the Avaya 4602SW IP phone at 10.1.14.10 on port 1025. For test 1, the attack was initiated before a call was originated from x211 to x221. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.10 4096 1025 100000000

At first, x211 froze, but then it started to reboot, though it never completed rebooting. When the attack was terminated, the IP phone completed its reboot cycle and returned to normal operation.

For test 2, we used the udpflood tool to attack the Avaya 4602SW IP phone at 10.1.14.10 on port 1025. The attack was initiated after a call was originated from x211 to x221. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.10 4096 1025 100000000

The audio in the call remained fineas if the IP phone was not under attack. When we hung up the handsets, the phone at x211 then performed as in the first attack (it began to reboot and then froze). When the attack was terminated, x211 completed the reboot cycle and resumed normal operation.

For test 3, the attack was initiated before a call was originated from x221 to x211. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.12 4096 1025 100000000

At first, x221 froze, but then it started to reboot, though it never completed rebooting. When the attack was terminated, the IP phone completed its reboot cycle and returned to normal operation.

For test 4, we used the udpflood tool to attack the Avaya 4602SW IP phone at 10.1.14.12 on port 1025. The attack was initiated after a call was originated from x221 to x211. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.12 4096 1025 100000000

The audio in the call remained fineas if the IP phone was not under attack. When we hung up the handsets, the phone at x221 then performed as in the first attack (it began to reboot and then froze). When the attack was terminated, x221 completed the reboot cycle and resumed normal operation.

For test 5, we used udpflood to attack the 4610 phone at x231 (10.1.14.13). The Nmap UDP port scan had shown all ports to be in the closed status or openfiltered status, so we attacked one of the same UDP ports that had been attacked during the Avaya 4602SW phone testing (port 1025). The attack was initiated before a call was originated from x251 to x231. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.13 4096 1025 100000000

x251 operated normally; however, x231 was completely nonresponsive.

When we terminated the attack five minutes later, x231 immediately resumed normal operation and was responsive to all button presses, and calls could be originated to and from the extension.

For test 6, we used udpflood to attack the 4610 phone at x231 (10.1.14.13). The Nmap UDP port scan had shown all ports to be in the closed status or openfiltered status, so we attacked one of the same UDP ports that had been attacked during the Avaya 4602SW phone testing (port 1025). The attack was initiated after a call was originated from x251 to x231. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.13 4096 1025 100000000

x251 operated normally. The call remained active between x231 and x251, and audio from x231 to x251 seemed typical. Audio from x251 presented at the earpiece of x231 had a very slight delay, which was really only apparent when holding the handset of x231 to an ear while speaking into the mic of x251. The display of x231 appeared to be almost frozen. The call duration incremented one second every couple of minutes. There was a very long latency from the press of a button on x231 (for example, the speaker button) until the result of the button press became manifest.

When the attack was terminated five minutes later, x231 immediately resumed normal operation from all appearances (it was responsive to all button presses, and calls could be originated to and from x231).

For test 7, we used udpflood to attack the 9630 phone at x251 (10.1.14.15). The Nmap UDP port scan had shown all ports to be in the closed status or openfiltered status, so we attacked one of the same UDP ports that had been attacked during the Avaya 4602SW phone testing (port 1025). The attack was initiated before a call was originated from x231 to x251. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.15 4096 1025 100000000

x231 operated normally. x251 rang when the call was placed from x231. However, x251 continued to ring even though the handset was removed from its cradle. Its display appeared frozen for a time, and the phone did not respond to most button presses. Randomly hitting the Phone button followed by pressing the arrow/OK buttons caused the display to blank for a couple of minutes. x251 continued to ring throughout.

When the attack was terminated five minutes later, x251 immediately answered the call and normal phone operations resumed from that point.

For test 8, we used udpflood to attack the 9630 phone at x251 (10.1.14.15). The Nmap UDP port scan had shown all ports to be in the closed status or openfiltered status, so we directed the attack to one of the same UDP ports that had been attacked during the Avaya 4602SW phone testing (port 1025). The attack was initiated after a call was originated from x231 to x251. The actual command used was

 ./udpflood 10.1.14.99 10.1.14.15 4096 1025 100000000

x231 operated normally. The call remained active between x231 and x251. Audio appeared unaffected in both directions. x251's display appeared to be frozen, except that the call duration updated once. x251 would not respond to button presses.

When the attack was terminated five minutes later, x251 immediately resumed normal operation from all appearances (it was responsive to all button presses, and calls could be originated to and from x251).

Table 8-6 summarizes the results of these tests.

Table 8-6: IP Phone UDP Flood Test Summary
IP Phone	Test No.	Call Up? Audio OK?	Make Calls?	Response After the Attack Was Over
4602 x211	1	No N/A	No	The phone restarted and did not require a user response.
4602 x211	2	Yes Audio OK	No	The phone restarted and did not require a user response.
4602 x221	3	No	No	The phone restarted and did not require a user response.
4602 x221	4	Yes Audio OK	No	The phone restarted and did not require a user response.
4610 x231	5	No	No	The phone behaved poorly for a few minutes, but eventually recovered.
4610 x231	6	Yes Audio OK*	No	The audio was delayed. The phone was fine after the attack was over.
9630 x231	7	No	No	The phone was fine after the attack was over.
9630 x231	8	Yes Audio OK	No	The phone was fine after the attack was over.

Countermeasurs Network DoS Attack Countermeasures

There are several countermeasures you can employ to protect the Avaya Media Server and IP phones from network DoS attacks. These are covered next.

Use a Firewall to Protect the IP PBX/Media Server

Tables 8-1, 8-2, and 8-3 list ports and access lists that you can use to program a firewall, which protects the Avaya Media Server from DoS attacks originating from the rest of the network.

Network-Level DoS Mitigation

As with any IP-enabled device, LAN switch-based DoS limits exist with the DoS protection and mitigation mechanisms a product can implement. Thereafter, network-based protection mechanisms must be implemented to mitigate and/or prevent such flooding-based attacks.

Avaya DoS Mitigation

Avaya limits the number of TCP SYNs to five per minute and logs a rate above this threshold. Avaya has also performed custom development on the underlying Linux kernel to help reduce the impact of a DoS attack. In larger configurations, C-LAN cards are used as " front-ends " to the Communication Manager. These C-LAN cards have a built-in rate-limiting firewall that may also help to mitigate DoS attacks. When multiple C-LAN cards are used, the system may be more resilient because the C-LAN cards balance the load across cards. An attack against one card might affect traffic running through that card, but should not affect other cards. Of course, an attacker who has the addresses of each card can run a DoS against all of them.

Stay Current on Firmware

Avaya recommends keeping up-to-date with IP phone firmware releases and states that future releases will have improvements that address DoS susceptibility.

Attack Denial of Service (Crash) and OS Exploitation

Popularity:	9
Simplicity:	8
Impact:	8
Risk Rating:	8

The servers at the core of an Avaya Communication Managerbased IP PBX run a customized version of the Red Hat Enterprise Linux 4 operating system.

Avaya's documentation does not claim its Linux-based IP PBX devices are impervious to network attacks such as DoS. It does claim that a DoS attack will not cause a media server or media gateway to crash. In separate trials to test this claim, a S8300 Media Server module was attacked by a host on its home network executing one of the UDP flood tools ( udpflood ) and the TCP SYN flood tool ( junotcpsynflood ). Both tools effectively denied Communication Manager service to IP phones. The Communication Manager appeared to resume call processing service after each attack was terminated.

Many members of the suite of Avaya Integrated Management servers and adjunct devices execute operating systems that run the gamut (for example, Linux, HP-UX, Sun Unix, Windows). While Avaya and third parties might have taken pains to remove unnecessary services from these devices and have them patched appropriately at the time of installation, one might expect they remain subject to new operating system exploits as they arise unless the IT/telephony administration personnel remain vigilant.

Countermeasurs Denial of Service (Crash) and OS Exploitation Countermeasures

There are several countermeasures you can employ to protect the underlying operating system.

Monitor for Known Vulnerabilities/Patch Management

Avaya recommends its customers subscribe to their Avaya Security Advisories to stay aware of potential vulnerabilities. The Avaya Security Advisory web page is http://support.avaya.com/security.

Of the many advisories listed thus far for 2006 (JanJune), only a very small fraction have been assigned a Risk Level above Low. The majority are stipulated as having no risk. Go to their web page for more information on Avaya's classification levels and criteria.

There are several sites that list numerous past and present postings for actual or potential exploits of Avaya systems. These include, but are not limited to, "platform" issues. For example, multiple security vulnerabilities were discovered in the Apache freeware httpd (the HTTP web server). Apache is contained within Red Hat's Linux distribution and is deployed in several Avaya products and components . Go to http://www.us-cert.gov/ and search for Avaya.

When a vulnerability is identified, Avaya will generally provide a patch. Applying patches is a necessary step in addressing these vulnerabilities.

Host-Based Intrusion Prevention

The Linux operating system running on the Avaya media server and media gateways is closed, meaning that customers can't modify it directly. Nonessential network services are removed in their version of Linux, and Avaya allows fine-grained control over those services that are available (see the earlier section "Open Ports/Services Countermeasures"). Avaya bundles the Tripwire product, which monitors for unauthorized changes to key system files.

Network-based Intrusion Prevention Systems

Network-based Intrusion Prevention Systems (NIPSs) are inline network devices that detect and block attacks at wire speed. A NIPS can be deployed in a network in much the same way as a switch or a router. The NIPS inspects each packet that passes through it, looking for any indication of a malicious exploitation of a vulnerability.

When the NIPS does detect an attack, it blocks the corresponding network flow. As an element of the network infrastructure, it must also identify attacks without blocking legitimate traffic.

NIPSs also buy IT administrators time to patch enterprise-wide by providing a sort of virtual patch for any exploits that might emerge soon after a new vulnerability is discovered in the public domain.

There are a plethora of NIPS vendors including

Cisco Systems
Forescout Inc.
Fortinet Inc.
Internet Security Systems
Juniper Networks
Lucid Security
McAfee
NFR Security
NitroSecurity Inc.
Panda GateDefender Integra
Radware
Refl ex Security
SecureWorks
Third Brigade
TippingPoint
Top Layer

Attack Eavesdropping and Interception Attacks

Popularity:	5
Simplicity:	7
Impact:	7
Risk Rating:	6

As you remember from Chapters 5 and 6, we demonstrated a variety of attacks that took advantage of weaknesses in network design and architecture in order to eavesdrop and alter VoIP signaling and conversations. These attacks, along with Cisco network-specific countermeasures, are also covered in Chapter 7. Virtually all of the attacks described in these chapters are also possible in an Avaya environment, unless the countermeasures are followed.

Countermeasurs Eavesdropping and Interception Countermeasures

The main countermeasure unique to Avaya is the ability to enable encryption and authentication for signaling and media. Avaya supports the Advanced Encryption Standard (AES) on all endpoints when using H.323 loads. H.235 media encryption is also supported when using Communication Manager 3.1 or higher. Avaya plans to support SRTP in Communication Manager 4.0.