What your softswitch can stop in a SIP DDoS attack

You run MOR or M4 yourself. By the end you can tell a full pipe from a SIP flood, set the switch controls that limit a flood which reaches the server, and ask the host the right questions when the pipe is full. You can also put new customers on a second server, so a competitor posing as a customer learns that address and not the one your trusted clients use.

A softswitch can stop a SIP flood that reaches the server. It cannot clear a pipe that is already full. There is no guaranteed way to stop a targeted DDoS. Once the uplink is saturated, a firewall rule and a call limit have nothing left to act on. Customers will report dead calls, a dead GUI, or both. That report does not name the layer. The first job is to name it: host, server, or call control.

A full pipe and a SIP flood fail in different places

A volumetric flood fills the path. The server can be up and still be unreachable, because the loss happens on the way in. A SIP-layer flood is REGISTER and INVITE traffic, plus scanners, aimed at the softswitch. The path still has room. The process does not.

VirtualGlobalPhone published the volumetric case on 24 July 2026. The attack followed an extortion demand they called consistent with a campaign against several U.S. service providers in the weeks before. Traffic came from thousands of places, across the whole prefix, on every upstream. The upstream link was already full, so the filter at their edge had nothing clean to pass. Blackhole routing of one address left the rest of the prefix under attack. Each source sent a small share, so automated detection missed the pieces. VoIP and the web panel both failed.

FibreMax reported the same split on 15 May 2026. Their servers stayed up. Hosted voice failed because the attack hit the hosting provider’s upstream. FibreMax says the host put the volume at about 400 Gbps. The outage started about 1:00 PM AEST. The host brought in GSL Networks, a filtering network, about 6:30 PM AEST. Phone service was back by 10:00 PM AEST. The 400 Gbps figure is the host’s number, as FibreMax reported it.

Ringotel hit the second kind on 31 August 2026. A coordinated attempt against their SIP infrastructure started about 11:30 AM UTC in US East and US West, then London, Dublin, Singapore, and a few on-premise regions. Calls failed in bursts. The regions stayed up in a degraded state, so automatic failover did not move traffic. Staff moved them by hand. Customers who had allowed one IP on their firewall could not reach the secondary address. Most regions were back by 2:30 PM UTC. A few stayed affected until about 3:00 AM UTC on 1 September. Ringotel says no customer data was read and no unauthorised calls were placed.

Read the port graph and ask the host if they see an attack on your prefix. A full graph, or a host ticket that names an attack upstream of you, is the network layer. A quiet graph plus a storm of REGISTER or INVITE is the server or the call layer. Do that check before you edit the switch.

The host owns a full pipe

Hetzner includes DDoS filtering at no extra charge, and detection runs all the time. The filter list Hetzner publishes names DNS reflection, NTP reflection, UDP floods on port 80, SYN floods, DNS floods, and invalid packets. SIP on 5060 is absent from that list. A move from a 1 Gbit port to a 10 Gbit port gives legitimate packets more room beside the flood. The attack is still on the wire.

OVHcloud includes Anti-DDoS on every product, at no extra charge, with detection left on. They publish more than 17 Tbit/s of filtering capacity and say the system has mitigated attacks up to 1.3 Tbit/s. The price includes mitigation for the whole attack, with no cap on how many times you are hit. They also say many of these floods fill the link in front of the server, which means the server cannot filter them. That page does not describe a SIP parser. Ask whether they scrub UDP 5060 and your RTP range.

A Cloudflare proxy in front of the GUI covers HTTP and HTTPS when staff open the GUI by domain name. Any other protocol ignores that proxy. The same domain cannot carry the GUI and SIP. Someone who knows the server IP sends the attack at the IP and skips the proxy. Cloudflare is a separate company. Kolmisoft does not support Cloudflare products.

Cloudflare Spectrum is a different product: a TCP and UDP proxy with layer 3 and layer 4 filtering. Custom TCP and UDP applications sit on the Enterprise plan as a paid add-on. Spectrum drops packets for a protocol or a port you did not list. It carries SIP and RTP when you list those ports, and RTP means the whole media range. Plan on several thousand USD a month. The range we give clients is about 3,000 to 4,000 USD and up, on a quote, with no public price list. For many of those providers the quote is higher than what they pay for the softswitch. Spectrum sits next to the filter the host already includes. It is one option with a price.

If the path is full, the host is the party who can act. VirtualGlobalPhone’s edge never got a clean path. FibreMax’s platform stayed up while the host’s upstream did not.

Scanners, countries, and addresses

Use this layer when the port graph still has room and the SIP log shows a tool name, a country you do not serve, or a subnet you can write down.

MOR from X16, and M4, install iptables rules that drop SIP scanners by User-Agent. The default list is friendly-scanner, sundayddr, sipsak, sipvicious, iWar, sipcli, VaxSIPUserAgent, and pplsip. Add or remove names in system.conf. The switch rewrites the rules every 15 minutes. Run the block-scanners script when the new list has to hit the wire now.

Blocked Countries, under Security, loads country address lists from ipdeny.com into ipset. MOR and M4 both have the screen. The lists refresh every month. A save with many countries can take 4 to 5 minutes. Each country list keeps an emergency allow: the server’s own address, Kolmisoft support access, the server’s DNS resolvers, the list source, and SSH on port 22. The lists are not exact, so a new carrier address can sit inside a country you blocked. The kernel has to support ipset (2.6.32 or newer, with ip_set and ip_set_hash_netport). Otherwise the GUI warns you, and that server does not enforce the list.

Blocked IPs, also under Security, takes a single address, a subnet in CIDR form, or a range. The GUI stores a CIDR entry in canonical form: 2.2.2.1/24 becomes 2.2.2.0/24. A range such as 2.2.2.1-125 becomes one row per address, so prefer a subnet. The block takes effect within one minute. On M4 you can aim it at one server or at every server. You cannot block the server’s own address, a local address, or a private address.

The rules drop packets that arrive. Packets the uplink already discarded never reach them.

CPS, Asterisk load, and one number

Use this layer when the SIP comes from a customer you allow, or when one destination is the number under attack. The firewall is the wrong tool for a customer who is supposed to send you calls.

On MOR, set “Limit up to (number) calls, during (number) seconds” on the device, and the same pair on the provider. Hangup cause 244 is the device cap. 243 means the provider was skipped for the cap. MOR documents a system ceiling of 100 CPS. One Asterisk server is documented up to 50 CPS, and in practice nearer 20. A steady 150 CPS or more into MOR, with no proxy in front, can take the server down. The caps do not save that box. The setups overwhelm it before a reject can run.

On M4, set “Limit up to X calls, during Y seconds” on the origination point or the termination point, and again on a dial-peer and termination-point pair. M4 documents a system ceiling of 1,000 CPS. Hangup cause 304 is the origination point. 329 is the termination point. 342 is the system incoming cap. 345 is the cap inside a dial peer.

On MOR, a screen of pending calls that never connect means Asterisk is past its load. Set maxload in /etc/asterisk/asterisk.conf to the number of cores, or lower, and restart Asterisk. Read high Asterisk CPU before that restart. A flood is one cause. A stuck query, a full disk, or qualify traffic is another, and the restart hides which one you had.

On M4, destination DDoS protection is a per-number call-burst limit in /etc/m2/system.conf. It ships off (dst_ddos_check_enabled = 0). Turn it on and M4 blocks a destination after Y attempts inside Z seconds, then holds the block for X seconds. The defaults are 10 attempts, a 60-second window, and a 60-second block. The block can cover every user, or a profile can name user ids (up to 99 profiles). A profile can also leave the check off for a dialer whose retries are real traffic. The CDR shows hangup cause 385, “Destination number temporarily blocked (DDoS protection).” That cap stops setup toward one number. It does not filter the uplink.

Failover has to move while the service is degraded

Ringotel’s regions never went dark, so the automatic move never ran. The move staff made by hand then failed for customers whose firewall allowed one address.

Publish the secondary SIP addresses before you need them. A move to an address their firewall drops looks like a second outage. Test the move while SIP is slow, not after you power a server off. If failover waits for a dead peer, the pair stays put while SIP is slow. That is the state Ringotel was in.

High availability, redundancy, and failover separates an automatic failover from a switchover you start by hand. Read it before you tell customers the second server takes over on its own.

Two servers, two addresses

A competitor can sign up as a customer, learn the SIP address you hand them, and send a DDoS at that address. If your trusted clients use that same address, the flood hits them too.

Run two servers and two addresses. One address is for new customers. Every new signup registers there and sends traffic there. All of them share that one address. The other address is for trusted clients. A new signup does not receive it.

After some time, once you have decided a signup is a real customer, move that customer to the trusted-client server. Until the move, an attack that follows a signup takes the new-customer server down. The trusted clients stay up.

A second address in the same prefix still goes down with that prefix. VirtualGlobalPhone’s flood covered every address they announced. Put the new-customer server on a different prefix, and on a different upstream if you have one.

The first hour

1. Read the port graph and open a ticket with the host. If the pipe is full, or the host says the attack is upstream of your edge, stop editing the switch. Blackhole routing of one address fails when the attack covers the whole prefix.
2. If the graph has room, sample User-Agent values and the REGISTER and INVITE rate. Confirm the scanner list is on. Add a name you see in the log if it is missing. Wait 15 minutes, or run the block-scanners script.
3. Block addresses and subnets you can name. Use Blocked Countries when the sources sit in countries you do not serve. Leave the emergency allow in place. A carrier address can still surprise you, because the country list is not exact.
4. Open active calls. A pile of pending calls on MOR is the maxload case. Set it to the core count. Use the CPU article before you restart.
5. Put a CPS cap on the device, provider, origination point, or termination point that is sending the storm.
6. If one destination is the target on M4, enable the per-number burst and watch for hangup cause 385. Tell that customer the number is blocked for the reject window. This does nothing to a network flood.
7. Move traffic to addresses those customers already allow. If the secondary address is missing from their firewall, add it first. Otherwise the move is a second outage.

Ask the host this, before an extortion mail shows up:

• Does detection stay on all the time, or start after someone notices?
• Does filtering sit on your side of the port we pay for, or upstream of it?
• Do you scrub UDP 5060 and our RTP range, or volumetric and protocol floods such as SYN, DNS, and NTP?
• Each source stays small and the sum covers the whole prefix. Do you still mitigate?
• Does a blackhole of one address leave the rest of the prefix reachable?
• What size is the port today, and what is the next size? A larger port adds room for good traffic. It does not end the attack.
• Who do we call in the first 15 minutes, and how do you notify us?
• Can a filtering network take the prefix on short notice?

Set the durable pieces on a quiet day. Leave the scanner rules on. Block countries you do not serve, and know what the emergency allow keeps open. Put CPS caps on dialer customers before a campaign. Decide the M4 per-number burst in advance, with a profile for a user whose retries are legitimate. Put secondary SIP addresses on customer firewalls now. Point new customers at the new-customer server, and move one to the trusted-client server only after you have decided they are real. If the GUI sits behind a web proxy, give that proxy its own domain and leave SIP on the address. The longer checklist for passwords, open ports, and who may send you SIP is PBX security best practices.

FAQ

Can MOR or M4 stop a DDoS?

They can limit a SIP flood that reaches the server: scanner User-Agents, country lists, named addresses, CPS, Asterisk maxload on MOR, and a per-number burst on M4. They cannot clear a saturated uplink. There is no guaranteed way to stop a targeted DDoS.

Does a Cloudflare proxy on the GUI protect SIP?

It protects HTTP and HTTPS when people open the GUI by the domain. It does not protect SIP. That domain cannot carry SIP as well. An attacker who knows the server IP bypasses the proxy.

Is destination DDoS protection network mitigation?

On M4 it blocks one destination number after too many attempts in a window. The default is 10 attempts in 60 seconds, then a 60-second block, and the CDR shows hangup cause 385. The uplink is untouched.

Do customers need the secondary address before a failover?

Ringotel moved regions by hand, and customers who had allowed one IP could not connect. Put both addresses on the customer firewall while the primary path is healthy.

Which SIP address does a new signup get?

The one address on the new-customer server. Every new signup uses that same address. The trusted-client address stays off that account until you move them. A second address in the same prefix can still go down with the rest of the prefix.

Set the control that matches the layer you measured

A full pipe goes to the host. A SIP flood that reaches the server goes to scanner rules, Blocked IPs, a CPS cap, and on M4 the per-number burst. If you want those call controls checked on the MOR or M4 you already run, open a ticket at support.kolmisoft.com.