Asterisk 1.8 introduced the security events API, which is defined in
include/asterisk/security_events.h. The SIP channel driver,
chan_sip, needs to be updated to take advantage of this API for reporting events that potentially have security implications.
Problem: Attacks or unintentional configuration problems on various IP-based communications mechanisms (VoIP signalling, or IM, or media channels, or manager or...?) can lead to conditions in Asterisk that create denial-of-service circumstances, permit brute-force password attacks, or message/media confusion. Other attack results, including application or system security issues, may be exposed as a result of high-volume packet floods or malformed packets from trusted or untrusted sources.
Root problem: Asterisk has no sophisticated method of defining packet or signaling profile groups and taking action based on desired or undesired patterns.
Proposed Solution: Implement attack detection on a per-channel driver basis, reporting up to a generic socket API for blocking/logging. Create named ACLs for passive as well as dynamic packet examination/filtering. Create dynamic filter capability based on attack detection, and allow all channels to utilize a common filtering framework. Permit external exportation of passive and dynamic filters to external third-party attack mitigation tools.
Details on threats: There are several vulnerabilities that can occur when exposing the various IP-based protocol stacks to the public (or private) Internet(s). These include but are not limited to:
- Denial of Service from one or more attack origin IP addresses
- Random packet garbage
- Syntactically valid but session-invalid packet garbage
- Session-valid but malformed packet garbage
- Brute-force password attacks on VoIP protocols from one or more IP addresses
- System penetration via buffer overflow or other methods
Other problems that a robust filtering/rate-limiting package may provide:
- Protection against DDoS amplification
- Protection against runaway UA messaging
- Arbitrary re-direction of VoIP call signaling to alternate servers
- It is desirable to have named access-lists that are available across all channel drivers
- It is desirable to have both IP-generic (flooding) security as well as protocol-specific filtering built into Asterisk
- It is desirable to have each channel driver able to define what is "bad" and then describe what actions to take in the event of "bad" packets.
- It is desirable to have a packet filtering mechanism that is re-usable across all channel types.
- It may be desirable to have the ability to export actions to external programs based on filters defined in the channels, as whatever protective measures that are built into Asterisk may be insufficient or otherwise inappropriate based on the attack method.
- ACLs and actions should be capable of acting on channel-specific events, IP src/dst pattern matching, port pattern matching, session pattern matching, volume pattern matching
- Actions based on "bad" events should be both passive (standard ACLs) and active (dynamic filters that change based on behaviors)
- Actions and filters should APPLY IN BOTH DIRECTIONS OF IP COMMUNICATIONS. This means as an example and somewhat counter-intuitively, that SIP packets outbound from Asterisk to some remote endpoint should be able to be limited. This is in response to some remote devices being incapable of handling large volumes of certain packet types, or having call volumes (CPS) of a particular limit. It also helps reduce the (unusual) chance of Asterisk being an amplifier in DoS attacks.
- Dynamic filters should be stored across instantiations of Asterisk, including timers.
- External filters should be flushed and re-added at instantiations of Asterisk BEFORE channels are loaded.
- RED and other dynamic algorithms for filtering may be found in ipfw, which is BSD-licensed (note: Luigi Rizzo is/was an ipfw programmer?)
- named and grouped ACLs are part of ipfw also
- All syntaxes and configurations should support IPv4 and IPv6 addresses and methods to avoid the nightmare of backwards-reengineering when IPv6 is embedded
- Kamailio RED and Rate-Limit:
- Kamailio PIKE module:
- Postfix Anvil daemon
- "calls per second" - should apply only to INVITEs?
- RTP media dynamic filters: should support dynamic updating of filters based on RTP expected from one or more endpoints. This should block the problem with unauthorized media insertion, or media cross-confusion.
- methods - match on Methods as described by http://www.iana.org/assignments/sip-parameters
- actions: all actions have an optional ability to also be applied to dynamic filters. All actions have the optional ability to log a message. All actions have the ability to inform external programs.
Action types of -
- deny (drop silently)
- deny (with reply to non-local end)
- replies: replies can be any SIP message in the 3xx, 4xx, 5xx, or 6xx fields as noted by http://www.iana.org/assignments/sip-parameters. Note that 3xx replies need to be able to contain different redirection pointers to allow load shedding.