Production ASTPP hardening: steps we always recommend before going live

Over the years of deploying ASTPP across different environments, we have noticed that most security incidents happen not because of platform bugs, but because of skipped basics during setup.

Here are the steps we always recommend before any production ASTPP deployment:

Fail2ban - configure it for both the web portal and FreeSWITCH SIP traffic. The default ASTPP installation includes a basic setup but it needs to be reviewed for your specific environment.

Event socket password - change the default FreeSWITCH event socket password immediately. Leaving it as the default is a common mistake that exposes the switch internally.

Admin portal access restriction - limit access to the admin panel by IP using Nginx or firewall rules. There is no reason the portal should be publicly reachable from every IP.

SIP port - avoid running FreeSWITCH on the default 5060 port in production if possible. It significantly reduces automated SIP scanning noise.

Strong password policy - CE v7 will enforce this at the platform level. Until then, enforce it manually during customer onboarding.

If you are running a multi-server or cluster setup, network segmentation between nodes adds another meaningful layer.

Feel free to add anything your team does that is not on this list.

I use this on the server

Though there is this also available

Would you be able to share a bit more about your setup? For example how you have integrated APIBAN with ASTPP or FreeSWITCH, and whether you are using any automation to keep the blocklist updated. Any configuration steps or references you found useful would be great to share here for the community.

API ban works with IPtables or firewalld. It runs a script which checks in with home to see what IP addresses are still banned. IP addresses are not permabanned, but you can use an APIban cli to tell it to permaban an IP address. It just blocks IP addresses based on behavior when the IP address gets banned on honeypots

1 Like