امنیت پایه ایزابل؛ محدودکردن دسترسی مرکز تلفن

مبنای این آموزش Issabel 5 روی Rocky Linux 8 با Asterisk 18 و PJSIP است؛ نام گزینه‌های PBX با کد رسمیِ ثبت‌شده تا ۱ مهٔ ۲۰۲۴ تطبیق داده شده است. این مبنای مستندات، ادعای نصب یک Build ثابت نیست. نسخهٔ دقیق بسته‌ها و پورت فعال را از مرکز خود ثبت کنید و اختلاف نسخه را پیش از تغییر بررسی کنید. این تنظیمات جای بررسی امنیتی روش نصب و وضعیت اصلاحات را نمی‌گیرند؛ به‌ویژه پس از نصب با اسکریپت، فعال‌بودن فایروال را فرض نکنید.

این متن برای مسئول مجاز یک نصب آماده است. اجرای نمونه را روی مرکز آزمایشی بدون ترانک انجام دهید. پیش از تغییر مرکز کاری، بکاپ قابل بازیابی، بازهٔ تغییر و دسترسی کنسول میزبان را آماده کنید؛ قطع‌شدن دسترسی وب نباید تنها راه مدیریت را از بین ببرد. دستورالعمل نسخهٔ متفاوت را بی‌تطبیق اجرا نکنید.

نمونهٔ شبکه، PBX با 10.77.50.20، رایانهٔ مدیر با 10.77.50.10 و دو تلفن آزمایشی با 10.77.50.31 و 10.77.50.32 در زیرشبکهٔ جداست. این نشانی‌ها و محدودیت‌ها طرح نمونه‌اند، نه تنظیم آمادهٔ هر شرکت.

در مدیریت Users و Groups، حساب هر مسئول را جدا تعریف و Group Permissions را به بخش‌های موردنیازش محدود کنید. مثلاً کاربری که فقط گزارش می‌بیند نباید اجازهٔ تغییر ترانک یا دریافت بکاپ داشته باشد. حساب آزمایشی محدود بسازید و در نشست جدا امتحان کنید که هم بخش مجاز باز می‌شود و هم بخش غیرمجاز در دسترس نیست؛ پنهان‌بودن منو به‌تنهایی آزمون کافی نیست.

رمز پنل، root و Secret داخلی نقش یکسانی ندارند. برای هر داخلی رمز قوی و مستقل نگه دارید و حساب‌های بلااستفاده را پس از تطبیق مالکیت غیرفعال کنید. دسترسی وبِ گروه کاربری، مجوز شماره‌گیری تلفن آن شخص را خودکار تعیین نمی‌کند. به‌خصوص پس از پایان همکاری یا تعویض دستگاه، هر دو نوع دسترسی را جدا بررسی کنید.

وضعیت و قواعد را در Security → Firewall → Firewall Rules و تعریف سرویس‌ها را در Define Ports بررسی کنید. پیش از فعال‌سازی یا محدودترکردن، قواعد فعلی و ترتیب آن‌ها را ثبت کنید؛ قانون مجازکردن همهٔ مبداها می‌تواند محدودیت تازه را بی‌اثر کند. برای خدماتی که واقعاً استفاده نمی‌شوند مجوز عمومی ایجاد نکنید.

ابتدا دسترسی مدیریتی لازم را تعریف و در نشست تازه آزمایش کنید، سپس مجوز گستردهٔ همان سرویس را محدود کنید. تغییرها را یکی‌یکی انجام دهید. اگر مدیریت یا تماس قطع شد، از کنسول فقط تغییر اخیر را به وضعیت ثبت‌شده برگردانید؛ پاک‌کردن همهٔ قواعد راه بازگشت این آموزش نیست.

در شبکهٔ محلی، ترافیک هم‌زیرشبکه ممکن است از روتر عبور نکند؛ قانون روتر جای کنترل روی میزبان را نمی‌گیرد. اگر Direct Media فعال باشد، مسیر صدا می‌تواند بین تلفن‌ها باشد. پورت SIP و محدودهٔ رسانه را از تنظیم واقعی بگیرید؛ یک فهرست ثابت پورت، مجوز بازکردن همهٔ آن‌ها روی اینترنت نیست. پنل را برای دورکاری عمومی نکنید؛ داخلی راه دور مسیر جدا دارد.

در Security → Fail2ban → Administration، وضعیت سرویس و قواعد موجود را بررسی کنید. مستند رسمی توصیه می‌کند سرویس غیرفعال فعال شود؛ پیش از آن مطمئن شوید راه کنسول و تنظیمات معتبر دارید. فعال‌بودن سرویس را با حفاظت همهٔ وب، SSH و SIP یکسان نگیرید؛ هر Jail باید با لاگ و سرویس مربوط به نصب سازگار باشد.

رخداد ناموفقِ واقعی را با زمان، مبدا و سرویس مربوط تطبیق دهید. برای امتحان‌کردن، رمز مدیر را پشت‌سرهم اشتباه وارد نکنید. اگر مبدا مجاز مسدود شده، ابتدا خطای حساب یا دستگاه را برطرف کنید و سپس از راه مجاز همان مورد را بررسی کنید؛ استثناکردن کل اینترنت یا حذف همهٔ مسدودی‌ها علت را حل نمی‌کند.

در مرکز تازهٔ این تمرین، ترانک و مسیر خروجی واقعی ایجاد نکنید. در مرکز شرکت، یک جدول جدا از کاربران مجاز، نوع مقصد و زمان مجاز تماس داشته باشید و آن را با امکانات همان نسخه، مسیرها و محدودیت سمت اپراتور اجرا کنید. شمارهٔ نمایشی Caller ID را به‌تنهایی مجوز قابل اعتماد کاربر تلقی نکنید.

در PBX Configuration → Connectivity → Outbound Routes، الگوهای Dial Patterns و ترتیب مسیرها را بازبینی کنید. ستون CallerID در الگو با شمارهٔ داخلی تماس‌گیرنده تطبیق می‌کند و با Outbound CID نمایشی فرق دارد. مثلاً برای یک مقصد عادیِ مشخص که شرکت اجازه داده، یک ردیف با همان شماره در match pattern و 201 در CallerID محدودیت همان ردیف را تعریف می‌کند؛ این به معنی منع 202 در کل مرکز نیست، چون مسیر دیگر ممکن است تماس را بپذیرد. همهٔ مسیرهای جایگزین، Aliasها، فورواردها و دسترسی به ترانک باید مطابق سیاست بررسی شوند. این مثال دستور ایجاد ترانک واقعی در آزمایش نیست.

برای هر گروه، یک تماس مجاز و یک مقصد عادیِ خارج از مجوز را با هماهنگی بررسی کنید؛ از شماره‌های اضطراری یا پرهزینه برای آزمون استفاده نکنید. محدودیت سمت اپراتور می‌تواند لایهٔ مکمل باشد، ولی مجوز داخلی را جایگزین نمی‌کند. اگر داخلی مجاز تماس ندارد، عیب‌یابی خروج تماس را دنبال کنید؛ برداشتن محدودیت همهٔ کاربران روش آزمون نیست.

نسخهٔ ایزابل به‌تنهایی وضعیت وصلهٔ هر بسته را نشان نمی‌دهد. برای نمونه، اطلاعیهٔ رسمی INC-2025-0012 اصلاح مشخصی را در بسته‌های issabel-pbx و issabel-agenda توضیح می‌دهد؛ نسخه‌های آن اطلاعیه، فهرست کامل آخرین اصلاحات امروز نیستند. بسته‌های نصب‌شده را با اطلاعیهٔ مرتبط و مخزن رسمی همان نسخه تطبیق دهید و از ارتقای کور همهٔ اجزا وسط کار خودداری کنید.

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

بکاپ می‌تواند رمز، اطلاعات خط و فایل‌های حساس داشته باشد؛ دسترسی و نگهداری آن محدود و نسخه‌ای مستقل از خود مرکز لازم است. زمان سیستم و نگهداری رخدادها را هماهنگ کنید تا مقایسهٔ خطاها ممکن باشد. این تنظیمات، گواه نفوذناپذیری یا آزمایش امنیت عملی نیستند.

قبل از تغییرات بعدی، آزمون بازیابی بکاپ ایزابل را در محیط جدا انجام دهید و گزارش آخرین وضعیت سالم را نگه دارید.

• جدول مبدا و سرویس مجاز، نسخه‌ها و قواعد تغییرکرده، بدون درج رمز در گزارش عمومی.
• نتیجهٔ ورود تازهٔ مدیر و رد دسترسی از مبدا غیرمجازِ آزمایشی؛ همراه نتیجهٔ حساب محدود.
• ثبت دوبارهٔ هر دو داخلی و تماس با صدای دوطرفه پس از تغییر فایروال.
• در مرکز کاری، نتیجهٔ تماس مجاز و نامجاز طبق سیاست شرکت؛ این نتیجه از آزمایش بدون ترانک به دست نمی‌آید.
• وضعیت Fail2ban، پیگیری رخداد و برنامهٔ به‌روزرسانی و بازیابی با مسئول مشخص.

اگر یکی از این کنترل‌ها نتیجهٔ روشن ندارد، همان محدودیت را در تحویل باز بگذارید. برای اصلاح مرکز موجود می‌توانید از خدمات ایزابل استفاده کنید.