چرا FusionPBX داخلی‌ها را Ban می‌کند؟ رفع مشکل Fail2Ban بدون کاهش امنیت

Fail2Ban در FusionPBX دقیقاً چه کاری انجام می‌دهد؟

Fail2Ban فایل‌های Log را می‌خواند، الگوهای خطا را با Filterهای Regex تطبیق می‌دهد و اگر یک IP در بازه زمانی مشخص بیشتر از حد مجاز خطا ایجاد کند، Action مربوط به Jail اجرا می‌شود.

به زبان ساده:

FreeSWITCH / NGINX / SSH log
          |
          v
      Fail2Ban filter
          |
          v
maxretry failures inside findtime
          |
          v
         BAN
          |
          v
iptables / nftables action

در Installer رسمی FusionPBX، Fail2Ban از قبل نصب و پیکربندی می‌شود، اما خود پروژه نیز تأکید می‌کند تنظیمات پیش‌فرض ممکن است برای تمام معماری‌ها مناسب نباشند و باید بر اساس مدل امنیتی شما بازبینی شوند.

اول مشخص کنید واقعاً Fail2Ban شما را Ban کرده است

اگر یک IP خاص نمی‌تواند وارد پنل شود یا Phoneها از همان محل Register نمی‌شوند، مستقیم Config را تغییر ندهید. ابتدا سرویس و Jailها را ببینید.

وضعیت خود Fail2Ban:

systemctl status fail2ban
fail2ban-client ping
fail2ban-client status

خروجی fail2ban-client status نام Jailهای فعال را نشان می‌دهد. بعد Jail مشکوک را جدا ببینید:

fail2ban-client status freeswitch-ip
fail2ban-client status auth-challenge-ip
fail2ban-client status sip-auth-failure

در انتهای خروجی دنبال Banned IP list بگردید.

با Fail2Ban جدید می‌توانید خود IP را هم جست‌وجو کنید

در نسخه‌های جدید Fail2Ban، دستور زیر Jailهایی را که یک IP در آن‌ها Ban شده نشان می‌دهد:

fail2ban-client banned 198.51.100.25

اگر نسخه نصب‌شده این Subcommand را ندارد، همان status Jailهای فعال روش سازگارتری است.

کدام Jail در FusionPBX داخلی‌ها را Ban می‌کند؟

فایل فعلی Installer رسمی FusionPBX چند Jail مهم دارد. همه آن‌ها الزاماً فعال نیستند؛ بعضی برای افزایش امنیت باید دستی فعال شوند.

نکته بسیار مهم این است که Jailهای فعلی FusionPBX در فایل Installer از Action نوع iptables-allports استفاده می‌کنند. یعنی Ban می‌تواند روی تمام Portها اثر بگذارد، نه فقط 5060. به همین دلیل یک SIP Failure ممکن است از دید کاربر شبیه «کل VPS من را بسته» دیده شود.

چرا یک داخلی اشتباه می‌تواند کل دفتر را از FusionPBX قطع کند؟

فرض کنید ۲۰ تلفن در یک شرکت پشت مودم هستند و همه با یک Public IP به FusionPBX می‌رسند:

Phone 1001 ─┐
Phone 1002 ─┤
Phone 1003 ─┤
Phone 1004 ─┤
             ├─ NAT ─ 198.51.100.25 ─ Internet ─ FusionPBX
Phone 1019 ─┤
Phone 1020 ─┘

اگر فقط Phone 1007 رمز قدیمی داشته باشد و پشت‌سرهم Authentication Failure تولید کند، Fail2Ban IP داخلی آن Phone را نمی‌بیند؛ Source واقعی در اینترنت همان 198.51.100.25 است.

اگر Jail آن IP را Ban کند، تمام تلفن‌های آن دفتر از همان Public IP آسیب می‌بینند. اگر Action هم allports باشد، مدیر شرکت ممکن است هم‌زمان پنل وب یا SSH را نیز از همان محل از دست بدهد.

freeswitch-ip و auth-challenge-ip چرا این‌قدر حساس‌اند؟

در Jail فعلی Installer، هر دو Rule به‌صورت پیش‌فرض غیرفعال هستند، اما Documentation رسمی FusionPBX برای سخت‌ترکردن امنیت پیشنهاد می‌کند آن‌ها را فعال کنید.

تنظیم فعلی آن‌ها بسیار سخت‌گیرانه است:

[freeswitch-ip]
maxretry = 1
findtime = 60
bantime = 86400

[auth-challenge-ip]
maxretry = 1
findtime = 60
bantime = 86400

یعنی یک Match می‌تواند IP را برای یک روز Ban کند. این برای مقابله با Scannerهایی که مستقیم Public IP را هدف می‌گیرند مفید است، اما اگر Phoneهای قانونی شما به IP خام سرور Register شوند، ممکن است خودتان Trigger ایجاد کنید.

خود FusionPBX توصیه می‌کند Phoneها با FQDN رجیستر شوند، نه Public IP، چون بیشتر Scanهای خودکار Public IP را هدف می‌گیرند و Jailهای freeswitch-ip و auth-challenge-ip نیز برای همین مدل امنیتی طراحی شده‌اند.

مرحله ۱: IP Ban‌شده را بدون Restart کردن همه Fail2Ban آزاد کنید

اگر می‌دانید Jail کدام است، فقط همان IP را از همان Jail آزاد کنید:

fail2ban-client set auth-challenge-ip unbanip 198.51.100.25

یا برای Jail دیگر:

fail2ban-client set freeswitch-ip unbanip 198.51.100.25

در Fail2Ban جدید، اگر می‌خواهید IP از تمام Jailها Unban شود:

fail2ban-client unban 198.51.100.25

Restart کردن Fail2Ban برای Unban کردن یک IP راه‌حل خوبی نیست؛ چون ممکن است تمام Banهای مهاجمان واقعی را هم پاک کند.

مرحله ۲: قبل از Whitelist کردن، ببینید IP چرا Ban شده است

Log اصلی خود Fail2Ban:

grep "198.51.100.25" /var/log/fail2ban.log

ممکن است چیزی شبیه این ببینید:

Ban 198.51.100.25
Found 198.51.100.25
auth-challenge-ip

بعد به Log Source همان Jail بروید. برای Jailهای SIP/FreeSWITCH:

grep "198.51.100.25" /var/log/freeswitch/freeswitch.log | tail -n 50

برای پنل FusionPBX:

grep "198.51.100.25" /var/log/auth.log | tail -n 50

برای NGINX:

grep "198.51.100.25" /var/log/nginx/access.log | tail -n 50

مرحله ۳: Filter را با fail2ban-regex تست کنید

اگر یک IP قانونی مرتب Ban می‌شود، شاید Log واقعی با Regex Filter به شکلی Match می‌شود که انتظارش را نداشتید. قبل از تغییر maxretry، Filter را روی Log واقعی تست کنید.

برای جلوگیری از پردازش فایل بسیار بزرگ، نمونه کوچک بسازید:

tail -n 5000 /var/log/freeswitch/freeswitch.log > /tmp/freeswitch-sample.log

بعد Filter را تست کنید:

fail2ban-regex /tmp/freeswitch-sample.log /etc/fail2ban/filter.d/auth-challenge-ip.conf

این خروجی مشخص می‌کند چند خط Match شده و کدام IPها توسط Regex دیده شده‌اند.

مرحله ۴: IgnoreIP را امن طراحی کنید، نه گسترده

ignoreip به Fail2Ban می‌گوید یک IP یا Network را هیچ‌وقت Ban نکند. این ابزار بسیار مفید است، اما اگر اشتباه استفاده شود می‌تواند عملاً Brute-force را برای یک شبکه آزاد کند.

Fail2Ban به‌صورت رسمی IP، CIDR و FQDN را در ignoreip پشتیبانی می‌کند.

چه IPهایی مناسب Whitelist هستند؟

چه چیزهایی را Whitelist نکنیم؟

Global IgnoreIP یا فقط Jail مخصوص SIP؟

این تصمیم روی سطح امنیت اثر زیادی دارد.

اگر IP ثابت دفتر را در [DEFAULT] قرار دهید، Fail2Ban آن را در همه Jailها Ignore می‌کند؛ یعنی اگر Credential پنل FusionPBX از همان IP مورد حمله قرار بگیرد، Jail وب هم آن IP را Ban نخواهد کرد.

برای IP مدیریتی کاملاً قابل‌اعتماد، Global Ignore قابل‌قبول است:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 198.51.100.25

اما برای SIP Provider یا یک دفتر کار بهتر است Ignore را فقط روی Jailهای SIP موردنیاز اعمال کنید:

[freeswitch-ip]
ignoreip = 127.0.0.1/8 ::1 198.51.100.25

[auth-challenge-ip]
ignoreip = 127.0.0.1/8 ::1 198.51.100.25

[sip-auth-failure]
ignoreip = 127.0.0.1/8 ::1 198.51.100.25

با این روش همان IP هنوز در برابر SSH و Login Brute-force پنل محافظت می‌شود.

فایل تغییرات محلی را کجا بسازیم تا Upgrade امن‌تر باشد؟

مستند خود FusionPBX برای Whitelist به jail.conf اشاره می‌کند، اما Fail2Ban upstream توصیه می‌کند فایل‌های اصلی *.conf را دست‌کاری نکنید و Overrideهای محلی را در jail.local یا jail.d/*.local بگذارید.

برای اینکه تنظیم اختصاصی شما از فایل Installer جدا باشد، یک فایل Local Override بسازید:

nano /etc/fail2ban/jail.d/99-fusionpbx-local.local

نمونه برای یک دفتر ثابت:

[freeswitch-ip]
ignoreip = 127.0.0.1/8 ::1 198.51.100.25

[auth-challenge-ip]
ignoreip = 127.0.0.1/8 ::1 198.51.100.25

ترتیب Parse در Fail2Ban به این شکل است: jail.conf، سپس فایل‌های jail.d/*.conf، بعد jail.local و در پایان jail.d/*.local. بنابراین فایل .local شما برای Override انتخاب مناسبی است.

مرحله ۵: قبل از Reload، Config را تست کنید

بعد از هر تغییر:

fail2ban-client -t

اگر Config سالم بود:

fail2ban-client reload

سپس Ignore List Jail را ببینید:

fail2ban-client get freeswitch-ip ignoreip
fail2ban-client get auth-challenge-ip ignoreip

اگر IP از قبل Ban بوده، اضافه‌کردن آن به Ignore List لزوماً Ban فعلی را پاک نمی‌کند؛ بعد از Reload همان IP را Unban کنید.

آیا maxretry و bantime را تغییر دهیم؟

فقط زمانی که مطمئن شده‌اید Pattern واقعی ترافیک قانونی با Threshold فعلی سازگار نیست.

مثلاً Jail عمومی sip-auth-failure در Installer فعلی چنین Thresholdی دارد:

maxretry = 6
findtime = 60
bantime = 7200

اگر یک Phone سالم هر چند ثانیه Credential اشتباه می‌فرستد، بالا بردن maxretry مشکل واقعی را پنهان می‌کند. اول Password، Realm، Domain و Provisioning Device را اصلاح کنید.

برای Scannerهای واقعی حتی می‌توانید Ban را طولانی‌تر کنید؛ Fail2Ban قابلیت bantime.increment هم دارد تا IPهای تکرارشونده هر بار مدت بیشتری Ban شوند. این گزینه را برای سخت‌ترکردن امنیت مهاجمان استفاده کنید، نه برای جبران Config اشتباه داخلی‌ها.

اگر IP کاربران Dynamic است چه کنیم؟

Whitelist کردن یک Range بزرگ ISP راه‌حل امنی نیست. گزینه‌های بهتر:

مستند FusionPBX نیز به امکان Whitelist کردن Dynamic DNS اشاره می‌کند، اما در محیط Production بهتر است به DNS Update، TTL و زمان Resolution توجه داشته باشید.

iptables یا nftables؛ از کجا بفهمیم Ban واقعاً کجا اعمال شده است؟

مستند فعلی FusionPBX می‌گوید Installer Debian به‌صورت پیش‌فرض iptables را نصب می‌کند، اما مسیر nftables نیز پشتیبانی می‌شود. اگر nftables انتخاب شده باشد، Jailهای Fail2Ban از Action نوع nftables-allports استفاده می‌کنند.

برای iptables:

iptables -L -n -v

برای nftables:

nft list ruleset

اما برای مدیریت Banها بهتر است همچنان از fail2ban-client استفاده کنید؛ حذف دستی Rule از Firewall می‌تواند State داخلی Fail2Ban را با Firewall ناهماهنگ کند.

Brute-force واقعی را چطور از False Positive تشخیص دهیم؟

سناریو ۱: بعد از تغییر Password یک داخلی، کل دفتر Ban شده است

این سناریو بسیار رایج است. Password را در FusionPBX تغییر داده‌اید اما Phone هنوز Credential قبلی را دارد. Device چند بار REGISTER می‌زند و Public IP دفتر Ban می‌شود.

روش درست:

سناریو ۲: Phoneها به Public IP رجیستر می‌شوند و freeswitch-ip آن‌ها را می‌بندد

مستند رسمی FusionPBX دقیقاً درباره این حالت هشدار می‌دهد. اگر freeswitch-ip و auth-challenge-ip را فعال کرده‌اید، Registration مستقیم به IP می‌تواند توسط این Ruleها Block شود.

راه‌حل حرفه‌ای این است که یک A Record بسازید:

pbx.example.com  A  203.0.113.10

و Registrar Phoneها را از:

203.0.113.10

به این تغییر دهید:

pbx.example.com

سناریو ۳: SIP Provider Ban شده است

ابتدا مطمئن شوید Source IP واقعاً متعلق به Provider است. Providerهای بزرگ ممکن است چند SBC یا Range داشته باشند.

اگر IP/CIDR رسمی Provider ثابت است، به‌جای Global Ignore، فقط Jailهای SIP مربوطه را Override کنید. این کار باعث می‌شود همان IP هنوز نتواند بدون محدودیت به SSH یا پنل مدیریت حمله کند.

سناریو ۴: پنل FusionPBX باز نمی‌شود اما SIP سالم است

فقط Jailهای FreeSWITCH را بررسی نکنید. Jailهای fusionpbx، fusionpbx-mac، nginx-404 و nginx-dos می‌توانند IP را به‌دلیل رفتار وب Ban کنند.

مثلاً:

fail2ban-client status fusionpbx
fail2ban-client status nginx-404
fail2ban-client status nginx-dos

پیکربندی پیشنهادی امن برای یک دفتر با IP ثابت

فرض کنیم دفتر شما IP ثابت 198.51.100.25 دارد و تمام تلفن‌ها از همان NAT خارج می‌شوند. هدف این است که SIP آن دفتر در برابر False Positive محافظت شود، اما پنل و SSH همچنان Fail2Ban داشته باشند.

فایل:

/etc/fail2ban/jail.d/99-fusionpbx-local.local

محتوا:

[freeswitch-ip]
ignoreip = 127.0.0.1/8 ::1 198.51.100.25

[auth-challenge-ip]
ignoreip = 127.0.0.1/8 ::1 198.51.100.25

[sip-auth-failure]
ignoreip = 127.0.0.1/8 ::1 198.51.100.25

سپس:

fail2ban-client -t
fail2ban-client reload

fail2ban-client set freeswitch-ip unbanip 198.51.100.25
fail2ban-client set auth-challenge-ip unbanip 198.51.100.25
fail2ban-client set sip-auth-failure unbanip 198.51.100.25

در این مدل، دفتر برای Jailهای SIP Whitelist است، اما هنوز Jailهای SSH و FusionPBX Web می‌توانند حمله از همان IP را متوقف کنند.

چک‌لیست عیب‌یابی FusionPBX Fail2Ban

اشتباه‌هایی که امنیت FusionPBX را پایین می‌آورند

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

چرا FusionPBX همه تلفن‌های یک دفتر را هم‌زمان Ban می‌کند؟

اگر Phoneها پشت یک NAT باشند، همه با یک Public IP به سرور دیده می‌شوند. یک داخلی با Credential اشتباه می‌تواند باعث Ban شدن همان Public IP و در نتیجه قطع همه تلفن‌های آن دفتر شود.

چرا بعد از Ban شدن SIP، پنل وب و SSH هم باز نمی‌شود؟

Jailهای فعلی FusionPBX از Action نوع allports استفاده می‌کنند؛ بنابراین Ban یک IP می‌تواند تمام Portهای آن IP را مسدود کند، نه فقط SIP.

چطور فقط یک IP را Unban کنیم؟

با دستور fail2ban-client set JAIL unbanip IP فقط همان IP را از Jail مشخص آزاد کنید. در نسخه‌های جدید Fail2Ban، fail2ban-client unban IP می‌تواند IP را از همه Jailها آزاد کند.

آیا ignoreip امنیت Fail2Ban را از بین می‌برد؟

اگر محدود و هدفمند باشد، خیر. بهتر است IP دفتر یا Provider را فقط در Jailهای SIP Ignore کنید تا SSH و پنل وب همچنان تحت حفاظت Fail2Ban باشند.

freeswitch-ip و auth-challenge-ip را خاموش کنیم؟

نه به‌صورت پیش‌فرض. این Jailها برای سخت‌سازی مفیدند. ابتدا Phoneها را روی FQDN رجیستر کنید و False Positive را با IgnoreIP محدود یا اصلاح Device برطرف کنید.

اگر IP دفتر Dynamic باشد چه کنیم؟

Whitelist کردن Range بزرگ ISP توصیه نمی‌شود. VPN مدیریت، FQDN، Dynamic DNS کنترل‌شده یا تنظیم Threshold بر اساس Log واقعی گزینه‌های امن‌تری هستند.

Log Banهای FusionPBX کجاست؟

خود Fail2Ban Banها را در /var/log/fail2ban.log ثبت می‌کند. Jailهای SIP معمولاً /var/log/freeswitch/freeswitch.log را می‌خوانند و Jailهای وب/NGINX از auth.log، syslog یا access log استفاده می‌کنند.

اگر سرور nftables داشته باشد دستورات Fail2Ban فرق می‌کنند؟

مدیریت Jail و Unban همچنان با fail2ban-client انجام می‌شود. فقط Action Firewall زیرساخت می‌تواند به‌جای iptables از nftables استفاده کند.