Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.
Obě strany předchozí revize Předchozí verze Následující verze | Předchozí verze | ||
mgr-szz:in-bit:9-bit [2014/02/06 15:01] marvel |
mgr-szz:in-bit:9-bit [2020/04/12 16:56] (aktuální) |
||
---|---|---|---|
Řádek 1: | Řádek 1: | ||
+ | |||
+ | |||
+ | ====== 9. Bezpečnost v sítích ====== | ||
+ | Bezpečnost relací se systémy (SSL, SSH, IPSec, WEP, WPA, ). Kerberos, autentizace v sítích GSM. Bezpečnost v prostředí Internetu. Dosažení bezpečnosti v SOA, WEB Services Security. | ||
+ | ====== Vypracování ====== | ||
+ | |||
+ | ===== Bezpečnost relací se systémy (SSL, SSH, IPSec, WEP, WPA, ) ===== | ||
+ | |||
+ | ==== SSL/TLS ==== | ||
+ | * TLS 1.0 je vylepšené SSL 3.0 | ||
+ | * vytváří spojení (asym. krypto.) a s ním tunel nad TCP/IP (dále sym. krypto.) | ||
+ | * umožňuje jednostranou (server clientovi) nebo vzájemnou autentizaci pomocí certifikátů | ||
+ | * podporuje různé algoritmy pro šifrování a MAC (dohodnuto při ustavení spojení) | ||
+ | * v současné době se za bezpečné považuje TLS 1.1 a vyšší (**BEAST** útok na TLS 1.0/SSL 3.0). TLS 1.2 je v dnešní době podporována všemi moderními prohlížečmi (Firefox 27, Chrome 30, IE 11) | ||
+ | * SSL/TLS verze služeb buď na samostatných portech (HTTPS, SMTPS, IMAPS, ...), nebo pomocí STARTTLS spojení ustanoveno v rámci standardního protokolu na standardním portu | ||
+ | * útoky - **BEAST** (JavaApplet v kombinaci s útokem na CBC mód sym. šifry), **CRIME** (získání zašifrované session cookie pomocí komprimace), útoky na RC4 šifru (proudová, doporučovaná kvůli útokům na CBC mód), **POODLE** (downgrade útok na SSL 3.0, stačí 256 požadavek na získaní 1 byte zašifrovaný zprávy) a další | ||
+ | * DTLS - verze pro UDP a DCCP | ||
+ | |||
+ | ==== SSH ==== | ||
+ | * náhrada za **telnet**, **rsh**, **rlogin** a další nedostatečně bezpečné protokoly | ||
+ | * hybridní systém používající asym. i sym. kryptografii | ||
+ | * podporuje různé algoritmy | ||
+ | * client (SSH klient) - server (SSH démon) architektura, SSH agent může držet zpřístupněné soukromé klíče (dešifrované), což umožňuje něco jako "single-sign-on" | ||
+ | * verze 1.x (problém např. s CRC-32 používaným pro kontrolu intergrity, často již nepodporované) a 2.x (MAC pro kontrolu integrity, D-H pro ustanovení klíče sezení, ECDSA, ECDH atd., běžně podporována a užívána) | ||
+ | * při prvním přihlášení na stroj je třeba ověřit veřejný klíč serveru, při dalších připojeních je uživatel upozorněn pouze v případě změny klíče | ||
+ | * otisky (fingerprint) veřejných klíčů serverů můžou být součástí DNS záznamů (SSHFP) | ||
+ | * umožňuje přihlášení a práci v příkazovém prostředí (shell), vzdálené provádění příkazů nebo vytvoření tunelu, kterým může probíhat jakýkoliv jiný protokol (SFTP, SCP, rsync, SSHFS, X forwarding, případně i VPN) | ||
+ | * různé způsoby autentizace klienta - heslem, veřejným (na serveru) a soukromým klíčem (může být chráněný heslem nebo nemusí), interaktivně na klávesnici (výzva k zadání hesla) nebo GSSAPI (např. Kerberos) | ||
+ | |||
+ | ==== IPsec ==== | ||
+ | |||
+ | IPSec je šifrování provozu na síťové vrstvě OSI modelu. | ||
+ | |||
+ | Internet Protocol Security (IPsec) je sada protokolů pro zabezpečení komunikace pomocí IP protokolu pomocí autentizace a šifrování každého packetu sezení. | ||
+ | |||
+ | IPsec zajišťuje zabezpečení mezi koncovými uzly (end-to-end), je ho možné použít na ochranu komunikace host-to-host, network-to-network nebo network-to-host. | ||
+ | |||
+ | Protokoly IPsec: | ||
+ | * Authentication Header (AH) - zajišťuje integritu a autentizaci zdroje paketu. Může chránit proti replay útokům. V podstatě digitální podpis dat. | ||
+ | * Encapsulating Security Payload (ESP) - zajišťuje důvěrnost, integritu a autenticitu paketů. Slouží na šifrování dat. | ||
+ | |||
+ | Podporuje dva módy: | ||
+ | * transportní - pouze data jsou zašifrována případně autentizována, IP hlavičky zůstávají, takže směrování apod. probíhá normálně, při použití AH nelze dělat překlady adres (NAT) | ||
+ | * tunelovací - celý paket je zašifrován, autentizován a kontrolován na integritu zabalením pomocí ESP do nového IP paketu, který je standardně směrován, adresa může být překládána apod. (využívá se např. pro VPN) | ||
+ | |||
+ | a několik způsobů vzájemné autentizace a ustanovení "spojení" (spíše sezení): | ||
+ | * ISAKMP (Internet Security Association and Key Management Protocol) | ||
+ | * IKE (Internet Key Exchange) - používá ISAKMP a X.509 certifikáty, které jsou přednastaveny, nebo získány z DNS/DNSSEC, následně D-H pro ustanovení sym. klíče) | ||
+ | * KINK (Kerberized Internet Negotiation of keys) | ||
+ | |||
+ | IPsec používá celou řadu algoritmů - např. HMAC-SHA-1 (autenticita, integrita), TripleDES-CBC/AES-CBC (důvěrnost), Diffie-Hellman pro ustanovení klíče a další. | ||
+ | |||
+ | IPsec je součástí IPv6. IPsec ale není všelék, existuje množství útoků, kde IPsec nepomůže (nebo pomůže útočníkovi obejít firewall skrytím obsahu). | ||
+ | |||
+ | |||
+ | ==== WEP ==== | ||
+ | |||
+ | WEP je zastaralý způsob zabezpečení bezdrátových sítí. Používá proudovou šifru RC4 pro zajištění důvěrnosti a CRC-32 kontrolní součet pro zajištění integrity. | ||
+ | |||
+ | Standardní 64-bitový WEP používá 40-bitový klíč (WEP-40), který je spojen s 24-bitovým inicializačním vektorem a tvoří tak RC4 klíč. Klíč byl obvykle zadáván jako 10 hexadecimálních číslic (alternativně 5 ASCII znaků). | ||
+ | |||
+ | Variantou je 128-bitový WEP (26 hexadecimálních číslic, 13 ASCII znaků) a 256-bitový WEP (58 hexadecimálních znaků). | ||
+ | |||
+ | WEP je nedostatečné zabezpečení, dá se prolomit nástroji jako aircrack-ng. | ||
+ | |||
+ | ==== WPA ==== | ||
+ | |||
+ | WPA a WPA2 jsou bezpečnostní protokoly, které byly navrženy pro nahrazení zastaraleného WEPu. | ||
+ | |||
+ | WPA používá 128-bitový klíč pro každý nový packet a Micheal pro kontrolu integrity packetů. WPA má bezpečnostní nedostatky plynoucí z vlastností Michael umožňující re-injekci packetů a spoofing. | ||
+ | |||
+ | WPA2 nahradilo WPA. WPA2 přineslo CCMP, což je šifrování založeno na AES. | ||
+ | |||
+ | Pre-shared key mód (PSK, Personal mode) je určen pro domácí použití a nevyžaduje 802.1X autentizační server. Zařízení šifruje přenos pomocí 256-bitového klíče (64 hexadecimálních číslic nebo 8 až 63 tisknutelných ASCII znaků). | ||
+ | |||
+ | Pokud je WPA (WPA2) implementováno s vlastností Wi-Fi Protected Setup, je možné zabezpečení prolomit nástrojem Reaver během 4 až 10 hodin, často i v polovičním čase. | ||
+ | |||
+ | ==== 802.1X ==== | ||
+ | * zabalení EAP (pouze framework pro autentizaci s mnoha různými implementacemi/metodami) protokolu pro (W)LAN (EAPOL) | ||
+ | * poskytuje tzv. **port-based Network Access Control** (PNAC) | ||
+ | * 3 účastníci: | ||
+ | * žadatel (Supplicant) - žádá autentizátor o přístup do sítě přes port (a analogicky v případě WLAN) | ||
+ | * autentizátor (Authenticator) - řídí přístup do sítě, typicky switch nebo AP | ||
+ | * autentizační server (Authentication server) - poskytuje ověření identity (autentizaci) žadatele, na základě které je následně žadateli povolen/odmítnut přístup do sítě | ||
+ | * využívá EAPOL pro komunikaci mezi žadatelem a autentizátorem a RADIUS/Diameter (opět zabalení EAP) pro komunikaci mezi autentizátorem a autentizačním serverem | ||
+ | * problémy: | ||
+ | * autentizace probíhá pouze na začátku, takže je možný man-in-the-middle útok, pokud je útočník schopný se fyzicky dostat mezi autentizované zařízení a autentizátor (na stejný port), možnou obranou je použití IPsec | ||
+ | * //EAPOL-Logoff// zpráva (datagram) není nijak autentizována, a proto lze snadno udělat DoS útok | ||
+ | |||
+ | ===== Kerberos ===== | ||
+ | |||
+ | Kerberos je síťový autentizační protokol umožňující komukoli komunikujícímu v nezabezpečené síti prokázat bezpečně svoji identitu někomu dalšímu. Kerberos zabraňuje odposlechnutí nebo zopakování takovéto komunikace a zaručuje integritu dat. Byl vytvořen primárně pro model klient-server a poskytuje vzájemnou autentizaci – klient i server si ověří identitu své protistrany. | ||
+ | |||
+ | **Autentizace proběhne ve čtyřech krocích: [[http://www.abclinuxu.cz/clanky/bezpecnost/kerberos-prihlasovani-snadno-a-rychle|zdroj]]** | ||
+ | //Krok 1// | ||
+ | * Klient požádá autentizační server (AS) o Ticket Granting Ticket (TGT). | ||
+ | * AS vyhledá klienta ve své databázi, vygeneruje klíč relace (session key) SK1, který bude použit pro komunikaci mezi klientem a Ticket Granting Serverem (TGS). AS zašifruje klíč SK1 za použití tajného klíče (secret key) klienta (uživatelského hesla) a pošle jej klientu. | ||
+ | * AS dále vytvoří TGT zašifrovaný pomocí tajného klíče TGS a také jej pošle klientu. | ||
+ | |||
+ | //Krok 2// | ||
+ | * Klient dešifruje přijatý SK1 pomocí svého tajného klíče. | ||
+ | * Klient vytvoří authenticator obsahující uživatelské jméno, IP klienta a časové razítko. Pošle authenticator spolu s TGT službě TGS spolu s požadavkem na službu, kterou chce použít. | ||
+ | * TGS dešifruje TGT zaslaný klientem pomocí svého tajného klíče a získá z něj klíč relace SK1. Pomocí SK1 dešifruje authenticator. Ověří informace z authenticatoru. | ||
+ | * TGS vytvoří klíč relace SK2 pro komunikaci mezi klientem a cílovým serverem (službou). Zašifruje SK2 pomocí SK1 a pošle jej klientu. TGS vytvoří tiket pro použití cílové služby obsahující jméno klienta, jeho IP adresu, časové razítko, čas expirace tiketu a SK2. Tiket zašifruje pomocí tajného klíče a jména cílového serveru a pošle jej klientu. | ||
+ | |||
+ | //Krok 3// | ||
+ | * Klient dešifruje SK2 pomocí SK1. | ||
+ | * Klient vytvoří nový authenticator, zašifruje jej pomocí SK2 a spolu s tiketem jej zašle cílovému serveru. | ||
+ | * Cílový server dešifruje tiket pomocí svého tajného klíče a ověří jej. | ||
+ | * U služeb, kde je vyžadováno, aby se server prokázal klientu, zašle cílový server klientu časové razítko zvětšené o 1 zašifrované pomocí SK2. | ||
+ | |||
+ | //Krok 4// | ||
+ | * Nyní cílový server i klient mají jistotu o totožnosti komunikačního partnera. | ||
+ | * Vzájemný síťový provoz šifrují pomocí SK2. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== Autentizace v sítích GSM ===== | ||
+ | |||
+ | * Zkratky | ||
+ | * Subscriber Identity Module (SIM) | ||
+ | * mobilní stanice (MS) | ||
+ | * autentifikační centrum sítě (AUC) | ||
+ | * které je součástí provozního a servisního centra sítě (OMS) | ||
+ | * SIM — obsahuje: | ||
+ | * IMSI (International Mobile Subscriber Identity) | ||
+ | * tajný klíč autentifikace Ki | ||
+ | * algoritmus pro generování šifrovacího klíče A8 | ||
+ | * autentifikační algoritmus A3 (algoritmy A3 a A8 si definuje operátor, bývají oba shodné) | ||
+ | * osobní identifikační číslo PIN. | ||
+ | * Mobilní stanice — obsahuje šifrovací algoritmus A5. | ||
+ | * AUC — obsahuje: | ||
+ | * databázi s identifikačními a autentifikačními údaji úživatelů sítě. | ||
+ | * V databázi jsou uloženy | ||
+ | * IMSI | ||
+ | * TMSI (Temporary Mobile Subscriber Identity) | ||
+ | * LAI (Location Area Identity) | ||
+ | * tajný klíč Ki, který je unikátní pro každého uživatele. | ||
+ | * Pro provedení autentifikace uživatele je třeba součinnosti všech tří výše uvedených částí. | ||
+ | |||
+ | ==== Proces autentizace ==== | ||
+ | Autentifikace uživatele je prováděna při každém vstupu uživatele do sítě. GSM síť ověřuje identitu uživatele pomocí mechanismu challenge–response. Síť pošle MS 128 bitové náhodné číslo, které označujeme jako RAND. V MS je číslo RAND předáno modulu SIM, který na základě znalosti Ki a algoritmu A3 vypočítá odpověd, kterou označíme jako SRES nebo K3. SRES je počítána na základě čísla RAND, tajného klíče Ki a algoritmu A3, tzn. SRES = A3(Ki, RAN D). MS po vypočtení SRES pošle výslednou hodnotu zpátky do sítě. Síť po přijetí SRES vypočítané v SIM provede stejný výpočet jako byl proveden v SIM. K výpočtu využije opět algoritmus A3, kód Ki a čísla RAND které bylo zasláno do MS. Pokud síť dojde ke stejnému výsledku jako obdržela od MS, je autentifikace úspěšná. Pokud ne, je spojení ukončeno. Schéma autentifikace uživatele sítě je na obrázku 1. | ||
+ | |||
+ | {{:mgr-szz:in-bit:gsm-auth.png|}} | ||
+ | |||
+ | Zde je dobré si povšimnout, že Ki se sítí vůbec nepřenáší. Hodnota Ki je totiž napevno uložena jak v uživatelově SIM, tak v AUC a přenos tohoto klíče tak není nutný. Dalším prvkem posilujícím zabezpečení je omezení manipulace s Ki v rámci SIM. Jediné co SIM dovolí s Ki provádět jsou operace kódování A38 (kódování algoritmem A3 a A8, které jsou zpravidla shodné). Kromě těchto operací je přístup ke Ki zamezen, takže tento kód nelze jen tak z SIM karty přečíst. Pomocí A8 je z RAND vygenerován šifrovací klíč Kc, který je použit pro šifrování komunikace a zajíštění důvěrnosti. | ||
+ | |||
+ | ==== Zdroje ==== | ||
+ | |||
+ | * [[http://radio.feld.cvut.cz/personal/mikulak/MK/MK07_semestralky/prehled_zabezpeceni_GSM.pdf|Semestrální práce o bezpečnosti GSM z CVUT]] | ||
+ | * http://www.hackcanada.com/blackcrawl/cell/gsm/gsm-secur/gsm-secur.html | ||
+ | |||
+ | ===== Bezpečnost v prostředí Internetu ===== | ||
+ | |||
+ | Vhodne prejsť slajdy z prednašok: | ||
+ | * [[https://is.muni.cz/auth/el/1433/podzim2009/PA159/um/prednaska_04_2009.PDF|PA159 - prednaska_04_2009.PDF]] | ||
+ | * [[https://is.muni.cz/auth/el/1433/podzim2009/PA159/um/prednaska_05_2009.PDF|PA159 - prednaska_05_2009.PDF]] | ||
+ | |||
+ | === AAA === | ||
+ | * Autentizace (potvrzeni deklarované Id) | ||
+ | * Autorizace (povolení přístupu/použití na základě oprávnění, ACL) | ||
+ | * Accounting (řízení přístupu) | ||
+ | === Pož. vlastnosti === | ||
+ | Důvěrnost (utajení), autentizace, integrita zpráv, nepopiratelnost a další | ||
+ | Míra bezpečnosti - jak závisí šifr. text na původní zprávě vs. možnost a cena útoku | ||
+ | Symetrická a asymetrická krypto (duvernost) + digitální podpis(autentizace, integrita, nepopiratelnost), hašovací fce (integrita) (viz jiné ot.) | ||
+ | |||
+ | === Autentizace v síti === | ||
+ | Pomocí protokolů (PAP - slabé, plaintext hesla přes síť; CHAP - MD5 + challange response). | ||
+ | |||
+ | === Aut. Služby === | ||
+ | RADIUS - challange-response, hierarchie radius serveru, požadavek jde až k domácímu, protokol rozšiřitelný z pohledu přenášených atributů | ||
+ | TACACS - staré, pro modemy, umí i autorizaci) | ||
+ | |||
+ | === Správa a spárování klíčů a id držitele === | ||
+ | KDC u kerbera - symetrické klíče | ||
+ | CA u PKI - asym, vydá certifikát (viz jiná otázka) | ||
+ | |||
+ | === bezp. emailů === | ||
+ | Využití seasion keys, kombinace asym+sym krypto (S/MIME). HASH pro integritu | ||
+ | === PGP === | ||
+ | Šifrování symetrickou krypto. Digitální podpis asym. Různé algoritmy, Web of trust - věřím v nějaké míře různým lidem a klíčům od nich podepsaným. | ||
+ | |||
+ | Další pojmy v této obecné podkapitole: SSL, IPsec viz začátek této vypracované otázky. | ||
+ | SET - zabezpečení komunikace zákazník-obchodník-banka, používá certifikáty a tedy asym. krypto | ||
+ | |||
+ | === Ochrana sítě === | ||
+ | Firewally - filtrování paketů:kontrola IP hlaviček, často spojeno s NAT, rozdělení sítě do zón, může sloužit jako aplikační brána (proxy):pro druhou stranu komunikace viděna jako klient. | ||
+ | |||
+ | === DoS === | ||
+ | Zahlcení serveru požadavky z 1 zdroje vs **DDoS** - synchronizovaně z mnoha míst, horší obrana, je třeba postupovat s odřezáváním komunikace přes směrovače směrem ke zdrojům. | ||
+ | |||
+ | === Viry === | ||
+ | Samošiřitelný kód, pro zábavu vs. škodit. Ochrana antivir, update, výchova uživatelů, firewall atd... | ||
+ | === Hacking === | ||
+ | K získání přístupu ke zdrojům, ukázat se vs. průmyslové využití(terorismus), krádeže dat (id, platební údaje ke kartám) nebo příprava k dalším útokům:DDoS | ||
+ | |||
+ | ===== Dosažení bezpečnosti v SOA ===== | ||
+ | Viď kapitola 2: | ||
+ | * [[http://is.muni.cz/th/98993/fi_m/|Bezpečnost ve službově orientované architektuře]] | ||
+ | |||
+ | === XML Encryption === | ||
+ | Standard | ||
+ | Šifrování na úrovni zpráv: | ||
+ | * vezmi část XML elementu a zašifruj ji např. do <encrypted data ...> šifr. zpráva <...> | ||
+ | * nebo vezmi vnitřek elementu | ||
+ | Podporuje různé krypto alg. (AES, RC4 ...) | ||
+ | === XML Signature === | ||
+ | Doporučení W3C | ||
+ | zajišťuje autentizaci, nepopiratelnost, integritu zpráv: | ||
+ | * převeď XML do kanonického tvaru | ||
+ | * vytvoř podpis (hash + alg. dig. podpisu) | ||
+ | * připoj k originální zprávě mezi <signature> ... <...> | ||
+ | |||
+ | === SAML === | ||
+ | Na XML založený jazyk slouží k autentizaci uživatele a řizení přístupu na základě doprovodných atributů uživatele, lze dosáhnout webSSO | ||
+ | Často se používá ve federacích identit | ||
+ | Správce identity zasílá o uživateli tvrzení (assertions) | ||
+ | |||
+ | === Další protokoly === | ||
+ | XACML, XKSM (PKI operace přesouvá od uživatele na server důvěryhodné 3. strany) | ||
+ | |||
+ | ===== WEB Services Security ===== | ||
+ | |||
+ | Vid. PV222 Security Architectures - Web Security | ||
+ | https://is.muni.cz/auth/el/1433/jaro2013/PV222/um/PV222_2012-13_Lec_2.pdf | ||
+ | |||
+ | ====== Materiály ====== | ||
+ | |||
+ | * [[https://is.muni.cz/auth/el/1433/jaro2012/PB156/um/lecture9.pdf|9. lekce PB158 Počítačové sítě]] - obsahuje popis IPSec | ||
+ | * [[https://is.muni.cz/auth/el/1433/jaro2011/PA018/um/PA018_2011_L9short.pdf|Jeden slide o Man in the middle útoku]] | ||
+ | * [[https://is.muni.cz/auth/el/1433/jaro2011/PA018/um/PA018_2011_L3.pdf|Security in communications - PA018 (Kerberos, SSL, SSH, shared key..)]] | ||
+ | |||
+ | ====== Vypracoval ====== | ||
+ | Věci převzaté z INS-7: Rado Šupolík | ||
+ | Věci převzaté z INS-5: zdenek.kedaj@gmail.com | ||
+ | Věci převzaté z PSK-5: DevelX - Martin Jurča | ||
+ | SSL/TLS, SSH, IPsec módy a autentizace, 802.1X: Vratislav Podzimek | ||
+ | SOA, Bezpečnost v prostředí Internetu: Marcel Poul | ||
+ | Zbytek: Michal Trunečka | ||
+ | |||
+ | ~~DISCUSSION~~ |