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-09-07Operational 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.

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.