Amir Jabbari
نکته مهم: همه تنظیمات این مقاله را یک‌باره روی صدها Phone اعمال نکنید. ابتدا روی یک دستگاه آزمایشی اجرا کنید، Registration، تماس ورودی/خروجی، Provisioning و Recovery Path را تست کنید و بعد آن را وارد Template اصلی کنید.
مدل تهدید در Cisco MPP؛ دقیقاً چه چیزی را امن می‌کنیم؟
قبل از تغییر تنظیمات، باید مشخص باشد از چه چیزی محافظت می‌کنیم. در MPP حداقل شش سطح حساس وجود دارد:
🔹 Management Plane: پنل Web UI، Admin Login و تنظیمات Local.
🔹 Provisioning Plane: فایل XML، Profile Rule، Upgrade Rule و Credentialهایی که از Server می‌آیند.
🔹 Signaling Plane: SIP REGISTER و INVITE.
🔹 Media Plane: RTP/SRTP و محتوای صوت.
🔹 Trust Plane: CA، Certificate، Hostname Validation و Client Certificate.
🔹 Local Network Surface: PC Port، CDP/LLDP، TR-069 و Firewall داخلی Phone.
امن‌سازی خوب یعنی هر سطح فقط به اندازه‌ای که برای سرویس لازم است باز بماند.
مرحله ۱: Admin و User Credential را از هم جدا کنید
Cisco MPP دو سطح Web Access اصلی دارد: Admin و User. Admin به تنظیمات کامل‌تری دسترسی دارد و User فقط باید به پارامترهایی که واقعاً برای کاربر لازم است دسترسی داشته باشد.
در مستندات Cisco، Admin Password می‌تواند بین ۴ تا ۱۲۷ کاراکتر باشد و نسخه‌های جدید برای Password معتبر ترکیبی از چند نوع Character را می‌پذیرند. اما حداقل فنی محصول را با استاندارد امنیتی سازمان یکی نگیرید. برای محیط واقعی بهتر است Password طولانی، یکتا و غیرقابل‌حدس باشد و در Password Manager سازمان ذخیره شود.
اگر یک Password مشترک روی تمام Phoneها دارید، با لو رفتن یک Device کل Fleet در معرض خطر قرار می‌گیرد. در صورت امکان، Secretها را Device-specific یا حداقل Site-specific کنید.
نمونه تنظیم Admin Password در cfg.xml
نام Tag دقیق می‌تواند با نسخه Firmware و Template شما متفاوت باشد؛ قبل از Deploy، XML Reference همان Firmware را تطبیق دهید. الگوی کلی به این شکل است:
<Admin_Password ua="na">CHANGE-TO-A-UNIQUE-LONG-PASSWORD</Admin_Password>Credential واقعی را داخل مقاله، Wiki عمومی، Ticket یا Repository بدون Secret Management نگه ندارید.
مرحله ۲: دسترسی User را با ua محدود کنید
یکی از قابلیت‌های مهم MPP، ویژگی User Access Attribute یا همان ua است. با آن می‌توانید مشخص کنید User به هر Parameter چه نوع دسترسی داشته باشد:
🔹 na: بدون دسترسی.
🔹 ro: فقط خواندن.
🔹 rw: خواندن و نوشتن.
برای پارامترهای حساسی مثل SIP Proxy، Profile Rule، Credential و Security Setting بهتر است User دسترسی Write نداشته باشد.
نمونه:
<flat-profile>
<SIP_TOS_DiffServ_Value_1_ ua="na"/>
<Dial_Plan_1_ ua="ro"/>
<Speed_Dial_1_ ua="rw"/>
</flat-profile>هدف این نیست که همه چیز را `na` کنید؛ باید بین امنیت و نیاز واقعی User تعادل برقرار شود.
مرحله ۳: Web UI را فقط با HTTPS باز بگذارید
اگر Web UI برای مدیریت Local لازم است، HTTP ساده انتخاب مناسبی نیست. در تنظیمات MPP می‌توانید Web Server را فعال نگه دارید اما Protocol را روی HTTPS بگذارید.
مسیر معمول در Web UI:
Admin Login
→ advanced
→ Voice
→ System
→ Enable Web Server
→ Enable Protocol: Httpsپورت پیش‌فرض HTTPS در این بخش 443 است.
اگر Web UI اصلاً لازم نیست، آن را خاموش کنید
اگر تمام مدیریت از Provisioning Server انجام می‌شود و هیچ نیاز عملی به Web Interface ندارید، بهترین سطح Attack Surface این است که Web Server خاموش باشد.
<Enable_Web_Server ua="na">No</Enable_Web_Server>اگر Web Server را لازم دارید ولی نمی‌خواهید User یا Technician عادی به Admin Page برسد، می‌توانید Admin Access را جداگانه محدود کنید.
<Enable_Web_Admin_Access ua="na">No</Enable_Web_Admin_Access>هشدار: Cisco هشدار می‌دهد اگر Admin Web Access را ببندید، بازیابی Local آن می‌تواند به Factory Reset نیاز پیدا کند. قبل از Deploy گروهی، حتماً مطمئن شوید Provisioning Server و Recovery Path سالم هستند.
مرحله ۴: Provisioning را از HTTP/TFTP به HTTPS ببرید
فایل Provisioning ممکن است اطلاعات بسیار حساسی داشته باشد: SIP Username، Proxy، Auth Parameter، Server Address و حتی Secretهای مدیریتی. انتقال Plaintext آن روی HTTP یا TFTP ریسک بزرگی است.
برای MPP بهتر است Profile Rule از HTTPS استفاده کند:
https://prov.example.com/cisco/$MA.cfg`$MA` نمونه متغیر MAC است. نام دقیق فایل و Macroها را با Provisioning Guide همان Firmware تطبیق دهید.
HTTPS به‌تنهایی کافی نیست
این نکته بسیار مهم است. اگر Provisioning Server روی HTTPS باشد اما هر Clientی که URL را حدس بزند بتواند فایل Config را دانلود کند، Transport رمز شده است ولی Access Control شما هنوز ضعیف است.
Cisco برای Secure HTTPS Resync امکان Client Certificate Authentication را مستند کرده است. در این مدل، Server فقط Phoneای را می‌پذیرد که Client Certificate معتبر داشته باشد.
نمونه در Apache:
SSLVerifyClient requireدر این حالت Provisioning Server هم Phone را Authenticate می‌کند و Phone هم Server را از طریق Certificate بررسی می‌کند.
مرحله ۵: SIP Signaling را روی TLS ببرید
TLS محتوای SIP Signaling را در مسیر رمز می‌کند. یعنی REGISTER، INVITE، Headerها و بسیاری از اطلاعات Signaling به‌صورت Plaintext روی شبکه عبور نمی‌کنند.
روی Extension موردنظر:
Voice
→ Ext(n)
→ SIP Settings
→ SIP Transport: TLSدر XML:
<SIP_Transport_1_ ua="na">TLS</SIP_Transport_1_>اما TLS فقط Signaling را امن می‌کند. برای Audio باید SRTP را جداگانه در نظر بگیرید.
مرحله ۶: SRTP را برای Media فعال کنید
اگر SIP روی TLS باشد ولی Media همچنان RTP معمولی باشد، Voice Payload روی شبکه رمز نشده باقی می‌ماند. MPP برای Secure Call و SRTP تنظیم جداگانه دارد.
ابتدا Secure Call Service باید فعال باشد:
<Secure_Call_Serv ua="na">Yes</Secure_Call_Serv>سپس روی Extension می‌توانید Secure Call Option را متناسب با PBX یا Provider تنظیم کنید:
<Secure_Call_Option_1_ ua="na">Strict</Secure_Call_Option_1_>در حالت Strict، Cisco رفتار امنیتی سخت‌گیرانه‌تری اعمال می‌کند و وقتی SIP Transport روی TLS است، SRTP را انتظار دارد. این گزینه را بدون بررسی PBX/Provider فعال نکنید؛ اگر سمت مقابل Secure Media را پشتیبانی نکند، تماس ممکن است Fail شود و حتی با Responseهایی مثل 488 روبه‌رو شوید.
مرحله ۷: Hostname Verification را برای SIP TLS خاموش نکنید
یکی از اشتباه‌های رایج Troubleshooting این است که برای حل سریع Certificate Error، گزینه Hostname Validation را خاموش می‌کنند و همان حالت در Production باقی می‌ماند.
MPP می‌تواند Hostname موجود در Connection را با SAN یا CN داخل Certificate مقایسه کند. اگر Hostname Match نباشد، TLS Connection نباید قابل اعتماد تلقی شود.
برای SIP TLS:
<TLS_Name_Validate_1_ ua="na">Yes</TLS_Name_Validate_1_>Cisco برای این گزینه مقدار پیش‌فرض `Yes` را مستند کرده است. اگر Certificate با FQDN درست Match نمی‌شود، Certificate یا DNS را اصلاح کنید؛ Validation را به‌عنوان راه‌حل دائمی خاموش نکنید.
مرحله ۸: Chain و Custom CA را درست مدیریت کنید
حتی اگر Certificate ظاهراً معتبر باشد، Provisioning یا SIP TLS می‌تواند به‌خاطر Chain ناقص Fail شود. Cisco در FAQ مربوط به MPP نیز اشاره می‌کند که نبود Intermediate CA روی Server می‌تواند باعث عدم Trust شود.
اگر Provisioning Server شما با CA اختصاصی امضا شده است، Custom CA Status را روی Phone بررسی کنید و مطمئن شوید Certificate Chain کامل است.
برای HTTPS و TLS همیشه این موارد را کنترل کنید:
🔹 Certificate منقضی نشده باشد.
🔹 SAN/CN با FQDN واقعی Server Match باشد.
🔹 Intermediate Certificateها روی Server کامل باشند.
🔹 Root CA موردنیاز روی Phone Trust شود.
🔹 NTP و زمان Phone صحیح باشد.
Certificate درست با ساعت اشتباه هم می‌تواند Fail شود، چون Validity Window بر اساس زمان بررسی می‌شود.
مرحله ۹: Restricted Access Domains را به‌عنوان Allowlist استفاده کنید
MPP قابلیتی به نام Restricted Access Domains دارد. این تنظیم می‌تواند Phone را محدود کند تا Registration، Provisioning، Firmware Upgrade و Report را فقط با Serverهایی انجام دهد که شما مشخص کرده‌اید.
نمونه:
<Restricted_Access_Domains ua="na">prov.example.com,sip.example.com</Restricted_Access_Domains>این قابلیت بسیار ارزشمند است، اما یک نکته مهم دارد: همه Serverهایی که Phone واقعاً نیاز دارد باید داخل Allowlist باشند؛ از جمله Profile Rule، Upgrade Rule، Report Rule، Custom CA Rule و Proxy/Outbound Proxy مربوطه.
Restricted Access Domains با IP ACL یکی نیست
این تنظیم محدودیت Domain در خود Phone است، نه یک Source-IP ACL برای اینکه چه Administratorی بتواند به Web UI وصل شود.
برای محدودکردن Management Sourceها، بهتر است روی Voice VLAN یا Management Firewall فقط Subnet یا Jump Host مدیریتی را به HTTPS Phoneها راه بدهید و دسترسی سایر Client VLANها را ببندید.
برای نمونه معماری:
Admin VLAN / Jump Host
|
| HTTPS 443
v
Voice VLAN → Cisco MPP
User VLAN ──X──→ Phone Web Adminمرحله ۱۰: Firewall داخلی Phone را خاموش نکنید
Cisco برای MPP Firewall داخلی دارد و در مستندات فعلی مقدار پیش‌فرض آن Enabled است. Firewall ورودی‌های غیرمنتظره را Block می‌کند و برای Flowهایی که Phone خودش ایجاد کرده، Return Traffic را به‌صورت Dynamic اجازه می‌دهد.
اگر Firewall خاموش شده است:
<Firewall ua="na">Enabled</Firewall>در Firewall Options نیز قابلیت‌هایی مانند Block کردن ICMP Echo یا محدودیت‌های TFTP وجود دارد. اما این گزینه‌ها را فقط با درک Dependencyهای شبکه تغییر دهید.
مثلاً:
<Firewall_Config ua="na">NO_ICMP_PING</Firewall_Config>این کار Ping ورودی را Block می‌کند و می‌تواند بعضی روش‌های Traceroute را هم تحت تأثیر قرار دهد؛ پس Blind Hardening انجام ندهید.
مرحله ۱۱: سرویس‌های بلااستفاده را ببندید
اصل ساده است: هر Featureی که فعال است، Attack Surface و Dependency خودش را دارد. اگر استفاده نمی‌شود، خاموش‌کردن آن معمولاً بهتر از رهاکردن Default است.
| سرویس/قابلیت | اگر استفاده نمی‌شود | قبل از خاموش‌کردن چه چیزی را چک کنیم؟ |
|---|---|---|
| Web Server | غیرفعال | آیا Local Admin لازم است؟ |
| Web Admin Access | محدود/غیرفعال | Recovery Path دارید؟ |
| TR-069 | غیرفعال | آیا ACS سازمان از آن استفاده می‌کند؟ |
| PC Port | غیرفعال | آیا PC از پشت Phone به شبکه وصل است؟ |
| PC Port Mirror | خاموش بماند | فقط برای Troubleshooting روشن شود |
| CDP/LLDP | فقط در صورت عدم نیاز خاموش | Voice VLAN، PoE/QoS و Switch Discovery وابسته نیست؟ |
| TFTP/HTTP Provisioning | به HTTPS مهاجرت | Server و Certificate آماده‌اند؟ |
TR-069
اگر ACS ندارید و TR-069 بخشی از Deployment شما نیست، آن را فعال نکنید. Default فعلی Cisco برای این Feature برابر No است.
<Enable_TR-069 ua="na">No</Enable_TR-069>PC Port
اگر هیچ PC یا Device دیگری پشت Phone وصل نیست، PC Port را هم می‌توانید غیرفعال کنید:
<PC_PORT_Enable ua="na">No</PC_PORT_Enable>PC Port Mirroring نیز در حالت عادی باید خاموش بماند و فقط برای Troubleshooting موقت روشن شود.
مرحله ۱۲: CDP و LLDP را کورکورانه خاموش نکنید
از دید Hardening، پروتکل‌های Discovery می‌توانند اطلاعات Topology ارائه دهند؛ اما در شبکه Voice ممکن است برای Voice VLAN، Power Negotiation یا QoS به آن‌ها وابسته باشید.
بنابراین:
🔹 اگر Voice VLAN با CDP/LLDP-MED تحویل می‌شود، خاموش‌کردن آن می‌تواند Phone را از VLAN صحیح خارج کند.
🔹 اگر هیچ Dependency ندارید و VLAN/Power به روش دیگری مشخص است، می‌توانید خاموش‌کردن را در Lab تست کنید.
🔹 تصمیم باید بر اساس Design Network باشد، نه صرفاً Checklist امنیتی.
مرحله ۱۳: 802.1X را برای کنترل دسترسی شبکه بررسی کنید
در محیط‌های سازمانی، 802.1X می‌تواند تعیین کند Phone قبل از دسترسی به LAN احراز هویت شود. راهنمای فعلی Cisco MPP از EAP-FAST و EAP-TLS پشتیبانی را توضیح می‌دهد و برای EAP-TLS می‌توان از Certificate دستگاه استفاده کرد.
در تنظیم XML:
<Enable_802.1X_Authentication ua="rw">Yes</Enable_802.1X_Authentication>اما 802.1X را بدون هماهنگی با Switch و RADIUS/ISE فعال نکنید. اگر Authentication Path آماده نباشد، Phone ممکن است Network Access را از دست بدهد.
مرحله ۱۴: Cipher List را فقط با دلیل تغییر دهید
MPP امکان تعریف TLS Cipher List را در سطح System دارد. این List روی چند Application از جمله Provisioning، SIP over TLS، PRT Upload، WebSocket API و سرویس‌های دیگر اثر می‌گذارد.
نمونه مستند Cisco:
<TLS_Cipher_List ua="na">RSA:!aNULL:!eNULL</TLS_Cipher_List>اما از Copy/Paste کردن Cipher String بدون Test خودداری کنید. ممکن است PBX یا Provisioning Server شما Cipher مشترک نداشته باشد و TLS Handshake Fail شود. ابتدا Supported Cipherها و Server-side Policy را تطبیق دهید.
مرحله ۱۵: Syslog و PRT را برای Audit نگه دارید
Hardening بدون Visibility ناقص است. اگر کسی Config را تغییر دهد، Provisioning Fail شود یا TLS Handshake مشکل داشته باشد، Syslog و PRT باید امکان بازسازی اتفاق را بدهند.
برای محیط‌های بزرگ:
🔹 Syslog Server مرکزی داشته باشید.
🔹 NTP دقیق و یکسان روی Phoneها داشته باشید.
🔹 Version و Config Baseline را نگه دارید.
🔹 تغییر Template را با Change Control انجام دهید.
🔹 PRT را فقط هنگام Incident نخواهید؛ مسیر Upload آن را از قبل تست کنید.
یک Baseline پیشنهادی برای Cisco MPP
| کنترل | وضعیت پیشنهادی |
|---|---|
| Admin Password | طولانی، یکتا و مدیریت‌شده |
| User Access | حداقل دسترسی لازم |
| Web UI | HTTPS؛ یا کاملاً Disabled اگر نیاز نیست |
| Web Admin Access | فقط در صورت نیاز و با Recovery Path |
| Provisioning | HTTPS + Access Control |
| Client Authentication | در Deploymentهای حساس، Certificate-based |
| SIP Signaling | TLS در صورت پشتیبانی PBX/Provider |
| Media | SRTP در صورت پشتیبانی End-to-End |
| TLS Name Validate | Yes |
| Restricted Access Domains | Allowlist Serverهای لازم |
| Phone Firewall | Enabled |
| TR-069 | No مگر واقعاً استفاده شود |
| PC Port | خاموش اگر استفاده نمی‌شود |
| PC Port Mirror | خاموش مگر Troubleshooting |
| 802.1X | برای محیط سازمانی در صورت آمادگی شبکه |
| Syslog/NTP | مرکزی و تست‌شده |
می‌خواهید Cisco MPP را Hardening کنید اما Registration یا Provisioning قطع نشود؟
برای یک Hardening امن باید قبل از تغییر، مسیر Provisioning، نوع PBX، SIP Transport، Certificate Chain، Voice VLAN و Recovery Path هر Phone مشخص باشد. فعال‌کردن TLS/SRTP یا بستن Admin Access بدون بررسی Dependencyها می‌تواند Phone را از سرویس خارج کند.
ایرانیکاسرور می‌تواند در بررسی Cisco MPP، Asterisk/FreePBX، Provisioning، SIP TLS، SRTP و طراحی امن شبکه VoIP کمک کند تا Hardening با کمترین Downtime انجام شود.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج
آیا فقط گذاشتن Admin Password برای امنیت Cisco MPP کافی است؟
خیر. Web UI، Provisioning، SIP Signaling، Media، Certificateها، Firewall و سرویس‌های مدیریتی باید جداگانه بررسی شوند.
HTTPS Provisioning چه مزیتی نسبت به HTTP دارد؟
HTTPS محتوای Configuration را در مسیر رمز می‌کند و امکان احراز هویت Server را فراهم می‌کند. برای امنیت بالاتر، Provisioning Server می‌تواند Client Certificate خود Phone را هم Verify کند.
TLS و SRTP چه فرقی دارند؟
TLS برای امن‌کردن SIP Signaling استفاده می‌شود. SRTP محتوای Media مانند Voice را رمز می‌کند. داشتن TLS بدون SRTP به معنی رمزشدن خود Audio نیست.
آیا TLS Name Validate را برای رفع خطا خاموش کنیم؟
به‌عنوان راه‌حل دائمی خیر. اگر Certificate با Hostname مطابقت ندارد، SAN/CN، DNS و Certificate Chain را اصلاح کنید.
Restricted Access Domains همان ACL است؟
خیر. این قابلیت Domainهایی را محدود می‌کند که Phone برای Registration، Provisioning، Upgrade و Report به آن‌ها مراجعه می‌کند. Source-IP ACL برای مدیریت بهتر است در Firewall یا شبکه Voice پیاده‌سازی شود.
آیا Firewall داخلی Cisco MPP باید روشن باشد؟
بله؛ در مستندات فعلی Cisco مقدار پیش‌فرض Firewall داخلی Enabled است. فقط برای Troubleshooting مشخص و موقت آن را تغییر دهید.
آیا TR-069 را خاموش کنیم؟
اگر ACS و TR-069 در Deployment شما استفاده نمی‌شود، بله؛ Default مستند Cisco نیز No است. اگر Provider از TR-069 برای مدیریت Phone استفاده می‌کند، بدون هماهنگی آن را خاموش نکنید.
آیا 802.1X برای تلفن Cisco MPP لازم است؟
برای همه شبکه‌ها الزامی نیست، اما در محیط‌های سازمانی می‌تواند کنترل دسترسی Network را قوی‌تر کند. قبل از فعال‌سازی باید Switch، RADIUS/ISE و Certificate Policy آماده باشند.
جمع‌بندی
Hardening تلفن Cisco MPP یک Setting واحد نیست. Password قوی فقط اولین لایه است. Web UI را به HTTPS محدود کنید یا اگر نیاز ندارید ببندید، Access کاربر را با `ua` کنترل کنید و فایل Provisioning را از HTTP/TFTP به HTTPS منتقل کنید.
برای Signaling از SIP over TLS و برای Media از SRTP استفاده کنید؛ اما قبل از سخت‌گیرکردن Policy مطمئن شوید PBX و Provider هر دو پشتیبانی لازم را دارند. TLS Name Validation و Certificate Chain را درست نگه دارید و برای Provisioning حساس از Client Certificate Authentication استفاده کنید.
در نهایت، Restricted Access Domains، Firewall داخلی، 802.1X و حذف سرویس‌های بلااستفاده Attack Surface را کم می‌کنند. هر تغییری را ابتدا روی یک Phone آزمایشی اجرا کنید و فقط بعد از تست Registration، تماس، Provisioning و Recovery آن را در Template اصلی منتشر کنید.
برای امن‌سازی Cisco MPP بدون قطع Provisioning کمک می‌خواهید؟
اگر Phoneها در Production هستند، قبل از بستن Web Admin، تغییر TLS/SRTP یا محدودکردن Domainها باید Dependencyهای PBX، Provisioning Server، Voice VLAN و Certificate Chain دقیق بررسی شوند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)