VoIP.infoThe independent guide to business communications.
VoIP.info Guide

SIP scanning, failed registration and rate limits

Distinguish routine authentication challenges from abuse and contain bursts without locking out a site.

Reviewed 2026-10-18Operational guidance; Asterisk 22 / FreePBX 17 where applicableIntermediateDocumentation based · not lab tested

A challenge is not an intrusion by itself

A normal SIP digest exchange can include a 401 or 407 challenge before an authenticated retry succeeds. Look at the sequence and outcome. Repeated unknown account names, sustained failures, unusual source changes or attempts to reach forbidden destinations deserve investigation. An OPTIONS probe alone does not demonstrate a compromised account.

Reduce unnecessary public reachability first. Use documented provider source ranges or an approved remote-access architecture where appropriate, with a process to maintain changes. Authentication remains necessary even when the network is restricted.

Apply limits at the right identity boundary

A source-IP limit can affect many legitimate phones behind one NAT. A registration storm can also follow a site power outage or mass firmware reboot. Set limits from observed normal bursts, not from a single quiet phone. Separate attempted registrations, call attempts and concurrent calls where the platform allows it; they protect different resources.

Automatic blocking needs expiry, a recovery path and monitoring. A blanket permanent ban can turn one misconfigured handset into a branch outage. Do not whitelist all internet sources to solve the lockout.

Correlate before changing policy

Collect security events, registrar results and provider call records around the incident. Asterisk provides a security event framework and logger, but generating events is separate from deciding which events justify blocking. Verify that the module and log destination are active on the installed version.

For confirmed credential compromise, revoke the credential, contain outbound permissions and investigate exposure. Raising a rate limit cannot remediate a stolen secret. After tuning, test a normal challenge/retry, an authorized reconnect burst and the documented unblock procedure.

Separate a provider throttle from SIP's registered 429 meaning

A service may document a local 429 Too Many Requests registration response, but SIP 429 is registered as Provide Referrer Identity. Use the 429 diagnostic to preserve the protocol, method, responder and account-specific policy before tuning a legitimate refresh or a defensive rate limit.

Prove the event, parser and rate-limit action separately

Use the missing-or-noisy diagnostic when scanning evidence does not reach the intended collector or control.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Guide

Responding to a compromised VoIP extension

Constrain the affected identity and trace its permissions before returning it to service.

Read guide →
Guide

Should a PBX be exposed to the public internet?

Separate necessary carrier and phone reachability from administrative exposure.

Read guide →
Reference · SIP standards; extension support depends on both peers

SIP digest authentication: challenges, realms and algorithms

Investigate repeated authentication challenges while keeping credentials out of traces and configuration examples.

Read guide →
SIP response reference · IANA's SIP response-code registry, RFC 3892, RFC 6585, Skyetel's current SIP Registration limitations and Asterisk's current outbound-registration and diagnostic guidance were reviewed October 8, 2026; no provider account, PBX, registration object, referral, token, credential, request rate, response, retry timer, availability result or call was inspected or tested

SIP 429 Provide Referrer Identity

The registered SIP 429 asks for valid referrer identity; it is not HTTP 429 Too Many Requests, even when a provider reuses the number for a local registration policy.

Read guide →
Diagnostic · IANA's SIP response-code registry, RFC 3892, RFC 6585, Skyetel's current SIP Registration limitations and Asterisk's current outbound-registration and diagnostic guidance were reviewed October 8, 2026; no provider account, PBX, registration object, referral, token, credential, request rate, response, retry timer, availability result or call was inspected or tested

A provider returns SIP 429 Too Many Requests

Preserve the method, reason phrase and responder, then separate a provider-local registration throttle from SIP 429's registered referrer-identity meaning.

Read guide →
Asterisk · Current first-party Asterisk security-framework, logging, command, configuration and source evidence reviewed October 18, 2026. Security-event generation, res_security_log module state, dynamic SECURITY level registration, logger channel configuration, destination path, file write, rotation, downstream parser, alert and enforcement action remain separate evidence. A security event is not by itself proof of compromise, and a written record is not proof of a ban or alert. No host, module, logger channel, file, permission, event, parser, firewall, packet, account or call was inspected or tested

Asterisk security-event logging: generation, channel and custody evidence

Trace a security event from the producing subsystem through res_security_log, the dynamic SECURITY level, logger channel, file custody, rotation and downstream consumers.

Read guide →
Troubleshooting · Current first-party Asterisk security-framework, logging, command, configuration and source evidence reviewed October 18, 2026. Security-event generation, res_security_log module state, dynamic SECURITY level registration, logger channel configuration, destination path, file write, rotation, downstream parser, alert and enforcement action remain separate evidence. A security event is not by itself proof of compromise, and a written record is not proof of a ban or alert. No host, module, logger channel, file, permission, event, parser, firewall, packet, account or call was inspected or tested

Asterisk security events are missing, too noisy or not reaching enforcement

Separate event generation, res_security_log state, dynamic logging level, channel path, file custody, rotation, parser, alert and defensive action.

Read guide →