A collection of practical advice for running the CloudSOE Asterisk image in production, on either cloud.
Working with the fail2ban jail
The image ships an armed jail (5 failures in 10 minutes → 1 hour ban, escalating to 1 week for repeat offenders). Day-to-day commands:
sudo fail2ban-client status asterisk # jail status + banned IPs
sudo fail2ban-client set asterisk unbanip <ip> # release an IP
sudo fail2ban-client set asterisk banip <ip> # ban one manually
sudo fail2ban-client set asterisk addignoreip <ip> # whitelist (until restart)
Ban activity is logged in /var/log/fail2ban.log. To whitelist permanently, add an ignoreip line to /etc/fail2ban/jail.d/asterisk.local and restart fail2ban.
Don’t lock yourself out: whitelist your admin IP before testing registrations with wrong credentials. If you do get banned, the cloud serial console (EC2 serial console / Azure serial console) gets you in without SSH.
Toll fraud is the real threat
A compromised Asterisk box is monetised by pumping calls to premium-rate numbers, usually at 3 a.m. on a Sunday:
- Restrict 5060 to your trunk provider’s and phones’ IP ranges — fail2ban slows attackers down; source-IP restrictions stop them.
- Long random passwords on every endpoint; never
1234. - Don’t build dialplan contexts that let unauthenticated callers reach outbound trunks.
- Ask your trunk provider for spend caps and premium-prefix blocking.
One-way or no audio on calls
The classic cloud symptom, almost always one of:
- NAT not configured —
external_media_address/external_signaling_address/local_netmissing on the transport (see the configuration guide). - RTP range closed —
10000–20000UDP missing from the security group / NSG (on Azure, check the rule is actually UDP). - Changed public IP — new Elastic IP / public IP, but
pjsip.confstill holds the old address.
Watch it live: sudo asterisk -rvvv, then pjsip set logger on to trace SIP, and rtp set debug on to see whether media flows. Turn both off afterwards.
Watch what the scanners are doing
Within hours of opening 5060 to the world you’ll see probes. Two views:
sudo tail -f /var/log/asterisk/security # auth failures as Asterisk sees them
sudo tail -f /var/log/fail2ban.log # bans as fail2ban issues them
A busy security log with a quiet fail2ban log means attackers are staying under 5 attempts per 10 minutes per IP — tighten your NSG/security group source ranges instead of chasing them.
Back up the one directory that matters
Asterisk on this image is entirely defined by /etc/asterisk/:
sudo tar czf /home/$(whoami)/asterisk-etc-$(date +%F).tar.gz -C /etc asterisk
Ship it off the instance (S3, Azure Blob, anywhere). Add /var/spool/asterisk/ if you keep voicemail or recordings. Restoring onto a fresh instance of a newer image is just untarring and sudo systemctl restart asterisk.
Keep things updated
- Asterisk and fail2ban update from Ubuntu’s repositories:
sudo apt update && sudo apt upgradeon your own schedule. - For major version moves, launch a fresh instance from the latest CloudSOE image and restore
/etc/asterisk/rather than upgrading in place.
Troubleshooting first boot
systemctl status asterisk-firstboot
journalctl -u asterisk-firstboot --no-pager
First boot only fills the public IP into the login banner — Asterisk itself is installed at image-build time, so a first-boot hiccup never breaks telephony. If the banner shows a stale IP after you attach a new Elastic IP / public IP, edit /etc/motd (and remember to update your pjsip.conf NAT settings too — see the getting-started guides for AWS and Azure).