دليل Cisco لحماية أجهزة المؤسسات التي تدعم العناصر الحدودية الموحدة (CUBE) من Cisco

المقدمة

سيساعدك هذا المستند على تأمين أجهزتك التي تعمل بنظام Cisco IOS و IOS-XE لوحدة التحكم في حد جلسة العمل (SBC) التي تشغل برنامج Cisco Unified Border Element (CUBE) Enterprise وتقويتها.

المتطلبات الأساسية

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

المكونات المستخدمة

- برنامج Cube Enterprise الذي يعمل بنظام التشغيل IOS-XE 17.10.1a.

ملاحظة:

أن بعض الميزات التفصيلية في هذا المستند قد لا تكون متوفرة في إصدارات IOS-XE القديمة. حيث يكون قد تم الحرص على توثيق عند تقديم أمر أو ميزة أو تعديلها.

لا ينطبق هذا المستند على وكيل الوسائط CUBE أو موفر خدمة CUBE أو بوابات MGCP أو SCCP أو بوابات Cisco SRST أو ESRST أو بوابات H323 أو البوابات الصوتية التناظرية/TDM الأخرى.

معلومات أساسية

يعمل هذا المستند كإضافة إلى ما يمكن العثور عليه في دليل Cisco لتعزيز أجهزة Cisco IOS.  وعلى هذا النحو فإن أي عناصر مكررة من ذلك المستند لن يتم تكرارها في هذا المستند.

المعايير المشتركة ومعايير المعلومات الفيدرالية

يمكن ل Cisco Virtual Cube الذي يستخدم IOS-XE 16.9+ على CSR1000v أو CAT8000v إستخدام الأمر cc-mode لتمكين تنفيذ المعايير المشتركة (CC) ومعايير المعلومات الفيدرالية (FIPS) للتصديق على الوحدات المشفرة المختلفة مثل تلك الموجودة في أمان طبقة النقل (TLS) و . لا يوجد أمر مكافئ ل CUBE الذي يتم تشغيله على موجهات الأجهزة ولكن الأقسام اللاحقة ستوفر أساليب لتمكين التعزيز المماثل يدويا.

المصدر: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_cc_fips_compliance.html

أمان طبقة النقل (TLS) والبنية الأساسية للمفتاح العام (PKI)

سيناقش هذا القسم العناصر حول TLS و PKI التي يمكنها تعزيز الأمان الذي توفره هذه البروتوكولات بجانب عمليات البروتوكول الأولي للجلسة الآمنة (SIP) وبروتوكول الوقت الفعلي الآمن (SRTP).

إستخدام TCP TLS و SRTP

سيقبل المكعب الافتراضي إتصالات SIP الواردة عبر TCP أو UDP أو SIP TCP-TLS. بينما ستفشل إتصالات TCP-TLS إذا لم يتم تكوين أي شيء، سيتم قبول TCP و UDP ومعالجتها بواسطة CUBE. بالنسبة للاتصالات الصادرة، سيستخدم SIP إتصالات UDP بشكل افتراضي ما لم يكن هناك أمر TCP أو TCP-TLS. سيقوم CUBE نفسه بالتفاوض على جلسات عمل بروتوكول الوقت الفعلي غير الآمن (RTP). يوفر كلا البروتوكولين فرصة وفيرة للمهاجم لالتقاط بيانات من إشارات جلسة SIP غير المشفرة أو تدفق الوسائط. وحيثما كان ذلك ممكنا، يوصى بتأمين إرسال إشارات SIP باستخدام SIP TLS وتدفق الوسائط باستخدام SRTP.

ارجع إلى دليل تكوين SIP TLS و SRTP:

• https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_sip_tls_support_cube.html
• https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_cc_fips_compliance.html?bookSearch=true#id_118373

تذكر أن الأمان لا يكون قويا إلا بقدر ما يكون أقل الارتباط ضعفا، كما يجب تمكين SIP-TLS و SRTP على جميع أجهزة الاستدعاء من خلال CUBE.

ستتم إضافة الأقسام المتبقية إلى التكوينات الافتراضية هذه في محاولة لتوفير ميزات أمان إضافية:

تعطيل منافذ SIP غير الآمنة

قم باستدعاء المقطع السابق المفصل بأن CUBE سيقبل TCP و UDP الواردين ل CUBE بشكل افتراضي. بمجرد إستخدام SIP TLS لجميع أرجل المكالمات، قد يكون من المفضل تعطيل منفذ الاستماع ل UDP و TCP SIP غير الآمن 5060.

وبمجرد تعطيلها، يمكنك إستخدام show sip-ua status، أو show sip connections udp brief، أو show sip connections tcp brief لتأكيد CUBE لم يعد منصتا إلى 5060 لاتصالات TCP أو UDP الواردة SIP.

Router# show sip-ua status
SIP User Agent Status
SIP User Agent for UDP : ENABLED
SIP User Agent for TCP : ENABLED
SIP User Agent for TLS over TCP : ENABLED

Router# show sip connections udp brief | i 5060
0 [0.0.0.0]:5060: 0

Router# show sip connections tcp brief | i 5060
0 [0.0.0.0]:5060: 0!

!
sip-ua
 no transport udp
 no transport tcp
!

Router# show sip-ua status
SIP User Agent Status
SIP User Agent for UDP : DISABLED
SIP User Agent for TCP : DISABLED
SIP User Agent for TLS over TCP : ENABLED

Router# show sip connections tcp brief | i 5060
Router# show sip connections udp brief | i 5060

كما يمكن تكوين CUBE ليعمل جنبا إلى جنب مع IOS-XE VRFs لتوفير المزيد من تقسيم الشبكة.

من خلال تكوين VRFs وربط واجهة VRF ممكنة إلى الطلب-peer/المستأجر؛ سيقوم CUBE فقط بالاستماع إلى الاتصالات الواردة لمجموعة IP، و Port، و VRF تلك.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-multi-vrf.html

فرض TLS 1.2

في وقت كتابة هذا المستند TLS 1.2 هو أعلى إصدار من TLS مدعوم بواسطة CUBE. تم تعطيل TLS 1.0 في IOS-XE 16.9 ولكن يمكن التفاوض حول TLS 1.1. ولمزيد من التحديد للخيارات أثناء مصافحة TLS، قد يفرض المسؤول إصدار CUBE Enterprise الوحيد المتاح على TLS 1.2

!
sip-ua
 transport tcp tls v1.2
!

فرض تشفير TLS

قد يكون من المفضل تعطيل شفرات TLS الأضعف من التفاوض عليها في جلسة. يمكن للمسؤول الذي يبدأ في IOS-XE 17.3.1 تكوين ملف تعريف TLS مما يتيح للمسؤول القدرة على تحديد شفرة TLS التي سيتم تقديمها بالضبط أثناء جلسة TLS. في الإصدارات الأقدم من IOS-XE، تم التحكم في هذا باستخدام الأمر strict-cipher أو ecdsa-cipher postfix على تشفير signaling sip-ua. 

لاحظ أن الشفرات التي تحددها يجب أن تكون متوافقة مع الأجهزة النظيرة التي تتفاوض مع SIP TLS باستخدام CUBE. ارجع إلى جميع وثائق المورد القابلة للتطبيق لتحديد أفضل التشفير بين جميع الأجهزة.

IOS-XE 17.3.1+

Router(config)# voice class tls-cipher 1
Router(config-class)# cipher ?
<1-10> Set the preference order for the TLS cipher-suite (1 = Highest)
Router(config-class)# cipher 1 ?
   DHE_RSA_AES128_GCM_SHA256      supported in TLS 1.2 & above
   DHE_RSA_AES256_GCM_SHA384      supported in TLS 1.2 & above
   DHE_RSA_WITH_AES_128_CBC_SHA   supported in TLS 1.0 & above
   DHE_RSA_WITH_AES_256_CBC_SHA   supported in TLS 1.0 & above
   ECDHE_ECDSA_AES128_GCM_SHA256  supported in TLS 1.2 & above
   ECDHE_ECDSA_AES256_GCM_SHA384  supported in TLS 1.2 & above
   ECDHE_RSA_AES128_GCM_SHA256    supported in TLS 1.2 & above
   ECDHE_RSA_AES256_GCM_SHA384    supported in TLS 1.2 & above
   RSA_WITH_AES_128_CBC_SHA       supported in TLS 1.0 & above
   RSA_WITH_AES_256_CBC_SHA       supported in TLS 1.0 & above

!
voice class tls-cipher 1
 cipher 1 ECDHE_RSA_AES128_GCM_SHA256
 cipher 2 ECDHE_RSA_AES256_GCM_SHA384
!
voice class tls-profile 1
 trustpoint TEST
 cipher 1
!
sip-ua
 crypto signaling default tls-profile 1 
!

جميع الإصدارات الأخرى

! STRICT CIPHERS
sip-ua
 crypto signaling default trustpoint TEST strict-cipher
 ! Only Enables:
 ! TLS_RSA_WITH_AES_128_CBC_SHA
 ! TLS_DHE_RSA_WITH_AES_128_CBC_SHA1
 ! TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 ! TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
!
! ECDSA Ciphers
sip-ua
 crypto signaling default trustpoint TEST ecdsa-cipher
 ! Only Enables:
 ! TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
 ! TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
!

إستخدام مفاتيح التشفير الكبيرة

معايير تشفير الجيل التالي من Cisco الموصى باستخدامها مع تطبيقات TLS 1.2. يمكن إستخدام الأوامر أدناه لإنشاء مفاتيح RSA للاستخدام مع جلسات عمل TLS.

يتيح أمر التسمية للمسؤول تحديد هذه المفاتيح بسهولة على نقطة موثوق بها ويضمن الأمر القابل للتصدير أنه إذا لزم الأمر، يمكن تصدير زوج المفاتيح الخاص/العام باستخدام الأمر مثل 

كلمة مرور AES الطرفي ل Crypto key export rsa CUBE-ENT!123

!
crypto key generate rsa general-keys modulus 2048 label CUBE-ENT exportable
!

Router# show crypto key mypubkey rsa CUBE-ENT
% Key pair was generated at: 11:38:03 EST Mar 10 2023
Key name: CUBE-ENT
Key type: RSA KEYS
 Storage Device: private-config
 Usage: General Purpose Key
 Key is exportable. Redundancy enabled.
 Key Data:
  [..truncated..]

إستخدام الشهادات الموقعة من هيئة الشهادات (CA)

يجب على المسؤولين إستخدام الشهادات الموقعة من CA بدلا من الشهادات الموقعة ذاتيا عند إنشاء شهادة TrustPoint و Identity (ID) لمؤسسة CUBE.

توفر شهادات CA عادة آليات أمان إضافية مثل عناوين URL الخاصة بقائمة إبطال الشهادة (CRL) أو بروتوكول حالة الشهادة عبر الإنترنت (OCSP) التي يمكن إستخدامها من قبل الأجهزة لضمان عدم إبطال الشهادة. يؤدي إستخدام سلاسل المرجع المصدق العام الموثوق بها إلى تسهيل تكوين علاقة الثقة على الأجهزة النظيرة التي قد تحتوي على ثقة مضمنة في المرجع المصدق الجذر المعروف أو قد تحتوي بالفعل على ثقة الجذر بمجال المؤسسة لديك.

بالإضافة إلى ذلك، يجب أن تتضمن شهادات CA علامة CA ل TRUE في القيود الأساسية ويجب أن تتضمن شهادة هوية CUBE معلمة إستخدام المفتاح الموسع لمصادقة العميل الممكنة.

يتم أدناه عرض نموذج شهادة المرجع المصدق الجذر وشهادة معرف للمكعب باستخدام:

openssl x509 -في بعض-cert.cer -text -noout

### Root CA Cert
Certificate:
[..truncated..]
 X509v3 extensions:
   X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0
[..truncated..]
   X509v3 Extended Key Usage: 
     TLS Web Server Authentication, TLS Web Client Authentication
[..truncated..]

### ID Cert
Certificate:
 Data:
[..truncated..]
  Signature Algorithm: sha256WithRSAEncryption
[..truncated..]
  Subject Public Key Info:
   Public Key Algorithm: rsaEncryption
    RSA Public-Key: (2048 bit)
[..truncated..]
  X509v3 extensions:
   X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
[..truncated..]
   X509v3 Extended Key Usage: 
    TLS Web Server Authentication, TLS Web Client Authentication
[..truncated..]

الاستفادة من التجزئة القوية

عند تكوين TrustOn لشهادة هوية CUBE، يجب على المرء تحديد خوارزميات تجزئة قوية مثل SHA256 أو SHA384 أو SHA512:

Router(config)# crypto pki trustpoint CUBE-ENT
Router(ca-trustpoint)# hash ?
 md5 use md5 hash algorithm
 sha1 use sha1 hash algorithm
 sha256 use sha256 hash algorithm
 sha384 use sha384 hash algorithm
 sha512 use sha512 hash algorithm

تمكين عمليات التحقق من قائمة إلغاء الشهادة (CRL) أو إختبارات بروتوكول حالة الشهادة عبر الإنترنت (OCSP)

بشكل افتراضي، سيحاول IOS-XE TrustPoints التحقق من CRL المدرج ضمن شهادة أثناء أمر مصادقة crypto pki، وفي وقت لاحق أثناء رسائل TLS، سيقوم IOS-XE أيضا بإجراء إحضار CRL آخر استنادا إلى الشهادة التي تم تلقيها للتأكد من أن الشهادة لا تزال صالحة. قد تكون أساليب CRL إما HTTP أو LDAP ويلزم وجود الاتصال ب CRL حتى ينجح ذلك. بمعنى أن دقة DNS ومأخذ TCP وتنزيل الملفات من الخادم إلى موجه IOS-XE يجب أن تكون متوفرة وإلا فإن التحقق من CRL سيفشل. وبالمثل، يمكن تكوين IOS-XE TrustPoint لاستخدام قيمة OCSP من رأس AuthorityInfoAccess (AIA) داخل الشهادة التي تقوم بإجراء استعلامات لمستجيب OCSP عبر HTTP للتحقق من عمليات التحقق المماثلة وتنفيذها. يمكن أن يتخطى المسؤول OCSP أو CRL Distribution Point (CDP) ضمن ترخيص بتوفير URL ثابت على ترخيص. علاوة على ذلك، يمكن للمسؤول أيضا تكوين الأمر الذي يتم فيه التحقق من CRL أو OCSP بافتراض وجود كليهما.

يقوم العديد منها ببساطة بتعطيل عمليات التحقق من الإبطال باستخدام الأمر Revocation-check none لتبسيط العملية ولكن من خلال القيام بذلك، يقوم المسؤول بإضعاف الأمان ويزيل آلية IOS-XE للتحقق بشكل كبير من ما إذا كانت الشهادة المحددة لا تزال صالحة. يجب على المسؤولين، حيثما كان ذلك ممكنا، الاستفادة من OCSP أو CRL لإجراء التحقق من الشهادات التي تم تلقيها. لمزيد من المعلومات حول CRL أو OCSP، راجع المستند التالي:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_pki/configuration/xe-17/sec-pki-xe-17-book/sec-cfg-auth-rev-cert.html

فحص CRL

! Sample A: CRL from the certificate
crypto pki trustpiont ROOT-CA
 revocation-check crl
!
! Sample B: CRL Override OCSP in certificate
crypto pki certificate map CRL-OVERRIDE 1
 issuer-name eq root-ca.cisco.com
 subject-name eq root-ca.cisco.com
 alt-subject-name co cisco.com
!
crypto pki trustpoint ROOT-CA
 revocation-check crl
 match certificate CRL-OVERRIDE override cdp url http://www.cisco.com/security/pki/crl/crca2048.crl
!

فحص OCSP

! Sample A: OCSP from the certificate
crypto pki trustpiont ROOT-CA
 revocation-check ocsp
!
! Sample B: Override OCSP in certificate
crypto pki certificate map OCSP-OVERRIDE 1
 issuer-name eq root-ca.cisco.com
 subject-name eq root-ca.cisco.com
 alt-subject-name co cisco.com
!
crypto pki trustpoint ROOT-CA
 revocation-check ocsp
 match certificate OCSP-OVERRIDE override ocsp 1 url http://ocsp-responder.cisco.com
!

تم طلب فحص OCSP و CRL

! Check CRL if failure, check OCSP
crypto pki trustpoint ROOT-CA
 revocation-check crl ocsp
!

تمكين التحقق من الاسم الشائع (CN) والاسم البديل للموضوع (SAN) 

يمكن تكوين المكعب للتحقق من مطابقة CN للشهادة أو SAN لاسم المضيف من DNS هدف جلسة العمل: الأمر. في IOS-XE 17.8+ يمكن تكوين ملف تعريف TLS عبر ملف تعريف TLS.

IOS-XE 17.8+

Router(config)# voice class tls-profile 1
Router(config-class)# cn-san validate ?
  bidirectional Enable CN/SAN validation for both client and server certificate
  client Enable CN/SAN validation for client certificate
  server Enable CN/SAN validation for server certificate

تذكر أن تعيين العميل/الخادم يشير إلى دور الأجهزة النظيرة في مصافحة TLS

لإيضاح اضافي:

• خادم التحقق من صحة CN-SAN: سيقوم CUBE بإجراء التحقق من اسم المضيف لشهادات خادم النظير المستلمة لاتصالات TLS الصادرة حيث يكون CUBE دور العميل.
• عميل التحقق من صحة CN-SAN: سيقوم CUBE بالتحقق من صحة اسم المضيف لشهادات عميل النظير المستلمة لاتصالات TLS الواردة حيث يكون CUBE هو دور الخادم.
• التحقق من صحة CN-SAN بالاتجاه الثنائي: تمكين التحقق من اسم المضيف لكل من أدوار النظير أثناء مصافحة TLS.

عند إستخدام الأمر cn-SAN Verify Client (أو ثنائي الإتجاه)، يجب تكوين شبكة منطقة تخزين (SAN) للتحقق منها حيث إن التحقق من هدف جلسة العمل هو للاتصال الصادر فقط وخادم التحقق من صحة cn-SAN.

التحقق من صحة اسم المضيف للعميل:

!
voice class tls-profile 1
 cn-san validate client
 cn-san 1 *.example.com
 cn-san 2 subdomain.example.com
!

التحقق من صحة اسم المضيف للخادم:

!
voice class tls-profile 1
 cn-san validate server
!
sip-ua
 crypto signaling default tls-profile 1
!
dail-peer voice 1 voip
 session target dns:subdomain.example.com
!

قبل 17-8-1

ملاحظة: يتوفر التحقق من صحة اسم المضيف للخادم فقط من خلال هذه الطريقة. 

!
sip-ua
 crypto signaling default trustpoint TEST cn-san-validate server
!
dail-peer voice 1 voip
 session target dns:subdomain.example.com
!

كما يمكن تكوين CUBE لإرسال ملحق TLS 1.2 الخاص بإشارة اسم الخادم (SNI) مع اسم المضيف FQDN الخاص ب CUBE داخل مصافحة TLS إلى الأجهزة النظيرة لتسهيل جهود التحقق من صحة اسم المضيف.

!
voice class tls-profile 1
 sni send
!
sip-ua
 crypto signaling default tls-profile 1
!

ملاحظة على TLS المشترك للمكعب:

• بشكل افتراضي عندما يعمل CUBE كخادم TLS (قراءة اتصال TLS الوارد) فإنه سيطلب دائما شهادة عميل. لا يوجد تكوين لتعطيل هذا السلوك.
• عندما يعمل CUBE كعميل TLS ويبدأ اتصال TLS الصادر يكون TLS المشترك متروكا للجهاز النظير الذي يعمل كخادم TLS. في هذا السيناريو، قد لا يطلب جهاز نظير شهادة عميل من CUBE.
• في كلا السيناريوهين، يتم التحكم في سلسلة الشهادات التي يرسلها المكعب بواسطة TrustPoint المحدد في ملف تعريف TLS أو على أمر إرسال إشارات التشفير.

!
sip-ua
 crypto signaling default trustpoint CUBE-ENT
!
! OR
voice class tls-profile 1
 trustpoint CUBE-ENT
!
sip-ua
 crypto signaling default tls-profile 1
!

تعيين إتصالات TLS البعيدة بنقاط ثقة محددة

عند إستخدام الأمر crypto signaling default sip-ua يتم تعيين جميع إتصالات TLS الواردة إلى هذا التكوين إما عبر TLS-profile أو أوامر post-fix الفردية. وعلاوة على ذلك، يتم التحقق من جميع نقاط الثقة المتاحة عند إجراء التحقق من صحة الشهادة.

قد يكون من المفضل إنشاء تكوينات ملف تعريف TLS معينة لجهاز نظير معين استنادا إلى عنوان IP لضمان تطبيق معلمات الأمان التي تقوم بتعريفها بدقة على جلسة TLS تلك. لتنفيذ ذلك، أستخدم الأمر crypto signaling remote-addr لتحديد شبكة فرعية IPv4 أو IPv6 للتعيين إلى ملف تعريف TLS أو مجموعة من أوامر إعادة التوجيه. يمكنك أيضا تعيين أوامر VerificationPoint مباشرة عبر client-vtp) لتأمين نقاط الثقة التي يتم إستخدامها للتحقق من شهادات النظير بدقة.

يلخص الأمر أدناه معظم العناصر التي تمت مناقشتها حتى هذه النقطة:

!
voice class tls-cipher 1
 cipher 1 ECDHE_RSA_AES128_GCM_SHA256
 cipher 2 ECDHE_RSA_AES256_GCM_SHA384
!
voice class tls-profile 1
 trustpoint CUBE-ENT
 cn-san validate bidirectional
 cn-san 1 *.example.com
 cipher 2
 client-vtp PEER-TRUSTPOINT
 sni send
!
sip-ua
 crypto signaling remote-addr 192.168.1.0 /24 tls-profile 1
!

بالنسبة للإصدارات الأقدم، يمكن القيام بذلك على النحو التالي:

!
sip-ua
 crypto signaling remote-addr 192.168.1.0 /24 trustpoint CUBE-ENT cn-san-validate server client-vtp PEER-TRUSTPOINT strict-cipher
!

بداية من 17.8 يمكنك أيضا تكوين منافذ إستماع إلى ملف تعريف TLS و لكل مستأجر لكل مستأجر من فئة الصوت لتوفير خيارات تجزئة إضافية على منفذ إستماع معطى.

!
voice class tenant 1
 tls-profile 1
 listen-port secure 5062
!

فرض بروتوكول SRTP الصارم

عند تمكين SRTP على CUBE Enterprise، تكون العملية الافتراضية هي عدم السماح بالنسخ الاحتياطي ل RTP.

وحيثما كان ذلك ممكنا، سيقوم إستخدام SRTP على جميع أقدام المكالمات ومع ذلك المكعب الافتراضي بتنفيذ RTP-SRTP حسب الحاجة.

لاحظ أن CUBE لا يقوم بتسجيل مفاتيح SRTP في تصحيح الأخطاء بدءا من 16.11+

!
voice service voip
 srtp
!
! or
!
dial-peer voice 1 voip
 srtp
!

تشفير SRTP غير الآمن

بشكل افتراضي، يتم إرسال جميع شفرات SRTP بواسطة CUBE عند إنشاء عرض. يمكن أن يقتطع المسؤول إلى شفرة أكثر أمانا مثل مجموعات تشفير AEAD من الجيل التالي باستخدام الأمر voice class srtp-crypto في IOS-XE 16.5+. 

كما يمكن لهذا التكوين تغيير التفضيل الافتراضي المستخدم عندما يقوم CUBE بتحديد تشفير SRTP وإنشاء إجابة على بعض العروض باستخدام خيارات متعددة متوفرة.

ملاحظة: قد لا تدعم بعض أجهزة Cisco أو الأجهزة النظيرة القديمة شفرات AEAD. راجع جميع الوثائق القابلة للتطبيق عند اقتطاع مجموعات التشفير.

Router(config)# voice class srtp-crypto 1
Router(config-class)# crypto ?
  <1-4> Set the preference order for the cipher-suite (1 = Highest)
Router(config-class)# crypto 1 ?
  AEAD_AES_128_GCM        Allow secure calls with SRTP AEAD_AES_128_GCM cipher-suite
  AEAD_AES_256_GCM        Allow secure calls with SRTP AEAD_AES_256_GCM cipher-suite
  AES_CM_128_HMAC_SHA1_32 Allow secure calls with SRTP AES_CM_128_HMAC_SHA1_32 cipher-suite
  AES_CM_128_HMAC_SHA1_80 Allow secure calls with SRTP AES_CM_128_HMAC_SHA1_80 cipher-suite

!
voice class srtp-crypto 1
 crypto 1 AEAD_AES_256_GCM
 crypto 2 AEAD_AES_128_GCM
!
voice service voip
 sip
  srtp-crypto 1
!
! or
!
voice class tenant 1
 srtp-crypto 1
!
! or
! 
dial-peer voice 1 voip
 voice-class srtp-crypto 1
!

تعطيل بروتوكولات VoIP الأخرى غير المستخدمة

إذا لم يتم إستخدام H323 و MGCP و SCCP و STCAPP و CME و SRST على هذه البوابة، فإن الأمر يستحق إزالة التكوينات لتقسية المكعب.

تعطيل H323 والسماح فقط ل SIP بمكالمات SIP

!
voice service voip
 allow-connections sip to sip
 h323
  call service stop
!

تعطيل MGCP و SCCP و STCAPP و SIP و SCCP SRST.

ملاحظة: ستقوم بعض هذه الأوامر بحذف جميع التكوينات الأخرى، فتأكد من عدم إستخدام الميزات قبل إزالتها بالكامل.

Router(config)# no mgcp
Router(config)# no sccp
Router(config)# no stcapp
Router(config)# no voice register global
Router(config)# no telephony-service
Router(config)# no call-manager-fallback

توجيه المكالمات والاحتيال على المكالمات

السماح بالاتصالات من عناوين IP الموثوق بها

افتراضيا، سيثق CUBE بالاتصالات الواردة من عناوين IPv4 و IPv6 التي تم تكوينها على عمليات تكوين هدف جلسة عمل الطلب وعمليات تكوين مجموعة خادم الصوت.

لإضافة عناوين IP إضافية باستخدام أمر القائمة الموثوق بها لعنوان IP الذي تم تكوينه من خلال الخدمة الصوتية عبر بروتوكول الإنترنت.

عندما يتم تكوين التحقق من اسم المضيف للعميل/الخادم بجانب SIP TLS عن طريق ميزة التحقق من صحة CN/SAN التي تمت مناقشتها مسبقا، فإن التحقق من صحة CN/SAN بنجاح سوف يتجاوز عمليات التحقق من قائمة عناوين IP الموثوق بها.

تجنب إستخدام مصادقة غير موثوق بها لعنوان IP مما سيمكن CUBE من قبول أي اتصال وارد.

!
voice service voip
 ip address trusted authenticate 

 ip address trusted list
  ipv4 192.168.1.1
  ipv4 172.16.1.0 /24
!

أستخدم show ip address trusted list لعرض حالة التحقق من عنوان IP وجميع تعريفات القائمة الموثوق بها الثابتة والحيوية المشتقة من تكوينات أخرى.

لاحظ أنه يتم إزالة القيمة الديناميكية المشتقة من نظير الطلب/مجموعة الخادم من القائمة الموثوق بها عند إيقاف تشغيل نظير الطلب أو تعيينه على حالة إيقاف التشغيل بعد فشل عمليات التحقق من رسائل تنشيط الاتصال.

بشكل افتراضي عند عدم تمرير مكالمة واردة للتحقق من قائمة IP الموثوق بها يتم تجاهلها بصمت ولكن يمكن تجاوز هذا الإجراء باستخدام الأمر no silent-discard غير موثوق به عبر الخدمة الصوتية > sip لإرسال خطأ مرة أخرى إلى المرسل. ومع ذلك، فعن طريق إرسال رد قد يستخدم المهاجم هذا للإشارة إلى أن الجهاز يستمع في الواقع لحركة مرور SIP ويكثف جهود هجومه. مثل هذا التجاهل الصامت هو الطريقة المفضلة لمعالجة عمليات إسقاط قائمة IP الموثوق بها.

تجنب توجيه نظير الطلب العام

يمكن أن يؤدي إستخدام أنماط وجهة "التقاط الكل" العامة مثل نمط الوجهة .T إلى زيادة أحتمالية توجيه مكالمة احتيالية عبر CUBE.

يجب على المسؤولين تكوين CUBE إلى مكالمات التوجيه فقط لنطاقات أرقام الهاتف المعروفة أو SIP URIs. 

راجع المستند التالي للحصول على شرح أكبر لميزات توجيه مكالمات CUBE:

https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html

تخفيف تهديد المكعب

معالجة الحزم غير المشكلة

يقوم المكعب الافتراضي بفحص حزم SIP و RTP للتحقق من عدم وجود أخطاء وإسقاط الحزمة.

حزم RTP المخادعة

بشكل افتراضي، يقوم مكعب IOS-XE بإجراء التحقق من صحة منفذ المصدر لجميع تدفقات RTP/RTCP عن طريق السماح فقط للاتصالات التي تم التفاوض عليها عبر إرسال إشارات العرض/الإجابة الخاصة ب SIP SDP ولا يمكن تعطيلها.

هذا يستطيع كنت monitore ب يفحص التالي أمر:

show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets:

للتفاعل مع CUCM، يوصى بتمكين تدفق الوسائط المزدوجة من خلال خدمة Cisco CallManager لتجنب إسقاط الموسيقى قيد الانتظار عندما يتم الحصول عليها من المنفذ 4000.

تقوية نطاق منفذ RTP

افتراضيا يستعمل IOS-XE الميناء مدى من 8000 حتى 48198. يمكن تكوين هذا إلى نطاق مختلف مثل 16384 حتى 32768 من خلال الأمر التالي:

!
voice service voip
 rtp-port range 16384 32768
!

قد يقوم المسؤول أيضا بتكوين نطاقات منافذ RTP لكل نطاقات عناوين IPv4 و IPv6.

كما يتيح هذا التكوين لتطبيق VoIP الخاص بالمكعب إجراء معالجة الحزم الوهمية بكفاءة أكبر من خلال عدم تقييد هذه الحزم بعملية UDP في وحدة المعالجة المركزية للموجه نظرا لأنه يتم تعريف IP ونطاق المنفذ بشكل ثابت. ويمكن أن يساعد ذلك على تخفيف إرتفاع وحدة المعالجة المركزية (CPU) عند معالجة عدد كبير من حزم RTP الشرعية أو غير الشرعية عن طريق تجاوز سلوك فرض إختبارات على وحدة المعالجة المركزية (CPU).

voice service voip
 media-address range 192.168.1.1 192.168.1.1
  port-range 16384 32768
 media-address range 172.16.1.1 172.16.1.1
  port-range 8000 48198

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_phantom-packet-handling.html

منع قطع الخدمة (DoS)

يمكن تمكين ميزة التحكم بإذن دخول المكالمة للحد من المكالمات استنادا إلى إجمالي المكالمات ووحدة المعالجة المركزية والذاكرة والنطاق الترددي. بالإضافة إلى ذلك، يمكن الكشف عن "زيادات المكالمات" لرفض المكالمات ومنع رفض الخدمة.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-call-admission-control.html

إخفاء العنوان

سيقوم المكعب الافتراضي باستبدال عناوين IP في رؤوس SIP مثل، وليس حصرا على VIA وجهات الاتصال ومن خلال عنوان IP الخاص به.

يمكن توسيع هذا الإجراء للإشارة إلى رؤوس جهات الاتصال 3xx و History-Info و Switching عن طريق تطبيق إخفاء عنوان أمر الخدمة الصوتية عبر بروتوكول الإنترنت.

وبالإضافة إلى ذلك، يتم إنشاء معرف اتصال جديد لكل عنوان IP مخفف لخط الاتصال قد يكون مضمنا في قيمة الرأس هذه.

حيث يكون اسم المضيف مطلوبا بدلا من عنوان IP لأغراض إخفاء العنوان يمكن تكوين الأمر voice-class sip localhost dns:cube.cisco.com.

خصوصية معرف المتصل

يمكن تكوين CUBE لإسقاط قيم اسم معرف المتصل من رؤوس SIP باستخدام الأمر clid-strip name الذي تم تكوينه على أي نظير اتصال.

علاوة على ذلك، يمكن أن يتداخل CUBE ويفهم رؤوس خصوصية SIP مثل الهوية المفضلة ل P (PPID)، والهوية المؤكدة ل P (مدفوعة)، والخصوصية، وهوية الطرف المسماة ب (PCPID)، وهوية الطرف البعيد (RPID). لمزيد من المعلومات، ارجع إلى المستند التالي: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-paid-ppid-priv.html

مصادقة ملخص SIP

أثناء تسجيل SIP بواسطة CUBE إلى موفر الخدمة أو أثناء إستدعاء إرسال إشارات UAS للتدفق قد تقوم أجهزة UAS بإرجاع رمز حالة 401 أو 407 باستخدام WWW-Authenticate/Proxy-Authenticate لحقل رأس قابل للمصادقة لمصادقة WWW-Authenticate/Proxy-Authenticate للمصادقة لمصادقة CUBE. أثناء عملية مصافحة CUBE هذه، يدعم خوارزمية MD5 لحساب قيمة حقل رأس التخويل في طلب ثابت.

رؤوس SIP غير المدعومة أو SDP 

سيقوم CUBE بتجريد رؤوس SIP غير المدعومة أو SDP التي لا يفهمها. يجب توخي الحذر عند إستخدام أوامر مثل pass-thru content sdp أو pass-thru content unsupp أو pass-through headers unsupp لضمان نقل البيانات من خلال CUBE.

إزالة رؤوس SIP أو SDP أو تعديلها

حيث يكون التحكم الإضافي مطلوبا يمكن أن يتم تكوين توصيفات SIP الواردة أو الصادرة بواسطة مسؤول لتعديل رأس SIP أو سمة SDP أو إسقاطها بشكل مرن.

ارجع إلى المستندات التالية في إستخدام ملف تعريف SIP:

• https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-sip-param-mod.html
• https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html#anc45

ميزات الأمان الأخرى

كلمات المرور المشفرة

يتطلب CUBE كلمات مرور مشفرة ل 16.11 والإصدارات الأحدث لتشفير تسجيل SIP وكلمات مرور IOS-XE الأخرى في التكوين الجاري.

password encryption aes
key config-key password-encrypt cisco123

قوائم الوصول

تعمل ميزة القائمة الموثوق بها في الطبقة 7 داخل تطبيق CUBE. بحلول الوقت الذي يتم فيه إسقاط الحزمة بصمت، يكون المكعب قد بدأ معالجة الحزمة بالفعل.

قد يكون من المفضل قفل الواجهات باستخدام قوائم الوصول الواردة أو الصادرة من الطبقة 3 أو 4 لإسقاط الحزمة عند نقطة إدخال الموجه.

وهذا يضمن قضاء دورات وحدة المعالجة المركزية (CPU) من CUBE على حركة المرور الشرعية. توفر قوائم التحكم في الوصول (ACL) جنبا إلى جنب مع قائمة IP الموثوق بها والتحقق من صحة اسم المضيف نهجا متعدد الطبقات لأمان CUBE.

جدار الحماية المستند إلى المنطقة (ZBFW)

يمكن تكوين CISCO CUBE بجانب IOS-XE ZBFW لتوفير فحص التطبيق ومميزات الأمان الأخرى.

راجع CUBE و ZBFW للحصول على مزيد من المعلومات حول هذا الموضوع:

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220378-configure-zone-based-firewall-zbfw-co.html