- Hjem
- /
- Artikkel
Sikkerhetskrav for Webex Calling
Denne artikkelen er ment for nettverksadministratorer, spesielt sikkerhetsadministratorer for brannmur og proxy som ønsker å bruke Webex Calling i organisasjonen sin.
Hvis du vil vite portreferanseinformasjonen for brannmur- og tilgangskrav, kan du se Portreferanseinformasjon for Cisco Webex Calling.
Krav til endepunkter
Webex Calling Edge
Følg disse trinnene for å utføre en SIP-registrering eller et anrop:
-
Oppdag vertsadressen til et SIP-endepunkt for aktive Edge-noder.
-
Fullfør eventuelle forutsetninger relatert til bruker- og enhetskonfigurasjon.
-
Kontroller at endepunktet har offentlig nettverkstilkobling for å starte tjenesteoppdagelse.
-
Fullfør betingelsene for oppstart av endepunktet med en region- eller datasenterspesifikk klargjøringskonfigurasjon. Denne konfigurasjonen bidrar til å skaffe det relevante domenenavnet for tjenestesøk.
IPv4 kontra IPv6
Enheter kan fungere i enkeltversjons- eller dobbeltstakkmodus. Det er konfigurasjonen som bestemmer endringene i den foretrukne protokollen, og disse endringene er ikke en del av tjenesteoppdagelse.
-
Enkeltstakkmodus – aktiverer bare én IP-protokoll (for eksempel IPv4) og ignorerer de andre protokolladressene.
-
Dobbeltstakkmodus – velger en foretrukket IP-versjon gjennom konfigurasjonen.
Klienten anser prioriteten for alle foretrukne adresser som lavere (dvs. foretrukket) enn alle adressene til IP-en. Hvis IPv4 foretrekkes, forsøkes alle IPv4-adresser før en IPv6-adresse forsøkes. Hvis alle adresser mislykkes, starter syklusen på nytt med den laveste foretrukne protokolladressen.
En mobilklient som registrerer seg ved mottak av et push-varsel kan bestemme seg for å optimalisere modusen basert på tidligere registreringer.
Løsning av vertsadresse fra DNS SRV-adressen
I konfigurasjonsfilen for endepunkter hentet fra klargjøring angir domeneindikatoren domenenavnet for å oppdage tjenesten for Access Edge. 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 en respons 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 alle verter til kontaktport 5061 med forskjellig vekt og prioritet.
Vurder disse kravene for endepunkter.
-
Et endepunkt må bruke
_sips._tcp
(tjeneste- og protokollkombinasjon) som prefiks for å utføre et DNS SRV-oppslag for å hente vertsadresse for å starte TLS-basert kommunikasjon. -
Et endepunkt må utføre et DNS SRV-oppslag for betingelsene som er forklart i Løsning av vertsadresse fra DNS SRV-adressedelen.
-
Et endepunkt må respektere vert, port, vekt og prioritet som annonsert for hver av vertsadressene. Den må også skape en affinitet mellom vert og port når du oppretter en socket-tilkobling under SIP-registrering.
-
Valgkriteriene for verter basert på prioritet og vekt er spesifikt for bruk av DNS SRV-posten, forklart i RFC 2782.
Krav til SIP og media
Krav |
Beskrivelse |
---|---|
Klareringssertifikat kreves for kryptering av offentlig nøkkel |
Se artikkelen for å vite om Webex-sertifikatenes signeringsmyndighet og rotsertifiseringsinstans som kreves på enheter |
TLS-versjon støttes for sikker SIP |
1.2 |
TLS-chifre støttes for sikker 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-nøkler støttes for sikre medier |
AES_CM_128_HMAC_SHA1_80 |
Krav til sikker SIP med mTLS (felles TLS)
Kravene er forklart i detalj her.
Et signert sertifikat kreves for vellykket godkjenning og godkjenning av samtaler fra trunken. Sertifikatet må oppfylle følgende krav:
-
Sertifikatet må signeres av en sertifiseringsinstans nevnt i Hvilke rotsertifiseringsinstanser støttes for samtaler til Cisco Webex lyd- og videoplattformer?
-
Last opp klareringspakken nevnt i Hvilke rotsertifiseringsinstanser støttes for samtaler til Cisco Webex lyd- og videoplattformer? til CUBE.
-
Sertifikatet skal alltid være gyldig:
-
Signerte sertifikater må alltid ha gyldig utløpsdato.
-
Rot- eller mellomsertifikater må ha gyldig utløpsdato og må ikke tilbakekalles.
-
Sertifikater må signeres for klient- og serverbruk.
-
Sertifikater må inneholde Fully Qualified Domain Name (FQDN) som et vanlig navn eller alternativt emnenavn i sertifikatet med FQDN valgt i Control Hub. For eksempel:
-
En trunk som er konfigurert fra organisasjonens Control Hub med london.lgw.cisco.com:5061 som FQDN, må inneholde london.lgw.cisco.com i sertifikatets CN eller SAN.
-
En trunk konfigurert fra organisasjonens Control Hub med london.lgw.cisco.com som SRV, må inneholde london.lgw.cisco.com i sertifikatets CN eller SAN. Oppføringene som SRV-adressen løser til (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.
-
Ikke tilgjengelig
Denne artikkelen inkluderer ikke følgende informasjon relatert til nettverkssikkerhet:
-
F5-krav for CA og ciphers
-
Et HTTP-basert API for å laste ned brannmurregler for Webex.
-
API for en klareringspakke
-
Brannmurkrav og ALG-deaktivering