Mennyire veszed komolyan a biztonságot?

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

napi cvsup/apt-get upgrade/stb.
32% (135 szavazat)
heti cvsup/apt-get upgrade/stb.
17% (72 szavazat)
naponta olvasom a bugtraq/stb. listákat
7% (30 szavazat)
a hiba bejelentéskor azonnal frissítek
18% (75 szavazat)
már a hibajegy megjelenése előtt frissítek
1% (4 szavazat)
csak akkor frissítek, ha nagyon muszáj
11% (45 szavazat)
nem frissítek, nem érdekel
3% (12 szavazat)
verzió váltáskor frissítek (pl. OpenBSD 3.3->3.4)
6% (24 szavazat)
csak CD-ROM-ról futtatok OS-t :-)
3% (12 szavazat)
frissíteni? huh, az mi?
2% (7 szavazat)
Összes szavazat: 416

( borso | 2003. 10. 27., h – 20:28 )

Megkerdezhetem a "hibajegy" pontsan micsoda?

( mogorva v | 2003. 10. 27., h – 21:41 )

Annyira komolyan veszem, hogy itt sem a valosagnak megfeleloen szavaztam, mert ha trey egy kesobbi betoresi kiserlet remenyeben esetleg loggolja a hostokat, a feltetelezett kesobbi betores soran kinos meglepetesekkel talalja majd magat szemkozt. B;-))))

mogorva

( borso | 2003. 10. 28., k – 00:15 )

Akkor mast is hozzaszolok.. A kerdoiv olyasmit sugall a szamomra mintha

a biztonsag es az upgrade elvalaszthatatlan lenne egymastol. Ugy

gondolom, helyesebb lett volna ugy megfogalmazni hogy "Mennyire veszed

komolyan a security upgrade-eket?"

Hááth, azért még ezen is lehetne vitatkozni.

Pl. volt már a történelemben olyan, hogy kiadtak valamire javítást, és két nap múltán meg a javítás javítását, sít.

Számomra pl. nagyon jól mutatja a szavazás jelenlegi állása, hogy egyeseknek hamis biztonságérzetet ad az, hogy naponta upgradelnek, függetlenül attól, hogy BSD vagy Debian júzerek.

A biztonságnak, kockázattervezésnek más szempontjai is vannak. Pl. exec stack protection megoldásokkal el lehet kerülni buffer overflow hibák jó részét, sít...

De tovább nem részletezem, mert itt alszok be, együltőhelyemben :-)

( vomberg | 2003. 10. 28., k – 08:25 )

A kérdés jó, de a megadott lehetséges válaszok messze nem illenek hozzá.

Én naponta upgrade-elek apt-tal, de nem biztonsági okok miatt, sőt a kettő üti egymást.

Unstable-t használok, a biztonsághoz meg messze nem tartozik a rendszerese frissítés. A biztonságot egyrészt úgy oldom meg, hogy a (külső router) tűzfalon forwardolva van az SSH oszt kézcsók. (Minden más a sóhivatalba van irányítva)

A lányok meg Mozillát használnak böngészésre és levelezésre a (legál) Windowsos gépeiken és 1-2 megvett játékot.

Az adatok időnként (nem túl sűrűn) meg mentve vannak.

Szóval ebben az egy kérdésben legalább 3 másik benne foglaltatik, amit esetleg érdemes lenne szétbontani mert így megválaszolhatatlanok.

szerinted miert volt ugy irva h cvsup/apt-get/stb. ?

az h te cvs-t hasznalsz a cvsuppal szemben az mennyivel nagyobb differencia? az egyel feljebb levo hozzaszolasnak nem ez volt a lenyege, hanem az , hogy a hozzaszolos szerint a biztonsagnak nincs koze a frissiteshez. olvasd el megegyszer

PS: attol meg, hogy egy BSD rendszeren lehet mondjuk kezzel is forgatni, sot csomagbol is telepiteni, az emberek 80% a cvsup-ot hasznalja mert az a logikus. Persze vannak mindenhol kivetelek, van aki a logikusabb apt-get helyett a dselect-re eskuszik, van aki synaptic-ot, stb. t hasznal, de a lenyeg nem ez. hanem az, hogy a frissitesnek igenis nagy szerepe van a biztonsagban.

jah, lyukas sshd eseten meg jelszo se kell, mert a tamado bejon anelkul is. Security policy alatt mit ertesz? eleg fogalom. Ha elolvasol egy ilyen temaju irast, akkor megtalalod benne, hogy a sec policyba beletartozik a fizikai vedelem (tuz, lopas, szabotazs, disaster, stb). Van szoftveres biztonsag, ebbe tartozik bele a jelszavak kezelese, a frissites, a pro-aktiv vedelem, a jogosultsagok, stack es buffer vedelem meg amit akarsz. Ebbol jelenleg a frissites van napirenden. Abban igazad van, hogy kell jo policy, de ha nem frissitesz, akkor hiaba van jo policy-d egy lyukas sendmail-en, sshd-n ami tavoli root shellt adakkor is bejonnek.

Ha ma megjelenik egy tavoli root exploit az ssh-d-hez akkor nem frissitesz? Azzal a felkialtassal, hogy minek, mert jo a sec policy-m? :-)

Biztonságos rendszerben a ma megjelenő "távoli root exploit" az sshd-re vagy a sendmailre maximum akkora hatással van, hogy ssh-n keresztül egy homokozót user jogokkal el fog tudni érni a rosszindulatú betörő, illetve sendmail esetén hamis levelet képes küldeni a felhasználóknak, legrosszabb esetben megakadályozhatja egy levél megérkezését. Biztonságos rendszernél nincs olyan, hogy valódi "távoli root exploit". (legalábbis ahhoz többszörös kernel hibára és a bolygók igen-igen gonosz konstellációjára van szükség)

Kötelező hozzáférés-védelem. Nem csak jail.

Te hoztad fel példának a deface-t PHP bug miatt. Egy normálisan beállított rendszeren az Apache-nak/PHP-nak van olvasási joga a html fájlokra és a PHP fájlokra, írási joga valamilyen tmp directoryra és append joga a logfájlokra. Nincs írási joga az index.html és hasonló fájlokra, így aztán elég nehéz deface-elni a rendszert.

Egyébként nem, ne törjenek be. Nyilvánvaló, hogy frissíteni kell. Csak ha kernel szinten ki van kényszerítve, hogy egy adott szolgáltatás csak azokat az erőforrásokat érheti el, amire valóban szüksége van, akkor egy betörésnek egyrészt komoly nyoma marad (mert a logot nem tudják megpiszkálni) másrészt nagyon jól lokalizálható.

Ha a kérdés tehát úgy merül fel, hogy találtak egy remote root exploitot, amit kihasználva a rendszeremben valódi kárt nem tehetnek, maximum ledosolhatják egy szolgáltatását, akkor nem biztos, hogy azonnal frissíteni kell. Nem is jó mindig azonnal frissíteni.

Az ssh persze kissé necces, főleg ha rendszerkarbantartásra (is) használják, mert akkor ugye a rendszer konfigurációs állományaihoz, mint erőforráshoz hozzá kell férnie, ez a rendeltetésszerű használata. Ez az egyik ok, ami miatt szerintem kritikus rendszereknél karbantartást és shell szintű hozzáférést csak konzolról szabad engedélyezni. Ha ez nem lehetséges, akkor is lehetnek módszerek az egyszeres sebezhetőség elkerülésére.

Volt pelda pl arra, hogy a linux kernelben ptrace bug miatt barki! lokalis felhasznalo root jogot szerzett. Arra nem emlekszem, hogy ez hogyan hatott a chroot() ra de gyanitom, tokre nem erdekelte a chroot() meg az egy rendszerhivas, es ha maga a kernel rossz, akkor tokmindegy.

> Te hoztad fel példának a deface-t PHP bug miatt. Egy normálisan beállított rendszeren az Apache-nak/PHP-nak van olvasási joga a html fájlokra és a PHP fájlokra, írási joga valamilyen tmp directoryra és append joga a logfájlokra.

Az elmult evben legalabb 4-5 olyan hibat tudok neked mutatni (csak erre a rendszerre), ami szemberohogi a file csak olvashato mivoltat, kozvetlenul az sql tablaba ir (sql injection bug). PHP-nel kulonben sem a php fileokat szoktak manipulalni, hanem a sql adatokat. Ebben az evben egyszer 2 percen mulott, hogy a PHPNuke hibaja miatt nem defaceltek az oldalt. Szerencsere leallitottam a http szervert, es frissitettem.

>Nem is jó mindig azonnal frissíteni.

Ebben egyetertunk azt hiszem :-)

De leragadtál a chroot-nál. Nem chroot. Kötelező hozzáférés védelem. Ha egy bug segítségével valóban root jogot tudsz szerezni, de az "apache" security contextusban vagy éppen, akkor abban is maradsz: továbbra sem tudod írni például a /etc-t. A kötelező hozzáférés védelmi modellek unix-szerű rendszereken implementálva a unixos jogosultságrendszerre ortogonális jogosultsági rendszert alkotnak. Legalábbis én még csak ilyen implementációt láttam.

Előforulhat persze, hogy a kernelben több sebezhetőség van egyszerre, meg a szolgáltatásban is van távoli sebezhetőség. De ez azért nem jellemző.

php: kötelező hozzáférés védelemnél nem tudod kikerülni valaminek a csak olvasható voltát. A közvetlen SQL manipulációra is van megoldás (gyakorlatilag csak volt), de szerintem ez már messze vezet.

A frissítés szerintem is fontos dolog. De amíg diszkrét hozzáférési modellt használ valaki, addig egy zero-day exploitot mindenképpen megszív, akármilyen gyakran frissít. A baj az, hogy a "Mennyire veszed komoylan a biztonságot?" kérdésnél fel sem merül a "Komolyan veszem, trusted rendszert használok" válasz. Pedig jó open source megoldások vannak hozzá. Nem kellene, hogy ennyire ritkák legyenek a kötelező hozzáférésvédelmi rendszerek.