SIP attack traffic reaches Asterisk: verify the boundary before blocking more

Name what is actually expected before calling it broken

SIP, the signalling protocol Asterisk uses to set up a call, normally runs over UDP, a connectionless transport with no built-in handshake — which is exactly why an internet-facing SIP port draws constant scanning traffic from across the internet, on any server, not only a VICIdial one. That exposure alone is not a sign of compromise; it is the ordinary condition of running SIP in the open.

The specific pattern worth naming is: "I blocked one address, and the same kind of traffic keeps arriving." On its own, that is exactly what a rotating or distributed source hitting a single-address block looks like, not proof the firewall itself failed.

A VICIdial forum thread reports this same pattern: traffic reaching Asterisk despite an active firewall block — a starting point for the checks below, not evidence by itself of which layer actually failed.

Before doing anything else, write down what you can already see without guessing: the approximate time the traffic was noticed, which port or ports it hit, and whether it was one address repeating or many different ones. Keep raw source addresses out of any shared ticket or chat message until your security owner has actually reviewed them; this guide's own checks below stay read-only for the same reason.

Two independent listeners, one blacklist habit

This build loads both of Asterisk's SIP channel drivers at once, chan_sip and PJSIP, and each keeps its own independent UDP listener on its own port. Check the firewall policy for both listeners; a listening socket alone does not establish whether it is reachable from the internet.

A single-IP blacklist rule only ever answers the last address a source used; a rotating or distributed source simply presents a new one on its next attempt. Traffic continuing after one block is the normal failure mode of that strategy, not evidence the firewall failed to apply the rule you added.

This build has both firewalld and ViciBox's own VB-firewall helper present. Exactly how the two divide responsibility for a given rule is worth confirming on your own host with the checks below rather than assumed; this guide does not assert a specific rule set either one has already installed on your build.

Rank the likely causes before writing another rule

Work through these before adding a fourth or fifth individual IP block.

• Most likely: the strategy itself is blacklist-only against a rotating or distributed source, which will always look like it is failing no matter how many individual addresses you add to it.
• Second: the rule you added is scoped to the wrong port or the wrong SIP stack — a rule against chan_sip's port does nothing for traffic reaching PJSIP's separate listener, or the reverse.
• Third: the intended rule is missing from the active configuration or is assigned to a zone that does not handle the traffic. Compare runtime and permanent configuration before deciding what changed.
• Fourth: a separate, overly broad allow rule is already open on the same port, which no amount of blacklisting the first rule will ever fix.

Read the evidence in order, not by instinct

Resist the urge to add a block before finishing all three checks below. The order matters: confirming the listeners first tells you which ports are even in scope, confirming the firewall state second tells you whether a rule already exists and is simply misplaced, and the log check last tells you whether this is scanning or something more urgent — doing them out of order tends to produce a rule aimed at the wrong port or the wrong stack.

Confirm both SIP stacks before touching the firewall

Never assert a fixed PJSIP port in your own notes or rules. On this build PJSIP's transport happens to sit on 5061 and chan_sip on 5060, but that is this build's current value, not a VICIdial constant — the only way to know your own is to ask Asterisk and the kernel directly, in that order.

asterisk -rx 'pjsip show transports'ss -lnup | grep asterisk

Read the firewall's real state instead of assuming it

A source-bound zone and an interface-bound zone can both appear in the inventory. Determine the effective zone for the source being investigated; the zone attached to eth0 is not automatically the zone used by a matching source ipset. In this historical output public owns eth0, external has trusted source ipsets and drop has blocked source ipsets. The recorded ZONE=external command inspects that trusted-source zone only.

First list active zones. For each relevant source/interface zone, inspect runtime and permanent sources, services, ports and rich rules privately. Check membership of the suspect/trusted source in the applicable ipsets and account for policy/direct rules and upstream controls with the firewall owner. Missing rules from one zone alone do not establish a failed block.

1. Read --get-active-zones and record the public interface zone plus source-based zones. Identify the source address and address family privately.
2. Use firewall-cmd --get-ipsets and --info-ipset=ACTUAL_SET to inspect the relevant set; the inventory can be sensitive. Ask the firewall owner to resolve overlapping sources/priorities rather than guessing a zone.
3. For every applicable zone run firewall-cmd --zone=ACTUAL_ZONE --list-all and firewall-cmd --permanent --zone=ACTUAL_ZONE --list-all. Expand named services and compare their protocols/ports with the actual listeners.
4. If the owner cannot map the source to the effective path, stop rule changes. Preserve the timestamp and ask for a controlled permitted/denied-source test; a config listing alone does not prove reachability.

firewall-cmd --statefirewall-cmd --get-active-zonesZONE='<ZONE>'firewall-cmd --zone="$ZONE" --list-all

Check whether traffic is scanning or actually authenticating

A targeted log check tells you whether traffic is merely knocking or actually attempting authentication, which changes how urgently to treat it.

grep -E 'chan_sip|res_pjsip' /var/log/asterisk/messages | grep -iE 'failed to authenticate|no matching endpoint|wrong password' | tail -n 50

Review an allowlist with the firewall administrator

Ask the firewall administrator to review a default-deny policy for the SIP listeners and the complete list of trusted sources. An ipset groups addresses, but assigning that set to a firewalld zone can grant access to every service allowed in that zone. The example below illustrates a source-to-zone assignment; it is not a port-scoped SIP rule.

This trades a list that only ever grows, one blocked attacker at a time, for a list of who is actually allowed to reach your SIP ports — smaller, easier to audit, and unaffected by how many different addresses the next scan uses.

For broader server hardening beyond this one incident, see Secure your VICIdial server: SSH, firewall and access control; this guide stays scoped to triaging a single active SIP traffic incident.

ZONE='<ZONE>'ALLOWLIST_IPSET='<ALLOWLIST_IPSET>'# On ViciBox, add trusted addresses to the ViciWhite IP List (Admin -> IP Lists) and run: VB-firewall --white --dynamic --quiet# On plain firewalld, apply the source live and permanently; a --reload would empty VB-firewall's runtime ipsets:firewall-cmd --zone="$ZONE" --add-source="ipset:$ALLOWLIST_IPSET"firewall-cmd --permanent --zone="$ZONE" --add-source="ipset:$ALLOWLIST_IPSET"

Verify the block and a real call together

Re-capture both the listener and firewall checks after the change, and confirm a real test call still connects — a security fix that also blocks legitimate traffic is not a fix.

• `ss` and `pjsip show transports` still show exactly the listeners expected, unchanged by the firewall edit.
• The runtime and permanent zone listings match the reviewed policy, including all services available to the source set.
• Unwanted authentication attempts in the log stop or drop sharply, while a real test call from an allowed address still connects.

When to stop and hand this to someone else

Escalate to your security or network owner immediately, rather than continuing to adjust rules alone, for sustained high-volume traffic, any successful authentication rather than routine scanning, or genuine uncertainty about which addresses are legitimate — guessing at an allowlist under any of those conditions risks locking out real traffic or leaving a working exploit in place.