Your VoIP Server Won't Get Hacked Overnight. It'll Get Scanned in Minutes.

If this showed up in your feed, take it as a sign to read it to the end — because if you’re running anything on a public IP, this is going to happen to you too. The only question is whether you’ll be ready when it does.

I bought an IP-based SIP trunk from Nayatel and wired it into my own Asterisk server. The config was clean. My first test call connected on the first try. I went to bed feeling like a genius.

By morning, I couldn’t make a single call. Not one. Incoming, outgoing — dead. And the trunk still showed as up.

That gap between "everything works" and "nothing works," with no warning in between, is exactly where most people get caught. So let’s walk through every part of it — what was attacking me, why it worked, how I stopped it, and the uncomfortable truth about the fix everyone reaches for first.

The thing nobody warns you about#

When I opened the logs, my stomach dropped. A relentless flood of SIP requests was pouring in from random IP addresses all over the world. None of them were mine. None of them were Nayatel’s. (Tell me in the comments — what’s the fastest your server has ever gotten scanned after going live?)

Here’s the part most beginners don’t know: this isn’t rare, and it isn’t personal. The internet is swept around the clock by automated bots — tools with names like SIPVicious and "friendly-scanner" — hunting for anything listening on UDP port 5060, the default SIP port. The moment your server appears on a public IP, it gets found. Not in days. In minutes.

Once they find you, they hammer the door with OPTIONS, REGISTER, and INVITE requests, trying to do one of three things:

• Enumerate your server — confirm you’re a real PBX and find your extensions.
• Brute-force your credentials to register a fake endpoint.
• Commit toll fraud — get inside and dial expensive international or premium-rate numbers on your bill.

The twist: nobody actually got in#

Here’s what makes this story interesting. My trunk authenticated by IP address. Nayatel only accepted my server’s IP, and my Asterisk only trusted Nayatel’s. So none of those thousands of attackers could ever authenticate. Not one of them could place a call.

And it didn’t matter.

Because the attack was never a break-in. It was a denial of service. The sheer volume of junk packets drowned the trunk. My server was so busy parsing and replying to bogus requests that it had no CPU or bandwidth left for real calls. The attackers didn’t need a key to the building — they just needed to crowd the doorway so nobody else could get through.

One attacker breaks the lock to get inside. Another just stands in the doorway so no one else can enter.

The second one doesn’t need to be clever. It only needs to be loud. And it was working perfectly.

How fail2ban brought me back#

The tool that rescued me was fail2ban. It’s simple in concept: it watches your logs and tells your firewall who to block.

The chain looks like this:

• Asterisk writes every failed auth and malformed request to its log.
• A fail2ban "jail" watches that log using a filter that recognizes the attack signature.
• When one IP trips the pattern too many times, fail2ban drops a firewall rule that bans all traffic from it.

The magic is where the block happens. Once an IP is dropped at the firewall, the kernel throws its packets away before they ever reach Asterisk. My server instantly stopped wasting itself on attackers, the trunk cleared, and my calls came back within minutes.

The uncomfortable truth: fail2ban was never the real fix#

This is where most tutorials stop, and where they fail you. fail2ban is a great layer, but be honest about what it is:

• It’s reactive. It only bans an IP after that IP has already flooded you enough to be noticed. Some attack always gets through first.
• It depends on log parsing. Misconfigure logging, or face an attack whose signature doesn’t match the filter, and it misses entirely.
• It doesn’t scale. Banning one IP at a time can’t keep up with an attack spread across thousands of addresses.

Treating fail2ban as your whole strategy is like treating a smoke alarm as fire safety. It’s essential — but it tells you the house is already burning. The real work is making the house hard to set alight.

For my situation, there was a far stronger fix sitting right in front of me.

The real fix for an IP-based trunk#

Here’s the cleanest principle I can give you, and it changes everything once it clicks:

If you already know the only address that should ever talk to you, then everyone else is, by definition, an attacker.

My trunk was IP-based. I knew the only IP that should ever reach my SIP port — Nayatel’s gateway. So the strongest move isn’t to catch bad traffic after it arrives. It’s to never let it arrive at all.

A firewall allowlist: default-DROP on the SIP port and the RTP media range, then ACCEPT only from Nayatel and my own internal endpoints. That single rule blocks 100% of the random scanners before they touch Asterisk. No log parsing. No delay. No scaling problem. fail2ban’s job shrinks to mopping up the rare thing that sneaks in elsewhere.

Stack a few more layers behind it, strongest first:

• Harden Asterisk — disable guest/anonymous calls and move off the deprecated chan_sip to PJSIP.
• Move SIP off port 5060 — pure obscurity, but it silences a huge share of dumb scanners.
• Rate-limit at the firewall so even a permitted source can’t flood you.
• Restrict international dialing in your dialplan to cap the damage if anything ever slips through.
• Add an SBC (Kamailio or OpenSIPS) once you outgrow a single box — it scrubs and rate-limits at scale.

When it’s username and password, the game gets harder#

The moment you switch from IP authentication to credentials, the whole threat model changes — and gets scarier. Now a successful brute-force isn’t just noise. It’s a real breach, and it ends in toll fraud and a phone bill that can hit five figures overnight.

And here’s the cruel part: you usually go credential-based because your endpoints come from unpredictable IPs — softphones, mobile apps, remote workers on dynamic home connections. Which means the firewall allowlist that saved me on the IP trunk often isn’t available to you. You lose your best weapon exactly when the stakes go up.

So you compensate with discipline:

• Never let the username equal the extension number. If extension 1001 uses username 1001, you’ve handed the attacker half the credential for free.
• Use long, random, unique passwords — 16+ characters, generated, never human-chosen. A scanner cracks 1234 in minutes; a 20-character random string, effectively never.
• Disable anonymous calls and set alwaysreject=yes so a wrong username and a wrong password look identical — otherwise attackers can map which accounts actually exist and focus their fire.
• Tune fail2ban aggressively here — a low maxretry, a short window, and a long, escalating ban. With no allowlist, this is now a primary defense, not a backup.
• Use TLS and SRTP so your passwords never travel the network in cleartext.

The layer nobody sets up until it’s too late#

Here’s the mindset that separates people who get burned from people who shrug off a breach: assume a credential will eventually leak, and make sure it doesn’t cost you anything when it does.

This is the cheapest insurance in the entire stack, and it’s the one people skip:

• Restrict international and premium-rate dialing in your dialplan by default. Almost all toll fraud targets a small set of expensive number ranges. Block them, and a stolen credential becomes worthless.
• Set a spending cap and fraud alerts with your provider — ask Nayatel exactly what they offer.
• Limit concurrent calls per account so a hijacked extension can’t fan out into dozens of simultaneous fraud calls.
• Monitor for the weird stuff — call spikes, 3am traffic, sudden international dialing. Fraud happens fast and at odd hours; catching it early is the difference between an annoyance and a disaster.

Today it feels unnecessary because nothing has gone wrong yet. But the real question is the same one I ask about any system: if your worst-case happened tonight, would it cost you ten minutes or ten thousand dollars? If you don’t know the answer, you haven’t built this layer.

What actually keeps you safe#

Tools change. Attack scripts change. fail2ban will get patched, Asterisk will get new versions, the scanners will get smarter. The one thing that stays valuable through all of it is the way you think about defense.

Security was never about finding the one magic tool. It’s defense in depth — layers, where each one catches what the others miss:

Firewall allowlist → hardened Asterisk → rate limiting → fail2ban → dialplan restrictions.

A flooded trunk taught me that the loudest threat isn’t always the one that breaks in — sometimes it’s the one that just won’t leave. fail2ban got me through the night. But understanding why I was vulnerable in the first place is what actually keeps the lights on.

So if you’re about to put a SIP server on a public IP: lock the front door before you go to bed, not after you wake up to silence. And that friend who just spun up a PBX on a cloud VM with port 5060 wide open and a password like admin123? Send this their way before the bots do.