SIP • SERVER • SDK • METHODS

VaxVoIP SIP Server SDK attack-detection methods

Technical guidance for using the exported methods and events that detect SIP scanning, request flooding and repeated authentication failures.

VaxVoIP SIP Server SDK exports three methods for enabling application-level detection of common SIP traffic problems. Each method configures a detection rule inside the SDK and has a corresponding event that reports the detected condition to the SIP Server SDK-based application.

The application decides how to process each event. It can record the source information, notify an administrator, apply a temporary restriction or pass the information to an existing firewall and monitoring system. The exported methods provide detection signals; they do not replace the deployment's wider network-security policy.

EXPORTED • METHODS • EVENTS

Attack-detection methods exported by SIP Server SDK

AttackDetectScanSIP() validates incoming SIP traffic against the configured SIP domain and reports requests that do not satisfy that rule through OnAttackDetectedScanSIP().

AttackDetectFloodSIP() monitors the incoming SIP request rate and raises OnAttackDetectedFloodSIP() when the configured request limit is exceeded.

AttackDetectBruteForceSIP() monitors authorization failures within a defined interval and raises OnAttackDetectedBruteForceSIP() after the configured failure limit is reached.

These methods are called after SDK initialization. Their exact signatures, parameter types and event arguments are documented in the SIP Server SDK Technical Manual.

DOMAIN • VALIDATION

AttackDetectScanSIP() exported method

AttackDetectScanSIP() associates accepted SIP requests with the configured domain URI. Requests that do not match the expected domain can be discarded without returning a SIP response, while OnAttackDetectedScanSIP() notifies the SIP server application.

Typical detection flow

  1. Initialize the SDK and open the required SIP transports.
  2. Call AttackDetectScanSIP(Domain-URI) with the domain accepted by the service.
  3. Record the source address, transport and request details when OnAttackDetectedScanSIP() is raised.
  4. Correlate repeated events before applying a temporary network restriction.

Domain validation should match the deployment model. A server that legitimately accepts several domains must account for each expected domain to avoid rejecting valid traffic.

RATE • MONITORING

AttackDetectFloodSIP() exported method

AttackDetectFloodSIP() configures a limit for incoming SIP requests. When traffic exceeds the configured request threshold, OnAttackDetectedFloodSIP() alerts the SIP server application so it can log, rate-limit or isolate the source.

Choose a realistic threshold

Measure normal registration, keep-alive and call traffic before setting the limit. Include expected peaks, failover events and NAT environments where many devices may share one public address. Start with monitoring, review the events and tighten the policy only after the normal traffic profile is understood.

AUTHENTICATION • PROTECTION

AttackDetectBruteForceSIP() exported method

AttackDetectBruteForceSIP() monitors failed authorization attempts within a configured interval. When failures exceed the limit, OnAttackDetectedBruteForceSIP() reports the condition to the SIP server application.

The method accepts a failure count and failure interval. These values should allow for occasional user mistakes and devices retaining an old password, while still identifying concentrated attempts against one or more accounts.

Typical detection flow

  1. Call AttackDetectBruteForceSIP(FailureCount, FailureInterval) after SDK initialization.
  2. Log the account, source address and event time when the detection event occurs.
  3. Apply a short lockout or temporary network block when the evidence supports it.
  4. Alert an administrator when attempts continue or affect several accounts.

EVENTS • RESPONSE • CONTROL

Handle the exported attack-detection events

Detection events should feed a response policy rather than automatically creating permanent firewall rules. A production policy can combine the event type, source address, account, event frequency and recent call activity before deciding what to do.

  • Log first: retain timestamps, source addresses, transports, accounts and event types for investigation.
  • Rate-limit when possible: temporary throttling may preserve service while reducing harmful traffic.
  • Use time-limited blocks: short blocks reduce damage from false positives and shared public addresses.
  • Escalate repeated behavior: extend restrictions only when the activity continues or multiple signals agree.
  • Monitor the result: verify that legitimate registrations and calls remain healthy after a policy change.

Firewall automation must run with controlled permissions and validated input. Do not insert untrusted event text directly into a system command.

DEPLOYMENT • CHECKLIST

SIP server security checklist

  • Expose only the SIP transports and management ports required by the deployment.
  • Use strong, unique SIP account credentials and remove unused accounts.
  • Restrict administrative access by network, identity and role.
  • Enable scan, flood and authentication-failure monitoring with tested thresholds.
  • Centralize logs and alert on repeated or correlated security events.
  • Keep the operating system, firewall rules and application dependencies current.
  • Test call setup, registration, failover and emergency access after security changes.

Exact method parameters and event signatures are available in the SIP Server SDK Technical Manual.

SIP • SECURITY • FAQ

Frequently Asked Questions

Which VaxVoIP SIP Server SDK methods detect SIP attacks?

AttackDetectScanSIP(), AttackDetectFloodSIP() and AttackDetectBruteForceSIP() enable detection of unexpected-domain requests, request floods and repeated authorization failures.

Which event reports a SIP request flood?

OnAttackDetectedFloodSIP() reports that the request limit configured through AttackDetectFloodSIP() has been exceeded.

Should every detected address be blocked permanently?

No. Validate the event and correlate it with logs before applying a temporary or permanent block. Shared networks and configuration errors can produce false positives.

Does SIP attack detection replace a firewall?

No. Application-level detection complements a firewall, rate limiting, secure credentials, monitoring and timely software updates.