Distribution av Expressway-C- och Expressway-E-parning möjliggör samtal till och från internet med teknik för brandväggstraversal. Den här distributionen ger säker samtalskontroll över lokala samtal och knyter den till Cisco Webex.

För Expressway-C och Expressway-E krävs inte att en inkommande port öppnas i brandväggen för demilitariserad zon (DMZ) på grund av brandväggens traversalarkitektur. Men TCP SIP-signaleringsportar och UDP-medieportar måste öppnas för att inkommande samtal ska komma igenom. Du måste vänta en stund för att lämplig port ska öppnas på företagsbrandväggen.

Brandväggens traversalarkitektur visas i följande diagram:

För till exempel inkommande B2B-samtal (business-to-business) där SIP-protokoll används måste TCP-portarna 5060 och 5061 (5061 används för SIP TLS) öppnas på den externa brandväggen, tillsammans med UDP-medieportar som används för tjänster som t.ex. röst, video, dokumentdelning, dubbel video och så vidare. Vilka medieportar som ska öppnas beror på antalet samtidiga samtal och antalet tjänster.

Du kan konfigurera SIP-lyssningsporten på Expressway med vilket värde som helst mellan 1024 och 65534. Samtidigt måste värdet och protokolltypen annonseras i offentliga DNS SRV-register och samma värde måste öppnas på internetbrandväggen.

Även om standarden för SIP TCP är 5060 och SIP TLS 5061 förhindras inte användning av olika portar, vilket visas i följande exempel.

Exempel

I det här exemplet förutsätter vi att port 5062 används för inkommande SIP TLS-samtal.

DNS SRV-registreringen för ett kluster med två Expressway-servrar ser ut så här:

_sips._tcp.example.com SRV service location:

prioritet = 10

vikt = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV service location:

prioritet = 10

vikt = 10

port = 5062

svr hostname = us-expe2.example.com

Registreringarna innebär att samtal dirigeras till us-expe1.example.com och us-expe2.example.com med samma lastdelning (prioritet och vikt) där TLS används som transporttyp och 5062 som lyssningsportnummer.

När ett SIP-samtal till en användare av företagsdomänen (user1@example.com) sker via en enhet som är extern i nätverket (på internet), måste DNS tillfrågas för att enheten ska förstå vilken transporttyp och vilket portnummer som ska användas, hur trafiken ska laddas/delas och till vilka SIP-servrar som samtalet ska skickas.

Om _sips._tcp inkluderas i DNS-registreringen specificeras SIP TLS i registreringen.

TLS är ett klientserverprotokoll för vilka det, i de vanligaste implementeringarna, används certifikat för autentisering. I ett business-to-business-samtalsscenario är TLS-klienten den anropande enheten och TLS-servern den uppringda enheten. Med TLS kontrollerar klienten certifikatet på servern och om kontrollen misslyckas kopplas samtalet bort. Det behövs inget certifikat för klienten.

TLS-handskakningen visas i följande diagram:

Med TLS-specifikationen fastställs dock att servern också kan kontrollera klientcertifikatet genom att skicka ett meddelande om certifikatförfrågan till klienten under TLS-handskakningsprotokollet. Det här meddelandet är användbart på en server-till-server-anslutning, till exempel på samtal som upprättas mellan Expressway-E och Cisco Webex-molnet. Konceptet kallas TLS med ömsesidig autentisering och krävs vid integrering med Cisco Webex.

Både parten som ringer och parten som blir uppringd kontrollerar certifikatet för den andra deltagaren enligt följande diagram:

Molnet kontrollerar Expressway-identiteten och Expressway kontrollerar molnets identitet. Om molnets identitet i certifikatet (CN eller SAN) inte överensstämmer med vad som är konfigurerat på Expressway bryts anslutningen.

Om ömsesidig autentisering är aktiverat gör Expressway-E alltid en begäran om klientcertifikatet. Som en följd av det fungerar inte mobil åtkomst eller fjärråtkomst (MRA) eftersom certifikat i de flesta fall inte distribueras för Jabber-klienter. I ett business-to-business-scenario, om den anropande enheten inte kan tillhandahålla ett certifikat, kopplas samtalet bort.

Vi rekommenderar att du använder ett annat värde än 5061 för TLS med ömsesidig autentisering, till exempel port 5062. Cisco Webex Med Hybrid-tjänster används samma SIP TLS-registrering som för B2B. I fallet med port 5061 fungerar inte vissa andra tjänster som inte kan tillhandahålla ett TLS-klientcertifikat.

Trafik för Business-to-business, mobil- och fjärråtkomst samt Cisco Webex på samma Expressway-par

För Business-to-business- samt mobil- och fjärråtkomstsamtal används port 5061 för SIP TLS och för Cisco Webex-trafik används port 5062 för SIP TLS med ömsesidig autentisering.

Kontrollen av ägarskap för domänen ingår i identitetsverifieringen. Verifiering av domänen är en säkerhetsåtgärd och identitetskontroll som Cisco Webex-molnet implementerar för att bevisa att du är den du säger att du är.

Identitetskontrollen utförs i två steg:

1. Kontroll av domänens ägarskap. Det här steget omfattar tre typer av domäner och är en engångsverifiering:

   • Reservera domän

   • DNS-domän för Expressway-E

   • URI-domän för katalog

2. Ägarskapskontroll av DNS-namn för Expressway-E. Det här steget utförs via implementeringen av TLS med ömsesidig autentisering och innebär användning av offentliga certifikat på både molnet och Expressway. Till skillnad från identitetskontrollen av domänen utförs det här steget under alla samtal som tas emot i molnet.

En historia som visar vikten av kontrollen av domänens ägarskap

Cisco Webex-molnet utför domänens ägarskapskontroll för att stärka säkerheten. Om kontrollen inte utförs är identitetsstöld ett möjligt hot.

Följande historia beskriver vad som kan hända om en ägarskapskontroll inte utförs.

Ett företag med DNS-domän inställd på ”hacker.com” köper Cisco Webex Hybrid-tjänster. Ett företag med sin egen domän inställd på ”exempel.com” använder också Hybrid-tjänster. En av cheferna på företaget Exempel.com heter Johanna Svensson och har katalog-URI johanna.svensson@exempel.com.

Administratören på företaget Hacker.com ställer in en av sina katalog-URI:er till johanna.svensson@exempel.com och e-postadressen till johanna.svensson@hacker.com. Hon kan göra det eftersom molnet inte kontrollerar SIP URI-domänen i det här exemplet.

Sedan loggar hon in på Cisco Webex Teams med johanna.svensson@hacker.com. Eftersom hon äger domänen har verifieringsmeddelandet lästs och besvarats och hon kan logga in. Slutligen ringer hon till en kollega, Johan Ek, genom att ringa johan.ek@exempel.com från sin Cisco Webex Teams-app. Johan sitter på det här kontoret och ser samtalet på videoenheten från johanna.svensson@exempel.com som är den katalog-URI som är kopplad till e-postkontot.

”Hon är utomlands,” tror han. ”Hon kan behöva något viktigt.” Han svarar i telefonen och den falska Johanna Svensson frågar efter ett mycket viktigt dokument. Hon förklarar att hennes enhet inte fungerar och eftersom hon är på resa ber hon honom att skicka dokumentet till sin privata e-postadress, johanna.svensson@hacker.com. På det sättet förstår inte företaget att viktig information har läckt utanför företaget förrän Johanna Svensson är tillbaka på kontoret.

Företaget Exempel.com har många sätt att skydda sig mot bedrägliga samtal från internet, men ett av ansvaren för Cisco Webex-molnet är att säkerställa att identiteten på någon som ringer från Cisco Webex är korrekt och inte förfalskad.

För kontroll av identiteten kräver Cisco Webex att företaget visar att de är ägare av de domäner som används i hybridsamtal. Om så inte är fallet fungerar inte .

Följande två kontrollsteg krävs för att säkerställa ägarskapet:

1. Bevisa att företaget äger e-postdomänen, Expressway-E-domänen, katalog-URI-domänen.

   • Alla domäner måste vara dirigerbara och kända av offentliga DNS-servrar.

   • DNS-administratören måste ange en TXT-registrering för att bevisa ägarskapet. EN TXT-registrering är en typ av resursregistrering i DNS som används för att tillhandahålla möjligheten att koppla viss skadlig och oformaterad text med en värd eller annat namn.

   • DNS-administratören måste ange den TXT-registreringen i zonen vars ägarskap måste bevisas. Efter det steget görs en förfrågan i Cisco Webex-molnet om TXT-registrering för domänen.

   • Domänen verifieras om TXT-förfrågan lyckas och resultatet överensstämmer med det token som skapades från Cisco Webex-molnet.

   • Som ett exempel måste administratören bevisa att hon äger domänen ”exempel.com” om hon vill att Cisco Webex Hybrid-tjänster ska fungera på hennes domän.

   • Via https://admin.webex.com startar hon verifieringsprocessen genom att skapa en TXT-registrering som ska överensstämma med det token som genererades med Cisco Webex-molnet:

     

   • DNS-administratören skapar sedan en TXT-registrering för domänen med värdet inställt på 1123456789abcdef123456789abcdef123456789abcdef123456789abcdef, som i följande exempel:

     

   • Då kan molnet verifiera att TXT-registreringen för domänen exempel.com överensstämmer med token.

   • Molnet utför en TXT DNS-sökning:

     

   • Eftersom TXT-värdet överensstämmer med tokenvärdet bevisar det att administratören har lagt till TXT-registreringen för sin egen domän till den offentliga DNS-servern och att hon äger domänen.

2. Ägarskapskontroll av DNS-namn för Expressway-E.

   • Molnet måste kontrollera att Expressway-E har en bekräftad identitet från en av certifikatutfärdarna som är betrodda av molnet. Administratören för Expressway-E måste begära ett offentligt certifikat för sin Expressway-E till en av de här certifikatutfärdarna. Certifikatutfärdaren utför en identitetsverifieringsprocess för att utfärda certifikatet, baserat på en domänvalideringskontroll (för domänvaliderade certifikat) eller en organisationsvalideringskontroll (för organisationsvaliderade certifikat).

   • Samtal till och från molnet är beroende av det certifikat som har utfärdats till Expressway-E. Om certifikatet inte är giltigt avbryts samtalet.

Anslutningsvärden för Expressway-C måste registreras på Cisco Webex för att Hybrid-tjänster ska fungera.

Expressway-C distribueras i det interna nätverket och registreringen i molnet går via en utgående HTTPS-anslutning – samma typ som används för alla webbläsare som ansluter till en webbserver.

För registrering och kommunikation med Cisco Webex-molnet används TLS. Expressway-C är TLS-klienten och Cisco Webex-molnet är TLS-servern. Expressway-C kontrollerar servercertifikatet.

Certifikatutfärdaren signerar ett certifikat med sin egen privata nyckel. Alla som har den offentliga nyckeln kan avkoda signaturen och bevisa att samma certifikatutfärdare signerade det certifikatet.

Om Expressway-C måste verifiera certifikatet som tillhandahålls från molnet, måste den offentliga nyckeln för certifikatutfärdaren användas för att avkoda signaturen. Det finns en offentlig nyckel i certifikatet för certifikatutfärdaren. För att upprätta förtroende med certifikatutfärdaren som används av molnet måste listan över betrodda certifikatutfärdare av dessa betrodda certifikatutfärdare finnas i den betrodda Expressway-E-lagringen. Genom att göra det kan Expressway verifiera att samtalet verkligen kommer från Cisco Webex-molnet.

Vid manuell överföring kan du överföra alla relevanta certifikat för certifikatutfärdare till den betrodda Expressway-C-lagringen.

Med automatisk överföring kan molnet automatiskt överföra certifikaten i den betrodda Expressway-C-lagringen. Vi rekommenderar att du använder automatisk överföring. Listan över certifikat kan ändras och med automatisk överföring garanteras du den mest uppdaterade listan.

Om du tillåter automatisk installation av certifikat för certifikatutfärdare, omdirigeras du till https://admin.webex.com (hanteringsportalen). Omdirigeringen utförs automatiskt med Expressway-C sig utan några åtgärder från användaren. Som Cisco Webex-administratör måste du autentisera via en HTTPS-anslutning. Kort därefter skickas CA-certifikat vidare från molnet till Expressway-C.

Det går inte att upprätta en HTTPS-anslutning förrän certifikaten har överförts till den betrodda Expressway-C-lagringen.

Det problemet undviks genom att Expressway-C har förinstallerats med Cisco Webex-betrodda CA-certifikat. De här certifikaten används bara för att konfigurera och validera den första HTTPS-anslutningen och visas inte i listan över betrodda certifikat i Expressway-C. När certifikaten med betrodda certifikatutfärdare hämtas från molnet via den första HTTPS-anslutningen är certifikaten tillgängliga för användning över hela plattformen. Sedan visas de i listan över betrodda certifikat i Expressway-C.

I listan visas certifikaten för de certifikatutfärdare som Cisco Webex använder för närvarande. Listan kan ändras i framtiden:

• C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

• C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

• C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

• C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

• C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

• C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

En lista över certifikat för certifikatutfärdare krävs även för Expressway-E i traversalparet. Expressway-E kommunicerar med Cisco Webex-molnet och använder SIP med TLS, förstärkt av ömsesidig autentisering. Expressway-E litar endast på samtal från och till molnet om CN eller SAN på certifikatet som visas av molnet under TLS-anslutningsinställningarna överensstämmer med ämnesnamnet som har konfigurerats för DNS-zonen på Expressway (”callservice.webex.com”). Certifikatutfärdaren utfärdar ett certifikat endast efter en identitetskontroll. Ägarskapet av callservice.webex.com-domänen måste kunna bevisas för att ett certifikat ska signeras. Eftersom vi (Cisco) äger domänen, är DNS-namnet ”callservice.webex.com” ett direkt bevis på att den fjärranslutna deltagaren verkligen är Cisco Webex.

Kalenderanslutning integreras Cisco Webex med Microsoft Exchange 2010, 2013, 2016 eller Office 365 via ett personifieringskonto. Rollen för personifieringshantering i Exchange gör det möjligt för program att efterlikna användare i en organisation och utföra uppgifter på uppdrag av användaren. Rollen för personifieringshantering måste konfigureras i Exchange och används i Kalenderanslutning som en del av Exchange-konfigurationen på Expressway-C-gränssnittet.

Personifieringskontot i Exchange är Microsofts rekommenderade metod för den här åtgärden. Expressway-C-administratörer behöver därför inte känna till lösenordet eftersom värdet kan anges i Expressway-C-gränssnittet av en Exchange-administratör. Lösenordet visas inte tydligt även om Expressway-C administratören har rotåtkomst till Expressway-C-rutan. Lösenordet lagras i krypterad form och använder samma krypteringsmekanism som andra lösenord på Expressway-C.

För extra säkerhet ska du följa stegen i installationsanvisningarna för Cisco Webex Hybrid Calendar Service för att aktivera TLS och säkra EWS-anslutningarna på ledningen.