چطور SIP Trunk را در ۲۰۲۶ امن کنیم؟ جلوگیری از Toll Fraud و سوءاستفاده

امنیت SIP Trunk فقط به داشتن یک Password قوی خلاصه نمی‌شود. اگر PBX یا SBC به اینترنت وصل است، مهاجم می‌تواند از چند مسیر مختلف سوءاستفاده کند: حدس Credential، جعل Source، سوءاستفاده از مسیرهای بین‌المللی، Call Forwarding غیرمجاز، Flood روی SIP، سرقت Credential از پنل مدیریت و در نهایت Toll Fraud؛ یعنی برقراری تماس‌های پرهزینه با هزینه شما.

در یک طراحی امن، باید چند لایه هم‌زمان داشته باشید: ACL، احراز هویت قوی، TLS/SRTP، محدودیت مقصد و هزینه، Dialplan ایمن، Rate Limit، Fail2Ban و مانیتورینگ CDR. اگر یکی از این لایه‌ها شکست بخورد، لایه بعدی باید جلوی خسارت را بگیرد.

این راهنما برای Asterisk/PJSIP نوشته شده، اما اصول آن برای FreePBX، FusionPBX، VitalPBX و بیشتر SIP Trunkها یکسان است. تمرکز مقاله روی دفاع و کاهش ریسک است، نه صرفاً مخفی‌کردن Port 5060.

Toll Fraud چیست و چرا SIP Trunk هدف جذابی است؟

Toll Fraud یعنی مهاجم از PBX، Trunk یا حساب Voice شما برای برقراری تماس غیرمجاز ــ معمولاً به مقصدهای پرهزینه ــ استفاده کند. Providerها این سناریو را یکی از رایج‌ترین ریسک‌های PBX هک‌شده می‌دانند؛ چون مهاجم بعد از دسترسی می‌تواند تماس خارجی بسازد، Call Forwarding را عوض کند یا مسیر تماس را به مقصدهای گران هدایت کند.

مشکل اصلی این است که اگر Provider تماس را معتبر تشخیص دهد، هزینه معمولاً روی حساب شما ثبت می‌شود. بنابراین هدف امنیت SIP فقط جلوگیری از Login غیرمجاز نیست؛ باید دامنه خسارت را هم محدود کنید.

لایه ۱: ACL؛ Provider را فقط از IPهای واقعی خودش بپذیرید

اگر Provider فهرست IPهای ثابت برای Signaling دارد، بهترین حالت این است که Trunk ورودی فقط از همان IPها پذیرفته شود. Asterisk در res_pjsip_acl امکان permit و deny روی IP و همچنین ACL روی Contact را فراهم می‌کند.

نمونه ACL:

[provider-acl]
type=acl
deny=0.0.0.0/0.0.0.0
permit=203.0.113.10/32
permit=203.0.113.11/32

سپس ACL را به Endpoint مرتبط کنید:

[provider]
type=endpoint
aors=provider
acl=provider-acl
context=from-provider

برای Trunkهایی که بر اساس Source IP شناسایی می‌شوند، identify هم می‌تواند Endpoint را به IP مشخص Provider متصل کند:

[provider-identify]
type=identify
endpoint=provider
match=203.0.113.10
match=203.0.113.11

لایه ۲: احراز هویت قوی؛ از Credential مشترک و ساده دوری کنید

اگر Trunk یا داخلی به Digest Authentication نیاز دارد، Credential باید طولانی، تصادفی و اختصاصی باشد. Password مشترک بین چند Trunk یا چند داخلی، دامنه حمله را بزرگ می‌کند.

در نسخه‌های جدید Asterisk/PJSIP، علاوه بر MD5، الگوریتم‌های Digest قوی‌تر SHA-256 و SHA-512-256 نیز با PJProject و OpenSSL مناسب پشتیبانی می‌شوند. Asterisk این قابلیت را از نسخه‌های 20.12.0، 21.7.0 و 22.2.0 به بعد مستند کرده است.

برای دیدن الگوریتم‌های قابل‌استفاده روی سیستم:

asterisk -rx "pjproject show buildopts"

نمونه Auth Object:

[provider-auth]
type=auth
auth_type=userpass
username=TRUNK_ACCOUNT
password=USE_A_LONG_RANDOM_SECRET

اگر Provider و تجهیزات شما SHA-256 یا SHA-512-256 را پشتیبانی می‌کنند، از الگوریتم قوی‌تر استفاده کنید. RFC 8760 نیز SIP Digest را برای الگوریتم‌های جدیدتر به‌روزرسانی کرده و MD5 را انتخاب ضعیف‌تری می‌داند.

لایه ۳: TLS برای Signaling و SRTP برای Media

Digest Authentication به‌تنهایی محرمانگی Signaling ایجاد نمی‌کند. RFC 3261 صراحتاً می‌گوید Digest Message Confidentiality یا Integrity کامل فراهم نمی‌کند. اگر Provider Secure Trunking دارد، SIP را روی TLS ببرید.

معماری امن‌تر:

PBX / SBC
   |
   | SIP over TLS
   v
Provider

Media:
PBX / SBC
   |
   | SRTP
   v
Provider

Providerهایی مثل Twilio برای Secure Trunking از TLS برای Signaling و SRTP برای Media استفاده می‌کنند و در مستند فعلی خود TLS 1.2 و بالاتر را پشتیبانی می‌کنند.

نمونه Transport در PJSIP:

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061

cert_file=/etc/asterisk/keys/fullchain.pem
priv_key_file=/etc/asterisk/keys/privkey.pem
method=tlsv1_2

تنظیم دقیق TLS باید با نسخه Asterisk و Provider شما تطبیق داده شود. Certificate معتبر، Chain کامل و زمان سیستم را هم بررسی کنید.

لایه ۴: Dialplan را طوری طراحی کنید که Trunk ورودی به تماس پرهزینه دسترسی نداشته باشد

یکی از مهم‌ترین توصیه‌های رسمی Asterisk این است که Context ورودی را از Context تماس‌های Outbound و Toll جدا کنید. اگر یک Trunk یا Channel ورودی وارد Contextی شود که Route بین‌الملل یا تماس پولی را دارد، یک اشتباه کوچک می‌تواند تبدیل به Toll Fraud شود.

نمونه طراحی:

[from-provider]
; only inbound DID routing
exten => 02100000000,1,Goto(internal,100,1)

[internal]
; internal extensions only
include => local-calls

[trusted-outbound]
; restricted outbound routes only
include => national-calls
include => international-approved

Context ورودی Provider نباید مستقیم به Routeهای بین‌المللی، Premium یا Dialplan عمومی دسترسی داشته باشد.

لایه ۵: مسیرهای بین‌المللی و Premium را Default باز نگذارید

یکی از مؤثرترین کنترل‌های ضد Toll Fraud این است که کشورها و Rangeهایی را که واقعاً نیاز ندارید ببندید. Providerهایی مثل Twilio Geo Permissions را برای همین هدف ارائه می‌کنند و توصیه می‌کنند فقط مقصدهای لازم فعال باشند.

این محدودیت را بهتر است در دو جا اعمال کنید: هم در Dialplan/PBX و هم در پنل Provider. اگر یکی اشتباه شد، دیگری جلوی خسارت را بگیرد.

لایه ۶: سقف تماس، CPS، مدت و هزینه تعیین کنید

مهاجم معمولاً برای سود بیشتر سعی می‌کند تماس‌های زیاد، طولانی یا هم‌زمان بسازد. بنابراین محدودیت عملیاتی مهم‌تر از چیزی است که به نظر می‌رسد.

اگر Provider Usage Trigger یا Spending Alert دارد، آن را فعال کنید. یک Alert مالی در سطح Provider می‌تواند حتی وقتی PBX شما Compromise شده است هشدار بدهد.

لایه ۷: CDR Anomaly؛ قبل از صورتحساب بزرگ، رفتار غیرعادی را ببینید

CDR فقط گزارش مالی نیست؛ یک منبع تشخیص تقلب است. باید Baseline رفتار عادی کسب‌وکار را بدانید و تغییرهای غیرعادی را Alert کنید.

مواردی که ارزش Alert دارند:

یک Query ساده مفهومی برای شناسایی افزایش تماس یک داخلی:

SELECT
    src,
    COUNT(*) AS calls,
    SUM(billsec) AS total_seconds
FROM cdr
WHERE calldate >= NOW() - INTERVAL 1 HOUR
GROUP BY src
ORDER BY calls DESC;

Threshold را بر اساس الگوی واقعی خودتان تعیین کنید؛ عدد ثابت برای همه کسب‌وکارها معنی ندارد.

یک مدل ساده برای Anomaly Score تماس‌ها

برای مانیتورینگ پیشرفته‌تر، به هر تماس یا بازه یک امتیاز ریسک بدهید:

risk_score =
    unusual_destination
  + unusual_time
  + high_call_rate
  + long_duration
  + new_forwarding_rule
  + repeated_auth_failures

هدف ساخت AI پیچیده نیست. حتی Ruleهای ساده می‌توانند حمله‌ای را که ساعت ۳ صبح با تماس‌های هم‌زمان به کشور جدید شروع شده تشخیص دهند.

لایه ۸: Fail2Ban؛ جلوی تکرار Authentication Failure را بگیرید

Fail2Ban جای ACL و Auth نیست، اما برای IPهایی که پشت سر هم Authentication Failure تولید می‌کنند لایه دفاعی مفیدی است. پروژه رسمی Fail2Ban یک Filter مخصوص Asterisk دارد که پیام‌هایی مثل Wrong Password، Username Mismatch، No Matching Peer و ACL Error را تشخیص می‌دهد.

ابتدا بررسی کنید Filter رسمی روی سیستم شما وجود دارد:

ls -l /etc/fail2ban/filter.d/asterisk.conf

نمونه Jail:

[asterisk]
enabled = true
filter = asterisk

logpath = /var/log/asterisk/messages

findtime = 600
maxretry = 5
bantime = 3600

بعد از تغییر:

fail2ban-client reload
fail2ban-client status asterisk

Fail2Ban را جای Rate Limit نگذارید

Fail2Ban معمولاً بعد از ثبت چند Failure واکنش نشان می‌دهد. برای Flood یا Scan سریع، Firewall یا SBC باید Rate Limit زودتری اعمال کند.

لایه‌های پیشنهادی:

Internet
   |
Firewall / ACL
   |
Rate Limit
   |
SBC / PJSIP
   |
Authentication
   |
Fail2Ban reacts to repeated failures

لایه ۹: پنل مدیریت PBX را از SIP جدا کنید

خیلی از Toll Fraudها از خود SIP شروع نمی‌شوند؛ مهاجم پنل مدیریت، SSH یا Credential مدیر را به دست می‌آورد و Routeها را تغییر می‌دهد.

لایه ۱۰: Caller ID و Call Forwarding را محدود کنید

مهاجم بعد از دسترسی ممکن است به‌جای تماس مستقیم، Call Forwarding را به مقصد خارجی بگذارد. بنابراین Forwarding و Caller ID باید Policy جدا داشته باشند.

لایه ۱۱: Provider-side Alertها را فعال کنید

کنترل فقط روی PBX کافی نیست. اگر Provider امکانات زیر را دارد، از آن‌ها استفاده کنید:

Twilio در راهنمای ضد تقلب خود پیشنهاد می‌کند برای SIP Trunk از IP Allow List همراه Credential استفاده شود، TLS/SRTP فعال باشد و Alert روی خطاهای مشکوک SIP ساخته شود.

اگر احتمال Toll Fraud دادیم، چه کار کنیم؟

در Incident واقعی اول Containment مهم است، نه تحلیل طولانی.

اگر فقط Password را عوض کنید ولی Route مخرب یا Credential مدیریتی همچنان باقی باشد، حمله می‌تواند ادامه پیدا کند.

چک‌لیست امنیت SIP Trunk

پرسش‌های رایج

Toll Fraud در SIP Trunk چیست؟

استفاده غیرمجاز از PBX یا Trunk برای برقراری تماس‌های پولی یا پرهزینه است. این حمله می‌تواند از Credential ضعیف، پنل هک‌شده، Call Forwarding یا Dialplan ناامن شروع شود.

آیا Password قوی به‌تنهایی کافی است؟

خیر. ACL، TLS، محدودیت مقصد، Dialplan امن، Fraud Limit و مانیتورینگ باید کنار Authentication باشند.

آیا Asterisk از SHA-256 برای SIP Digest پشتیبانی می‌کند؟

بله، در نسخه‌های جدید PJSIP با PJProject و OpenSSL مناسب، SHA-256 و SHA-512-256 علاوه بر MD5 پشتیبانی می‌شوند.

TLS چه مشکلی را حل می‌کند؟

TLS Signaling را در مسیر شبکه رمزنگاری می‌کند. Digest Authentication به‌تنهایی محرمانگی Signaling را فراهم نمی‌کند.

چرا مسیر بین‌الملل باید Default بسته باشد؟

چون Toll Fraud معمولاً از مقصدهای پرهزینه استفاده می‌کند. اگر کسب‌وکار به کشوری تماس ندارد، بازبودن آن Route فقط سطح خسارت را افزایش می‌دهد.

Fail2Ban جلوی Toll Fraud را می‌گیرد؟

به‌تنهایی نه. Fail2Ban IPهای دارای Authentication Failure تکراری را Block می‌کند، اما اگر Credential از قبل سرقت شده باشد یا مهاجم از IP مجاز وارد شود، کنترل‌های دیگری لازم‌اند.

CDR چگونه تقلب را نشان می‌دهد؟

با پیدا کردن الگوهای غیرعادی مثل تماس شبانه، مقصد جدید، جهش تعداد تماس، مدت غیرعادی و تماس‌های هم‌زمان زیاد.

اگر Toll Fraud در حال وقوع باشد اول چه کنیم؟

ابتدا Routeهای پرریسک را ببندید، Provider را مطلع کنید، Credentialها را Rotate کنید و Log/CDR را حفظ کنید؛ بعد Scope نفوذ را بررسی کنید.