Amir Jabbari
در این راهنما یک Cisco MPP را از دید عملی سخت‌سازی می‌کنیم: Admin Credential، پنل وب، HTTPS Provisioning، Certificate، SIP over TLS، SRTP، Firewall داخلی، Restricted Access Domains، ACL شبکه و سرویس‌های بلااستفاده را مرحله‌به‌مرحله بررسی می‌کنیم.
هدف این نیست که همه قابلیت‌ها را خاموش کنیم. هدف این است که فقط سرویس‌هایی که واقعاً نیاز دارید فعال بمانند و هر مسیر مدیریتی یا ارتباطی تا جای ممکن احراز هویت، رمزنگاری و محدود شود.
اصل مهم: TLS و SRTP دو چیز متفاوت‌اند. TLS از Signaling محافظت می‌کند؛ SRTP از خود Media یا صدای تماس. فعال‌بودن SIP over TLS به‌تنهایی به معنی رمزنگاری صدا نیست.
امنیت Cisco MPP را به ۶ لایه تقسیم کنید
به‌جای تغییر تصادفی چند گزینه، امنیت را در این شش لایه بررسی کنید:
🔹 دسترسی Admin و User
🔹 پنل مدیریت Web
🔹 Provisioning و Firmware
🔹 SIP Signaling
🔹 RTP Media
🔹 شبکه، Firewall و سرویس‌های جانبی
نسخه Firmware را قبل از Hardening ثبت کنید
رفتار Security در همه Firmwareها دقیقاً یکسان نیست.
در زمان بررسی این مقاله، آخرین Release Note رسمی موجود برای Cisco MPP سری 7800 و 8800 نسخه 12.0(7)SR5 با تاریخ ۳۱ مارس ۲۰۲۶ است.
این Release یک Maintenance Release است و Cisco برای Upgrade همچنان TFTP، HTTP و HTTPS را پشتیبانی می‌کند.
قبل از اعمال Policy امنیتی، Model و Firmware هر Endpoint را ثبت کنید و Release Notes همان شاخه را بررسی کنید.
مرحله ۱: Admin Password واقعی تعریف کنید
در Cisco MPP دو حساب اصلی وجود دارد:
🔹 admin برای مدیریت کامل
🔹 user برای دسترسی محدود کاربر
نام این Accountها قابل تغییر نیست.
نکته مهم این است که Cisco برای آن‌ها یک Password عمومی مثل admin/admin تعریف نکرده است.
در راهنمای فعلی، Password پنل وب باید ۸ تا ۱۲۷ کاراکتر داشته باشد و حداقل از سه دسته بین حروف بزرگ، حروف کوچک، عدد و Symbol استفاده کند.
چرا رمز مشترک برای همه تلفن‌ها بد است؟
اگر ۵۰ تلفن با یک Admin Password یکسان داشته باشید، افشای Credential یک دستگاه عملاً دسترسی به کل Endpointها را باز می‌کند.
برای محیط‌های جدی بهتر است Credentialها از Provisioning امن مدیریت شوند و دسترسی به Config Server نیز محدود باشد.
اگر معماری شما اجازه می‌دهد، Admin Password را per-device یا حداقل per-site متفاوت کنید.
نمونه تنظیم Admin Password با Provisioning
ساختار XML در MPP می‌تواند به این شکل باشد:
<Admin_Password ua="na">YOUR-STRONG-UNIQUE-PASSWORD</Admin_Password>مقدار بالا فقط Placeholder است. رمز واقعی را داخل نمونه عمومی، Git Repository یا فایل Config قابل‌دانلود عمومی قرار ندهید.
مرحله ۲: پنل مدیریت را روی HTTPS قرار دهید
اگر Web Administration نیاز دارید، HTTP انتخاب مناسبی برای مدیریت Endpoint نیست.
در MPP جدید:
Voice → System
این دو پارامتر را بررسی کنید:
🔹 Enable Protocol = Https
🔹 Web Server Port = 443
نمونه Provisioning:
<Enable_Protocol ua="na">Https</Enable_Protocol>
<Web_Server_Port ua="na">443</Web_Server_Port>در Firmwareهای جدید HTTPS اهمیت بیشتری پیدا کرده است
Cisco در Access Control فعلی توضیح می‌دهد که از Firmware 12.0(3)، دسترسی Web Administration روی HTTPS هدایت می‌شود.
این تغییر مهم است چون Credential Admin نباید روی HTTP ساده در شبکه منتقل شود.
اگر اصلاً به پنل Web نیاز ندارید، آن را خاموش کنید
بهترین پنل مدیریتیِ محافظت‌شده، پنلی است که اصلاً در دسترس کاربران عادی شبکه نباشد.
اگر تمام Endpointها با Provisioning مرکزی مدیریت می‌شوند و Web UI در عملیات روزانه لازم نیست، می‌توانید:
<Enable_Web_Server ua="na">No</Enable_Web_Server>را در نظر بگیرید.
این کار کل Phone Web Interface را از دسترس خارج می‌کند؛ پس قبل از آن مطمئن شوید روش Provisioning و Recovery شما سالم است.
فقط بخش Admin را هم می‌توان محدود کرد
اگر User Web UI لازم است اما Admin UI نباید در دسترس باشد، Cisco پارامتر جداگانه دارد:
<Enable_Web_Admin_Access ua="na">No</Enable_Web_Admin_Access>اما یک هشدار مهم وجود دارد: Cisco می‌گوید اگر Admin Access از Web غیرفعال شود، برای فعال‌کردن دوباره آن ممکن است نیاز به Factory Reset از خود تلفن داشته باشید.
پس این گزینه را فقط وقتی اعمال کنید که Recovery Plan دارید.
مرحله ۳: User Access را محدود کنید
MPP اجازه می‌دهد هر Parameter برای کاربر یکی از این حالت‌ها را داشته باشد:
🔹 قابل ویرایش
🔹 فقط خواندنی
🔹 کاملاً مخفی
در Profile، Attributeهای:
ua="rw"
ua="ro"
ua="na"به‌ترتیب برای Write، Read Only و No Access استفاده می‌شوند.
تنظیمات حساسی مثل Provisioning Rule، SIP Credential، Factory Reset و Network Policy را برای End User قابل تغییر نگذارید.
مثال؛ VLAN دیده شود ولی تغییر نکند
<Enable_VLAN ua="ro">Yes</Enable_VLAN>در این حالت کاربر می‌تواند مقدار را ببیند اما آن را تغییر نمی‌دهد.
مرحله ۴: Provisioning را از HTTP به HTTPS ببرید
Provisioning یکی از حساس‌ترین بخش‌های امنیت MPP است.
Config Profile می‌تواند شامل مواردی مثل:
🔹 SIP Server
🔹 Username و Auth ID
🔹 Credentialها
🔹 BLF و Featureها
🔹 Admin Policy
🔹 Upgrade Rule
باشد.
اگر این Profile بدون محافظت در شبکه منتقل شود، مهاجم می‌تواند اطلاعات مهم را بخواند یا تلاش کند Phone را به Provisioning Server دیگری هدایت کند.
HTTPS Provisioning چه چیزی را حل می‌کند؟
HTTPS دو کار مهم انجام می‌دهد:
رمزنگاری: Profile در مسیر به‌صورت واضح قابل مشاهده نیست.
احراز هویت Server: تلفن بررسی می‌کند با Provisioning Server مورد انتظار صحبت می‌کند.
MPP همچنین Client Certificate اختصاصی دارد و Provisioning Server می‌تواند برای احراز هویت Device از Client Certificate استفاده کند.
Provisioning Server را با FQDN تعریف کنید
برای HTTPS بهتر است Server با FQDN معتبر شناخته شود، نه IP خام.
Certificate باید با نام Server سازگار باشد و DNS نیز FQDN را به IP موردنظر Resolve کند.
Cisco برای Provisioning توضیح می‌دهد Phone علاوه بر Certificate، تطبیق نام Server و DNS را نیز بررسی می‌کند.
این یعنی اگر Certificate برای:
provision.example.comصادر شده، استفاده مستقیم از یک IP متفاوت ممکن است Certificate Validation را خراب کند.
Certificate Provisioning در MPP یک نکته تاریخی دارد
در مدل Secure Provisioning کلاسیک Cisco، Provisioning Server می‌تواند از Certificate امضاشده توسط Cisco Server CA استفاده کند و Phone نیز Client Certificate اختصاصی ارائه دهد.
در مستندات فعلی همچنین پشتیبانی از Certificateهای Third-Party و Custom CA دیده می‌شود.
پس برای Deployment جدید نباید فرض کنید هر Certificate عمومی یا Self-Signed بدون تنظیم Trust روی همه Firmwareها پذیرفته می‌شود.
Trust Chain واقعی همان Firmware و همان Provisioning Workflow را آزمایش کنید.
Certificate را فقط به خاطر خطای TLS دور نزنید
در صورت Certificate Error این موارد را بررسی کنید:
🔹 Expiry Date
🔹 Not Before
🔹 CN/SAN
🔹 Intermediate Chain
🔹 Trusted Root
🔹 DNS
🔹 ساعت و NTP تلفن
راه درست این نیست که Validation را خاموش کنید تا Connection برقرار شود.
مرحله ۵: Restricted Access Domains را فعال کنید
این قابلیت یکی از مفیدترین ابزارهای امنیتی MPP است.
Cisco اجازه می‌دهد FQDNهایی را مشخص کنید که تلفن فقط از همان Serverها برای مواردی مثل Registration، Provisioning، Firmware Upgrade و Report Upload استفاده کند.
نمونه:
<Restricted_Access_Domains ua="na">prov.example.com,sip.example.com,firmware.example.com</Restricted_Access_Domains>اگر از این قابلیت استفاده می‌کنید، همه Serverهای لازم باید در لیست باشند؛ وگرنه خودتان Provisioning یا Registration را Block می‌کنید.
Restricted Domains چه حمله‌ای را سخت‌تر می‌کند؟
فرض کنید کسی Profile Rule یا Upgrade Rule را به یک Domain ناشناس تغییر دهد.
اگر Phone فقط به Domainهای از قبل مجاز اجازه Provisioning و Upgrade بدهد، مسیر سوءاستفاده محدودتر می‌شود.
این قابلیت جای Firewall شبکه را نمی‌گیرد، اما یک کنترل Endpoint-side مهم است.
مرحله ۶: SIP Signaling را با TLS امن کنید
در MPP برای هر Extension می‌توانید SIP Transport را روی TLS قرار دهید:
Voice → Ext(n) → SIP Settings → SIP Transport
نمونه:
<SIP_Transport_1_ ua="na">TLS</SIP_Transport_1_>TLS از SIP Messageها مثل REGISTER، INVITE، REFER و NOTIFY در مسیر محافظت می‌کند.
TLS صدا را رمزنگاری نمی‌کند
این اشتباه بسیار رایج است.
SIP over TLS فقط Signaling را رمز می‌کند.
برای محافظت از Media باید SRTP فعال باشد.
پس یک تماس می‌تواند SIP TLS داشته باشد ولی RTP آن هنوز بدون رمزنگاری باشد، مگر Media Security نیز درست Negotiation شده باشد.
مرحله ۷: برای تماس امن SRTP را بررسی کنید
در Cisco MPP می‌توان Secure Call Service و Secure Call Option را Configure کرد.
گزینه‌های اصلی شامل:
🔹 Optional
🔹 Required
🔹 Strict
در حالت Strict، وقتی SIP Transport روی TLS باشد، Phone فقط SRTP را می‌پذیرد.
نمونه:
<Secure_Call_Serv ua="na">Yes</Secure_Call_Serv>
<Secure_Call_Option_1_ ua="na">Strict</Secure_Call_Option_1_>Strict را بدون بررسی PBX فعال نکنید
اگر PBX یا Provider شما SRTP و TLS را End-to-End پشتیبانی نکند، فعال‌کردن Strict می‌تواند تماس را قطع کند.
اول در محیط Test بررسی کنید:
🔹 Registrar از SIP TLS پشتیبانی می‌کند؟
🔹 Certificate آن معتبر است؟
🔹 SBC و Trunk از SRTP پشتیبانی می‌کنند؟
🔹 Transfer، Hold و Conference هم Secure باقی می‌مانند؟
مرحله ۸: TLS Hostname Validation را خاموش نکنید
در SIP over TLS، Certificate فقط باید از CA مورد اعتماد باشد؛ نام Server هم باید با Certificate تطبیق داشته باشد.
MPP پارامتر:
<TLS_Name_Validate_1_ ua="na">Yes</TLS_Name_Validate_1_>را برای این کار دارد.
مقدار پیش‌فرض فعلی Cisco برابر Yes است.
اگر Certificate Error دارید، به‌جای تبدیل این گزینه به No، Certificate و DNS را اصلاح کنید.
Hostname Verification دقیقاً چه چیزی را می‌سنجد؟
Phone می‌تواند نام Host را با SAN و CN داخل Certificate مقایسه کند.
اگر تلفن به:
sip.example.comوصل می‌شود، Certificate باید برای همین Hostname معتبر باشد.
مرحله ۹: حداقل TLS را پایین نیاورید مگر مجبور باشید
در MPP جدید، مقدار پیش‌فرض TLS Client Min Version و TLS Server Min Version برابر TLS 1.2 است.
نمونه:
<TLS_Client_Min_Version ua="na">TLS 1.2</TLS_Client_Min_Version>
<TLS_Server_Min_Version ua="na">TLS 1.2</TLS_Server_Min_Version>اگر Server قدیمی فقط TLS 1.0 را پشتیبانی می‌کند، راه بهتر Upgrade کردن Server است، نه ضعیف‌کردن همه Phoneها.
TLS 1.3 روی همه MPPها یکسان نیست
در XML Reference فعلی Cisco، TLS 1.3 برای بعضی Conference Phoneهای 7832/8832 از Release 12.0(7)SR3 به بعد در این تنظیمات ذکر شده است.
پس قبل از انتخاب TLS 1.3، Model و Firmware را دقیق بررسی کنید و آن را به همه 7800/8800ها تعمیم ندهید.
مرحله ۱۰: Cipher List را بی‌دلیل دست‌کاری نکنید
MPP امکان تعریف TLS Cipher List را دارد.
این قابلیت مفید است، اما یک Cipher Policy اشتباه می‌تواند تمام Provisioning، SIP TLS، LDAPS و سرویس‌های دیگر را قطع کند؛ چون Cisco همان Cipher List را روی چند TLS Application استفاده می‌کند.
اگر Compliance خاصی ندارید، ابتدا Default/Supported Policy خود Firmware را بررسی کنید و بعد Cipherها را محدود کنید.
مرحله ۱۱: Firewall داخلی تلفن را روشن نگه دارید
در MPP جدید Firewall داخلی به‌صورت پیش‌فرض Enabled است.
این Firewall ترافیک ورودی غیرمنتظره را Block می‌کند و برای Flowهای خروجی، Return Traffic لازم را به‌صورت Stateful اجازه می‌دهد.
مسیر:
Voice → System → Security Settings → Firewall
نمونه:
<Firewall ua="na">Enabled</Firewall>چه Portهایی با Featureها باز می‌شوند؟
Cisco Firewall به بعضی Featureهای فعال وابسته است.
برای مثال:
🔹 SIP Port وقتی Line با UDP فعال باشد
🔹 RTP/RTCP Range برای Media
🔹 Web Server Port وقتی Web Server فعال باشد
🔹 Peer Firmware Sharing Port وقتی PFS فعال باشد
🔹 TR-069 Connection Request Port وقتی TR-069 فعال باشد
این دقیقاً دلیل خوبی است که Featureهای بلااستفاده را روشن نگذارید.
Unused Services را چطور مدیریت کنیم؟
یک Audit ساده انجام دهید و برای هر Phone مشخص کنید آیا واقعاً این Featureها لازم‌اند:
🔹 Web Administration
🔹 TR-069
🔹 Peer Firmware Sharing
🔹 WebSocket/Remote API
🔹 Automatic PRT Upload
🔹 Webex Metrics در محیطی که استفاده نمی‌شود
🔹 XML یا Directory Serviceهای خارجی
هر Feature بلااستفاده‌ای که Listener، Credential یا اتصال بیرونی اضافه می‌کند، سطح حمله و پیچیدگی مدیریت را بیشتر می‌کند.
مرحله ۱۲: ACL شبکه را روی Management Traffic اعمال کنید
Firewall داخلی Phone مفید است، اما شبکه نیز باید محدودیت خودش را داشته باشد.
در طراحی سازمانی، لازم نیست همه PCهای Voice/Data VLAN بتوانند به Port 443 مدیریت همه تلفن‌ها وصل شوند.
در Switch ACL یا Firewall می‌توانید دسترسی Management را فقط از:
🔹 Management VLAN
🔹 Jump Host
🔹 Provisioning Server
🔹 Monitoring Serverهای مشخص
مجاز کنید.
این ACL را قبل از Rollout روی یک Phone آزمایشی تست کنید تا Provisioning، PRT یا Monitoring لازم را ناخواسته قطع نکنید.
Voice VLAN به‌تنهایی Security Boundary کامل نیست
جداکردن Phoneها در Voice VLAN اقدام خوبی است، اما اگر بین VLANها ACL وجود نداشته باشد، یک Client آلوده در VLAN دیگر ممکن است همچنان به Web UI یا SIP Port تلفن‌ها دسترسی داشته باشد.
VLAN Segmentation را با ACL و Firewall تکمیل کنید.
مرحله ۱۳: 802.1X را برای شبکه‌های حساس بررسی کنید
MPP از 802.1X پشتیبانی می‌کند.
در محیط‌هایی که اتصال هر Device به Switch Port باید احراز هویت شود، 802.1X می‌تواند مانع ورود ساده دستگاه ناشناس به Voice Network شود.
این موضوع نیازمند هماهنگی Phone، Switch و Authentication Server است و نباید بدون Pilot روی کل شبکه فعال شود.
Custom Device Certificate و SCEP
در MPP جدید امکان نصب Custom Device Certificate و Enrollment خودکار از طریق SCEP وجود دارد.
این قابلیت برای سناریوهایی مثل 802.1X و PKI سازمانی مفید است.
Cisco برای SCEP Root CA Fingerprint از SHA-256 یا SHA-1 پشتیبانی مستند دارد؛ برای طراحی جدید، اگر زیرساخت شما اجازه می‌دهد SHA-256 انتخاب منطقی‌تری است.
در Certificate Enrollment، Private Key و Challenge Password را مثل Credential حساس مدیریت کنید.
ساعت تلفن بخشی از امنیت TLS است
اگر NTP درست کار نکند، Certificate Validation ممکن است Fail شود.
قبل از اینکه Certificate را Trust کنید یا Validation را خاموش کنید، این موارد را چک کنید:
🔹 NTP Reachability
🔹 Date/Time تلفن
🔹 Time Zone
🔹 Not Before/Not After Certificate
Provisioning Profile را روی Web Server عمومی رها نکنید
یکی از بدترین طراحی‌ها این است که Config File تلفن با URL قابل حدس و بدون Authentication روی اینترنت قرار گیرد.
اگر Filename بر اساس MAC است ولی Directory Listing یا URL قابل حدس است، «مخفی بودن اسم فایل» Security Control کافی نیست.
برای Provisioning Server:
🔹 HTTPS استفاده کنید.
🔹 Authentication مناسب داشته باشید.
🔹 Client Certificate را در صورت معماری مناسب بررسی کنید.
🔹 Directory Listing را ببندید.
🔹 Access Log و Alert داشته باشید.
🔹 Profileها را Version و Backup کنید.
آیا Encryption خود Config File هم لازم است؟
MPP علاوه بر HTTPS، Provisioning Profile Encryption را نیز پشتیبانی می‌کند.
این دو جایگزین کامل هم نیستند.
HTTPS از Channel محافظت می‌کند؛ Profile Encryption می‌تواند در Storage و مسیرهای دیگر لایه اضافه‌ای ایجاد کند.
اگر Config شامل Credential حساس است، طراحی چندلایه ارزش بیشتری دارد.
Syslog را برای Resync و Upgrade فعال کنید
در محیط مدیریت‌شده، Security فقط Prevention نیست؛ Visibility هم مهم است.
Cisco اجازه می‌دهد رویدادهای Resync و Firmware Upgrade به Syslog Server ارسال شوند.
اگر Phone ناگهان از یک Provisioning URL غیرمنتظره Config بگیرد یا Upgrade شکست بخورد، Log مرکزی تشخیص را سریع‌تر می‌کند.
PRT و Packet Capture را بدون کنترل رها نکنید
PRT و PCAP ابزارهای عیب‌یابی بسیار خوبی هستند، اما ممکن است اطلاعات شبکه، SIP Headerها و Metadata حساس داشته باشند.
فایل‌های PRT/PCAP را مثل Log امنیتی مدیریت کنید:
🔹 فقط برای تیم مجاز قابل دسترسی باشند.
🔹 بعد از پایان Incident بی‌دلیل عمومی نگه‌داری نشوند.
🔹 قبل از اشتراک با شخص ثالث اطلاعات حساس بررسی و در صورت لزوم حذف شوند.
یک Baseline پیشنهادی برای Cisco MPP سازمانی
| کنترل | Baseline پیشنهادی |
|---|---|
| Admin Password | قوی، منحصربه‌فرد و مدیریت‌شده |
| Web UI | HTTPS؛ در صورت عدم نیاز خاموش |
| Web Admin Access | فقط برای Admin Network |
| Provisioning | HTTPS و Trust Validation |
| Restricted Domains | فقط FQDNهای موردنیاز |
| SIP | TLS در صورت پشتیبانی PBX/Provider |
| Media | SRTP برای تماس‌های امن |
| TLS Name Validate | Yes |
| TLS Minimum | حداقل TLS 1.2 در مدل‌های پشتیبانی‌شده |
| Phone Firewall | Enabled |
| Unused Services | Disabled |
| Management ACL | فقط Management VLAN/Hosts |
| Firmware | نسخه پشتیبانی‌شده و بررسی Release Notes |
نمونه Profile پایه برای Hardening
نمونه زیر فقط ساختار را نشان می‌دهد و باید با Firmware و معماری واقعی شما تطبیق داده شود:
<Enable_Protocol ua="na">Https</Enable_Protocol>
<Web_Server_Port ua="na">443</Web_Server_Port>
<Firewall ua="na">Enabled</Firewall>
<TLS_Client_Min_Version ua="na">TLS 1.2</TLS_Client_Min_Version>
<TLS_Server_Min_Version ua="na">TLS 1.2</TLS_Server_Min_Version>
<SIP_Transport_1_ ua="na">TLS</SIP_Transport_1_>
<TLS_Name_Validate_1_ ua="na">Yes</TLS_Name_Validate_1_>
<Secure_Call_Serv ua="na">Yes</Secure_Call_Serv>
<Secure_Call_Option_1_ ua="na">Strict</Secure_Call_Option_1_>
<Restricted_Access_Domains ua="na">prov.example.com,sip.example.com</Restricted_Access_Domains>این Profile را مستقیم روی Production اعمال نکنید. اگر PBX شما SIP TLS/SRTP ندارد یا Domainهای لازم از Restricted Access Domains جا افتاده‌اند، تماس یا Provisioning قطع می‌شود.
قبل از Rollout چه تستی بگیریم؟
مرحله ۱: یک Phone آزمایشی انتخاب کنید.
مرحله ۲: Config فعلی و Firmware را ثبت کنید.
مرحله ۳: Admin HTTPS را تست کنید.
مرحله ۴: Resync روی HTTPS را تست کنید.
مرحله ۵: SIP Registration با TLS را بررسی کنید.
مرحله ۶: در یک تماس، SRTP را Verify کنید.
مرحله ۷: Hold، Transfer، BLF و Voicemail را هم تست کنید.
مرحله ۸: Restricted Domains را فعال و Resync/Upgrade را دوباره تست کنید.
مرحله ۹: ACL شبکه را اعمال کنید.
مرحله ۱۰: سپس Policy را مرحله‌ای روی بقیه Endpointها Deploy کنید.
چطور بفهمیم SIP واقعاً TLS شده است؟
صرف دیدن TLS در Config کافی نیست.
در Packet Capture نباید SIP Messageهای REGISTER و INVITE را به‌صورت Plaintext ببینید.
به‌جای آن باید TLS Session به SIP Server دیده شود.
اگر هنوز SIP روی UDP/5060 دیده می‌شود، Transport مورد انتظار اعمال نشده است یا Provisioning بعدی تنظیم را برگردانده است.
چطور بفهمیم Media واقعاً SRTP است؟
در PCAP، RTP معمولی با Payload قابل تشخیص است؛ SRTP Payload رمزنگاری‌شده دارد.
همچنین SDP و Security Negotiation را بررسی کنید.
اگر SIP TLS است ولی Media هنوز RTP است، Secure Call Policy را بازبینی کنید.
Provisioning بعد از Hardening شکست خورد؛ از کجا شروع کنیم؟
این ترتیب را بررسی کنید:
🔹 DNS FQDN درست Resolve می‌شود؟
🔹 Restricted Access Domains شامل Provisioning Server هست؟
🔹 Certificate معتبر و نام آن درست است؟
🔹 NTP/Clock درست است؟
🔹 TLS Minimum با Server سازگار است؟
🔹 Cipher Policy بیش از حد محدود نشده؟
🔹 ACL شبکه HTTPS را Block نکرده؟
برای حل سریع، Validation را خاموش نکنید؛ Fail Point را پیدا کنید.
Registration بعد از فعال‌کردن TLS قطع شد
اگر SIP TLS فعال کردید و Registration Fail شد، این موارد را بررسی کنید:
🔹 Server واقعاً TLS Listener دارد؟
🔹 Port TLS درست است؟
🔹 Certificate Chain کامل است؟
🔹 Hostname با SAN/CN مطابقت دارد؟
🔹 TLS Version مشترک وجود دارد؟
🔹 Provider TLS را برای Account فعال کرده؟
پرسش‌های رایج
برای امنیت Cisco MPP فقط Admin Password کافی است؟
خیر. Admin Password فقط یک لایه است. Provisioning، Web UI، SIP Signaling، Media، Certificate، Firewall و Network ACL نیز باید بررسی شوند.
آیا پنل Cisco MPP باید روی HTTPS باشد؟
بله، اگر Web Administration فعال است بهتر است HTTPS استفاده شود. Firmwareهای جدید MPP نیز مدیریت Web را به سمت HTTPS هدایت کرده‌اند.
فرق HTTPS Provisioning با SIP TLS چیست؟
HTTPS Provisioning از دانلود Config و Firmware Profile محافظت می‌کند؛ SIP TLS از Signaling تماس مثل REGISTER و INVITE محافظت می‌کند.
آیا SIP TLS صدای تماس را هم رمز می‌کند؟
خیر. برای رمزنگاری Media باید SRTP نیز Negotiation و فعال شود.
Restricted Access Domains در Cisco MPP چه کاری می‌کند؟
اجازه می‌دهد Phone فقط از Domainهای مشخص برای Registration، Provisioning، Upgrade و Report استفاده کند و ارتباط با مقصدهای خارج از لیست را محدود می‌کند.
آیا TLS Name Validate را خاموش کنیم تا Registration درست شود؟
در حالت عادی خیر. اگر Certificate نام درست ندارد، DNS یا Certificate را اصلاح کنید. خاموش‌کردن Hostname Validation امنیت TLS را کاهش می‌دهد.
Firewall خود Cisco MPP لازم است؟
بله. در Firmware جدید Firewall داخلی به‌صورت پیش‌فرض فعال است و Incoming Traffic غیرمنتظره را محدود می‌کند.
آیا باید Web Server تلفن را کامل خاموش کنیم؟
اگر مدیریت کاملاً از Provisioning مرکزی انجام می‌شود و Web UI هیچ کاربرد عملی ندارد، خاموش‌کردن آن سطح حمله را کم می‌کند. اما قبل از آن مسیر Recovery را آماده کنید.
آیا TLS 1.3 روی همه Cisco MPPها قابل استفاده است؟
خیر. پشتیبانی TLS 1.3 به Model و Firmware بستگی دارد. برای بسیاری از MPPها TLS 1.2 همچنان Baseline مناسب و پیش‌فرض فعلی است.
جمع‌بندی
امنیت Cisco MPP با یک تنظیم واحد ساخته نمی‌شود. اول Admin Access را قوی کنید، Web UI را روی HTTPS ببرید یا در صورت عدم نیاز خاموش کنید و دسترسی User را محدود کنید.
بعد Provisioning را با HTTPS و Certificate Validation امن کنید، Restricted Access Domains را برای Serverهای مجاز تعریف کنید و SIP Signaling را در صورت پشتیبانی PBX روی TLS قرار دهید.
اگر تماس واقعاً باید امن باشد، SRTP را نیز Verify کنید؛ SIP TLS بدون SRTP فقط Signaling را محافظت می‌کند.
در پایان Firewall داخلی Phone را فعال نگه دارید، Management ACL شبکه را محدود کنید، سرویس‌های بلااستفاده را خاموش کنید و Firmware را روی Release پشتیبانی‌شده نگه دارید.
مهم‌تر از همه، Hardening را ابتدا روی یک Endpoint آزمایشی انجام دهید. امنیتی که باعث قطع Provisioning یا تماس شود، Policy قابل‌استفاده‌ای نیست.
چند تلفن Cisco دارید و نمی‌خواهید Hardening را دستی روی تک‌تک دستگاه‌ها انجام دهید؟
اگر Endpointها با Asterisk، FreePBX، 3CX یا SIP Server اختصاصی کار می‌کنند، امن‌سازی واقعی زمانی پایدار است که Admin Policy، HTTPS Provisioning، TLS/SRTP، Certificate و Restricted Domainها از یک Provisioning Profile مرکزی مدیریت شوند.
ایرانیکاسرور می‌تواند ساختار Provisioning و PBX را بررسی کند، Profile امن و قابل بازیابی طراحی کند و تنظیمات را ابتدا روی یک Phone آزمایشی تست کند تا بعد از Hardening، Registration، BLF، Voicemail، Transfer و KEM دچار اختلال نشوند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)