Amir Jabbari
امنیت Yealink را باید در چند لایه ببینیم؟
| لایه | تهدید | کنترل اصلی |
|---|---|---|
| مدیریت | ورود غیرمجاز به Web UI | رمز قوی، HTTPS و محدودکردن دسترسی |
| SIP Signaling | شنود یا تغییر پیام‌های SIP | TLS |
| صدای تماس | شنود RTP | SRTP |
| Provisioning | تزریق CFG یا سرقت Credential | HTTPS، Authentication و Certificate Validation |
| Configuration | خواندن رمزهای داخل CFG | رمزگذاری Configuration |
| Remote Control | فرمان از سیستم غیرمجاز | Disable یا IP Allow List |
| Network | دسترسی آزاد کاربران Data VLAN | Voice VLAN، ACL و Firewall |
| Firmware | آسیب‌پذیری قدیمی | Firmware به‌روز و Rollout کنترل‌شده |
مرحله اول: رمزهای پیش‌فرض را تغییر دهید
این ساده‌ترین کنترل است، اما هنوز یکی از مهم‌ترین آن‌ها محسوب می‌شود. Yealink در مستندات فعلی خود نیز صریحاً توصیه می‌کند رمزهای پیش‌فرض User و Administrator پس از راه‌اندازی تغییر داده شوند.
در بسیاری از تلفن‌های SIP Yealink دو سطح دسترسی وجود دارد:
Administrator برای تنظیمات مدیریتی و Accountها، و User برای تنظیمات محدودتر.
اگر تلفن‌ها با Provisioning مرکزی مدیریت می‌شوند، بهتر است Password Policy از همان Template مرکزی اعمال شود تا یک تلفن فراموش‌شده با Credential قدیمی در شبکه باقی نماند.
یک رمز خوب برای تلفن چه ویژگی‌ای دارد؟
رمز Administrator نباید:
شماره داخلی،
شماره تلفن،
MAC Address،
نام شرکت،
مدل Phone،
یا یک رمز یکسان و ساده برای تمام زیرساخت باشد.
اگر تعداد زیادی تلفن دارید، نگهداری Credential را با Password Manager یا سیستم مدیریت مرکزی انجام دهید و رمزها را در فایل Excel، پیام‌رسان یا متن ساده نگه ندارید.
آیا همه تلفن‌ها باید یک Admin Password داشته باشند؟
برای محیط کوچک ممکن است یک Credential مدیریتی مرکزی از نظر عملی ساده‌تر باشد، اما از نظر امنیتی بهتر است حداقل Credentialهای Device Management از Credential سایر تجهیزات شبکه جدا باشند.
اگر یک Password واحد روی صدها تلفن استفاده می‌کنید، افشای همان یک Credential عملاً تمام Endpointها را درگیر می‌کند.
در محیط حساس، Password per-device یا حداقل per-site گزینه امن‌تری است.
مرحله دوم: HTTP پنل وب را خاموش کنید
Yealink اجازه می‌دهد HTTP و HTTPS پنل مدیریتی مستقل از هم کنترل شوند.
اگر HTTPS کار می‌کند، دلیلی برای باز نگه‌داشتن HTTP معمولی وجود ندارد.
برای خاموش‌کردن HTTP و نگه‌داشتن HTTPS:
static.wui.http_enable = 0
static.wui.https_enable = 1تغییر این پارامترها در بسیاری از مدل‌ها باعث Reboot تلفن می‌شود، بنابراین روی شبکه Production آن را مرحله‌ای اعمال کنید.
اگر اصلاً Web UI لازم نداریم چه؟
اگر تمام تلفن‌ها فقط از طریق Provisioning مرکزی مدیریت می‌شوند و تیم پشتیبانی هیچ نیازی به Web UI ندارد، می‌توانید بعد از آزمایش روی چند Phone، هر دو مسیر Web Management را ببندید.
اما قبل از انجام این کار مطمئن شوید یک روش مدیریتی جایگزین و تست‌شده دارید.
بستن Web UI بدون Provisioning سالم می‌تواند مدیریت صدها تلفن را دشوار کند.
HTTPS به‌تنهایی کافی نیست
وجود آدرس:
https://192.168.50.20فقط نشان می‌دهد ارتباط Web از TLS استفاده می‌کند. هنوز باید بررسی کنید Certificate معتبر است، تلفن Certificate Serverهای دیگر را کورکورانه قبول نمی‌کند و Management Network نیز محدود شده است.
مرحله سوم: Certificate Validation را جدی بگیرید
Yealink می‌تواند Server Certificate را با Trusted Certificate List بررسی کند.
برای Hardening واقعی بهتر است گزینه Only Accept Trusted Certificates فعال باشد.
پارامتر:
static.security.trust_certificates = 1Common Name Validation را هم فعال کنید
فقط معتبر بودن CA کافی نیست. بهتر است Phone بررسی کند Certificate واقعاً برای همان Hostname صادر شده است.
static.security.cn_validation = 1در این حالت Common Name یا Subject Alternative Name Certificate باید با Server Name مورد استفاده هماهنگ باشد.
از IP استفاده کنیم یا Domain؟
اگر Certificate برای:
prov.example.comصادر شده، بهتر است تلفن نیز با همین Domain به Server وصل شود؛ نه با IP خامی که داخل SAN Certificate نیست.
CA خصوصی سازمان را می‌توان روی Yealink نصب کرد
اگر PBX یا Provisioning Server شما از Private CA استفاده می‌کند، Root یا Intermediate CA را داخل Trusted Certificates تلفن Import کنید.
Yealink همچنین اجازه Provision کردن Trusted Certificate را می‌دهد.
نمونه:
static.trusted_certificates.url = https://prov.example.com/certs/company-ca.crtبرای حل خطای TLS، Trust Verification را دائمی خاموش نکنید
گاهی برای عیب‌یابی Provisioning پیشنهاد می‌شود Only Accept Trusted Certificate موقتاً غیرفعال شود.
این کار فقط برای تشخیص کوتاه‌مدت قابل قبول است.
اگر با خاموش‌کردن Verification مشکل حل شد، نتیجه این نیست که Verification باید خاموش بماند؛ نتیجه این است که Certificate Chain، CA یا Hostname باید اصلاح شوند.
مرحله چهارم: SIP Signaling را با TLS امن کنید
SIP روی UDP یا TCP معمولی رمزگذاری نمی‌شود. User Name، شماره‌ها و بخش‌های مهم Signaling می‌توانند روی مسیر شبکه قابل مشاهده باشند.
در صورت پشتیبانی PBX، Transport را روی TLS تنظیم کنید.
پارامتر Yealink:
account.1.sip_server.1.transport_type = 2در Yealink:
| مقدار | Transport |
|---|---|
| 0 | UDP |
| 1 | TCP |
| 2 | TLS |
| 3 | DNS NAPTR/SRV |
TLS روی 5061 به‌تنهایی امنیت را تضمین نمی‌کند
پورت 5061 یک Convention رایج برای SIP TLS است، اما چیزی که اهمیت دارد این است که TLS واقعاً Negotiation شود و Certificate نیز معتبر باشد.
ممکن است Server روی Port دیگری TLS ارائه کند.
بنابراین امنیت را با شماره Port قضاوت نکنید.
TLS فقط Signaling را رمزگذاری می‌کند
یکی از اشتباه‌های رایج این است که بعد از فعال‌کردن SIP TLS تصور کنیم صدای تماس نیز رمزگذاری شده است.
TLS از Signaling محافظت می‌کند.
برای Media یا صدای تماس باید SRTP فعال شود.
مرحله پنجم: SRTP را برای Audio فعال کنید
SRTP نسخه امن RTP است و برای جلوگیری از شنود Audio استفاده می‌شود.
در Yealink:
account.1.srtp_encryption = 2مقادیر اصلی:
| مقدار | رفتار |
|---|---|
| 0 | غیرفعال |
| 1 | Optional |
| 2 | Compulsory |
Optional یا Compulsory؟
در مهاجرت مرحله‌ای، Optional می‌تواند برای تست Compatibility مفید باشد.
اما اگر Policy سازمان می‌گوید تماس نباید بدون Encryption برقرار شود، Compulsory انتخاب منطقی‌تری است.
نکته مهم این است که PBX، SBC و Endpoint طرف مقابل نیز باید SRTP را پشتیبانی کنند؛ در غیر این صورت تماس ممکن است برقرار نشود.
TLS و SRTP را با هم استفاده کنید
خود Yealink نیز در مستندات SRTP توصیه می‌کند هنگام استفاده از SRTP، TLS نیز فعال باشد.
علت روشن است: اگر Media را رمزگذاری کنیم اما Signaling مربوط به Negotiation کلیدها روی کانال ناامن منتقل شود، طراحی امنیتی کامل نیست.
Baseline مناسب:
SIP Signaling = TLS
Voice Media = SRTPاز کجا بفهمیم SRTP واقعاً فعال شده است؟
در تماس آزمایشی Packet Capture بگیرید.
در SDP تماس SRTP معمولاً نشانه‌هایی مانند:
RTP/SAVPیا پارامترهای Crypto دیده می‌شود.
در تلفن نیز بعد از Negotiation موفق TLS/SRTP معمولاً Lock Indicator قابل مشاهده است.
مرحله ششم: Provisioning را از HTTP به HTTPS منتقل کنید
CFG فایل ساده‌ای نیست. ممکن است داخل آن اطلاعاتی مانند:
SIP Username،
Authentication Name،
SIP Password،
Server Address،
Admin Password،
Certificate URL،
و سایر تنظیمات حساس
وجود داشته باشد.
بنابراین قرار دادن فایل Provisioning روی HTTP عمومی یک ریسک جدی است.
نمونه Server URL امن‌تر
static.auto_provision.server.url = https://prov.example.com/yealink/
static.auto_provision.server.username = phone-provision
static.auto_provision.server.password = StrongRandomPasswordبهتر است Credential داخل خود URL نوشته نشود مگر اینکه معماری شما مجبور به این کار باشد.
چرا نوشتن رمز داخل URL ایده‌آل نیست؟
URLهایی مانند:
https://user:password@prov.example.com/yealink/ممکن است در Configuration Export، Log یا ابزارهای مانیتورینگ ثبت شوند.
وقتی Firmware اجازه می‌دهد، Credential را در فیلدهای مجزای Provisioning نگه دارید.
Provisioning Server نباید Directory Listing داشته باشد
یک اشتباه خطرناک این است که این آدرس:
https://prov.example.com/yealink/فهرست تمام فایل‌های MAC.cfg را به هر بازدیدکننده نمایش دهد.
روی Web Server، Directory Listing را خاموش و Authentication و Permission فایل‌ها را محدود کنید.
دسترسی Read-only برای Provisioning کافی است
Phone برای دانلود CFG معمولاً به Write Access روی همان Directory نیاز ندارد.
اکانت Provisioning را تا حد نیاز واقعی محدود کنید.
اصل امنیتی مناسب اینجا Least Privilege است: هر Credential فقط همان کاری را بتواند انجام دهد که برای Provisioning لازم است.
Provisioning غیرمجاز چگونه رخ می‌دهد؟
یکی از سناریوهای خطرناک این است که Phone به یک Provisioning Server جعلی هدایت شود.
این Redirect می‌تواند از:
DHCP دست‌کاری‌شده،
RPS اشتباه،
DNS آلوده،
URL قدیمی،
یا Configuration اشتباه
ایجاد شود.
در چنین شرایطی HTTPS همراه با Certificate Validation اهمیت زیادی پیدا می‌کند؛ زیرا تلفن فقط داشتن یک Server روی IP مقصد را کافی نمی‌داند و هویت Server را نیز بررسی می‌کند.
مرحله هفتم: فایل CFG را رمزگذاری کنید
HTTPS فایل را هنگام انتقال محافظت می‌کند، اما اگر خود فایل روی Server یا Backup به دست فرد غیرمجاز برسد، Plaintext بودن CFG هنوز مشکل‌ساز است.
Yealink امکان Encryption فایل‌های Configuration را فراهم می‌کند.
فایل‌هایی مانند:
y0000000000xx.cfg
001565112233.cfg
account.cfg
sip.cfgمی‌توانند با ابزارهای Encryption خود Yealink رمزگذاری شوند.
چرا Encryption فایل CFG مهم است؟
ممکن است داخل account.cfg این موارد باشند:
account.1.auth_name = 201
account.1.user_name = 201
account.1.password = SIP_SECRET_PASSWORDاگر فایل Plaintext قابل دانلود باشد، مهاجم ممکن است Credential SIP را مستقیماً به‌دست آورد.
Yealink برای CFG از AES پشتیبانی می‌کند
در مستند فعلی، کلیدهای AES مورد استفاده برای Configuration دارای طول 16 کاراکتر هستند.
نمونه ساختاری:
static.auto_provision.aes_key.com = EXAMPLEKEY123456
static.auto_provision.aes_key.mac = MACKEYEXAMPLE123مقادیر بالا فقط نمونه هستند و نباید در Production استفاده شوند.
Aeskey.txt را روی Web Root عمومی نگذارید
اگر Encryption Tool فایل Aeskey.txt تولید می‌کند، آن فایل حاوی اطلاعات بسیار حساس است.
قرار دادن CFG رمزگذاری‌شده در کنار Aeskey.txt قابل دانلود، بخش بزرگی از مزیت Encryption را از بین می‌برد.
کلیدهای Encryption باید خارج از Web Root، Backup عمومی و Repository کد نگهداری شوند.
در مدل‌های پشتیبانی‌شده فقط CFG رمزگذاری‌شده را قبول کنید
Yealink پارامتری دارد که Phone را مجبور می‌کند فقط Configuration رمزگذاری‌شده را دریافت کند:
static.auto_provision.update_file_mode = 1قبل از فعال‌کردن این Policy روی همه Phoneها، حتماً فایل‌های Encryption و Recovery Path را روی چند دستگاه آزمایشی تست کنید؛ در غیر این صورت یک اشتباه در Key Management می‌تواند Provisioning کل شبکه را متوقف کند.
مرحله هشتم: Action URI را اگر لازم نیست خاموش کنید
Action URI قابلیت قدرتمندی است. با آن می‌توان از یک Server یا سیستم دیگر فرمان‌هایی به Phone ارسال کرد.
در استفاده قانونی بسیار کاربردی است، اما اگر بدون محدودیت باز بماند سطح حمله را افزایش می‌دهد.
اگر از آن استفاده نمی‌کنید:
features.action_uri.enable = 0اگر Action URI لازم است، IP آن را محدود کنید
اگر مثلاً فقط Automation Server با IP زیر باید Phone را کنترل کند:
features.action_uri.enable = 1
features.action_uri_limit_ip = 10.50.10.20از مقدار:
anyدر محیط Production استفاده نکنید مگر اینکه واقعاً دلیل مشخص و کنترل شبکه‌ای دیگری داشته باشید.
چرا Action URI حساس است؟
مستندات خود Yealink نشان می‌دهند Action URI می‌تواند عملیاتی مانند Dial و Hangup را از طریق Request شبکه انجام دهد.
پس این قابلیت فقط یک API برای مشاهده Status نیست؛ می‌تواند رفتار عملی Phone را کنترل کند.
به همین دلیل Allow List آن باید جدی گرفته شود.
Screen Capture و Remote Control غیرضروری را نیز خاموش کنید
در مدل‌هایی که Screen Capture یا Remote Control دارند، اگر سازمان از آن‌ها استفاده نمی‌کند بهتر است غیرفعال باقی بمانند.
هر قابلیت Remote Management اضافه باید پاسخ این سؤال را داشته باشد:
«کدام سیستم واقعاً به این Feature نیاز دارد؟»
اگر پاسخ «هیچ‌کدام» است، Feature نباید فقط به‌دلیل حالت پیش‌فرض روشن بماند.
مرحله نهم: Direct IP Call را اگر استفاده نمی‌کنید ببندید
Direct IP Call امکان تماس مستقیم Endpoint با Endpoint بدون SIP Proxy را فراهم می‌کند.
در بسیاری از شبکه‌های سازمانی همه تماس‌ها باید از PBX عبور کنند؛ بنابراین این قابلیت ضرورتی ندارد.
در مدل‌های پشتیبانی‌شده:
features.direct_ip_call_enable = 0اگر Direct IP Call بخشی از طراحی شماست، آن را کورکورانه غیرفعال نکنید؛ این مقاله درباره حذف Featureهای غیرضروری است.
مرحله دهم: Voice VLAN جدا بسازید
یکی از قوی‌ترین کنترل‌های امنیتی اصلاً داخل تلفن قرار ندارد؛ در Switch و Firewall قرار دارد.
تلفن‌ها را در Voice VLAN مجزا از Clientهای معمولی، سیستم‌های مهمان و IoT قرار دهید.
این جداسازی دو مزیت دارد:
Broadcast Domain کوچکتر می‌شود،
و می‌توانید ACL دقیقی برای تلفن‌ها تعریف کنید.
تلفن واقعاً به چه مقصدهایی نیاز دارد؟
در یک معماری کنترل‌شده، Phone VLAN معمولاً فقط باید به مقصدهایی مانند این دسترسی داشته باشد:
| مقصد | کاربرد |
|---|---|
| PBX / SBC | SIP و RTP/SRTP |
| Provisioning Server | HTTPS |
| DNS | Name Resolution |
| NTP | زمان صحیح و Certificate Validation |
| LDAP در صورت استفاده | Directory |
| Management Host | HTTPS Admin در صورت نیاز |
لزومی ندارد Voice VLAN بتواند به تمام Workstationهای شرکت، File Serverها و تجهیزات مدیریتی دسترسی آزاد داشته باشد.
Management VLAN باید به Phone برسد، نه برعکس
یک الگوی مناسب این است که Administrator از Management Network بتواند روی HTTPS به تلفن‌ها دسترسی داشته باشد، اما کاربران Data VLAN نتوانند Web UI تمام تلفن‌ها را Scan و باز کنند.
این Policy را بهتر است روی Firewall یا Layer 3 ACL پیاده کنید.
یک ACL مفهومی ساده
Management VLAN → Voice VLAN : HTTPS ALLOW
User VLAN → Voice VLAN : HTTPS DENY
Voice VLAN → PBX : SIP-TLS ALLOW
Voice VLAN → Provision : HTTPS ALLOW
Voice VLAN → Internet : DENY unless explicitly requiredاین Syntax مربوط به یک Vendor مشخص نیست و فقط منطق Policy را نشان می‌دهد.
VLAN به‌تنهایی Firewall نیست
ساختن VLAN 20 برای Voice و VLAN 10 برای User کافی نیست اگر Router آزادانه تمام ترافیک را بین آن‌ها Route کند.
جداسازی امنیتی زمانی ایجاد می‌شود که Inter-VLAN Traffic با ACL یا Firewall Policy محدود شود.
مرحله یازدهم: برای شبکه حساس 802.1X را بررسی کنید
Yealink در مدل‌های متعدد از 802.1X پشتیبانی می‌کند.
802.1X باعث می‌شود صرف اتصال یک Device به Port شبکه برای دریافت دسترسی کافی نباشد؛ Device باید Authentication انجام دهد.
برای محیط‌های حساس، EAP-TLS گزینه قدرتمندی است چون Authentication بر پایه Certificate انجام می‌شود.
802.1X چه تهدیدی را کاهش می‌دهد؟
اگر کسی کابل Ethernet تلفن را جدا کند و Laptop خود را به همان Port وصل کند، بدون Network Access Control ممکن است همان VLAN و دسترسی شبکه را دریافت کند.
802.1X می‌تواند قبل از اعطای دسترسی، Device یا User را Authenticate کند.
قبل از فعال‌کردن 802.1X روی همه تلفن‌ها آزمایش کنید
یک اشتباه در EAP Certificate، RADIUS، VLAN Assignment یا Switch Configuration می‌تواند صدها Phone را هم‌زمان Offline کند.
ابتدا:
یک Phone آزمایشی،
یک Switch Port،
و یک Policy محدود
را تست کنید و بعد Rollout مرحله‌ای انجام دهید.
مرحله دوازدهم: Firmware را بخشی از امنیت بدانید
Hardening روی Firmware قدیمی کامل نیست.
Firmware جدید می‌تواند:
Security Fix،
بهبود TLS،
Cipher جدید،
Certificate Update،
و رفع آسیب‌پذیری‌های مدیریتی
داشته باشد.
اما Update مستقیم صدها Phone نیز کار درستی نیست.
Firmware Update را مرحله‌ای انجام دهید
ابتدا روی تعداد محدودی Phone با مدل و Hardware Revision مشابه Production آزمایش کنید.
بعد:
Registration،
TLS،
SRTP،
Provisioning،
BLF،
Headset،
و تماس ورودی/خروجی
را تست کنید.
برای روند کامل می‌توانید مقاله آپدیت امن Firmware تلفن‌های Yealink را ببینید.
مرحله سیزدهم: Provisioning امن را به‌صورت جداگانه کنترل کنید
اگر ده‌ها یا صدها Phone دارید، تنظیم دستی تک‌تک این موارد منطقی نیست.
Hardening باید بخشی از Common CFG سازمان باشد.
برای طراحی کامل HTTPS Provisioning می‌توانید راهنمای راه‌اندازی امن Auto Provisioning یالینک با HTTPS را نیز ببینید.
نمونه Baseline اولیه Hardening
این Configuration فقط یک نمونه پایه است و باید قبل از Production با Firmware و مدل واقعی تلفن بررسی شود:
#!version:1.0.0.1
# Web Management
static.wui.http_enable = 0
static.wui.https_enable = 1
# Certificate Validation
static.security.trust_certificates = 1
static.security.cn_validation = 1
static.security.ca_cert = 2
# SIP Signaling
account.1.sip_server.1.transport_type = 2
# Secure Media
account.1.srtp_encryption = 2
# Remote Control
features.action_uri.enable = 0
# Direct IP Call
features.direct_ip_call_enable = 0
# Secure Provisioning
static.auto_provision.server.url = https://prov.example.com/yealink/همه این موارد را یک‌باره Push نکنید
Hardening اشتباه می‌تواند خودش Outage بسازد.
برای مثال اگر:
TLS را Compulsory کنید ولی PBX آماده نباشد،
Certificate Validation را فعال کنید ولی CA روی Phone نباشد،
HTTP را ببندید ولی HTTPS Certificate مشکل داشته باشد،
یا Provisioning را فقط Encrypted کنید ولی AES Key اشتباه باشد،
تلفن می‌تواند از مدیریت خارج شود.
پس Hardening باید Staged Rollout داشته باشد.
ترتیب امن اجرای Hardening
| مرحله | اقدام |
|---|---|
| 1 | Inventory مدل و Firmware |
| 2 | Backup و Export Config |
| 3 | Admin Password |
| 4 | HTTPS Web UI |
| 5 | Certificate Trust |
| 6 | HTTPS Provisioning |
| 7 | SIP TLS |
| 8 | SRTP |
| 9 | Disable Remote/Unused Features |
| 10 | Voice VLAN و ACL |
| 11 | CFG Encryption |
| 12 | Rollout گسترده |
مرحله چهاردهم: سرویس‌های غیرضروری را شناسایی کنید
قرار نیست یک Template ثابت را روی تمام سازمان‌ها اعمال کنیم.
ابتدا مشخص کنید این قابلیت‌ها واقعاً استفاده می‌شوند یا خیر:
Action URI،
Direct IP Call،
Remote Screen Capture،
XML Push،
Remote Phonebook،
LDAP،
USB Recording،
Bluetooth،
Wi-Fi،
و Web UI.
هر Feature غیرضروری سطح حمله‌ای است که بدون منفعت عملی باز مانده است.
Bluetooth و Wi-Fi را هم بر اساس نیاز فعال کنید
اگر یک T54W فقط از Ethernet و هدست سیمی استفاده می‌کند، روشن نگه‌داشتن Bluetooth صرفاً به‌دلیل اینکه Phone آن را دارد ضرورتی ندارد.
همین منطق برای Wi-Fi نیز صدق می‌کند.
Hardening یعنی Capability دستگاه با Use Case واقعی تطبیق داده شود.
مرحله پانزدهم: NTP یک تنظیم امنیتی هم هست
زمان اشتباه فقط ساعت نمایشگر را خراب نمی‌کند.
Certificateها دارای:
Not Before
Not Afterهستند.
اگر ساعت Phone اشتباه باشد، Certificate معتبر می‌تواند Not Yet Valid یا Expired دیده شود.
پس NTP Server معتبر و قابل دسترس را جزئی از Hardening TLS بدانید.
مرحله شانزدهم: Log و Monitoring داشته باشید
امنیت بدون Visibility ناقص است.
در محیط سازمانی حداقل باید بتوانید بفهمید:
Phone چه زمانی Provision شده،
Firmware چه زمانی تغییر کرده،
Registration چه زمانی Fail شده،
Certificate چه زمانی Expire می‌شود،
و آیا Device رفتار غیرعادی دارد یا خیر.
برای عیب‌یابی امنیتی، Syslog سطح مناسب و Packet Capture در لحظه رخداد بسیار ارزشمند هستند.
به چه رفتارهایی حساس باشیم؟
| نشانه | احتمال |
|---|---|
| Provisioning URL ناگهان تغییر کرده | Configuration یا مدیریت مرکزی بررسی شود |
| Admin Password غیرمنتظره تغییر کرده | Provisioning یا Access غیرمجاز |
| Phone به Server جدید وصل می‌شود | DNS، RPS یا Provisioning بررسی شود |
| HTTP دوباره فعال شده | Template یا Factory Reset |
| TLS ناگهان Fail می‌شود | Certificate، NTP یا PBX Change |
| Action URI Request ناشناس | Remote Control Exposure |
Factory Reset چه اثری روی Security دارد؟
Factory Reset می‌تواند برخی تنظیمات Hardening را به Default برگرداند.
در بعضی مدل‌ها Custom Certificateها نیز به‌صورت پیش‌فرض پس از Factory Reset حذف می‌شوند، مگر اینکه رفتار مربوط به نگهداری Certificate از قبل پیکربندی شده باشد.
بنابراین Recovery Procedure سازمان باید مشخص کند بعد از Reset چگونه:
Certificate،
Admin Password،
Provisioning URL،
TLS،
SRTP،
و ACLها
دوباره اعمال می‌شوند.
Factory Reset نباید یک راه دورزدن Hardening باشد
اگر کاربر محلی بتواند Phone را Reset کند و دستگاه بعد از Boot بدون Provisioning امن با Password پیش‌فرض بالا بیاید، Hardening پایدار نیست.
Phone باید بعد از Recovery نیز دوباره از Source of Truth امن Configuration دریافت کند.
سناریوی اول: پنل Yealink از تمام شبکه باز می‌شود
اول HTTP را خاموش کنید.
بعد روی Firewall فقط Management VLAN را به HTTPS تلفن‌ها Allow کنید.
اگر Web UI اصلاً لازم نیست، دسترسی Web را به‌طور کامل ببندید.
سناریوی دوم: HTTPS فعال است ولی Certificate Warning دارید
Warning را با خاموش‌کردن دائمی Validation پنهان نکنید.
Certificate Chain، Hostname، تاریخ و NTP را بررسی کنید.
اگر Private CA دارید، CA صحیح را روی Phone Import کنید.
سناریوی سوم: SIP روی TLS رجیستر نمی‌شود
Transport، Port، Certificate و NTP را بررسی کنید.
همچنین مطمئن شوید PBX واقعاً Listener مربوط به TLS را فعال کرده است.
اگر روی UDP Register می‌شود ولی TLS نه، مشکل SIP Credential عمومی احتمال کمتری دارد و باید TLS Handshake بررسی شود.
سناریوی چهارم: بعد از فعال‌کردن SRTP تماس برقرار نمی‌شود
PBX یا Endpoint مقابل احتمالاً SRTP را قبول نمی‌کند یا Cipher/Negotiation هماهنگ نیست.
برای تست ابتدا Optional را امتحان کنید و SDP دو سمت را مقایسه کنید.
پس از اطمینان از سازگاری می‌توانید Compulsory را اعمال کنید.
سناریوی پنجم: Provisioning با HTTPS فقط وقتی Verification خاموش است کار می‌کند
این یک سرنخ مستقیم است.
مشکل را در:
CA،
Certificate Chain،
Hostname/SAN،
یا زمان Phone
پیدا کنید.
Verification را خاموش نگه ندارید.
سناریوی ششم: کاربر می‌تواند از طریق URL تلفن را کنترل کند
Action URI را بررسی کنید.
اگر استفاده نمی‌شود خاموشش کنید.
اگر لازم است، Allow IP List را فقط روی Management/Automation Serverهای واقعی تنظیم کنید.
سناریوی هفتم: CFG با واردکردن MAC Address دانلود می‌شود
این یک مشکل مهم Provisioning است.
دانستن MAC Address نباید به‌تنهایی مجوز دانلود Configuration حاوی SIP Password باشد.
HTTPS، Authentication، Authorization و ترجیحاً Encryption فایل CFG را اعمال کنید.
سناریوی هشتم: همه تلفن‌ها یک Provisioning Password دارند
اگر آن Credential لو برود، Blast Radius بزرگ است.
حداقل:
Password را با Credentialهای دیگر مشترک نکنید،
دسترسی Account را Read-only کنید،
Directory را محدود کنید،
و در محیط حساس Credential per-site یا per-device را بررسی کنید.
سناریوی نهم: تلفن‌ها در همان VLAN کاربران هستند
حتی اگر TLS فعال باشد، Segmentation همچنان ارزش دارد.
Voice VLAN مستقل بسازید و Inter-VLAN Firewall Policy تعریف کنید.
هدف فقط جلوگیری از شنود نیست؛ کاهش Reachability مدیریتی و محدودکردن حرکت جانبی نیز مهم است.
سناریوی دهم: بعد از Factory Reset همه تنظیمات امنیتی از بین می‌روند
Hardening باید داخل Provisioning Baseline قرار بگیرد.
به این ترتیب بعد از Reset و Enrollment مجدد، Device دوباره:
HTTP را می‌بندد،
HTTPS را فعال می‌کند،
Certificate Policy را می‌گیرد،
TLS/SRTP را اعمال می‌کند،
و Featureهای غیرضروری را می‌بندد.
یک Baseline عملی برای دفتر کوچک
| کنترل | وضعیت پیشنهادی |
|---|---|
| Admin Password | تغییر داده شود |
| HTTP Web | خاموش |
| HTTPS Web | روشن |
| Provisioning | HTTPS + Authentication |
| Certificate Trust | فعال |
| SIP | TLS در صورت پشتیبانی PBX |
| Audio | SRTP در صورت پشتیبانی |
| Action URI | خاموش اگر استفاده نمی‌شود |
| Direct IP Call | خاموش اگر استفاده نمی‌شود |
| Firmware | نسخه پشتیبانی‌شده و به‌روز |
Baseline قوی‌تر برای سازمان
| کنترل | پیشنهاد |
|---|---|
| Voice VLAN | مجزا |
| Inter-VLAN ACL | Least Privilege |
| 802.1X | ترجیحاً EAP-TLS در محیط مناسب |
| Provisioning CFG | Encrypted |
| Certificate | CA و CN/SAN Validation |
| Management | فقط از Management Network |
| Provisioning User | Read-only و محدود |
| Monitoring | Syslog و Alert |
| Firmware Rollout | Canary → Batch → Production |
پرسش‌های متداول درباره امنیت Yealink
برای امن‌کردن Yealink فقط عوض‌کردن رمز admin کافی است؟
خیر. رمز مدیریت فقط یکی از لایه‌هاست. HTTP/HTTPS، SIP Transport، SRTP، Provisioning، Certificate Validation، Remote Control، Firmware و Segmentation شبکه نیز باید بررسی شوند.
آیا باید HTTP پنل Yealink را خاموش کنیم؟
اگر HTTPS سالم و در دسترس است، بهتر است HTTP غیررمزشده غیرفعال شود. Yealink امکان کنترل مستقل HTTP و HTTPS را فراهم می‌کند.
TLS و SRTP چه فرقی دارند؟
TLS عمدتاً از SIP Signaling محافظت می‌کند، در حالی که SRTP برای رمزگذاری Media یا صدای تماس استفاده می‌شود. برای ارتباط امن بهتر است هر دو در صورت پشتیبانی PBX فعال شوند.
آیا SRTP را روی Optional بگذاریم یا Compulsory؟
Optional برای مهاجرت و تست Compatibility مفید است. اگر Policy سازمان الزام به Encryption دارد و تمام مسیر تماس SRTP را پشتیبانی می‌کند، Compulsory مناسب‌تر است.
آیا Provisioning روی HTTP خطرناک است؟
اگر CFG حاوی Credential و تنظیمات حساس باشد، HTTP می‌تواند اطلاعات را در مسیر شبکه افشا کند. HTTPS همراه با Authentication و Certificate Validation انتخاب امن‌تری است.
آیا رمزگذاری CFG هنوز با وجود HTTPS لازم است؟
این دو کنترل تهدیدهای متفاوتی را پوشش می‌دهند. HTTPS از انتقال محافظت می‌کند؛ Encryption فایل می‌تواند در صورت دسترسی غیرمجاز به خود فایل Provisioning نیز از اطلاعات حساس محافظت کند.
Action URI در Yealink خطرناک است؟
این قابلیت ذاتاً مخرب نیست، اما می‌تواند فرمان‌های Remote Control دریافت کند. اگر استفاده نمی‌شود آن را غیرفعال کنید و در صورت نیاز فقط IPهای مجاز را Allow کنید.
آیا قرار دادن تلفن‌ها در Voice VLAN کافی است؟
خیر. اگر Routing بین VLANها آزاد باشد جداسازی امنیتی کامل نیست. Voice VLAN باید همراه با Firewall یا ACL و محدودیت Management Access استفاده شود.
آیا 802.1X برای تلفن Yealink لازم است؟
برای همه شبکه‌ها الزامی نیست، اما در سازمان‌های حساس باعث می‌شود Device قبل از دریافت دسترسی LAN Authenticate شود. مدل‌ها و Firmwareهای پشتیبانی‌شده Yealink از روش‌هایی مانند EAP-TLS پشتیبانی می‌کنند.
اگر HTTPS Provisioning فقط با خاموش‌کردن Certificate Check کار کند چه کنیم؟
CA، Chain، Hostname، SAN و ساعت دستگاه را اصلاح کنید. خاموش‌کردن دائمی Certificate Validation راه‌حل امنیتی مناسبی نیست.
جمع‌بندی
امنیت تلفن Yealink باید به‌صورت لایه‌ای طراحی شود. تغییر Password قدم اول است، نه آخر. بعد از آن پنل وب را فقط با HTTPS ارائه کنید و اگر Web Management لازم نیست دسترسی آن را کامل ببندید یا از شبکه مدیریتی محدود کنید.
برای SIP امن، Signaling را با TLS و Audio را با SRTP محافظت کنید. Certificate Validation را فعال نگه دارید و اگر Private CA دارید Certificate صحیح را روی Phone نصب کنید. خاموش‌کردن Verification فقط باید یک تست موقت برای پیدا کردن مشکل Certificate باشد.
Provisioning یکی از حساس‌ترین قسمت‌هاست؛ چون CFG می‌تواند Credentialهای SIP و تنظیمات مدیریتی را در خود داشته باشد. از HTTPS، Authentication، Permission محدود و در محیط‌های حساس Encryption فایل CFG استفاده کنید. Provisioning Directory نباید عمومی یا قابل Browse باشد.
Remote Controlهایی مانند Action URI، Direct IP Call و قابلیت‌های غیرضروری را بر اساس Use Case واقعی غیرفعال کنید. سپس تلفن‌ها را داخل Voice VLAN جدا قرار دهید و با ACL فقط ارتباط لازم با PBX، DNS، NTP، Provisioning و Management Server را باز نگه دارید.
در نهایت Hardening را وارد Common CFG و سیستم Provisioning کنید تا پس از Reset یا تعویض تلفن نیز دوباره اعمال شود. Security Baseline وقتی ارزش واقعی دارد که قابل تکرار، قابل مانیتور و قابل Rollback باشد.
PBX، تلفن‌های Yealink و شبکه Voice را یک‌جا Hardening کنید
اگر می‌خواهید TLS، SRTP، Provisioning امن، Certificate و جداسازی شبکه تلفن‌های سازمانی را اصولی پیاده‌سازی کنید، می‌توانید درخواست کانفیگ ثبت کنید و در صورت اجرای PBX روی سرور، زیرساخت مناسب آن را نیز بررسی کنید.
تماس با پشتیبانی ایرانیکاسرور
دیدگاه‌ها (۰)