News / Security
Asterisk advisory warns of IAX2 denial-of-service risk
A 2006 security warning said that a flood of IAX2 call requests could deny service to an Asterisk PBX by exhausting its ability to process new telephone calls.
A configuration-sensitive mitigation
Internet Security Systems said the problem affected older Asterisk versions and improperly configured installations of the then-current release. IAX2 was described as carrying VoIP call setup and call content between Asterisk systems; the risk arose when an attacker sent enough requests to overwhelm the PBX.
According to the advisory, version 1.2.10 could limit simultaneous unauthenticated calls from one user, but each installation needed to set the threshold low enough to reduce exposure while still allowing ordinary use. This is a dated advisory about a specific version and configuration, not a current hardening instruction.
Availability is the asset at risk
The advisory frames the attack as a flood of call requests that can stop a PBX from accepting new calls. That makes the primary consequence service availability rather than a subtle loss of one feature. In a voice environment, inability to place or receive calls can have operational importance even when no data is disclosed.
The threshold is a tradeoff
That detail matters because a lower threshold can reduce exposure while also rejecting more legitimate activity.
Version and configuration bound the claim
The 2006 item should be preserved as a dated advisory, not extended beyond its stated scope.
Security boundary
The advisory identifies a dated availability risk and a configuration tradeoff. It leaves the historically named mitigation inseparable from the exact version, configuration, and normal call demand of an installation. It provides no evidence that the balance was achieved in a specific real deployment.
How the pieces fit
IAX2 call requests reached the PBX before the system had established that the caller was entitled to use it. The suggested limit on simultaneous unauthenticated calls therefore protects a finite processing resource at the entrance to the service. Its trade-off is explicit: a very low limit may block an attack sooner, but it can also reject legitimate bursts of new calls. The useful operational lesson is not a magic threshold; it is to relate the threshold to the normal pattern of unauthenticated call setup at that installation.
The advisory described both call setup and call content under IAX2, which makes the denial effect easy to visualize: setup work can crowd out the PBX’s capacity before useful calls are accepted. Limiting unauthenticated setup protects that entrance, while leaving administrators to decide how much legitimate new traffic their environment normally needs to admit.