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

این اتفاق مخصوصاً زمانی دیده می‌شود که چند تلفن پشت یک NAT قرار دارند و فقط یکی از آن‌ها Password قدیمی، Domain اشتباه یا Provisioning ناقص دارد. Fail2Ban خطاهای تکراری همان یک Phone را از یک Public IP می‌بیند و در نهایت کل IP را مسدود می‌کند؛ در نتیجه همه داخلی‌های آن شعبه هم‌زمان Offline به نظر می‌رسند.

راه‌حل درست خاموش‌کردن Fail2Ban نیست. باید مشخص کنیم کدام Jail IP را Ban کرده، کدام Log باعث Trigger شده، کدام Device یا Login خطا تولید کرده و فقط در صورت نیاز ignoreip محدود و امن بسازیم.

در این آموزش از تشخیص Ban تا Unban هدفمند، بررسی Jailهای FusionPBX و FreeSWITCH، پیدا کردن Log Source، تنظیم امن Whitelist و جلوگیری از Brute Force را مرحله‌به‌مرحله انجام می‌دهیم.

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

Fail2Ban فایل‌های Log را مانیتور می‌کند و وقتی تعداد مشخصی Failure از یک IP در یک بازه زمانی دیده شود، آن IP را با Action تعریف‌شده در Firewall مسدود می‌کند.

در نصب رسمی FusionPBX، Fail2Ban همراه سیستم نصب و از قبل برای چند سرویس آماده می‌شود.

هدف آن محافظت از بخش‌هایی مثل:

در برابر تلاش‌های تکراری و Brute Force است.

چرا یک IP Ban شده می‌تواند هم‌زمان SIP، Web و SSH را قطع کند؟

در فایل رسمی فعلی Installer، بسیاری از Jailها از Action زیر استفاده می‌کنند:

iptables-allports

یعنی اگر IP داخل آن Jail Ban شود، فقط Port خاص Jail بسته نمی‌شود؛ ممکن است تمام Portها برای آن IP Drop شوند.

به همین دلیل یک کاربر ممکن است ابتدا متوجه شود Phone رجیستر نمی‌شود و چند دقیقه بعد ببیند:

این رفتار در بسیاری از موارد نشانه خرابی VPS نیست؛ Public IP شما در Fail2Ban Ban شده است.

اولین نشانه: همه تلفن‌های یک شعبه هم‌زمان قطع شده‌اند

فرض کنید ۱۵ تلفن در یک دفتر هستند و همه از یک مودم اینترنت استفاده می‌کنند.

از دید FusionPBX، همه آن‌ها ممکن است با یک Public IP دیده شوند:

203.0.113.25

اگر فقط یک تلفن Password قدیمی داشته باشد و دائماً REGISTER ناموفق بفرستد، Fail2Ban Source IP را می‌بیند؛ نه اینکه الزاماً بداند این Failure فقط متعلق به یک دستگاه از ۱۵ دستگاه است.

اگر آن IP Ban شود، تمام تلفن‌های همان NAT تحت تأثیر قرار می‌گیرند.

قبل از هر تغییر، Public IP کاربر را مشخص کنید

برای عیب‌یابی دقیق باید بدانید کدام IP را دنبال می‌کنید.

اگر کاربر از Branch یا Office تماس گرفته است، Public IP اینترنت آن دفتر را مشخص کنید.

بعد آن IP را در Fail2Ban و Logها جست‌وجو می‌کنیم.

در مثال‌های این مقاله از:

203.0.113.25

به‌عنوان IP مستندسازی استفاده می‌کنیم؛ آن را با IP واقعی خود جایگزین کنید.

مرحله ۱: وضعیت کلی Fail2Ban را ببینید

systemctl status fail2ban --no-pager

سپس:

fail2ban-client status

خروجی فهرست Jailهای فعال را نشان می‌دهد.

همه Jailهایی که در فایل وجود دارند لزوماً فعال نیستند

این نکته برای FusionPBX مهم است.

در فایل رسمی فعلی Debian Installer، برخی Jailهای SIP تعریف شده‌اند اما به‌صورت پیش‌فرض:

enabled = false

هستند.

از جمله:

در مقابل، در فایل فعلی Installer Jailهایی مثل:

فعال هستند.

اما مستند رسمی FusionPBX برای افزایش امنیت توصیه می‌کند Jailهای `freeswitch-ip` و `auth-challenge-ip` نیز فعال شوند؛ بنابراین روی بسیاری از سرورهای Production این دو Jail را فعال خواهید دید.

مرحله ۲: بفهمیم IP دقیقاً در کدام Jail Ban شده است

برای هر Jail مشکوک:

fail2ban-client status freeswitch-ip

یا:

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

به بخش:

Banned IP list

دقت کنید.

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

اگر نسخه نصب‌شده از دستور `banned` پشتیبانی می‌کند:

fail2ban-client banned 203.0.113.25

می‌تواند Jailهایی را که IP در آن‌ها Ban شده نشان دهد.

اگر فرمان روی نسخه شما شناخته نشد، همان روش `status` برای Jailها را استفاده کنید.

مرحله ۳: Log خود Fail2Ban را بررسی کنید

FusionPBX در مستندات خود این فایل را برای ثبت Banها معرفی می‌کند:

/var/log/fail2ban.log

برای IP موردنظر:

grep "203.0.113.25" /var/log/fail2ban.log | tail -n 50

خروجی معمولاً مشخص می‌کند کدام Jail عمل Ban را انجام داده است.

مثلاً مفهومی شبیه:

[freeswitch-ip] Ban 203.0.113.25

بلافاصله مشخص می‌کند دنبال کدام Filter برویم.

اگر fail2ban.log نداریم

در برخی تنظیمات Log به systemd journal می‌رود.

journalctl -u fail2ban --since "1 hour ago" --no-pager

را بررسی کنید.

مرحله ۴: Log Source همان Jail را پیدا کنید

فقط دانستن Jail کافی نیست.

باید بفهمیم چه خطی باعث Match شده است.

در فایل فعلی FusionPBX، Jailهای SIP مانند:

معمولاً این Log Source را دارند:

/var/log/freeswitch/freeswitch.log

خطاهای همان IP را در FreeSWITCH پیدا کنید

grep "203.0.113.25" /var/log/freeswitch/freeswitch.log | tail -n 100

حالا Timestamp قبل از Ban را بررسی کنید.

Jail freeswitch-ip دقیقاً دنبال چه چیزی است؟

Filter فعلی `freeswitch-ip` پیام‌هایی با مفهوم زیر را Match می‌کند:

Can't find user [extension@SERVER-IP] from CLIENT-IP

یعنی یک Client تلاش کرده User را روی Realm مبتنی بر IP سرور پیدا کند و FreeSWITCH چنین Userای در آن Realm پیدا نکرده است.

چرا Register کردن به IP خام می‌تواند مشکل بسازد؟

FusionPBX معماری Domain-based دارد.

اگر Extension متعلق به:

pbx.example.com

باشد ولی Phone به‌جای Domain مستقیماً Public IP را به‌عنوان SIP Server/Realm استفاده کند، FreeSWITCH ممکن است User را در Domain اشتباه جست‌وجو کند.

همین خطا دقیقاً چیزی است که Jail `freeswitch-ip` برای تشخیص Registration روی IP هدف قرار می‌دهد.

مستند FusionPBX نیز FQDN را توصیه می‌کند

FusionPBX صریحاً توصیه می‌کند Endpointها به Domain/FQDN رجیستر شوند، چون بیشتر اسکن‌های خودکار مستقیم Public IP را هدف می‌گیرند.

پس اگر Jailهای:

freeswitch-ip
auth-challenge-ip

را فعال کرده‌اید، همه Phoneها را از IP خام به FQDN منتقل کنید.

auth-challenge-ip چه چیزی را Match می‌کند؟

Filter فعلی این Jail روی Warningهای FreeSWITCH با مفهوم:

SIP auth challenge (INVITE|REGISTER) ... @SERVER-IP ... from ip CLIENT-IP

کار می‌کند.

در فایل فعلی Installer:

maxretry = 1
findtime = 60
bantime = 86400

برای این Jail تعریف شده است.

یعنی اگر آن را فعال کنید، یک Match می‌تواند IP را ۲۴ ساعت Ban کند.

این Jailها را غیرفعال کنیم؟

اگر همه Phoneها و Providerها با FQDN درست تنظیم شده‌اند، فعال‌بودن این Jailها لایه دفاعی ارزشمندی در برابر Botهایی ایجاد می‌کند که مستقیم Public IP را Scan می‌کنند.

پس اولین راه‌حل:

enabled=false

نیست.

اول Endpoint قانونی را درست کنید.

Jail sip-auth-failure چه زمانی مهم می‌شود؟

اگر این Jail را فعال کرده باشید، Authentication Failureهای تکراری می‌توانند IP را Ban کنند.

در فایل فعلی Installer مقدار نمونه آن:

maxretry = 6
findtime = 60
bantime = 7200

است.

یعنی چند Password اشتباه پشت سر هم می‌تواند دو ساعت Ban ایجاد کند.

سناریوی واقعی: یک تلفن، کل شعبه را Ban می‌کند

فرض کنید شعبه ۱۰ تلفن دارد.

داخلی 1004 چند روز قبل Password آن تغییر کرده اما Provisioning Phone هنوز Password قبلی را دارد.

Phone هر چند ثانیه تلاش می‌کند Register شود.

همه تلفن‌ها از Public IP زیر خارج می‌شوند:

203.0.113.25

Fail2Ban چند Failure را از همین IP می‌بیند و آن را Ban می‌کند.

نتیجه:

داخلی 1004 خراب بوده، اما داخلی‌های 1001 تا 1010 هم قطع می‌شوند.

در چنین حالتی فقط Unban کافی نیست

اگر فوراً:

unban

کنید ولی Password 1004 را اصلاح نکنید، چند ثانیه یا چند دقیقه بعد همان IP دوباره Ban می‌شود.

پس ترتیب درست:

تشخیص → توقف Failure → Unban → Retest

است.

مرحله ۵: همان IP را هدفمند Unban کنید

فرض کنیم Jail مسئول:

sip-auth-failure

است.

فقط همان IP را از همان Jail آزاد کنید:

fail2ban-client set sip-auth-failure unbanip 203.0.113.25

برای freeswitch-ip

fail2ban-client set freeswitch-ip unbanip 203.0.113.25

چرا Restart کردن Fail2Ban روش خوبی برای Unban نیست؟

مستند قدیمی FusionPBX اشاره می‌کند Restart کردن Fail2Ban می‌تواند Blockها را پاک کند.

اما این کار مشکل مهمی دارد:

ممکن است مهاجمان واقعی را هم آزاد کند.

Fail2Ban خودش Unban هدفمند را پشتیبانی می‌کند؛ بنابراین برای آزادکردن یک شعبه، کل سرویس را Restart نکنید.

اگر IP در چند Jail Ban شده باشد

Unban کردن فقط یک Jail کافی نیست.

همه Jailهایی که IP را Ban کرده‌اند مشخص کنید و IP را از همان‌ها آزاد کنید.

در نسخه‌های جدید Fail2Ban همچنین دستور:

fail2ban-client unban 203.0.113.25

می‌تواند IP را از Banهای مدیریت‌شده Fail2Ban آزاد کند، اما روی Production بهتر است ابتدا Jail مسئول را پیدا کنید تا علت اصلی مشخص بماند.

مرحله ۶: بعد از Unban فوراً Registration را مانیتور کنید

در یک Terminal:

tail -f /var/log/fail2ban.log

و در Terminal دیگر:

tail -f /var/log/freeswitch/freeswitch.log

Phone را دوباره Register کنید.

اگر همان Failure دوباره شروع شد، هنوز علت اصلی حل نشده است.

مرحله ۷: مشخص کنید کدام داخلی Failure تولید می‌کند

در Log FreeSWITCH معمولاً Extension/Username در همان پیام خطا دیده می‌شود.

مثلاً اگر چندین بار نام:

1004

را می‌بینید، همان تلفن را موقتاً از شبکه جدا کنید.

سپس:

Jail fusionpbx مربوط به SIP نیست

Jail:

[fusionpbx]

در فایل فعلی Installer فعال است و Log آن:

/var/log/auth.log

است.

Filter آن خطاهایی با مفهوم:

را دنبال می‌کند.

اگر Admin Password را چند بار اشتباه بزنیم چه می‌شود؟

در تنظیم فعلی Installer برای Jail `fusionpbx`:

maxretry = 20
findtime = 60
bantime = 3600

تعریف شده است.

یعنی تعداد زیادی Authentication Failure در یک دقیقه می‌تواند IP را یک ساعت Ban کند.

اگر Provisioning Script یا Application اشتباه Credential می‌فرستد، رسیدن به این حد بسیار سریع‌تر از ورود دستی کاربر اتفاق می‌افتد.

nginx-404 و nginx-dos را هم فراموش نکنید

گاهی کاربر تصور می‌کند Phone باعث Ban شده، در حالی که یک Scanner، Monitoring Tool یا Browser روی همان Public IP صدها Request اشتباه به پنل می‌فرستد.

Jailهای:

nginx-404
nginx-dos

Logهای:

/var/log/nginx/access*.log

را مانیتور می‌کنند.

پس همیشه Jail مسئول را ثابت کنید

اگر IP شما Ban شده است، این فرض‌ها را نکنید:

«حتماً Password SIP اشتباه بوده.»

«حتماً FreeSWITCH Ban کرده.»

«حتماً یک Attack بوده.»

Log Fail2Ban مشخص می‌کند Jail مسئول کدام است؛ Log Source همان Jail علت دقیق را نشان می‌دهد.

جدول Jailهای مهم FusionPBX

مرحله ۸: آیا واقعاً باید IP را Whitelist کنیم؟

Whitelist یا `ignoreip` زمانی منطقی است که IP واقعاً قابل اعتماد و کنترل‌شده باشد.

نمونه‌های مناسب‌تر:

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

این موارد معمولاً انتخاب خطرناکی هستند:

اگر یک IP در Ignore List باشد، Fail2Ban Failureهای آن را برای Jail مربوطه Ban نمی‌کند؛ بنابراین Whitelist بزرگ مستقیماً سطح دفاع را کاهش می‌دهد.

Whitelist سراسری یا فقط یک Jail؟

این یکی از تصمیم‌های مهم امنیتی است.

اگر IP ثابت دفتر مدیریت شما است و به:

دسترسی دارد، Whitelist سراسری ممکن است قابل توجیه باشد.

اما برای SIP Carrier بهتر است فقط Jailهای SIP را Ignore کنید تا مثلاً دسترسی Web آن IP بدون دلیل از محافظت خارج نشود.

روش پیشنهادی برای تغییرات پایدار Fail2Ban

Fail2Ban upstream توصیه می‌کند فایل‌های `.conf` اصلی را تغییر ندهید و Customization را داخل فایل‌های `.local` قرار دهید.

برای تنظیمات اختصاصی خود می‌توانید فایل جدا بسازید:

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

Whitelist سراسری برای یک Office IP ثابت

نمونه:

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

IP را با Public IP ثابت واقعی جایگزین کنید.

برای Carrier بهتر است Scope محدودتر باشد

مثلاً:

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

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

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

این روش فقط Jailهای SIP مشخص‌شده را برای آن Carrier Ignore می‌کند.

بعد از تغییر Config اول Syntax را تست کنید

fail2ban-client -t

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

fail2ban-client reload

چرا Reload بهتر از Restart است؟

در Fail2Ban جدید، `reload` Configuration را بدون Restart کردن Server Process دوباره بارگذاری می‌کند.

این کار برای تغییر Ignore List مناسب‌تر است و فعالانه همه Banهای موجود را پاک نمی‌کند.

در مقابل Stop/Start یا Restart می‌تواند وضعیت Firewall Actionها را بازسازی کند و برای یک تغییر ساده لازم نیست.

بعد از Reload بررسی کنید ignoreip واقعاً Load شده است

برای Jail موردنظر:

fail2ban-client get freeswitch-ip ignoreip

یا:

fail2ban-client get sip-auth-failure ignoreip

را اجرا کنید.

این مرحله مهم است؛ فقط وجود IP در فایل Configuration ثابت نمی‌کند Runtime همان Config را Load کرده است.

Whitelist موقت بدون ویرایش فایل

Fail2Ban اجازه می‌دهد در Runtime به یک Jail Ignore IP اضافه کنید:

fail2ban-client set freeswitch-ip addignoreip 203.0.113.25

این برای عیب‌یابی موقت مفید است.

اما برای تنظیم دائمی، آن را داخل Config `.local` بنویسید؛ Runtime Change به‌تنهایی جای Configuration پایدار را نمی‌گیرد.

برای حذف Ignore موقت

fail2ban-client set freeswitch-ip delignoreip 203.0.113.25

آیا می‌شود Hostname یا DDNS را Whitelist کرد؟

مستند FusionPBX اشاره می‌کند `ignoreip` می‌تواند IP، CIDR یا DNS Hostname داشته باشد و حتی برای Dynamic IP از سرویس DDNS استفاده شود.

اما برای یک PBX حساس، اگر امکان دارید راه‌های قابل پیش‌بینی‌تر بهترند:

Whitelist بر اساس Hostname یک Dependency جدید به DNS اضافه می‌کند و باید رفتار Resolution روی نسخه Fail2Ban خودتان تست شود.

کاربر خانگی با IP پویا را Global Whitelist نکنید

اگر یک کاربر Remote هر چند روز Public IP جدید می‌گیرد، اضافه‌کردن کل Range ISP به Ignore List راه‌حل امنی نیست.

برای چنین کاربری بهتر است:

مرحله ۹: Jail بیش از حد حساس است یا Client واقعاً خراب است؟

قبل از افزایش `maxretry`، Log واقعی را بررسی کنید.

اگر یک Phone طی یک دقیقه ۵۰ Password اشتباه می‌فرستد، مشکل از Threshold نیست.

Phone یا Provisioning خراب است.

اما اگر یک مدل Phone در Boot طبیعی خودش چند Event مشابه تولید می‌کند و Filter آن‌ها را اشتباه Failure می‌بیند، باید Filter و Threshold را تست کنید.

Filter را با fail2ban-regex تست کنید

مثلاً برای `freeswitch-ip`:

fail2ban-regex \
/var/log/freeswitch/freeswitch.log \
/etc/fail2ban/filter.d/freeswitch-ip.conf

برای Auth Challenge:

fail2ban-regex \
/var/log/freeswitch/freeswitch.log \
/etc/fail2ban/filter.d/auth-challenge-ip.conf

این تست نشان می‌دهد چه تعداد خط از Log با Regex Jail Match می‌شوند.

قبل از تغییر Regex، نمونه Log را ذخیره کنید

اگر Filter اشتباه Match می‌کند، فقط حدس نزنید.

چند خط واقعی قبل و بعد Event را ذخیره کنید و دقیقاً ببینید چه Patternای باعث Match شده است.

بعد در صورت نیاز Override محلی Filter بسازید؛ فایل اصلی Package را ویرایش نکنید چون Update ممکن است آن را بازنویسی کند.

مرحله ۱۰: maxretry، findtime و bantime را درست بفهمیم

maxretry تعداد Failure مجاز قبل از Ban است.

findtime بازه‌ای است که Fail2Ban Failureها را داخل آن می‌شمارد.

bantime مدت Ban است.

مثلاً:

maxretry = 6
findtime = 60
bantime = 7200

یعنی اگر شش Match در ۶۰ ثانیه رخ دهد، IP برای ۷۲۰۰ ثانیه Ban می‌شود.

افزایش maxretry همیشه راه‌حل نیست

اگر از:

6

به:

100

بروید فقط چون یک Phone خراب است، عملاً زمان بیشتری به Brute Force واقعی می‌دهید.

Threshold را فقط وقتی تغییر دهید که Log ثابت کند رفتار قانونی با Rule فعلی هم‌خوانی ندارد.

جلوگیری از Brute Force بدون Ban شدن کاربران واقعی

یک FusionPBX امن فقط به Fail2Ban وابسته نیست.

لایه‌های بهتر:

Password داخلی‌ها باید واقعاً تصادفی باشد

شماره داخلی را به‌عنوان Password استفاده نکنید.

مثلاً:

1001 / 1001
1002 / 123456
2000 / companyname

Credentialهای بسیار ضعیفی هستند.

هر Extension باید Password طولانی و منحصربه‌فرد داشته باشد.

Carrier را در Firewall محدود کنید، نه فقط Fail2Ban

اگر SIP Provider فقط از چند IP مشخص تماس می‌فرستد، بهتر است Firewall نیز فقط همان Sourceها را برای Profile خارجی مجاز کند.

در این حالت Botهای عمومی حتی قبل از رسیدن به Authentication سطح Application متوقف می‌شوند.

پنل FusionPBX را از اینترنت عمومی دور کنید

اگر امکان دارد Web Admin فقط از:

دسترسی داشته باشد.

Fail2Ban خط دفاع مفیدی است، اما جایگزین محدودکردن سطح Exposure نیست.

اگر روی VPS کار می‌کنید SSH را هم مستقل امن کنید

Fail2Ban در Installer FusionPBX از SSH نیز محافظت می‌کند، اما بهتر است Login با SSH Key، محدودکردن Root Login و سیاست Firewall را جداگانه رعایت کنید.

برای این بخش می‌توانید راهنمای ایرانیکاسرور درباره امن‌سازی SSH از Root Login تا SSH Key و Fail2Ban را نیز ببینید.

چرا Global Whitelist برای Carrier همیشه ایده خوبی نیست؟

فرض کنید Carrier فقط SIP Trunk شما است.

اگر IP آن را در `[DEFAULT]` قرار دهید، همان IP از Jailهای Web و SSH هم Ignore می‌شود.

در حالی که Carrier به پنل Admin یا SSH نیازی ندارد.

برای چنین حالتی Per-Jail Ignore دقیق‌تر است.

اگر یک شعبه IP ثابت دارد چه کنیم؟

برای شعبه‌ای که ده‌ها تلفن پشت یک Public IP ثابت دارد، دو گزینه داریم:

روش اول: Credentialها و Domain را درست کنیم و Fail2Ban را بدون Whitelist نگه داریم.

روش دوم: اگر IP کاملاً تحت کنترل سازمان است، آن IP را برای Jailهای SIP یا در صورت نیاز کل Jailها Ignore کنیم.

روش اول Security بیشتری دارد.

روش دوم Availability بالاتری برای شعبه ایجاد می‌کند، اما اگر یکی از دستگاه‌های همان شعبه آلوده یا Credential داخلی سرقت شود Fail2Ban دیگر از آن Source IP محافظت نمی‌کند.

VPN برای شعبه راه‌حل تمیزتری است

اگر چند شعبه با تعداد Phone بالا دارید، Site-to-Site VPN می‌تواند معماری بهتری ایجاد کند.

در این حالت:

اگر IP بعد از Unban هنوز وصل نمی‌شود چه کنیم؟

Fail2Ban فقط یکی از لایه‌هاست.

بررسی کنید:

۱. IP هنوز در Jail دیگری Ban نیست.

۲. Rule دستی Firewall آن را Block نکرده است.

۳. FreeSWITCH Registration درست است.

۴. Fail2Ban دوباره همان IP را Ban نکرده است.

۵. SIP Profile فعال است.

۶. DNS/FQDN درست است.

Ruleهای Fail2Ban را در iptables ببینید

iptables -L -n --line-numbers

برای پیدا کردن Chainهای Fail2Ban:

iptables -S | grep -i f2b

در Debian 12 ممکن است iptables روی backend مبتنی بر nftables کار کند، اما Interface سازگاری `iptables` همچنان Ruleها را نمایش می‌دهد.

به‌صورت دستی Rule Fail2Ban را از iptables پاک نکنید

اگر Fail2Ban خودش یک IP را مدیریت می‌کند، Rule را با:

iptables -D ...

به‌صورت دستی حذف نکنید، مگر اینکه دقیقاً بدانید چه می‌کنید.

Fail2Ban Database همچنان ممکن است IP را Ban بداند و State شما بین Firewall و Fail2Ban ناسازگار شود.

از `fail2ban-client unbanip` استفاده کنید.

روش استاندارد عیب‌یابی در کمتر از پنج دقیقه

مرحله ۱: Public IP شعبه را پیدا کنید.

مرحله ۲: `fail2ban-client status` را اجرا کنید.

مرحله ۳: `/var/log/fail2ban.log` را برای همان IP Search کنید.

مرحله ۴: Jail مسئول را مشخص کنید.

مرحله ۵: Log Source همان Jail را بررسی کنید.

مرحله ۶: Extension/Device خراب را پیدا و Failure را متوقف کنید.

مرحله ۷: همان IP را Targeted Unban کنید.

مرحله ۸: Phoneها را Re-register کنید.

مرحله ۹: اگر IP ثابت و قابل اعتماد است، درباره Whitelist محدود تصمیم بگیرید.

مرحله ۱۰: Fail2Ban Log را چند دقیقه مانیتور کنید.

یک جدول تشخیص سریع

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

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

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

چطور بفهمیم IP توسط کدام Jail Ban شده است؟

`fail2ban-client status` را برای مشاهده Jailهای فعال اجرا کنید و سپس وضعیت Jailهای مشکوک و `/var/log/fail2ban.log` را بررسی کنید. Log خود Fail2Ban معمولاً نام Jail مسئول Ban را ثبت می‌کند.

آیا Restart کردن Fail2Ban برای Unban کردن IP کار درستی است؟

برای رفع یک IP توصیه نمی‌شود، چون می‌تواند Banهای دیگر را هم تحت تأثیر قرار دهد. از دستور هدفمند `fail2ban-client set JAIL unbanip IP` استفاده کنید.

چرا freeswitch-ip تلفن قانونی را Ban می‌کند؟

یکی از علت‌های مهم این است که Phone به‌جای FQDN روی Public IP FusionPBX Register می‌شود و FreeSWITCH User را در Realm مبتنی بر IP پیدا نمی‌کند. FusionPBX برای Registration استفاده از FQDN را توصیه می‌کند.

ignoreip را کجا تنظیم کنیم؟

بهتر است Customization خود را در فایل `.local` مانند `/etc/fail2ban/jail.d/99-fusionpbx-local.local` قرار دهید، Config را با `fail2ban-client -t` تست و با `fail2ban-client reload` اعمال کنید.

آیا می‌توان کل Range ISP را Whitelist کرد؟

از نظر فنی CIDR قابل استفاده است، اما برای کاربران اینترنتی کار امنی نیست. Whitelist باید تا حد ممکن محدود به IP ثابت و واقعاً قابل اعتماد باشد.

آیا می‌توان فقط SIP Carrier را از Jailهای SIP مستثنا کرد؟

بله. به‌جای `[DEFAULT]` می‌توانید `ignoreip` را فقط در Jailهایی مانند freeswitch-ip، auth-challenge-ip و sip-auth-failure تعریف کنید.

فرق fail2ban.log و freeswitch.log چیست؟

`fail2ban.log` می‌گوید چه IPی توسط کدام Jail Ban یا Unban شده است؛ `freeswitch.log` Event واقعی SIP یا Authentication را نشان می‌دهد که Filter Fail2Ban از روی آن تصمیم گرفته است.

چرا بعد از Unban دوباره IP مسدود می‌شود؟

چون Failure اصلی هنوز ادامه دارد؛ معمولاً Phone با Password قدیمی، Domain اشتباه یا Provisioning نادرست دوباره خطا تولید می‌کند.

آیا خاموش‌کردن Fail2Ban راه حل است؟

خیر. روی PBX اینترنتی Fail2Ban یکی از لایه‌های مهم دفاع در برابر Password Guessing و Scannerهای SIP/Web است. علت False Positive یا Client خراب را اصلاح کنید و فقط در صورت نیاز Whitelist محدود بسازید.