Bizalom, biztonság és a szabad szoftverek Mátó Péter
kurátor fsf.hu alapíttvány
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 1999-2002
Linux-felhasználók Magyarországi Egyesülete
2002-
fsf.hu alapítvány alapító, kurátor 2
Miért szeretem meg?
Fischer Price
tversus
Lego
3
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://www.wired.com/sofware/coolapps/news/2004/12/660022)
4
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Köszönöm a figyelmet! 19
