- Start
- /
- Artikel
Säkerhetskrav för Webex Calling
Den här artikeln är avsedd för nätverksadministratörer, särskilt brandvägg- och proxysäkerhetsadministratörer som vill använda Webex Calling inom sin organisation.
Portreferensinformation för brandväggs- och åtkomstkrav finns i Portreferensinformation för Cisco Webex Calling.
Krav för slutpunkter
Webex Calling Edge
Gå igenom dessa steg om du vill göra en SIP-registrering eller ringa ett samtal:
-
Identifiera värdadressen till en SIP-slutpunkt för aktiva Edge-noder.
-
Se till att uppfylla alla förutsättningar som är relaterade till användar- och enhetskonfigurationen.
-
Säkerställ att slutpunkten har en anslutning till ett offentligt nätverk så att tjänstidentifieringen kan starta.
-
Se till att uppfylla förutsättningarna för start (bootstrapping) av slutpunkten med en region- eller datacenterspecifik etableringskonfiguration. Den här konfigurationen hjälper dig att erhålla det relevanta domännamnssuffixet för tjänstidentifiering.
IPv4 kontra IPv6
Enheter kan arbeta i ett enversions- eller dubbelstackläge. Det är konfigurationen som avgör vilka ändringar som görs i det föredragna protokollet och dessa ändringar är inte en del av tjänstidentifieringen.
-
Enkelstackläge – aktiverar endast ett IP-protokoll (till exempel IPv4) och ignorerar de andra protokolladresserna.
-
Dubbelstackläge – väljer en föredragen IP-version genom konfigurationen.
Klienten anser att prioriteten för alla föredragna adresser är lägre än (det vill säga föredras framför) alla IP-adresserna. Om IPv4 föredras prövas alla IPv4-adresser innan en IPv6-adress prövas. Om det inte går att nå någon av adresserna börjar cykeln om igen med den föredragna protokolladressen med lägst prioritet.
En mobilklient som registrerar sig vid mottagandet av ett push-meddelande kan bestämma sig för att optimera läget baserat på tidigare registreringar.
Matchning av värdadress från DNS SRV-adressen
I den slutpunktskonfigurationsfil som erhålls vid etableringen specificerar domänindikatorn det domännamn som ska identifiera Access Edge-tjänsten. Följande är ett exempel på domännamnet:
wxc.edge.bcld.webex.com
Från exemplet kan slutpunkten som utför en DNS SRV-sökning för den här domänen ge ett svar som liknar följande:
# nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com _sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com. _sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.
I detta fall pekar SRV-posten på tre A-poster.
sip-edge1.us-dc1.bcld.webex.com sip-edge2.us-dc1.bcld.webex.com
I exemplet annonseras alla värdar för kontaktport 5061 med olika vikt och prioritet.
Överväg dessa krav för slutpunkter.
-
En slutpunkt måste använda
_sips._tcp
(service- och protokollkombination) som prefix för att utföra en DNS SRV-sökning för att hämta värdadress för att initiera TLS-baserad kommunikation. -
En slutpunkt måste göra en DNS SRV-sökning efter villkoren som beskrivs i avsnittet Matchning av värdadress från DNS SRV-adressen.
-
En slutpunkt måste använda den värd, port, vikt och prioritet som annonseras för var och en av värdadresserna. Dessutom måste den skapa tillhörighet mellan värd och port när en sockelanslutning skapas under SIP-registreringen.
-
I RFC 2782 beskrivs urvalskriterierna för värdar baserat på prioritet och vikt specifikt för användning av DNS SRV-posten.
Krav för SIP och media
Krav |
Description |
---|---|
Förtroendecertifikat krävs för kryptering med offentlig nyckel |
Se artikeln för mer information om Webex-certifikatens signeringsrättighet och vilken rotcertifikatutfärdare som krävs på enheterna |
TLS-versionen stöds för säker SIP |
TLS 1.2 |
TLS-chiffrering stöds för säker SIP |
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 |
SRTP-nycklar stöds för säker media |
AES_CM_128_HMAC_SHA1_80 |
Krav för säker SIP med mTLS (ömsesidig TLS)
Kraven förklaras i detalj här.
Ett signerat certifikat krävs för att auktorisering och autentisering av samtal från trunken ska fungera. Certifikatet måste uppfylla följande krav:
-
Certifikatet måste signeras av en CA som nämns i Vilka rotcertifikatutfärdare stöds för samtal till Cisco Webex-ljud- och videoplattformar?
-
Överför det förtroendepaket som nämns i Vilka rotcertifikatutfärdare stöds för samtal till Cisco Webex-ljud- och videoplattformar? på till CUBE.
-
Certifikatet måste alltid vara giltigt:
-
Signerade certifikat måste alltid ha ett giltigt utgångsdatum.
-
Rotcertifikat eller mellanliggande certifikat måste ha ett giltigt utgångsdatum och får inte återkallas.
-
Certifikaten måste signeras för klient- och serveranvändning.
-
Certifikaten måste innehålla det fullständigt kvalificerade domännamnet (FQDN) som vanligt namn eller ett alternativt ämnesnamn (SAN) i certifikatet med den FQDN som har valts i Control Hub. Till exempel:
-
En trunk som konfigureras från din organisations Control Hub medlondon.lgw.cisco.com:5061 som FQDN måste innehålla london.lgw.cisco.com i certifikatets CN eller SAN.
-
En trunk som konfigureras från din organisations Control Hub med london.lgw.cisco.com som SRV måste innehålla london.lgw.cisco.com i certifikatets CN eller SAN. Posterna som SRV-adressen omvandlar till (CNAME/A-post/IP-adress) är valfria i SAN.
-
-
Du kan dela certifikat med fler än en lokal gateway, men du måste säkerställa att FQDN-kraven är uppfyllda.
-
Utanför hanteringsomfånget
Den här artikeln inkluderar inte följande information om nätverkssäkerhet:
-
F5-krav för certifikatutfärdare och chiffreringar
-
Ett HTTP-baserat API för nedladdning av brandväggsregler för Webex.
-
API för en betrodd grupp
-
Brandväggskrav och avstängning av ALG