Bizalom, biztonság és a szabad szoftverek. Mátó Péter kurátor fsf.hu alapíttvány

Átírás

1 Bizalom, biztonság és a szabad szoftverek Mátó Péter kurátor fsf.hu alapíttvány

2 Bemutatkozás 1996 az első találkozás: Chiptár Slackware 1997 első igazi munka: oktatás a GAMF-on 1998 teljes átállás Linuxra, irány a versenyszféra 13 évig IT biztonsági szakértő, publikációk, oktatás jelenleg KIM Sz2K2 szakmai vezető civil tevékenység Linux-felhasználók Magyarországi Egyesülete fsf.hu alapítvány alapító, kurátor 2

3 Miért szeretem meg? Fischer Price tversus Lego 3

4 2004-ben a Carnegie Mellon egyetem négy kutatója négy étves kutatás után azt a megállapítást tete, hogy a Linux kernel forráskódja extrém biztonságos a zárt tversenytársakhoz képest (Linux: Fewer Bugs Tan Ritvals htp:// 4

5 Megfelelő felhasználói megszokások Alig vannak vírusok A rendszert általában nem szokás admin jogokkal használni Főleg szakértők kezelik őket Lényegében nincs warez 5

6 Telepítés a frissítés Csomagkezelő rendszer Digitális aláírások A szabad szofverek ingyen vannak, nincs szükség warezra 6

7 A szabad szoftverek inhomogén rendszerek Sok terjesztés van Nincs egységes kernel Rendszerenként változik a telepítet csomagok verziója Elérhetők egyéni, speciális biztonsági funkciók 7

8 Biztonsági funkciók A felesleges funkciók eltávolíthatók A frissítések könnyen telepíthetők Automatikus frissítés Csomagszűrő Titkosítás, VPN 8

9 A zárt rendszerek tveszélyei ismeretlenek Huawei Ausztráliában a nemzetbiztonság tanácsára kizárva Törvények tiltják a rendszer működésének feltárását 2011 Ormandy elemzés: a Sophos antivírus alapfunkciói nem működnek A prospektusokban van valamilyen ígéret, amit a termék vagy tud, vagy nem Ken Tompson: ha a fordító gonosz, akkor a fejlesztő nem tud mit tenni, hiába minden tervezői, fejlesztői, tesztelői igyekezet, a rendszer hibás lesz 9

10 Kerckhofs axiómája "A rejtjelező rendszernek akkor is biztonságosnak kell lennie, ha a kulcson kívül minden részlete ismert." Claude Shannon "Az ellenség ismeri a rendszert." 10

11 Titkolózás és biztonság Angol neve: Security Trough Obscurity A titkolózás alapú biztonsági modell a biztonságot egyre jobban ismerő szakértők és a fekete doboz tesztek fejlődésével (pl. fuzzing) egyre túlhaladotabb A NIST (National Institute of Standards and Technology) több dokumentumában is erősen javasolja a titkolózáson alapuló biztonsági intézkedések kerülését Néha segíthet, de nem megoldás! (példa: ssh port áthelyezése segíthet tömeges támadások ellen, de nem garancia semmire!) 11

12 Hátsó ajtók, beépítet felhasználók és jelszatvak I. Hátsó ajtók nagyon sok zárt termékben vannak Mikor kiderül, akkor a gyártó magyarázkodni kényszerül Mi az oka? Fejlesztői hiba (pl. Dropbox jelszó ellenőrzés kikapcsolása) Ügyfél butaság elleni védekezés Nemzetbiztonság... Melyik nemzeté? 12

13 Hátsó ajtók, beépítet felhasználók és jelszatvak II. 2011, Charlie Miller: az Apple beégetet jelszavakkal kommunikál az akkumulátor vezérlésével, súlyos esetben akár felrobbantható a töltés megfelelő beállításával HTC által módosítot Android: localhost-on fgyelő, hitelesítést nem kérő szolgáltatás, mely bizalmas adatokat szolgáltatot 13

14 Nyílt biztonsági megoldások A kriptográfában alapvető elvárás a nyíltság AES, DH, RSA, DSA, SHA256 mind ismert algoritmusok A PGP forráskódja nyilvános, mégis katonai szintű biztonsági szofverként elfogadot NSA: SELinux Nyílt forrású Linux kiegészítő nagy biztonságú rendszerek építéséhez Több népszerű terjesztés alapvető része 14

15 A hibák feltárásának módjai Laikus azt gondolja, hogy a forráskód ismeretében egyszerűbb egy programban hibát találni A valóságban tipikusan a hibakeresés fekete doboz módszerekkel kezdődik Ha egy hiba megvan, akkor annak kihasználását egyszerűbbé teszi a forráskód Léteznek bináris programok visszafejtését végző eszközök 15

16 A szabad szoftverek megismerése és auditja A nyílt forráskód esetén a rendszer valódi működése megismerhető A forráskód elemzőkkel vizsgálható, javítható Komoly cégek a fontosabb szofvereket rendszeresen auditáltatják 16

17 A nyílt fejlesztési modell A fejlesztők sokszor nagy cégek prof alkalmazotai Kernel - 75% céges hozzájárulás Mindig van közös forráskód tároló rendszer Mindig van hibajegy kezelő rendszer A hibákat nagyon gyorsan javítják, terítik 17

18 A nyílt fejlesztési modell II. A modularitás szinte természetes Felhasználhatók kész védelmi megoldások más szofverből átemelve Ki lehet kérni hozzáértők véleményét a védelmi intézkedésekről A népszerű alkalmazások kódját sokan megnézik Visszatartó erő, az elvarratlan szálak kiderülnek A tervezési hibákra hamarabb fény derülhet 18

19 Köszönöm a figyelmet! 19