Linux kernel hibak

[quote:a1aa345587="nug"]Debian woody parti vagyok, nekem a stabilitas a legfontosabb a szervereimen, es az hogy a sebezhetosegi ablak minel kisebb legyen.

Ki van a ...-om azzal hogy minden egyes kernelverzioban local root exploit van. (lesz?)

Sajat kernelt hasznalok, es mindig updatelek, amint van ujabb, csak hat az eleg sok ido tud lenni a 2.4-es sorozat eseten.
Elkezdtem a grsec-et is hasznalni, de ezek ellen a hibak ellen az sem ved, raadasul van amikor meg kell varni amig a grsec kijon ehhez.

2.6-os kernelre nem akarok valtani, mivel abban meg tul sok a valtozas ahhoz hogy tavolrol batran merjek updatelni.

Ti mit csinaltok? Mit javasoltok?
Valtsak 2.6-ra? Valtsak BSD-re? Valtsak Windowsra? Hasznaljak 2.4.28prex kernelt?

Komolyan a windowsos szervereimet mar lassan nagyobb biztonsagban erzem. Ott nem az van, hogy tessek itt a local root exploit, barki letoltheti lefuttathatja, hello.

Persze valoszinu abban is vannak bugok, de legalabb a javitatlan hibakat kihasznalo szkriptek nem forognak kozkezen.

BSD-t nem ismerem, Windows annyiból szerencsétlenebb, hogy ott a "remote hibák" forognak ugyanígy, sz'al azzal még kevésbé jársz jól szerintem.

Ha a mostani binfmt_elf hiba akaszt ki, akkor nézd meg ezt:

http://linux.bkbits.net:8080/linux-2.6/gnupatch@41925edcVccsXZXObG444GFvEJ94GQ

amellett, hogy a 2.6.9et is úgy tűnik érinti a hiba, (különben minek adták volna ki a pecset ?), a patch felmegy 2.4es kernelre is.
A grsecet a (PaX) miatt kicsit "kézimunkázni" kell.

hogy aztán mennyit ér , azt nem'tom, meg kéne nézni egy exploit test-el, csak erre nekem már nincs időm.
ha neked van, és megcsinálod, írd már be a tapasztaltakat.

a binfmt_elf-re jelzett 5hibából állítólag 4et javít. (az első 4et).

A sec. hibák jórészére a javítás amúgy elérhető kisebb patch-ek formájában. tehát nem kell állandóan egy egész kernel forrást lekapni.

[quote:8be0505839="nug"]
Ti mit csinaltok? Mit javasoltok?
Valtsak 2.6-ra? Valtsak BSD-re? Valtsak Windowsra? Hasznaljak 2.4.28prex kernelt?

Tul van spilazva ez az egesz security temakor. En csak rotfl-kodok a sok onjelolet szakerton. A legyeg: legyen mindenrol backup. Az, hogy felkurjak a a geped, az benne van a pakliban. 100%-os biztonsag nincs. Orok paraban elni meg eljen a rak. Offsite mentes. Felkurtak? Nagy kaland. OS le, OS fel, backup vissza. Fasze' kell allandoan a para? Meg itt adni a ``tuti gyerek vagyok, en megmondom neked a frankot: BSD.'' Pff. A BSD-k sem biztonsagosabbak a Linuxnal. Mindegyiknem megvan a maga keresztje.

A legbiztosabb ha az adataid biztonsagban vannak.

Gondolom, nem egy blog deface-elése miatt megy a para, hanem amiatt, ha egy nagyobb rendszer 76544376547 juzerének kerülnek ki a jelszavai vagy egyéb adatai. Azon nem segít az offline mentés.

(Én is parázok, csak én ráadásul nem is értek hozzá :) bár lehet, pont azért...)

[quote:2f8bfe5f5d="nug"]asszem megtanulom az openbsdnek a hasznalatat is, es a backup szervert es/vagy a tuzfalat atallitom annak. Hogy ne legyen minden linux.

Javaslok egy FreeBSD-t es jailezd, amit kivulrol, tehat mindent ami publikus net felol jon a gepre jailen at engedj be. Szerencsés esetben csak a jailt nyomjak meg. Securelevel es hasonlokat pedig jomagasra tenni. A mentés fontos, viszont a megtolásból eredő károk, leállás és maga a tény, nagyon lerontja az image-et esetleg az illető cégen belüli statuszát.

Mondjuk a fentiek nyilvan nem csodaszerek es egyutt kell alkalmazni az adat es mukodes biztonsagat szavatolo dolgokat. BSD-k mellet szol meg talan az is, hogy ha sok scriptkiddie-t eleve elriaszt es mert mondjuk nincs is hozza rootkitje. Aki pedig tenyleg ert hozza es tenyleg be akar torni, azt nem fogod eszrevenni valoszinuleg. Szinten fontos hogy legyen masik gepre is (pl a mestesszerverre) naplozas a gepekrol, amik kulso tamadasnak vannak kiteve. Ebbe az auth, error es hasonlokat erdemes szerintem belevenni. Kulonosen hasznos ha jogi utra akarjak vinni a dolgot, de a var/log hianyzik.

Szinten megoldás ha egy OpenBSD -s átlátszó brigde -el szűrőd első körben a bejövő kapcsolatokat. A dolog szépsége, hogy gyakorlatilag ez a gép láthatatlan (nem cimezhető...), de még Layer 3 szinten tud a két (vagy több) bridge-elt interface forgalmába belenyulni. Sajnos eddig csak olvastam erről, de tetszik. :)

Egy nagyon jó leírás van, speciel ipf -ről itt: http://www.obfuscation.org/ipf/ipf-howto.html
A brigde fw dolgot a "What Firewall? Transparent filtering." pontban irjak le. Szinten csomo doksi, komplett handbook van egy-egy BSD terjesztes honlapjan, amiket erdemes nezegetni, mar csak feature ok miatt is. Peldanak okaert FreeBSD 5.x -től bevezetett MAC igencsak hasznos lehet neked. Ezzel szinten teljesen tudod szabalyozni, hogy egy egy user mihez ferhet hozza.

[quote:843f597db6="drojid"]Gondolom, nem egy blog deface-elése miatt megy a para, hanem amiatt, ha egy nagyobb rendszer 76544376547 juzerének kerülnek ki a jelszavai vagy egyéb adatai. Azon nem segít az offline mentés.

(Én is parázok, csak én ráadásul nem is értek hozzá :) bár lehet, pont azért...)

Gondolom ahol a "76544376547" user van csak valami csapdaba esett lehet az admin, hisz van local user ami nem trusted. A biztonsag nem oldhato meg box-on belul, csak torekedni lehet az igenyessegre.

[quote:4a18aebb9b="drojid"]Gondolom, nem egy blog deface-elése miatt megy a para, hanem amiatt, ha egy nagyobb rendszer 76544376547 juzerének kerülnek ki a jelszavai vagy egyéb adatai. Azon nem segít az offline mentés.

(Én is parázok, csak én ráadásul nem is értek hozzá :) bár lehet, pont azért...)

Az adatok csak addig erdekesek, amig el nem evulnek. Ha ilyen van, akkor be kell allitani a jelszavak elevuleset, es force-olni kell a cseret. 76544376547 user jelszavanak feltorese nem 3 percig tart.

[quote:6556a7e505="trey"]
Tul van spilazva ez az egesz security temakor. En csak rotfl-kodok a sok onjelolet szakerton.

A civil szférában megjelent biztonsági kutatásoknak köszönhető egyáltalán, hogy napvilágra kerülnek ilyen és ehez hasonló hibák. Ha a sok fiatal nem harapott volna rá erre a security témakörre, akkor még mindig csak az állami szerveknek lennének ilyen jellegű kutatásai.

[quote:6556a7e505="trey"]A legyeg: legyen mindenrol backup. Az, hogy felkurjak a a geped, az benne van a pakliban.

Ezt nevezik tűzoltás jellegű megoldásnak.

[quote:6556a7e505="trey"]Felkurtak? Nagy kaland. OS le, OS fel, backup vissza.

Ezt az elképzelésedet a banki szférában próbáld előadni. :wink:

[quote:6329da00cc="hunger"]
A civil szférában megjelent biztonsági kutatásoknak köszönhető egyáltalán, hogy napvilágra kerülnek ilyen és ehez hasonló hibák. Ha a sok fiatal nem harapott volna rá erre a security témakörre, akkor még mindig csak az állami szerveknek lennének ilyen jellegű kutatásai.

Ezeknek a kutatasoknak a nagy resze abbol all, hogy kiadnak egy javitast, a luzer megnezi mit javitottak, arra ir egy proof of conceptet, aztan nagy mellennyel hireszteli hibat talalt, de a legujabb verziora nem ervenyes am, csak az egyel regebbire. Hehe, komoly.

[quote:6329da00cc="hunger"]

Ezt nevezik tűzoltás jellegű megoldásnak.

Ez nem tuzoltas. A jol megszervezett backupra koltenek a cegek a legtobbet. Legalabbis nalunk. Nem ritka a tobb (akar 10) millios backup megoldas, ami mondjuk tud ``one button disaster recovery''-t

[quote:6329da00cc="hunger"]

Ezt az elképzelésedet a banki szférában próbáld előadni. :wink:

Minden alol van kivetel. Az itt felszolalo nyilvan nem a bankszektorban dolgozik, es en erre reagaltam. Kicsit elkaladoztal. A bankszektoros emberek nem nagyon erdeklodnek forumokon, hogy mit kene hasznalni.

Az en tapasztalatom szerint a bankok backendjei mainframe-ek, koztuk windows szerverek, a teller gepek szinten windows-ok, a penzkiadok meg egyeb celgepek pedig AS400-ok, meg IBM celgepek, nem Linuxot meg BSD-t futtato izek. Persze vannak kivetelek itt is. De elenyeszo.

Mindenesetre ezeket a problemakat nem spender-ek, meg hasonlo kaliberu emberek fogjak megoldani. Erre merget vehetsz. Az a barom aki egy szintu, vagy egy tipusu vedelmet epit fel (pl csak Linux), az vessen magara. Ha valakinek vedelem kell (pl. bank), ugyis tobb kulonbozo rendszerbol allitja ossze a vedelmi rendszeret (vesz checkpointot, raptort, zorp-ot, mittomenmit, aztan kombinalja). Mire az elsore betonek azt mar eszreveszi es van ideje cselekedni. Ezert nem kell allandoan a parat kelteni. Az ilyen paraknak a 80%-ka FUD.

"A BSD-k sem biztonsagosabbak a Linuxnal. Mindegyiknem megvan a maga keresztje."

igazis a mult honapban is hany local root jott ra nem is tudtam igy hirtelen osszeszamolni. nezd meg hogy mien hibak jonnek debianra meg mondjuk freebsdre. es akkor meg nem is beszeltunk a trustedbsd projectrol vagy az openbsdrol.

bsd, an operating system, not a religion.....

azonkivul meg mar ezer helyen el lett mondva de ismetles a tudas anyja:

bsd default security lehetosegek:

MI - MI KELL HOZZA - HANDBOOK

-jail - - http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/jail.html

-ACL - options UFS_ACL - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/fs-acl.html

-MAC - options MAC - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac-initial.html

-SECURELEVEL - sysctl kern.securelevel -http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/security.html#SECURELEVEL

[quote:7b3dd63bc6="drastik"]"A BSD-k sem biztonsagosabbak a Linuxnal. Mindegyiknem megvan a maga keresztje."

igazis a mult honapban is hany local root jott ra nem is tudtam igy hirtelen osszeszamolni. nezd meg hogy mien hibak jonnek debianra meg mondjuk freebsdre. es akkor meg nem is beszeltunk a trustedbsd projectrol vagy az openbsdrol.

bsd, an operating system, not a religion.....

azonkivul meg mar ezer helyen el lett mondva de ismetles a tudas anyja:

bsd default security lehetosegek:

MI - MI KELL HOZZA - HANDBOOK

-jail - -http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/jail.html

-ACL - options UFS_ACL - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/fs-acl.html

-MAC - options MAC - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac-initial.html

-SECURELEVEL - sysctl kern.securelevel -http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/security.html#SECURELEVEL

Rotfl, meg a mult havi REMOTE root a NetBSD-ben. Na jo, fejezzuk be a bohockodast.

[quote:c8cf4b061b="trey"]

Rotfl, meg a mult havi REMOTE root a NetBSD-ben. Na jo, fejezzuk be a bohockodast.

nem is latom pontosan hogy hol emlitem a netbsdt(ami ugye a tobb platformra van kihegyezve es nem feltetlenul a securityre)

jo hat nyugodtan fejezd be, rajtad kivul nem latom ki bohockodik....

[quote:78a3af8baa="drastik"][quote:78a3af8baa="trey"]

Rotfl, meg a mult havi REMOTE root a NetBSD-ben. Na jo, fejezzuk be a bohockodast.

nem is latom pontosan hogy hol emlitem a netbsdt(ami ugye a tobb platformra van kihegyezve es nem feltetlenul a securityre)

jo hat nyugodtan fejezd be, rajtad kivul nem latom ki bohockodik....

Arrol volt szo, hogy a BSD-knek is meg van a maga keresztje. Megfigyeltem, neked a BSD == FreeBSD. Pedig nem. En azt mondtam, hogy mindegyiknek megvan a maga gyengesege, te meg elvakultan nyomod szokas szerint a BSD mindenek felett szoveget. Vedd mar eszre, hogy a BSD se csodaszer. Az is csak egy program, ami az alatta futo vas gyengesegeitol (design, stb.) eppugy szenved, mint az osszes tobbi rendszer. A programokban meg altalaban vannak hibak, mert emberek irjak. Tokeletes meg nincs. Hunger is elismerte, hogy az OpenBSD se tokeletes. O legalabb latja a BSD-k gyengesegeit is, es nem csak szajkozza a semmit.

en felsoroltem azokat a vedelmi mechanizmusokat amik pl. a freebsd alprendszer reszeit kepezik. nem kell grsec meg ilyen pecs meg olyan pecs.
benne van az official rendszerben.

te itt osszehordasz hetet havat designrol meg anyam tyukjarol meg mindenrol.

tenyeket irjal lecci mert meset mar nem olvasok, kinottem.

[quote:62bd2ce91b="drastik"]en felsoroltem azokat a vedelmi mechanizmusokat amik pl. a freebsd alprendszer reszeit kepezik. nem kell grsec meg ilyen pecs meg olyan pecs.
benne van az official rendszerben.

te itt osszehordasz hetet havat designrol meg anyam tyukjarol meg mindenrol.

tenyeket irjal lecci mert meset mar nem olvasok, kinottem.

Eppen tegnap irtak meg nalam securityben jaratosabb emberek itt a HUP-on, hogy rahuzhatod a jail-edet, ACL-edet, MAC-edet, meg az osszes hasonlod dolgodat, ha a tamado mar a memoriaban elintezi a dolgat. Itt nem segit a mindenttudo FreeBSD se ezek szerint. A jail-bol, chroot-bol ki lehet torni, a az alaprendszer reszet kepezo mechanizmusuk meg elintezhetok mashogy.

A patchelessel egyebkent mi bajod van? A kernel listan megirtak, hogy ok ezzel nem foglakoznak, akiknek ezzel foglalkozni kell, azok a disztributorok, akik meg is teszik. Mi ezzel neked a problemad?

Kvázi laikusként készítettem egy
rövid listát, egy nem banki,
de fontos szerver igényes kialakításra:

- Kernel patch & UML,... | Jail,...
- Firewall & proxy

- Offsite backup
- Offsite log

- Cron – hour update
- Alert manager

Mi az, amit kihagytam szerintetek?
Esetleg mi az ami felesleges?

[quote:44aba2b66e="drastik"]"A BSD-k sem biztonsagosabbak a Linuxnal. Mindegyiknem megvan a maga keresztje."

igazis a mult honapban is hany local root jott ra nem is tudtam igy hirtelen osszeszamolni. nezd meg hogy mien hibak jonnek debianra meg mondjuk freebsdre. es akkor meg nem is beszeltunk a trustedbsd projectrol vagy az openbsdrol.

bsd, an operating system, not a religion.....

azonkivul meg mar ezer helyen el lett mondva de ismetles a tudas anyja:

bsd default security lehetosegek:

MI - MI KELL HOZZA - HANDBOOK

-jail - - http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/jail.html

-ACL - options UFS_ACL - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/fs-acl.html

-MAC - options MAC - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac-initial.html

-SECURELEVEL - sysctl kern.securelevel -http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/security.html#SECURELEVEL

TrustedBSD: MAC (FLASK), de: stack protection?
OpenBSD: stack protection, de: rendes MAC?

Mutassá olyan BSD-t, amibe van valami rendes RBAC (a'la RSBAC) és rendses stack védelem.
A legjobb kandidátus az OpenBSD, csak kéne hozzá csinálniuk még egy rendes RBAC-ot.

Üdv,
Dw.

[quote:f049668923="trey"]Ezeknek a kutatasoknak a nagy resze abbol all, hogy kiadnak egy javitast, a luzer megnezi mit javitottak, arra ir egy proof of conceptet, aztan nagy mellennyel hireszteli hibat talalt, de a legujabb verziora nem ervenyes am, csak az egyel regebbire. Hehe, komoly.

???
Őőő, én a szoftver hibák megkereséséről beszéltem, mint kutatási terület, nem az exploit elkészítéséről... A bugok felderítése annak köszönhető, hogy néhányan rákaptak a források/binárisok auditálására a civil szférában. Ha ők nem lennének, akkor ezek a hibák napvilágra se kerülnének, csak a titkosszolgálatok eszköztárát bővítenék.

Egyébként meg nem a nyilvánosságra került hibáktól kell tartani, ez teljesen egyértelmű.

[quote:f049668923="trey"]Ez nem tuzoltas.

Hát micsoda? :) Amikor beüt a ménykű, akkor gyorsan, "OS le, OS fel, backup vissza" ... Nem tűnik probléma megelőzésnek. ;)

[quote:f049668923="trey"]A jol megszervezett backupra koltenek a cegek a legtobbet.

Backup elsősorban az adatvesztés ellen lett kitalálva. Hiába végzel teljeskörű mentést, ha a magán (vagy céges) privát információk idegen kezekbe kerülnek.

[quote:f049668923="trey"]A bankszektoros emberek nem nagyon erdeklodnek forumokon, hogy mit kene hasznalni.

Dehogynem, még a titkosszolgálatok is folyamatosan figyelemmel kísérik, hogy hol tart a civil élet... (mert ők jópár évvel elöttünk járnak.)

[quote:f049668923="trey"]Az en tapasztalatom szerint a bankok backendjei mainframe-ek, koztuk windows szerverek, a teller gepek szinten windows-ok, a penzkiadok meg egyeb celgepek pedig AS400-ok, meg IBM celgepek, nem Linuxot meg BSD-t futtato izek. Persze vannak kivetelek itt is. De elenyeszo.

A pénzkiadó automaták sima PC-re telepített OS/2-n futnak (legalábbis amikkel én foglalkozom azok mind ilyenek, de lehet, hogy vannak kivételek). A backend szerverek között pedig egyre több féle rendszer található, akár Linux is, BSD is.

[quote:f049668923="trey"]Mindenesetre ezeket a problemakat nem spender-ek, meg hasonlo kaliberu emberek fogjak megoldani. Erre merget vehetsz.

A Linuxban alapból *nincs* behatolás megelőzésre (Intrusion Prevention) megfelelő megoldás. Amelyet PaXTeam és még jónéhányan készítenek azért nagyszerű, mert megpróbál védelmet nyújtani a jelenleg nem ismert kihasználható szoftver hibák ellen (0day exploitok, stb.). Persze sokszor ezek sem tudnak biztos védelmet adni, csak megnehezítik a egyes bugok kihasználását.

[quote:f049668923="trey"]Az a barom aki egy szintu, vagy egy tipusu vedelmet epit fel (pl csak Linux), az vessen magara.

Pedig nagyon sok helyen csak egyféle rendszert használnak, hogy megmaradjon a homogenitás.

[quote:f049668923="trey"]Mire az elsore betonek azt mar eszreveszi es van ideje cselekedni.

Ha ez ilyen egyszerű lenne, akkor nem lennének a mai napig sikeres betörések szerte a világon.

[quote:f049668923="trey"]Ezert nem kell allandoan a parat kelteni. Az ilyen paraknak a 80%-ka FUD.

Nem kelti senki sem a parát, de "attól hogy nem vagyok paranoiás, nem biztos, hogy nem követnek". :wink:

Ugyerzem itt is kiuttkozott az elite security divat.
Szocseples az egesz, mindig a gep adminjan mulik a vedekezes mertteke es nem a felhasznalt eszkozon. Az oprencer meg egy igen pici fogaskerek egy jol megtervezett rendszerben.
Egyedul ami szamit, hogyan tudja hasznalni az oprencer kinalta lehetosegeket az admin, ha a linuxban jobb akkor semmikepp nem alkot bsdbol jobb rendszert.

[quote:45a4092503="hunger"]Nem tűnik probléma megelőzésnek. ;)

Ez a problema megelozese. Te is megmondtad, hogy 100% vedelem nincs. A megelozes egyik formaja, hogy a szamomra ertekes adatokat biztonsagba helyezem. A szemeben az operacios rendszer semmilyen erteket nem hordoz, mivel ujratelepitheto ha betornek. Ez a hozzaallas meg mindig jobb, mint azt mondom ``baz+ a FreeBSD tokeletes mer van ACL, meg menteni se kell. Van RAID.'' Aztan majd egy szep nap becsongetnek a gepedre, nem erdekli oket semmilyen adat mer fogalmuk nincs arrol mi az, de szepen nyomnak egy rm -rf /-t. Az a szep mulatsag.

[quote:45a4092503="hunger"]
Backup elsősorban az adatvesztés ellen lett kitalálva. Hiába végzel teljeskörű mentést, ha a magán (vagy céges) privát információk idegen kezekbe kerülnek.

Ezt en kiegeszitenem: adatvesztes, emberi (operatori) hiba, szabotazs, betores, termeszeti katasztrofa, stb.

Dehogynem, még a titkosszolgálatok is folyamatosan figyelemmel kísérik, hogy hol tart a civil élet... (mert ők jópár évvel elöttünk járnak.)

Siralmas lehet az a hely ahol nincs kidolgozott koncepcio erre, es forumokbol kell osszeszedni a dolgokat...

[quote:45a4092503="hunger"]A pénzkiadó automaták sima PC-re telepített OS/2-n futnak (legalábbis amikkel én foglalkozom azok mind ilyenek, de lehet, hogy vannak kivételek).

Azt mondtam van kivetel. Viszont egy reszunknek semmi koze a pc-hez. Es nem OS/2-t futtatnak. Meg hat akkor tudnam miert viszik a penzszektorban annyira az AS400-akat....

A backend szerverek között pedig egyre több féle rendszer található, akár Linux is, BSD is.

Minden bizonnyal. Vannak olyan takarekszovetkezetek ahol win98 a backen szerver. Nem egyet lattam sajat szememmel. Mi ebben a csoda?

[quote:45a4092503="trey"]Mindenesetre ezeket a problemakat nem spender-ek, meg hasonlo kaliberu emberek fogjak megoldani. Erre merget vehetsz.

Kit erdekel, hogy mi van alapbol... az akkora szar szoveg... :-) Miert patchelni mar nem is tudunk? A FreeBSD 4-ben meg nem volt beleforditva a csomagszuro egy idoben. Es aki nem tud FreeBSD kernelt forditani akkor mi van? Ott meg nincs csomagszuro. Ja es abban sem vagyok biztos, hogy a FreeBSD ACL-hez nem-e kell kernelt forditani. Magyarul ha kell, alapbol nincs benne.

[quote:45a4092503="hunger"]Pedig nagyon sok helyen csak egyféle rendszert használnak, hogy megmaradjon a homogenitás.

Persze, ha az egyiket megnyomjak, akkor mar faszan vegig is tudjanak menni az osszesen :-) Ugyes :-)

[quote:45a4092503="hunger"]Ha ez ilyen egyszerű lenne, akkor nem lennének a mai napig sikeres betörések szerte a világon.

Ha a Windows rendszergazdak feltennek a kiadott patcheket akkor 10-ed ennyi Windows feltores se lenne. Ennek megin nincs koze a Linuxhoz. Ez vonatkozik minden OS-re.

[quote:45a4092503="hunger"]Nem kelti senki sem a parát, de "attól hogy nem vagyok paranoiás, nem biztos, hogy nem követnek".

Ezzel arra celoztam, hogy aki ezzel kel fekszik az beteg.

[quote:8b20d8f9e2="hunger"]
Egyébként meg nem a nyilvánosságra került hibáktól kell tartani, ez teljesen egyértelmű.

Szerintem is. cron - update
[quote:8b20d8f9e2="hunger"][quote:8b20d8f9e2="trey"]Ez nem tuzoltas.

Hát micsoda? :) Amikor beüt a ménykű, akkor gyorsan, "OS le, OS fel, backup vissza" ... Nem tűnik probléma megelőzésnek. ;)
[quote:8b20d8f9e2="trey"]A jol megszervezett backupra koltenek a cegek a legtobbet.

Backup elsősorban az adatvesztés ellen lett kitalálva. Hiába végzel teljeskörű mentést, ha a magán (vagy céges) privát információk idegen kezekbe kerülnek.

Ki mondta, hogy a céges, vagy privát infókat (a célszektorokon kívül)
Internetre kötött gépeken kell tárolni?
Tehát amiről beszélsz, az az esetek 99%-ban túlzás.
Épp úgy, ahogy Gábor mondja.

[quote:8b20d8f9e2="hunger"][quote:8b20d8f9e2="trey"]A bankszektoros emberek nem nagyon erdeklodnek forumokon, hogy mit kene hasznalni.

Dehogynem, még a titkosszolgálatok is folyamatosan figyelemmel kísérik, hogy hol tart a civil élet... (mert ők jópár évvel elöttünk járnak.)

Ez lehet, de biztosan nem a HUP fórumon fognak láma ügyeket feszegetni :-)

[quote:6314d1fa2a="global77"][quote:6314d1fa2a="hunger"]
Egyébként meg nem a nyilvánosságra került hibáktól kell tartani, ez teljesen egyértelmű.

Szerintem is. cron - update

Barmilyen komoly helyen az update-et ugy hivjak, hogy change management, es minimum egy identikus, de levalasztott tesztrendszeren kell leteszteni minden patch-et vagy mas valtozast a rendszeren.

A biztonsag folyamat. Tuzfalastul, IDS-estul, backup-ostul, mindenestul. A biztonsagos uzemeltetes legnagyobb resze kockazatelemzes es semmi koze nincs a bitekhez, patch-ekhez es operacios rendszerekhez. Aki ezt nem tudja megerteni, az orokre megmarad rendszergazdanak...

egy kicsit gerjesztem en is a flame-et :)

A jol megtervetett rendszer koncepciodat, egyetlen mozdulattal hazavaghatja egy bena rendszergazda, es utana mosolyogva lejelenti neked, hogy minden tokeletesen meg van valositva es tesztelve.

Eleg bonyolult rendszernel addig nem is derul ki a gebasz, amig be nem ut a mennyko.

[quote:317198f33a="_Joel"][quote:317198f33a="global77"][quote:317198f33a="hunger"]
Egyébként meg nem a nyilvánosságra került hibáktól kell tartani, ez teljesen egyértelmű.

Szerintem is. cron - update

Barmilyen komoly helyen az update-et ugy hivjak, hogy change management, es minimum egy identikus, de levalasztott tesztrendszeren kell leteszteni minden patch-et vagy mas valtozast a rendszeren.

A biztonsag folyamat. Tuzfalastul, IDS-estul, backup-ostul, mindenestul. A biztonsagos uzemeltetes legnagyobb resze kockazatelemzes es semmi koze nincs a bitekhez, patch-ekhez es operacios rendszerekhez. Aki ezt nem tudja megerteni, az orokre megmarad rendszergazdanak...

:)
Igen,
És ezeknek a rendszergazdák 99,9 % nem komoly helyen dolgozik.

Nekem úgy jött le a 29 év alatt, hogy a komoly helyeken
a főnökök feje tele van nyomva az általad említett szövegekkel,
és milliókat keresnek az informatikusok, azzal, hogy sikeresen
elhalgatják a winfos szerverek feltöréseit.
Aztán van az az egy ezrelék komoly hely, ahol tényleg komolyan veszik
azt, amit leírtál. És hozzáértő emberek güriznek naphosszat.

Szvsz a rendszergazdák 99% nak elégendő védelmet nyújt egy
cronba vésett rendszerfrissítés, mégsem teszik meg.

Egy ismerősöm esküdözött potato rendszerére, hogy feltörhetetlen:
3 éve egyszer sem volt frissítve,
az ipchains default policy minden láncon ACCEPT

Szerintem az ilyen rendszergazdák szintén túlsúlyban vannak.
Javítsatok ki, ha nincs igazam!

azt nem ertem hogy miert freebsd-n fut a hup ha ennyire jo a linux?

hmm trey erre leccives valaszolj mar.

[quote:7021b1eaa3="drastik"]azt nem ertem hogy miert freebsd-n fut a hup ha ennyire jo a linux?

hmm trey erre leccives valaszolj mar.

(na ezt elszurtam)

Nem a biztonsag miatt az biztos. Elotte van egy OpenBSD csomagszuro biztos ami biztos...

Annak idejen Solaris 8 futott a HUP alatt. Amikor uj gepre kerult a HUP, azert dontottem a FreeBSD mellett, mert a 4-es sorozatban igaz hogy az SMP gyengusz volt, de azt legalabb stabilan tudta. Emellett jo tapasztalataim voltak vele kapcsolatban. Nem a biztonsag teren, inkabb stabilitasban. Emellett mivel a gep Pesten van, en meg nem, es aki bele szokott rugni baj eseten a FreeBSD-hez ert legjobban, ez volt a kezenfekvo valasztas.

Ennek ellenere... amilyen "jo" mostanaban a FreeBSD stabilitasa az 5.x szeriaban meg az is lehet, hogy a kovetkezo nagy frissitesnel Linux kerul ra :-)

Az 5-ös széria azért még hiába stable hivatalosan van mit reszelni rajta ezt tudjuk. :) Ennek ellenére érdemes megvárni, míg kissé stabilizálják/optimáljak (mondjuk szerintem a jelenlegi szintnek pl. sokan orulnenek :) ) aztán jó lesz ez. Épp ma probaltam volna ki a SCHED_ULE utemezot, ami broken..., ahogy ez make buildkernelnel kiderult. Maradt a 4BSD.

Azért aki teheti, nem missioncritical vagy tesztrendszert huzzon fel 5.3-al es zaklassa aztán bugreportoljon. :)

Szoval visszaterve a biztonsaghoz. Azt hiszem pl. freebsd (tudom hogy nem csak ez a bsd, de altalaban ezt Debian Sarge -ot hasznalunk) alaprendszerhez kevesebb SA volt mint a megfelelo reszekhez linux-2.4+userland eseten. En szemely szerint azert is jobban kedvelem a BSD-t mert jobban testre szabhato es (optimalis esetben) csak azt csinalja a rendszer amit bealltok, szemben pl. a Sarge-ban meglevo logrotate automatimussal, ami lehet lamasag, de egyaltalan megtalalni se tudtam, hogy akkor konkretan mi dolgozik. A Debian viszont konnyedebben adminolhato, joval kevesbe reszelgetos, ami adott esetben szempont lehet (mondjuk sok szervernel, bar a jo konfigot eleg egyszer beallitani).

[quote:2683b037bd="andrej_"][quote:2683b037bd="nug"]asszem megtanulom az openbsdnek a hasznalatat is, es a backup szervert es/vagy a tuzfalat atallitom annak. Hogy ne legyen minden linux.

Javaslok egy FreeBSD-t es jailezd, amit kivulrol, tehat mindent ami publikus net felol jon a gepre jailen at engedj be. Szerencsés esetben csak a jailt nyomjak meg. Securelevel es hasonlokat pedig jomagasra tenni. A mentés fontos, viszont a megtolásból eredő károk, leállás és maga a tény, nagyon lerontja az image-et esetleg az illető cégen belüli statuszát.

Mondjuk a fentiek nyilvan nem csodaszerek es egyutt kell alkalmazni az adat es mukodes biztonsagat szavatolo dolgokat. BSD-k mellet szol meg talan az is, hogy ha sok scriptkiddie-t eleve elriaszt es mert mondjuk nincs is hozza rootkitje. Aki pedig tenyleg ert hozza es tenyleg be akar torni, azt nem fogod eszrevenni valoszinuleg. Szinten fontos hogy legyen masik gepre is (pl a mestesszerverre) naplozas a gepekrol, amik kulso tamadasnak vannak kiteve. Ebbe az auth, error es hasonlokat erdemes szerintem belevenni. Kulonosen hasznos ha jogi utra akarjak vinni a dolgot, de a var/log hianyzik.

Szinten megoldás ha egy OpenBSD -s átlátszó brigde -el szűrőd első körben a bejövő kapcsolatokat. A dolog szépsége, hogy gyakorlatilag ez a gép láthatatlan (nem cimezhető...), de még Layer 3 szinten tud a két (vagy több) bridge-elt interface forgalmába belenyulni. Sajnos eddig csak olvastam erről, de tetszik. :)

Egy nagyon jó leírás van, speciel ipf -ről itt: http://www.obfuscation.org/ipf/ipf-howto.html
A brigde fw dolgot a "What Firewall? Transparent filtering." pontban irjak le. Szinten csomo doksi, komplett handbook van egy-egy BSD terjesztes honlapjan, amiket erdemes nezegetni, mar csak feature ok miatt is. Peldanak okaert FreeBSD 5.x -től bevezetett MAC igencsak hasznos lehet neked. Ezzel szinten teljesen tudod szabalyozni, hogy egy egy user mihez ferhet hozza.

Az OpenBSD-ben a 3.0 óta nincs ipf...

De a pf-fel még jobban működik a bridge-ben való szűrés. man {pf,bridge}

[quote:085ddf9bdf="trey"][quote:085ddf9bdf="drojid"]Gondolom, nem egy blog deface-elése miatt megy a para, hanem amiatt, ha egy nagyobb rendszer 76544376547 juzerének kerülnek ki a jelszavai vagy egyéb adatai. Azon nem segít az offline mentés.

(Én is parázok, csak én ráadásul nem is értek hozzá :) bár lehet, pont azért...)

Az adatok csak addig erdekesek, amig el nem evulnek. Ha ilyen van, akkor be kell allitani a jelszavak elevuleset, es force-olni kell a cseret. 76544376547 user jelszavanak feltorese nem 3 percig tart.

76544376547 userből 15308875309-nek félórán belül megmondom a jelszavát.

[quote:542eece528="trey"]meg az is lehet, hogy a kovetkezo nagy frissitesnel Linux kerul ra :-)

bP, Frugal vagy UHU? :-)

[quote:85fe4d014a="bra"][quote:85fe4d014a="trey"][quote:85fe4d014a="drojid"]Gondolom, nem egy blog deface-elése miatt megy a para, hanem amiatt, ha egy nagyobb rendszer 76544376547 juzerének kerülnek ki a jelszavai vagy egyéb adatai. Azon nem segít az offline mentés.

(Én is parázok, csak én ráadásul nem is értek hozzá :) bár lehet, pont azért...)

Az adatok csak addig erdekesek, amig el nem evulnek. Ha ilyen van, akkor be kell allitani a jelszavak elevuleset, es force-olni kell a cseret. 76544376547 user jelszavanak feltorese nem 3 percig tart.

76544376547 userből 15308875309-nek félórán belül megmondom a jelszavát.

Fuggetlenul attol, hogy milyen bonyolult, milyen hosszu jelszot es ahhoz milyen chiper-t (blowfish, DES, MD5) hasznalok? Nem vagyok egy nagy crypto szakerto de ez biztos? :-)

[quote:c77dad7087="egmont"][quote:c77dad7087="trey"]meg az is lehet, hogy a kovetkezo nagy frissitesnel Linux kerul ra :-)

bP, Frugal vagy UHU? :-)

Vagy folytatom a sajat tobb evvel ezelott elkezdett Linux disztromat a Debi][inux-ot :-) (Debil Linux debileknek :-) Ugyis kell mindenkinek egy sajat Linux disztro nem? :-D

Screenshot:

http://portal.fsn.hu/~trey/debil01.jpg
http://portal.fsn.hu/~trey/debil1.jpg

(muhahaha, nem komolyan venni :-)

[quote:4b98ef7fec="bra"][quote:4b98ef7fec="andrej_"][quote:4b98ef7fec="nug"]asszem megtanulom az openbsdnek a hasznalatat is, es a backup szervert es/vagy a tuzfalat atallitom annak. Hogy ne legyen minden linux.

Egy nagyon jó leírás van, speciel ipf -ről itt: http://www.obfuscation.org/ipf/ipf-howto.html
A brigde fw dolgot a "What Firewall? Transparent filtering." pontban irjak le. Szinten csomo doksi, komplett handbook van egy-egy BSD terjesztes honlapjan, amiket erdemes nezegetni, mar csak feature ok miatt is. Peldanak okaert FreeBSD 5.x -től bevezetett MAC igencsak hasznos lehet neked. Ezzel szinten teljesen tudod szabalyozni, hogy egy egy user mihez ferhet hozza.

Az OpenBSD-ben a 3.0 óta nincs ipf...

De a pf-fel még jobban működik a bridge-ben való szűrés. man {pf,bridge}

Ok, OpenBSD-hez nem ertek, bar van itt SparcStation5-öm 3.4-el csak nem vettem meg ra magam hogy foglalkozzam vele. :) Szoval akkor pf is tokeletes persze, ipfhez annyira kotodik a tema hogy ipf leirasban volt.

[quote:a435e5acdb="willy"]Ugyerzem itt is kiuttkozott az elite security divat.
Szocseples az egesz, mindig a gep adminjan mulik a vedekezes mertteke es nem a felhasznalt eszkozon. Az oprencer meg egy igen pici fogaskerek egy jol megtervezett rendszerben.
Egyedul ami szamit, hogyan tudja hasznalni az oprencer kinalta lehetosegeket az admin, ha a linuxban jobb akkor semmikepp nem alkot bsdbol jobb rendszert.

Na igen. Az emberi tenyezoket teljes mertekben kihagytuk eddig a szamitasbol...

[quote:e32f918622="global77"]Ki mondta, hogy a céges, vagy privát infókat (a célszektorokon kívül)
Internetre kötött gépeken kell tárolni?

lol, ki mondta, hogy azok a gépek közvetlenül az internetre vannak kötve. Lehet az egy belső intranet hálózatban is és 1 teljesen másik gép a hálózatban meg az interneten... Aztán majd ha megtörik az interneten lévő gépet (vagy akár a tűzfalat), akkor szépen megtalálják a belső hálozatban lévő fontos információkat tartalmazó gépet is. Vagy te úgy gondoltad, hogy amelyik gépen fontos adatok vannak azok abszolút ne legyenek semilyen hálózatra kötve? :D Akkor ennyi erővel papíron is tárolhatná mindenki a féltve őrzött adatait.

[quote:e32f918622="global77"]Tehát amiről beszélsz, az az esetek 99%-ban túlzás.

Valószínűleg a Ciscotól is úgy lopták el az IOS forráskódját, hogy egy közvetlenül az Internetre kötött gépen tárolták azt, nem? :)

[quote:ed83b443b1="trey"][quote:ed83b443b1="bra"][quote:ed83b443b1="trey"][quote:ed83b443b1="drojid"]Gondolom, nem egy blog deface-elése miatt megy a para, hanem amiatt, ha egy nagyobb rendszer 76544376547 juzerének kerülnek ki a jelszavai vagy egyéb adatai. Azon nem segít az offline mentés.

(Én is parázok, csak én ráadásul nem is értek hozzá :) bár lehet, pont azért...)

Az adatok csak addig erdekesek, amig el nem evulnek. Ha ilyen van, akkor be kell allitani a jelszavak elevuleset, es force-olni kell a cseret. 76544376547 user jelszavanak feltorese nem 3 percig tart.

76544376547 userből 15308875309-nek félórán belül megmondom a jelszavát.

Fuggetlenul attol, hogy milyen bonyolult, milyen hosszu jelszot es ahhoz milyen chiper-t (blowfish, DES, MD5) hasznalok? Nem vagyok egy nagy crypto szakerto de ez biztos? :-)

Nem függetlenül. Átlag felhasználó átlag jelszavával.
De mondjuk tíz IBM Blue Gene-vel a hátam mögött megmondom neked mindezektől függetlenül is :)

[quote:9fdc902a8a="hunger"][quote:9fdc902a8a="global77"]Ki mondta, hogy a céges, vagy privát infókat (a célszektorokon kívül)
Internetre kötött gépeken kell tárolni?

lol, ki mondta, hogy azok a gépek közvetlenül az internetre vannak kötve. Lehet az egy belső intranet hálózatban is és 1 teljesen másik gép a hálózatban meg az interneten... Aztán majd ha megtörik az interneten lévő gépet (vagy akár a tűzfalat), akkor szépen megtalálják a belső hálozatban lévő fontos információkat tartalmazó gépet is. Vagy te úgy gondoltad, hogy amelyik gépen fontos adatok vannak azok abszolút ne legyenek semilyen hálózatra kötve? :D Akkor ennyi erővel papíron is tárolhatná mindenki a féltve őrzött adatait.

[quote:9fdc902a8a="global77"]Tehát amiről beszélsz, az az esetek 99%-ban túlzás.

Valószínűleg a Ciscotól is úgy lopták el az IOS forráskódját, hogy egy közvetlenül az Internetre kötött gépen tárolták azt, nem? :)

Azt úgy lopták el, hogy megbíztak a PIX-ben és a VPN koncentrátorukban :))))

[quote:cdbd7608b1="global77"]Tehát amiről beszélsz, az az esetek 99%-ban túlzás.

Valószínűleg a Ciscotól is úgy lopták el az IOS forráskódját, hogy egy közvetlenül az Internetre kötött gépen tárolták azt, nem? :)

Erősen olyan szaga volt a dolognak, hogy volt benne belső ember is. Ez csak az én véleményem a Ciscos esetről.

Laci

[quote:684f6df0b6="bra"][quote:684f6df0b6="hunger"][quote:684f6df0b6="global77"]Ki mondta, hogy a céges, vagy privát infókat (a célszektorokon kívül)
Internetre kötött gépeken kell tárolni?

lol, ki mondta, hogy azok a gépek közvetlenül az internetre vannak kötve. Lehet az egy belső intranet hálózatban is és 1 teljesen másik gép a hálózatban meg az interneten... Aztán majd ha megtörik az interneten lévő gépet (vagy akár a tűzfalat), akkor szépen megtalálják a belső hálozatban lévő fontos információkat tartalmazó gépet is. Vagy te úgy gondoltad, hogy amelyik gépen fontos adatok vannak azok abszolút ne legyenek semilyen hálózatra kötve? :D Akkor ennyi erővel papíron is tárolhatná mindenki a féltve őrzött adatait.

[quote:684f6df0b6="global77"]Tehát amiről beszélsz, az az esetek 99%-ban túlzás.

Valószínűleg a Ciscotól is úgy lopták el az IOS forráskódját, hogy egy közvetlenül az Internetre kötött gépen tárolták azt, nem? :)

Azt úgy lopták el, hogy megbíztak a PIX-ben és a VPN koncentrátorukban :))))

Halvány kisegítő pót fogalmam sincs, hogy lophatták el, de biztosan hibát követtek el.
Forráskódot ellopni úgy is lehet, hogy amíg elmegy WC-re az ipse, a konzolról copyzik a másik,
nem kell ahhoz tűzfalon átjutni.

Aki meg internetre köti féltett kicseit,
tűzfal ide, vagy oda, azt nagyon tudom sajnálni.

Kadlec (at kfki.hu) mondta, hogy valakik szerint a netfilter nem is tűzfal, mert a proxyzás az igazi tűzfal.
Szerintem sem a proxyk sem a ciscok nem tudnak abszolút védelmet nyújtani,
azaz ha valamit féltesz ne kösd internetre, meg vigyázz rá rendesen. Ahogy szokás mondani "fizikailag" is! :twisted:
Az ördög nem alszik :wink:

[quote:11a7895626="bra"][quote:11a7895626="trey"][quote:11a7895626="bra"][quote:11a7895626="trey"][quote:11a7895626="drojid"]Gondolom, nem egy blog deface-elése miatt megy a para, hanem amiatt, ha egy nagyobb rendszer 76544376547 juzerének kerülnek ki a jelszavai vagy egyéb adatai. Azon nem segít az offline mentés.

(Én is parázok, csak én ráadásul nem is értek hozzá :) bár lehet, pont azért...)

Az adatok csak addig erdekesek, amig el nem evulnek. Ha ilyen van, akkor be kell allitani a jelszavak elevuleset, es force-olni kell a cseret. 76544376547 user jelszavanak feltorese nem 3 percig tart.

76544376547 userből 15308875309-nek félórán belül megmondom a jelszavát.

Fuggetlenul attol, hogy milyen bonyolult, milyen hosszu jelszot es ahhoz milyen chiper-t (blowfish, DES, MD5) hasznalok? Nem vagyok egy nagy crypto szakerto de ez biztos? :-)

Nem függetlenül. Átlag felhasználó átlag jelszavával.
De mondjuk tíz IBM Blue Gene-vel a hátam mögött megmondom neked mindezektől függetlenül is :)

na igen, de lehet force-olni a felhasznalokat a jo jelszora. es tudok nem egy helyet, ahol meg is teszik.

Minimum 3 fontossági szintet (jobb ha több van) kell kialakítatni a felhasználókkal biztosnág terén:
1. publikus internetes gépeken is lehet, weben is fent lehet.
2. Nem publikus, de nem is lesz nagy tragédia, ha kikerül:
na ezek lehetnek tűzfallal leválasztott hálózaton.
3. Titkos, mindig cipeljék magukkal, ne használják más gépen őket.
Ha muszály, akkor csak rövid ideig, és írják felül a fájlrendszert.
pl. titkosított pendrive, vagy winchester.
+ Minden irodában legyen minimum egy hálózat nélküli gondosan kezelt gép.

Szerintem ez egy alpkövetelmény,
amit egy rendszergazdának biztosítania kell a felhasználóknak.