Alapértelmezetten biztonságos

Titkosítás, biztonság, privát szféra

Jason Miller a SecurityFocus biztonságtechnikával foglalkozó internetes szaklap állandó írója egyik mostani cikkében a OpenBSD ``Secure by Default'' hozzáállását méltatja. Az OpenBSD szlogenjét mindenki ismeri, aki egy kicsit is foglalkozott már érintőlegesen a számítógépes rendszerek biztonságával. Az OpenBSD honlapján olvasható ``Only one remote hole in the default install, in more than 8 years!'' (Egyetlen egy távoli rés több, mint 8 éven keresztül alapértelmezett telepítés esetén!) figyelemre méltó.

De felmerülhet a kérdés, hogy tényleg csak annak köszönheti ezt az OpenBSD, hogy alapértelemezett telepítés esetén szinte semmilyen szervizt nem futtat? Vagy szerepet játszhat ebben a szigorú kód audit, a megszorító intézkedések (W^X, ProPolice, Systrace, stb.) bevezetése is? Vagy csak azért kevesebb a feltört OpenBSD boxok száma, mert az OpenBSD-t futtatók már inkább az ``hozzáértők'' közül kerülnek ki? Vagy csak azért kevesebb a feltört OpenBSD boxok száma mert sokkal kisebb a felhasználói bázisa az OpenBSD-nek, mint a többi operációs rendszernek?

Aki tudja a választ, vagy van véleménye írja meg!

( Hunger | 2004. 05. 20., cs – 10:00 )

Vagy a felsoroltak közül mind1ik egy kicsit közrejátszik? :)

( anr | 2004. 05. 20., cs – 10:08 )

En nem hiszek a hitben. Hiszek viszont a tud. alapossaggal/modszertannal elvegzett fuggetlen meresben. Na ilyen a szamitastechnikai biztonsaggal kapcsolatban nincs.

Az, hogy 1db remote hole volt az teny. De hogy keves a feltort OpenBSD szerverek szama az _hit_.

Az is erdekes lenne, hogy hany darab OpenBSD szerver fut default installal...

Inkabb az erdekelne, hogy a _szokasos_ (nem default, hanem az altalaban hasznalt) installban hany remote hole volt.

Elismerem, a biztonsaghoz valo hozzaallasuk dicseretes, de sajnos korrekten nem osszehasonlithato semmivel.

Nagyon nagy szukseg lenne egy (netcraft szeru) biztonsagi mereseket vegzo site-ra.

pl: egy-egy remote-hole utan kikeresne a neten, hogy hogyan valtozik a tamadhato gepek szama.

Mivel a biztonsagnak az is resze, hogy a rendszergazdak frissitik a gepeiket. A debianosok ezert nem aggodnak a sok hiba miatt, a cron-apt elinditva akar 5 percenkent ugyis gyorsabban megoldja a dolgot, mint ahogy a rendszergazda egyaltalan olvasna a hibabejelentest.

OBSD-nel ez hogy van?

>Az, hogy 1db remote hole volt az teny.

Viszont akkor kerdes, hogy erdemes-e ezt a szlogent ennyire eroltetni. Hiszen a kutya nem használja alapértelmezett telepítéssel a gépét.

>Nagyon nagy szukseg lenne egy (netcraft szeru) biztonsagi mereseket vegzo site-ra.

Csinaljuk meg :-D Bar egy ilyen oldalt osszehozni nem kis melo.

>A debianosok ezert nem aggodnak a sok hiba miatt, a cron-apt elinditva akar 5 percenkent ugyis gyorsabban megoldja a dolgot, mint ahogy a rendszergazda egyaltalan olvasna a hibabejelentest.

na azert en ennyire nem biznek meg egy automatikus frissitesben :-D

>OBSD-nel ez hogy van?

Kijon a patch, megpatcheled, kernelt forditasz, alaprendszert forditasz, telepited, reboot.

>Csinaljuk meg :-D Bar egy ilyen oldalt osszehozni nem kis melo.

Tegyuk. van kedvem. ;-)

termeszzetesen angolul;-)))

>na azert en ennyire nem biznek meg egy automatikus frissitesben :-D

En igen. Ha az ember stabilt hasznal, akkor az apt policy szerint nem kerdezhet. Tehat nyugodtan raeresztheto automatikusan.

Neked van ezzel rossz tapasztalatod? Nekem nincs.

>Kijon a patch, megpatcheled, kernelt forditasz, alaprendszert forditasz, telepited,

Ertem, tehat kezihajtany...

Szerintem biztonsagi kockazatot 2 tipusu "elkoveto" jelent:

1. CIA fele verprofik, akik maguk talajak meg abiztonsagi lyukat (esetleg lefizetnek egy belsos, hogy tegyen bele), es nem kozlik, hanem kihasznaljak.

Ez merhetetlen.

2. script kiddy-k.

Ok a mar ismert hiba kihasznalasat kepesek megcsinalni, tehat azok a gepek vannak veszelyben, akik olyan rendszert futtatnak, ami nincs frissitve.

ez tisztan merheto, es mindenki kedvere elemezheti a nominalis/szazalekos/... aranyokat.

> En igen. Ha az ember stabilt hasznal, akkor az apt policy szerint nem kerdezhet. Tehat nyugodtan raeresztheto automatikusan. Neked van ezzel rossz tapasztalatod? Nekem nincs.

Nekem van. Ugyan nem kerdez az apt policy szerint, ez igaz, de sokszor elkurjak bizony a nagy sietsegben. Legutobb a tavalyi heimdal frissitesuk volt "nagyon kellemes", amit olyan developer alkotott, akinek koze nem volt a kerberoshoz. De lefordult, uploadolta joindulatuan :) Ritkabb szoftvereknel szerintem ez bizony elo szokott fordulni.

>En igen. Ha az ember stabilt hasznal, akkor az apt policy szerint nem kerdezhet. Tehat nyugodtan raeresztheto automatikusan.

Neked van ezzel rossz tapasztalatod? Nekem nincs.

Rossz tapasztalatom nincs, mert nem hasznalom. Nem biztos, hogy elfogadnak a magyarazatot abban a esetben, ha megallna egy mail szerver, hogy

``Hat azt igertek, hogy ha automatikusan frissitek, akkor nem lesz gaz..''

Tapasztalat, hogy a Windows Update-ben sem lehet vakon megbizni, pedig az mogott kereskedelmi ceg all.

(Ezt csak azoknak jegyeztem meg, akik mar keszitettek a billentyuzetet, hogy leirjak:

"Azert nem lehet megbizni a Debianban, mert az egy non-profit szervezet, es senki nem garantalja, hogy minden mindig mukodni fog.")

A Windows-nal sem tudjak ezt garantalni, igy minden kritikus szervert kezzel, felugyelve szoktam frissiteni.

> Neked van ezzel rossz tapasztalatod? Nekem nincs.

Bar meg nem volt nekem sem,de az

ordog nem alszik.

En nem hasznalok deb kernelt,

de nem is olyan regen hibas volt

a 2.4.18-as alap kernel csomag.

itt a cikk, ami akkor megjelnet a hup-on:

http://hup.hu/modules.php?name=News&file=article&sid=5807

Misi

1. Mi alapjan nezed, hogy egy gep torheto, vagy sem? Fogod a scriptet, es had szoljon? Verzioszam alapjan sok esetben nem allapithato meg, hogy mar patchelt, vagy meg lukas a futo szolgaltatas. Masreszt nem valoszinu, hogy hosszu eletu lenne az oldal, ha valos probalkozasokbol gyujtene az adatokat.

2. A BSDk felepitese egyebkent meg alapbol sokkal szigorubb, mint pl a linuxoke. Kernel biztonsagi szintek, jail, se ki-se be default configok. _Alapbol_. Nem kell 8 patch a kernel forrasra, hogy nyugi legyen. Ha igy nezzuk, szerintem konnyen elkepzelheto, hogy valoban biztonsagosabb. A kernelt, alap rendszert ugyanaz a tarsasag tartja karban, az esetek 99.9%-aban ez boven eleg garancia, hogy idoben lepni tudjal. A maradek riziko pedig mindig is ott lesz.

3. A frissitgetes kerdeseben pedig oszton trey nezetet. Foleg egy debian eseteben, ahol senkin se lehet szamonkerni, ha esetleg elszurtak egy csomagot. Mit csinalsz, ha egy eles gepen bugos csomagot rak automatikusan, es kizarod magad, esetleg leall egy fontos szolgaltatas? Megmondod az ugyfelnek, hogy xy maintainer szurta el? Nem hiszem, hogy tulsagosan erdekelni fogja. Masik problema meg ugye a debian velejaroja. Keves helyen elkepzelheto egy default stabil debian a sokeves csomagokkal. Ha viszont mar frissebb cuccot raksz fel, akkor lottek az auto upgrade-nek.

Nekem evvel van.

Emlékszem egy esetre, h. régen cron.daily-ben nekem is benne volt a az apt-get update ; apt-get ugprade

Aztán történt, hogy egy napon cron és ssh csomagok is frissültek.

Csak hogy a processzek hierarchiáját vázoljam:

crond-> updatelő scriptem-> apt-get upgrade -> csomagok maintainer scriptje, ami először leállítja az sshd-t, hogy később elindítsa... majd jön a másik maintainer script, ami ugyanezt a crond-vel...

Azán másnap se crond nem futott, se sshd, az update script elhalt, exploitot nem találtam, hogy be tudjak remote menni, weboldalam meg tudtam nézni... ftp szerver élt (userek kizárva, anonymous only, elvégre user ne menjen be plaintextes protokollon)...

Innentől kezdve maradt a zarándokút a szerverhez! :-)

>senkin se lehet szamonkerni,

Miert mondj egy esetet, amikor _akarki_ akarmelyik szoftvercegtol szamon tudott kerni valami?

Mar elegszermegbeszeltuk, hogy az aranyert mert _valodi_ szupportokon kivul semelyik ceg supportja sem er semmit. Jogi szamonkeresrol meg még nem is hallottam. Akkor meg mirol beszelunk?

Igy jar, aki nem maga forditja a kernelt. :))))

De en meg ezzel szivtam meg, a valtozatossag kedveert.

Egyik ugyfelnel adatbazisszerver, benne egy Adaptec 2100S RAID kartya, dpt_i2o driverrel megy. A gep tuzfal mogott volt, regota 2.4.19-es kernellel ment, gondoltam frissitunk .26-ra (mindez par hete tortent). Kernel lefordit, driverek minden maradt a regiben, reboot - majd mehettem be masnap hozzajuk, mert nem indult a gep ujra.

Az oka? A RAID driver hiaba volt benne statikusan, nem latta a kartyat!!! A .19-es kernelt visszabootolva minden mukodott remekul. Erdekes. :I

( Névtelen (nem ellenőrzött) | 2004. 05. 20., cs – 16:32 )

A biztonsag relativ. melle OBSD defaultnal is az a 8 ev 1 bug nem igaz ... Mar csak azert sem mert 2000 apache bug ... emlekszik ra valaki ??? Akkortajt durvan 2 hetente jottek az apache sec hole ok :) Es a vicces kisult olyan is hogy akar root is lehettel ha ugyesen jatszottal. Elotte volt a kedves php balhe ... es ezek nagyresze az OBSD t is erintette... Tudom nem az o hibajuk de akkor is.