Při připojování ke správě serverové aplikace (Kerio Control nebo Kerio Connect— dále jen server) kontroluje Administration Console (dále jen klient) identitu příslušného serveru. Toto je ochrana proti útoku typu „man-in-the-middle“ (útočník se vydává za cílový server, od klienta získá přihlašovací údaje a ty pak použije pro přihlášení na skutečný server).
Server svou identitu prokazuje SSL certifikátem. Klient pak porovnává tzv. otisk certifikátu s otiskem, který má uložený ve svém konfiguračním souboru. Pokud otisky certifikátu souhlasí, připojení je automaticky povoleno. V opačném případě je nutný zásah uživatele.
Poznámky:
Kontrola certifikátu se neprovádí při připojování přímo z počítače,
na kterém je nainstalována příslušná serverová aplikace (připojení
k localhost). V tomto případě totiž útok
„man-in-the-middle“ nemá smysl (pokud by útočník pronikl přímo na
server, mohl by získat požadované informace jednodušším způsobem).
Pro účely připojení programem Administration Console se nepoužívá SSL certifikát, který je v serverové aplikaci nastaven pro „klientské“ služby (webová rozhraní apod.), ale speciální automaticky generovaný certifikát.
Předpokládejme, že jsme na server server.firma.cz
nainstalovali aplikaci Kerio Control[1] a nyní se chceme k tomuto serveru poprvé připojit programem
Administration Console z jiného počítače.
Vyplníme přihlašovací dialog (případně vytvoříme záložku — podrobnosti viz kapitola 3.2 Připojení k serveru a vytvoření záložky). Po stisknutí tlačítka se zobrazí informace, že identitu serveru nebylo možné ověřit — viz obrázek 3.6 Kontrola identity serveru — připojení k novému serveru.
Nyní musíme zkontrolovat, zda se Administration Console skutečně připojuje k požadovanému serveru:
V poli Server zkontrolujeme typ serverové aplikace a IP adresu cílového serveru.
Pokud byl server zadán jménem a jeho IP adresa nesouhlasí, je třeba zkontrolovat DNS záznam pro příslušné jméno počítače, případně zadat server přímo IP adresou. Nesprávná IP adresa může signalizovat pokus o útok (podvržení DNS záznamu).
Poznámka: Pokud byl server zadán IP adresou, pak je kontrola DNS záznamů bezpředmětná.
Nesouhlasí-li typ serverové aplikace, pak je vhodné prověřit spuštěné serverové aplikace přímo na příslušném serveru a zkusit se k nim připojit lokálně.
Porovnáme otisk certifikátu v poli Podrobnosti certifikátu s otiskem certifikátu příslušného serveru.
Pokud otisky certifikátů nesouhlasí, jedná se o podvržený certifikát.
TIP: Otisk certifikátu lze označit myší, zkopírovat do schránky a vložit do souboru, e-mailové zprávy apod.
Souhlasí-li IP adresa, typ aplikace i otisk certifikátu, můžeme se k serveru bez obav připojit. V opačném případě připojení zamítneme (tlačítkem ) a pokusíme se najít příčiny zjištěných problémů.
Pokud se při příštím připojení nezmění IP adresa ani certifikát serveru, bude Administration Console považovat tento server za důvěryhodný a popsaný dialog pro ověření identity se již nezobrazí.
Pro zabezpečení komunikace mezi serverovou aplikací a programem
Administration Console se používá speciální automaticky
generovaný SSL certifikát. Tento certifikát se vytvoří při prvním startu
serverové aplikace po instalaci, resp. při každém startu, kdy není certifikát
nalezen (pokud byl smazán, poškozen apod.). Certifikát je uložen v souboru
server.crt v podadresáři dbSSL
instalačního adresáře serverové aplikace (konkrétní umístění závisí na typu
aplikace a operačním systému).
Způsob zjištění otisku certifikátu závisí na operačním systému serveru:
Certifikát serveru je standardně ukládán do adresáře
C:\Program Files\Kerio\WinRoute
Firewall\dbSSL
resp.
C:\Program
Files\Kerio\MailServer\dbSSL
Při otevření souboru s certifikátem (dvojitým kliknutím myší nebo klávesou Enter) se zobrazí dialog s informacemi o certifikátu.
V záložce Podrobnosti vyhledáme pole Miniatura[2]. Toto pole obsahuje otisk certifikátu, který můžeme označit myší, zkopírovat do schránky a vložit do souboru, e-mailové zprávy apod.
Certifikát serveru je standardně ukládán do adresáře
/opt/kerio/mailserver/dbSSL (Linux),
resp.
/usr/local/kerio/mailserver/dbSSL
(Mac OS X).
Pro zjištění otisku certifikátu využijeme program
openssl (v systému musí být nainstalován balík
OpenSSL).
V konzoli (terminálu) se přepneme do adresáře se souborem
server.crt a zadáme následující příkaz:
openssl x509 -in server.crt -noout
-text -fingerprint -sha1
Tento příkaz zobrazí informace o certifikátu, přičemž na posledním řádku výpisu bude uveden otisk certifikátu:
SHA1 Fingerprint=F4:D1:F4:49:57:99:81:10:D6:41:8F:0E:2E:A5: 77:42:80:E9:70:D0
Pokud nedojde ke změně otisku certifikátu nebo IP adresy serveru, pak při dalších připojeních Administration Console ověřuje pouze uživatelské jméno a heslo. Kontrola certifikátu a IP adresy serveru zůstává uživateli skryta.
Dojde-li ke změně otisku certifikátu, zobrazí se varování — viz obrázek 3.8 Kontrola identity serveru — detekce změny certifikátu.
Tato situace může nastat, pokud byl server přeinstalován, nebo pokud byl jeho certifikát z nějakého důvodu poškozen či smazán. V takovém případě serverová aplikace při svém startu vytvořila nový certifikát, jehož otisk se samozřejmě liší od otisku, který má Administration Console uložený. Pokud víme, že na serveru k takové změně došlo, provedeme kontrolu otisku certifikátu stejně jako v případě prvního připojení (viz výše). Pokud nový (přijatý) otisk certifikátu souhlasí s otiskem certifikátu serveru, můžeme připojení povolit. V tomto případě se uložený otisk certifikátu přepíše otiskem nového certifikátu a při dalším připojení již opět nebude zobrazováno žádné varování.
Jestliže k žádné změně certifikátu na serveru nedošlo, pak se s nejvyšší pravděpodobností jedná o útok (podvržení certifikátu). V takovém případě připojení zamítneme (tlačítkem ) a pokusíme se najít příčiny zjištěných problémů.
Poznámka: Při prosté aktualizaci (upgrade) serverové aplikace zůstává certifikát zachován. Přeinstalováním je v tomto případě míněna kompletně nová instalace — např. při výměně pevného disku apod.
Za určitých okolností může také dojít ke změně IP adresy serveru (např. pokud byl server přepojen do jiné subsítě). Při změně IP adresy se (zpravidla) provádí také aktualizace příslušných DNS záznamů. Z toho vyplývá, že při dalším pokusu o vzdálené připojení programem Administration Console k příslušné serverové aplikaci sice použijeme stejné DNS jméno, ale IP adresa bude odlišná. Na změnu IP adresy serveru může Administration Console reagovat dvěma způsoby:
Pokud pro novou IP adresu (a port příslušné serverové aplikace) dosud neexistuje záznam, Administration Console zobrazí varování jako v případě prvního připojení k novému serveru (viz obrázek 3.6 Kontrola identity serveru — připojení k novému serveru).
Existuje-li pro novou IP adresu a příslušný port záznam (tzn. Administration Console se v minulosti již připojovala k dané serverové aplikaci na dané IP adrese), pak je tato situace vyhodnocena jako změna identity serveru (viz obrázek 3.8 Kontrola identity serveru — detekce změny certifikátu).
V obou případech platí, že pokud se jedná o záměrnou (vědomou) změnu IP adresy, pak ve varovném dialogu zkontrolujeme IP adresu a otisk (nového) certifikátu a je-li vše v pořádku, můžeme připojení akceptovat. Pokud k žádné změně IP adresy serveru nedošlo, pak připojení zamítneme a pokusíme se zjistit příčinu tohoto problému.