Your Firewall Passed. Your Balance Didn’t.

You open Fail2Ban in the morning and the jail is quiet. Registrations succeeded. Last Calls shows a customer you know, on destinations you do not sell, for hours you were asleep. The prepaid wallet is empty, or a postpaid account with unlimited credit spent the night on satellite and premium-rate prefixes.

Edge tools catch failed REGISTER storms, SIPVicious User-Agents, hangup cause 200 from unknown sources. That layer is in SIP Attack: Friendly-Scanner and PBX Security Best Practices. The caller had working SIP credentials, so the session looked like a customer. You need money controls inside the softswitch so that session cannot empty the wallet.

Why the firewall stayed quiet

Someone owns a customer PBX, a softphone, or a stolen SIP password. Calls register as that user. Edge rules that allow known accounts let them through. Traffic goes to premium, satellite, pumping NPAs, or international routes you forgot to close. You discover it when prepaid balances vanish, or when the upstream bill arrives.

If you stop after layer 1, a locked firewall can still produce an invoice.

Cause 1: the account looks legitimate

A customer device or a valid SIP password is in someone else’s hands. From the switch, the INVITEs match a Device. Fail2Ban has nothing to ban.

Open Last Calls and Call Info. The source IP belongs to a customer you know, or the username matches. Destinations, duration, and simultaneous legs do not. Night and holiday windows show first, the same after-hours pattern the PBX security post flags.

Disable the user. Drop anything still up in Active Calls. Rotate SIP credentials. Reopen with a lower credit and with high-cost prefixes blocked. Treat the customer PBX as compromised.

Cause 2: postpaid with no ceiling

The user is postpaid, credit unlimited, no Daily Balance Limit. Rating happens when the CDR lands. Unlimited postpaid credit is documented as risky on Balance and Credit: the user originates without a debt cap, and the invoice collects later. User Details shows that mix. CDRs for the window exist. Nothing dropped the live calls.

New and untrusted accounts start prepaid, or postpaid with a low credit. Wiki example: credit 10 USD, balance allowed down to -10 USD, then origination stops. Raise the limit after traffic looks normal for a few weeks. Set a Daily Balance Limit: MOR checks it every second, drops ongoing calls at the cap, rejects new ones with hangup cause 290, and resets at midnight. Put the warning threshold below the cap.

Prepaid is a different contract. Prepaid Logic (from MOR X5) checks balance every few seconds and ends live calls when the balance nears zero. Credit on prepaid is always zero. Warning Balance email and the optional admin webhook fire on a check that runs once an hour. Use them before the wallet is empty. They do not cut the live call. If you cannot answer “does the platform kill an in-progress call when policy says stop?”, unlimited postpaid credit is the exposure.

Cause 3: high-cost destinations still open

Stolen accounts go where the margin is: premium-rate, satellite, cruise-ship, countries you never sell. Cheap LCR to a poisoned prefix is a loss.

Filter Last Calls by the user and sort by destination or price. Hangup cause 269 means Max Call rate blocked a prefix that was too expensive. If those calls completed, Max Call rate is 0 (no cap) or the tariff still prices the destination.

Block prefixes you do not sell. Block some Destination to User: empty LCR on the prefix, or wholesale tariff rate -1 / Blocked. Set Max Call rate so a high per-minute destination never starts.

Blocked Countries is iptables on source IPs (who may reach the server). It is not a dial-plan for where money can go. Use it for markets you do not serve. Use destination blocks for prefixes you do not sell.

Cause 4: alerts that stop at email

Dashboards sit unread at 03:00. An email lands in a folder and the calls keep running.

Open ADDONS → Monitorings → Alerts (this needs the Monitorings Addon, which is optional). If Alerts exist, check whether Disable Object is on, and whether Notify On Alert via Webhook is on. Email with Disable Object off notifies. It does not stop the account.

Configure alerts that disable the user or change LCR. Wiki examples on Alerts:

• PRICE SUM: Object Type User, spend ≥ 50 EUR in 24 hours, Disable Object, Disable Clear.
• SIMULTANEOUS CALLS: Object Type User, ≥ 2 parallel legs, Disable Object, Disable Clear.

Watch TOTAL CALLS on prepaid users and ASR/ACD/PDD on providers. A GROUP alert can fire when two other alerts are both raised.

Push the signal out of the GUI. Alert/Clear webhooks POST JSON to Slack, PagerDuty, or NOC tooling so an incident opens and closes with the fraud window. Payload and setup: Webhooks in MOR and M4.

Prevention: money-first before volume

Do this before you point real customers at a new server or a new account:

1. Default low credit or prepaid on every new account. No unlimited postpaid credit.
2. Daily Balance Limit on untrusted users, with a warning threshold below the cap.
3. Two alerts with Disable Object: 24h PRICE SUM, and unexpected simultaneous calls.
4. Block destination prefixes outside your market. Set Max Call rate on new users.
5. Hook alert webhooks to whoever wakes up at night.
6. Then put volume on the system.

SIP not world-open, Fail2Ban on, strong passwords: do those first (the older posts). Skip the money steps and “we will harden billing later” becomes a weekend invoice.

When spend is on the wire

Write the runbook before the first incident. Incidents cluster on nights and holidays.

1. Disable the user. Block the source IP if it is hostile.
2. Open Active Calls and drop anything still burning.
3. Export CDRs for the window. You will need them for upstream disputes.
4. Rotate SIP credentials for that account.
5. Reopen with a lower limit and with the destination blocks in place.

How this maps on MOR

Ask any vendor, including us, three questions before production traffic:

1. Can you cut a live call when balance or policy says stop?
2. Can you disable a user on spend or simultaneous-call thresholds without waiting for a human?
3. Can those alerts leave the box via webhook, not only inbox?

FAQ

Why did Fail2Ban miss this?

Fail2Ban watches failed registrations, scanner User-Agents, and unidentified callers. A stolen password produces successful REGISTER and INVITE. Layer 2 has to cap the account that authenticated.

Is this FAS or STIR/SHAKEN?

False Answer Supervision is a supplier billing the wrong duration. STIR/SHAKEN in MOR is Caller ID attestation for US termination. This post is unbounded spend on an account that looks like a customer. Terms: VoIP Business Glossary.

Do I need the Monitorings Addon?

Live cut-off is core: prepaid checks, postpaid credit, Daily Balance Limit. The addon auto-disables a user on spend or simultaneous calls and webhooks that event into ops. High-risk wholesale edges need an SBC in front of the switch.

Check layer 2 before the next new IP

Layer 1 keeps scanners noisy and unpaid when REGISTER fails. Layer 2 decides whether a valid account can still bankrupt you. Layer 3 decides whether a human hears about it while the calls are still up. If the firewall is fine and the balance is not, you are missing layer 2.

Open the MOR online demo and walk User Details (credit, Daily Balance Limit, Warning Balance) plus, if the addon is on the demo, ADDONS → Monitorings → Alerts with Disable Object. The demo is the admin UI; it does not place live calls.