- Hjem
- /
- Artikkel
Sikkerhetskrav for Webex Calling
Denne artikkelen er ment for nettverksadministratorer, spesielt brannmur- og proxy-sikkerhetsadministratorer som ønsker å bruke Webex Calling i organisasjonen sin.
For å finne ut portreferanseinformasjonen for brannmur og tilgangskrav, se Portreferanseinformasjon for Cisco Webex Calling.
Krav til endepunkter
Webex Calling Edge
For å utføre en SIP-registrering eller et anrop, fullfør disse trinnene:
-
Oppdag vertsadressen til et SIP-endepunkt for aktive Edge-noder.
-
Fullfør alle forhåndsbetingelser knyttet til bruker- og enhetskonfigurasjon.
-
Sørg for at endepunktet har offentlig nettverkstilkobling for å starte tjenesteoppdagelse.
-
Fullfør forutsetningene for oppstart av endepunktet med en region- eller datasenterspesifikk klargjøringskonfigurasjon. Denne konfigurasjonen bidrar til å hente det relevante domenenavnsuffikset for tjenesteoppdagelse.
IPv4 versus IPv6
Enheter kan operere i enkeltversjons- eller dobbeltstabelmodus. Det er konfigurasjonen som bestemmer endringene i den foretrukne protokollen, og disse endringene er ikke en del av tjenesteoppdagelsen.
-
Enkeltstabelmodus – aktiverer bare én IP-protokoll (for eksempel IPv4) og ignorerer de andre protokolladressene.
-
Dobbeltstabelmodus – velger en foretrukket IP-versjon gjennom konfigurasjon.
Klienten anser prioriteten for alle foretrukne adresser som lavere (det vil si foretrukket) enn alle adressene til IP-adressen. Hvis IPv4 foretrekkes, forsøkes alle IPv4-adresser før en IPv6-adresse forsøkes. Hvis alle adressene feiler, starter syklusen på nytt med den foretrukne protokolladressen med lavest prioritet.
En mobilklient som registrerer seg ved mottak av et push-varsel, kan bestemme seg for å optimalisere modusen basert på tidligere registreringer.
Oppløsning av vertsadresse fra DNS SRV-adressen
I endepunktkonfigurasjonsfilen som er hentet fra klargjøringen, spesifiserer domeneindikatoren domenenavnet for å oppdage tilgangskanttjenesten. Et eksempel på domenenavnet er:
wxc.edge.bcld.webex.com
Fra eksemplet kan endepunktet som utfører et DNS SRV-oppslag for dette domenet gi et svar som ligner på følgende:
# 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 dette tilfellet peker SRV-posten til 3 A-poster.
sip-edge1.us-dc1.bcld.webex.com
sip-edge2.us-dc1.bcld.webex.com
I eksemplet annonseres det at alle verter kontakter port 5061 med ulik vekt og prioritet.
Vurder disse kravene for endepunkter.
-
Et endepunkt må bruke
_sips._tcp
(tjeneste & protokollkombinasjon) som prefiks for å utføre et DNS SRV-oppslag for å hente vertsadresse for å starte TLS-basert kommunikasjon. -
Et endepunkt må gjøre et DNS SRV-oppslag for betingelsene som er forklart i delen Løsning av vertsadresse fra DNS SRV-adressen.
-
Et endepunkt må respektere vert, port og vekt & prioritet som annonsert for hver av vertsadressene. Den må også opprette en affinitet mellom vert og port når en socket-tilkobling opprettes under SIP-registrering.
-
Spesifikt for bruk av DNS SRV-posten, utvalgskriteriene for verter basert på prioritet & vekt er forklart i RFC 2782.
Krav til SIP og medier
Behov |
Beskrivelse |
---|---|
Klareringssertifikat kreves for kryptering av offentlig nøkkel |
Se artikkelfor å vite om Webex-sertifikaters signeringsmyndighet og rot-CA som kreves på enheter. |
TLS-versjon støttet for sikker SIP |
TLS 1.2 og TLS 1.3 |
TLS-chiffer støttes for sikker SIP |
TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 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-nøkler støttes for sikre medier |
AES_CM_128_HMAC_SHA1_80 |
Krav for sikker SIP med mTLS (gjensidig TLS)
Kravene er forklart i detalj her.
Et signert sertifikat er nødvendig for vellykket autorisasjon og autentisering av anrop fra trunk-linjen. Sertifikatet må oppfylle følgende krav:
-
Sertifikatet må signeres av en CA nevnt i Hvilke rotsertifikatmyndigheter støttes for anrop til Cisco Webex lyd- og videoplattformer?
-
Last opp tillitspakken som er nevnt i Hvilke rotsertifikatmyndigheter støttes for anrop til Cisco Webex lyd- og videoplattformer?til KUBE.
-
Sertifikatet skal alltid være gyldig:
-
Signerte sertifikater må alltid ha en gyldig utløpsdato.
-
Rot- eller mellomliggende sertifikater må ha en gyldig utløpsdato og kan ikke tilbakekalles.
-
Sertifikater må signeres for bruk på klient og server.
-
Sertifikater må inneholde det fullstendig kvalifiserte domenenavnet (FQDN) som et vanlig navn eller et alternativt emnenavn i sertifikatet, med FQDN valgt i Kontrollhuben. For eksempel:
-
En trunk konfigurert fra organisasjonens kontrollhub med london.lgw.cisco.com:5061 ettersom FQDN må inneholde london.lgw.cisco.com i sertifikatets CN eller SAN.
-
En trunk konfigurert fra organisasjonens kontrollhub med london.lgw.cisco.com var SRV-en, og må inneholde london.lgw.cisco.com i sertifikatets CN eller SAN. Postene som SRV-adressen løser to (CNAME/A Post/IP-adresse) er valgfrie i SAN.
-
-
Du kan dele sertifikater med mer enn én lokal gateway, men sørg for at FQDN-kravene er oppfylt.
-
Utenfor omfang
Denne artikkelen inneholder ikke følgende informasjon relatert til nettverkssikkerhet:
-
F5-krav for CA og chiffer
-
Et HTTP-basert API for å laste ned brannmurregler for Webex.
-
API for en tillitspakke
-
Brannmurkrav & ALG-deaktivering