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. Reacting to unwanted traffic on one without checking the other leaves the second exposed by definition, whether or not anyone is currently probing it.

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 rule was added but firewalld was never told to reload, or it landed in a zone the public interface is not actually in.
• 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

This build runs firewalld alongside VB-firewall, ViciBox's own helper layered on top of it. Confirm the active zone before listing rules for it, since a rule sitting in the wrong zone behaves exactly like no rule at all.

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

Replace one-off blocking with a scoped allowlist

Replace single-IP blacklisting with a default-deny allowlist scoped to the exact port or ports the checks above actually found, rather than adding one more individual block. An ipset manages a whole allowed range as one named set instead of one firewalld rule per address, so adding or removing a legitimate carrier later is one ipset edit, not a firewalld rule rewrite.

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.
• `firewall-cmd --list-all` shows the new allowlist rule attached to the correct zone.
• 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.