2.2 2.4 2.6 melyik a biztonságosabb?

[quote:27ab31a670="nevergone"]Szerintem a 2.2.x -es kernelsorozat a legbiztonságosabb a felsorolt három közül. Egyrészt az kisebb, egyszerübb, kevesebb hibalehetőséget rejt. Másrészt pedig már nagyon régóta "'nyúzzák", tehát ami hiba lehet benne, az már szerintem régen kiderült... :)

attol eltekintve, hogy ez egy oriasi baromsag, esetleg eszedbe juthatna, hogy osszevesd peldaul a 2.4 elotti halozati architekturat a jelenlegivel (az is eleg, ha csak a netfilterre gondolsz), az SMP support hatekonysagarol mar nem is beszelve, de emlitettek itt mar a tamogatott hardvereket is. 2.2 ota csomo olyan (nem feltetlenul "lathato") dolgot javitottak/fejlesztettek/csereltek a kernelben, ami miatt komoly rendszerek eseten szoba sem johetnek a korabbi (pre-2.4) szeriak (hacsak nem valami elkurt beagyazott cuccban, de mar ilyen teren is regota ott vannak az olyan szisztemek, amik gond nelkul futtatnak 2.4-es kerneleket). az pedig, hogy a mai napig jonnek ki olyan biztonsagi hibak, amik erintik a 2.2-es sorozatot is, nem nagyon arra vall, hogy "mar minden kiderult" (ha irtal mar valaha "hello world"-tol egy fokkal bonyolultabb programot, ekkora baromsagot nem mondasz).

[quote:d4fd945912="snq-"][quote:d4fd945912="rigidus"]A mai tamadasok nem igazan Linux-specifikusak, imho ilyen korulmenyek kozott messze biztonsagosabb egy M$-nel barmelyiket is tekintjuk.

te mirol beszelsz?

Amit leirtam: arrol, hogy altalanossagba veve szinte barmelyik kernelfat lehetne valasztani. Nem a Linux a crackerek elsodleges celpontja.

[quote:03bd7b3191="zsirfeka"]attol eltekintve, hogy ez egy oriasi baromsag, esetleg eszedbe juthatna, hogy osszevesd peldaul a 2.4 elotti halozati architekturat a jelenlegivel (az is eleg, ha csak a netfilterre gondolsz), az SMP support hatekonysagarol mar nem is beszelve, de emlitettek itt mar a tamogatott hardvereket is. 2.2 ota csomo olyan (nem feltetlenul "lathato") dolgot javitottak/fejlesztettek/csereltek a kernelben, ami miatt komoly rendszerek eseten szoba sem johetnek a korabbi (pre-2.4) szeriak (hacsak nem valami elkurt beagyazott cuccban, de mar ilyen teren is regota ott vannak az olyan szisztemek, amik gond nelkul futtatnak 2.4-es kerneleket). az pedig, hogy a mai napig jonnek ki olyan biztonsagi hibak, amik erintik a 2.2-es sorozatot is, nem nagyon arra vall, hogy "mar minden kiderult" (ha irtal mar valaha "hello world"-tol egy fokkal bonyolultabb programot, ekkora baromsagot nem mondasz).

Nem a teljesítményről volt szó, hanem a biztonságról.
Másrészt pedig, ha feltélezzük, hogy egy program forrásának minden 500. sora hibát rejt magában, akkor összességében melyik kernelben lehetséges több hiba?
Egy kis segítség: méretösszehasonlítás: 2.2 < 2.4 < 2.6

Ha mondjuk arra gondolok, hogy egy program használatala során (a teljes, minden ember által használatra fordított időmennyiség szerint) minden 500. percben kiderül egy hiba, akkor összeségében melyik kernelben lehetséges több hiba?
Egy kis segítség: használatra fordított idő (a legelső kibocsájtás dátuma szerint, lehet, hogy nem fedi a pontos adatokat): 2.6 < 2.4 < 2.2

Utána arra gondolok, hogy ha egy program forrása mennyi lehetőséget rejt a bonyolultság alapján. Bonyolultság, azaz több modul, csűrt-csavart megoldások, stb.
Egy kis segítség: bonyolultság alapján: 2.2 < 2.4 < 2.6

És ismétlem, itt nem tértem ki arra, hogy melyik megolás mennyire hatékony a végeredményül szolgáló kód szempontjából. Csak a biztonságot néztem, néhány másik szemszögből...

Most vagy írtó nagy hülyeséget írok, vagy kiütöm a 2.2 -t a nyeregből ;)
Van a 2.2.x szériában connection-tracking, illetve állapotérzékeny tűzfalszabály, multiport, patch-o-matic?

[quote:2197745bb0="tomyellow"]Most vagy írtó nagy hülyeséget írok, vagy kiütöm a 2.2 -t a nyeregből ;)
Van a 2.2.x szériában connection-tracking, illetve állapotérzékeny tűzfalszabály, multiport, patch-o-matic?

ezt is batorkodtam emliteni feljebb

[quote:159af9e140="nevergone"]Nem a teljesítményről volt szó, hanem a biztonságról.
Másrészt pedig, ha feltélezzük, hogy egy program forrásának minden 500. sora hibát rejt magában, akkor összességében melyik kernelben lehetséges több hiba?
Egy kis segítség: méretösszehasonlítás: 2.2 < 2.4 < 2.6

Ha mondjuk arra gondolok, hogy egy program használatala során (a teljes, minden ember által használatra fordított időmennyiség szerint) minden 500. percben kiderül egy hiba, akkor összeségében melyik kernelben lehetséges több hiba?
Egy kis segítség: használatra fordított idő (a legelső kibocsájtás dátuma szerint, lehet, hogy nem fedi a pontos adatokat): 2.6 < 2.4 < 2.2

Utána arra gondolok, hogy ha egy program forrása mennyi lehetőséget rejt a bonyolultság alapján. Bonyolultság, azaz több modul, csűrt-csavart megoldások, stb.
Egy kis segítség: bonyolultság alapján: 2.2 < 2.4 < 2.6

ezeket mi alapjan feltetelezed? persze ertem, hogy mire gondolsz. kisebb, kevesbe komplex kod, amit regebb ota nyuznak -- kevesebb hibalehetoseg (a tapasztalat egyebkent ezt nem igazolja olyan mertekben, ahogy te azt gondolod. de azt remelem, nem gondoltad komolyan, hogy ami hiba volt, az "mar mind elojott"...
egyebkent meg mindig nem latom, miert lenne biztonsag szempontjabol jobb egy olyan kernel, amiben szarabb a network alrendszer, nincs stateful csomagszuro tamogatas es nem lehet peldaul grsecurity-t tolni ra. persze nem a grsec az egyetlen, csak eppen nincs jelenleg eletkepes alternativaja. jo, van pax, van openwall, van LIDS, van sokminden, csak eppen onmagukban egyik sem versenyezhet a grsecurity-vel (v.ö. kezzel osszehekkelt patchsetek).

[quote:e6d8715990="tomyellow"]Most vagy írtó nagy hülyeséget írok, vagy kiütöm a 2.2 -t a nyeregből ;)
Van a 2.2.x szériában connection-tracking, illetve állapotérzékeny tűzfalszabály, multiport, patch-o-matic?

Nem ütötted ki, inkább csak nem figyelsz. Pl. arra, hogy miről is vitázunk. Nem arról van szó, hogy melyik tud többet, hiszen akkor egyértelműen a 2.6.x lenne a nyerő. Hanem arról, melyik biztonságosabb.

U.i.: Az, hogy nincs "connection tracking" nem feltétlenül baj, némely szervereken manapság is letiltják. Mert mondjuk nincs rá szükség, és csak felesleges biztonsági kockázat.

[quote:ed1bbdbffa="zsirfeka"]ezeket mi alapjan feltetelezed? persze ertem, hogy mire gondolsz. kisebb, kevesbe komplex kod, amit regebb ota nyuznak -- kevesebb hibalehetoseg (a tapasztalat egyebkent ezt nem igazolja olyan mertekben, ahogy te azt gondolod. de azt remelem, nem gondoltad komolyan, hogy ami hiba volt, az "mar mind elojott"...
egyebkent meg mindig nem latom, miert lenne biztonsag szempontjabol jobb egy olyan kernel, amiben szarabb a network alrendszer, nincs stateful csomagszuro tamogatas es nem lehet peldaul grsecurity-t tolni ra. persze nem a grsec az egyetlen, csak eppen nincs jelenleg eletkepes alternativaja. jo, van pax, van openwall, van LIDS, van sokminden, csak eppen onmagukban egyik sem versenyezhet a grsecurity-vel (v.ö. kezzel osszehekkelt patchsetek).

Persze, a hibák lehetséges számánál sarkítottam picit, hogy jobban érzékeltessem a külömbséget. Mindenesetre azt bátran le merem írni, hogy a 2.2.x -es kernek hibáinak nagy része előjött.

Hogy szarabb a network alrendszer, egy ultra-szigorú tűzfal sokat segít, hogy nincs állapottartó tűzfal, az nem mindig baj, fentebb már írtam. Biztonsági patch -ek, szerintem az adott kernelre szóló biztonsági patchek még elérhetőek pár helyen, és talán pár mostanit is rá lehet hekkelni.
Amúgy pedig, egy magára hagyott gépen, amin a root -on kívűl az egyetlen helyi user az admin -é, nem is tudom, milyen patch -ekről beszélünk. Esetleg PaX a memóriavédelemnek, és jól van...

[quote:2b5c7e547c="nevergone"][quote:2b5c7e547c="tomyellow"]Most vagy írtó nagy hülyeséget írok, vagy kiütöm a 2.2 -t a nyeregből ;)
Van a 2.2.x szériában connection-tracking, illetve állapotérzékeny tűzfalszabály, multiport, patch-o-matic?

Nem ütötted ki, inkább csak nem figyelsz. Pl. arra, hogy miről is vitázunk. Nem arról van szó, hogy melyik tud többet, hiszen akkor egyértelműen a 2.6.x lenne a nyerő. Hanem arról, melyik biztonságosabb.

U.i.: Az, hogy nincs "connection tracking" nem feltétlenül baj, némely szervereken manapság is letiltják. Mert mondjuk nincs rá szükség, és csak felesleges biztonsági kockázat.

Szerintem ezek a feature-ök növelik a biztonságot.

[quote:ee3eaf442a="tomyellow"][quote:ee3eaf442a="nevergone"][quote:ee3eaf442a="tomyellow"]Most vagy írtó nagy hülyeséget írok, vagy kiütöm a 2.2 -t a nyeregből ;)
Van a 2.2.x szériában connection-tracking, illetve állapotérzékeny tűzfalszabály, multiport, patch-o-matic?

Nem ütötted ki, inkább csak nem figyelsz. Pl. arra, hogy miről is vitázunk. Nem arról van szó, hogy melyik tud többet, hiszen akkor egyértelműen a 2.6.x lenne a nyerő. Hanem arról, melyik biztonságosabb.

U.i.: Az, hogy nincs "connection tracking" nem feltétlenül baj, némely szervereken manapság is letiltják. Mert mondjuk nincs rá szükség, és csak felesleges biztonsági kockázat.

Szerintem ezek a feature-ök növelik a biztonságot.

Ha valahol nincs szükség állapottartó-tűzfalra, mert nem olyan szolgáltatások futnak, akkor csak felesleges keverés. És így tovább. Gondold végig logikusan.

[quote:645994b68b="nevergone"][quote:645994b68b="tomyellow"][quote:645994b68b="nevergone"][quote:645994b68b="tomyellow"]Most vagy írtó nagy hülyeséget írok, vagy kiütöm a 2.2 -t a nyeregből ;)
Van a 2.2.x szériában connection-tracking, illetve állapotérzékeny tűzfalszabály, multiport, patch-o-matic?

Nem ütötted ki, inkább csak nem figyelsz. Pl. arra, hogy miről is vitázunk. Nem arról van szó, hogy melyik tud többet, hiszen akkor egyértelműen a 2.6.x lenne a nyerő. Hanem arról, melyik biztonságosabb.

U.i.: Az, hogy nincs "connection tracking" nem feltétlenül baj, némely szervereken manapság is letiltják. Mert mondjuk nincs rá szükség, és csak felesleges biztonsági kockázat.

Szerintem ezek a feature-ök növelik a biztonságot.

Ha valahol nincs szükség állapottartó-tűzfalra, mert nem olyan szolgáltatások futnak, akkor csak felesleges keverés. És így tovább. Gondold végig logikusan.

OK! Meggondolatlanul fogalmaztam.
Ezek olyan feature-ök, aminek meglétének/meg nem létének következményit érdemes megvizsgálni biztonsági szempontból.

[quote:13e5bd9a09="tomyellow"]OK! Meggondolatlanul fogalmaztam.
Ezek olyan feature-ök, aminek meglétének/meg nem létének következményit érdemes megvizsgálni biztonsági szempontból.

Ha mondjuk egy szerveren csak ssh szerver fut, akkor szerintem nem feltétlenül előnyös állapottartó tűzfallal, kapcsolatkövetéssel szórakozni. Csak feleslegesen keveri a csomagok útját, bonyolítja a tűzfal működését (és mint tudjuk, a nagyobb bonyolultság több hibalehetőséget hordoz magában), és mint kihasználatlan, szükségtelen, de létező feature, már meglétével is biztonsági kockázatot jelent.

[quote:550ecf0b8d="nevergone"]
Másrészt pedig, ha feltélezzük, hogy egy program forrásának minden 500. sora hibát rejt magában, akkor összességében melyik kernelben lehetséges több hiba?

Ha megjelenik egy uj driver vagy funkcio a kernelben akkor azt kotelezo hasznalni? Vagy szerinted tobbszorosere novekedett mondjuk a tcp stack, meg a scsi alrendszer merete? Vagy hogy van ez? Amit hasznalsz, annak a meretete kb ugyanakkora maradt, senkit nem erdekel hogy hany usb-s vibratorhoz van driver, ha szerverrol van szo.

[quote:550ecf0b8d="nevergone"]
Ha mondjuk arra gondolok, hogy egy program használatala során (a teljes, minden ember által használatra fordított időmennyiség szerint) minden 500. percben kiderül egy hiba, akkor összeségében melyik kernelben lehetséges több hiba?

Az elmeleted alapjan abban amit sokkal tobben hasznalnak?

[quote:550ecf0b8d="nevergone"]
Egy kis segítség: használatra fordított idő (a legelső kibocsájtás dátuma szerint, lehet, hogy nem fedi a pontos adatokat): 2.6 < 2.4 < 2.2

Ja! Es 2.2 < 2.0 < 0.97

Es meg egy kis segitseg: felhasznalok szama: 2.6 < 2.4 >> 2.2
Tehat mivel a 2.4-et ugyan kevesebb ideig hasznaltak mint a 2.2-t, de a 2.4-et nagysagrendekkel tobben mint a 2.2-t, ezert akkor az sokkal securebb?

[quote:550ecf0b8d="nevergone"]
Bonyolultság, azaz több modul, csűrt-csavart megoldások, stb.

Ha mar biztonsagrol van szo, akkor elso lepesben pl ki lehet kapcsolni a modul tamogatast is. Es mint fentebb emlitettem nem kotelezo mindenhez forditani tamogatast, es akkor mar nem tobb modul.

Szerintem kicsit tulegyszerusitetted a dolgokat. Bonyolutsagot meg nem tudom hogy mered, a jelek szerint kodmeretben, de azert vannak az alrendszerek meg a modulok, hogy ne nojjon jelentos mertekben a "bonyolultsag".

Ettol fuggetlenul nem biztos, hogy nem a 2.2 a "legbiztonsagosabb", csak eleg keves ember van aki erdemben tudna az ugyben megszolalni igazi ervekkel.

[quote:a8ff6b5a16="nevergone"][quote:a8ff6b5a16="_Polesz_"]Ne kezdjünk distwar-ba megint.

Ezt én is akartam javasolni... mert ugye a BSD -seknek mindenhova bele kell ugatni... de ez már OFF...

Sziasztok! :roll:

Én kedvelem az "okos fickók"-at :? pláne ha annyira okosak, hogy megmondják nekem:
Miért nem működik több Free BSD verziónál sem a kdm/xdm-en keresztül való bejelentkezés, illetve miért nem indul el egyik kiválasztott ablakkezelő sem?

Tehát :wink: a feladat adott........ :D
Lásd a fórumot is erről :P

Distwar helyett itt lehet megcsillogtatni az "ismereteket" :)

[quote:6fa348d2f0="nevergone"][quote:6fa348d2f0="zsirfeka"]ezeket mi alapjan feltetelezed? persze ertem, hogy mire gondolsz. kisebb, kevesbe komplex kod, amit regebb ota nyuznak -- kevesebb hibalehetoseg (a tapasztalat egyebkent ezt nem igazolja olyan mertekben, ahogy te azt gondolod. de azt remelem, nem gondoltad komolyan, hogy ami hiba volt, az "mar mind elojott"...
egyebkent meg mindig nem latom, miert lenne biztonsag szempontjabol jobb egy olyan kernel, amiben szarabb a network alrendszer, nincs stateful csomagszuro tamogatas es nem lehet peldaul grsecurity-t tolni ra. persze nem a grsec az egyetlen, csak eppen nincs jelenleg eletkepes alternativaja. jo, van pax, van openwall, van LIDS, van sokminden, csak eppen onmagukban egyik sem versenyezhet a grsecurity-vel (v.ö. kezzel osszehekkelt patchsetek).

Persze, a hibák lehetséges számánál sarkítottam picit, hogy jobban érzékeltessem a külömbséget. Mindenesetre azt bátran le merem írni, hogy a 2.2.x -es kernek hibáinak nagy része előjött.

Hogy szarabb a network alrendszer, egy ultra-szigorú tűzfal sokat segít, hogy nincs állapottartó tűzfal, az nem mindig baj, fentebb már írtam. Biztonsági patch -ek, szerintem az adott kernelre szóló biztonsági patchek még elérhetőek pár helyen, és talán pár mostanit is rá lehet hekkelni.
Amúgy pedig, egy magára hagyott gépen, amin a root -on kívűl az egyetlen helyi user az admin -é, nem is tudom, milyen patch -ekről beszélünk. Esetleg PaX a memóriavédelemnek, és jól van...

tenyleg elmegyek favagonak.
magyarazd mar amugy el, hogy a connection tracking ugy megis mifele biztonsagi kockazatot jelent, de tenyleg.

[quote:a0a95db65f="nevergone"][quote:a0a95db65f="tomyellow"]OK! Meggondolatlanul fogalmaztam.
Ezek olyan feature-ök, aminek meglétének/meg nem létének következményit érdemes megvizsgálni biztonsági szempontból.

Ha mondjuk egy szerveren csak ssh szerver fut, akkor szerintem nem feltétlenül előnyös állapottartó tűzfallal, kapcsolatkövetéssel szórakozni. Csak feleslegesen keveri a csomagok útját, bonyolítja a tűzfal működését (és mint tudjuk, a nagyobb bonyolultság több hibalehetőséget hordoz magában), és mint kihasználatlan, szükségtelen, de létező feature, már meglétével is biztonsági kockázatot jelent.

te tudod, hogy mirol beszelsz?

[quote:4b18e2fae5="zsirfeka"] iptables patch-o-matic-el

Ezt megkerdezhetnem, hogy mire jo? Probalok egy otthoni servert minel biztonsagosabbra megcsinalni, 2.6 kernel grsec, pax, pie/ssp (Hardened Gentoo) mar vannak rajta, de errol meg nem hallottam :)

Egyebkent azert 2.6 mert mar tobb mint 1 eve hasznalom desktopon, es eddig semmi problemam nem volt vele. Nincs kedvem mar 2.4-el, devfsd-vel szenvedni :)

Udv.
ProTech

[quote:c1b483a933="ProTech"][quote:c1b483a933="zsirfeka"] iptables patch-o-matic-el

Ezt megkerdezhetnem, hogy mire jo? Probalok egy otthoni servert minel biztonsagosabbra megcsinalni, 2.6 kernel grsec, pax, pie/ssp (Hardened Gentoo) mar vannak rajta, de errol meg nem hallottam :)

Egyebkent azert 2.6 mert mar tobb mint 1 eve hasznalom desktopon, es eddig semmi problemam nem volt vele. Nincs kedvem mar 2.4-el, devfsd-vel szenvedni :)

Udv.
ProTech

csomo olyan netfilter patch, amik (meg) nem kerultek be a mainline kernelbe.

[quote:7b05e48821="prygme"]Melyik kernelszéria a biztonságosabb egy magárahagyott server esetében?

Azaz ha felállítok egy web/ftp servert, akkor az aktuális 2.2.x vagya 2.4.x vagy a 2.6.x kernellel lesz a legkisebb az esélye, hogy kernel bug miatt feltörik? Melyik bírja a legtovább, karbantartás nélkül?
(Természeresen egyéb programcsomagok miatti sebzhetőség itt most nem számít)

Szia!

Ez sok mindentől függ. Pl minden HW-det támogatja-e a 2.2.x. Nem valószínű, de lehet. A másik véglet, ha valami speckó SATA, SCSI, akármi cuccod van, amit csak a 2.6.x támogat, akkor nincs miről beszélni.
Aztán mit csinál a rendszer. Egy egyszerű file-server nem fogja kihasználni a 2.6.x új ütemezőjének előnyeit, viszont egy alkalmazásszerver igen.
Szerintem inkább ezek alapján dönts. Biztonsági különbséget nem nagyon látok a három verzió között. Inkább arra kell figyelni, hogy az ember ne patch-elje agyon a kernelt, mert az sohasem jó. Ami kell, az kell, a többi csak hibalehetőség, ugyanez igaz a konfigurálására is. Konfigurálással, user-space biztonsági eszközökkel lehet egy gépet igazán biztonságosabbá tenni, nem a kernel főverziók váltogatásával.

Persze ez csak magánvélemény.

HTH.
Üdv.: Tomyellow

Hali,

Ez egesz dolog ott borul, hogy csinalsz fogsz egy 2.2-es kernelt, telerakod custom patchekkel, es orulsz.

Aztan egyszer csak jon egy exploit mondjuk 1 ev alatt biztos elofordul, ami erint teged is, mert mondjuk a hardening pecsek sem vedenek meg tole (gyakran elofordul).

Az update 2.2-hoz egy nagysagrenddel kesobb jon ki mint a 2.6-hoz vagy a 2.4-hez. Jo, mondjuk eltelt 2 het es kijott az uj 2.2-es kernel. Akkor mar az csak azt kell megvarnod, hogy az egyedi pecseket updateljek az uj 2.2-es kernelhez. Mivel ezt kevesen hasznaljak, ezert ez szinten elvehet egy kis idot.

Vegul az exploit megjelenese utan 1 honappal mar tudsz is kernelt upgradelni. Hurra! :(

Persze mondhatjatok azt is, hogy a local root exploit az nem szamit, mert nem lesz rajta user, vagy csak olyan amiben megbizol. Ilyen erovel aztan barmit rakhatsz ra.

Azert azt erdemes elkulonitani, hogy profi betoro ellen is akarsz vedekezni, vagy csak a script kiddiek ellen....
Ha otthoni geprol/kis cegrol van szo, mindegy mit hasznalsz. Script kiddie nem jon at rajta, a profi meg ugyis.... Mondjuk keres egy sajat 0-day exploitot. Ez amugy a linux kernel esetben nem tul nehez...

[quote:01efcabcc2="tomyellow"][quote:01efcabcc2="prygme"]Melyik kernelszéria a biztonságosabb egy magárahagyott server esetében?

Azaz ha felállítok egy web/ftp servert, akkor az aktuális 2.2.x vagya 2.4.x vagy a 2.6.x kernellel lesz a legkisebb az esélye, hogy kernel bug miatt feltörik? Melyik bírja a legtovább, karbantartás nélkül?
(Természeresen egyéb programcsomagok miatti sebzhetőség itt most nem számít)

Szia!

Ez sok mindentől függ. Pl minden HW-det támogatja-e a 2.2.x. Nem valószínű, de lehet. A másik véglet, ha valami speckó SATA, SCSI, akármi cuccod van, amit csak a 2.6.x támogat, akkor nincs miről beszélni.
Aztán mit csinál a rendszer. Egy egyszerű file-server nem fogja kihasználni a 2.6.x új ütemezőjének előnyeit, viszont egy alkalmazásszerver igen.
Szerintem inkább ezek alapján dönts. Biztonsági különbséget nem nagyon látok a három verzió között. Inkább arra kell figyelni, hogy az ember ne patch-elje agyon a kernelt, mert az sohasem jó. Ami kell, az kell, a többi csak hibalehetőség, ugyanez igaz a konfigurálására is. Konfigurálással, user-space biztonsági eszközökkel lehet egy gépet igazán biztonságosabbá tenni, nem a kernel főverziók váltogatásával.

Persze ez csak magánvélemény.

HTH.
Üdv.: Tomyellow

Szerintem a 2.2.x -es kernelsorozat a legbiztonságosabb a felsorolt három közül. Egyrészt az kisebb, egyszerübb, kevesebb hibalehetőséget rejt. Másrészt pedig már nagyon régóta "'nyúzzák", tehát ami hiba lehet benne, az már szerintem régen kiderült... :)

Használj valamilyen *BSD-t. s
Svsz. megbízhatóbbak a különböző linux-oknál, amennyiben nem akarsz sokáig hozzányúlni. Telepíteni és konfigoni sem nehezebb, könnyen megtanulható, jó a hw támogaottság (újabb release-ek).
cryp.

+pl. most neztem meg, freebsd handbookban benne van apache config is, (igaz nem tul reszletesen), es egy ftpd config is. konnyn osszehozhato a dolog.
...
cryp

A 2.4 es 2.6 kozott biztonsagi szempontbol nincs nagy kulonbseg, az utobbi 1 evben emlekeim szerint ha volt bug akkor mindkettot erintette. www.isec.pl-en jol lehet kovetni. :)

Magara hagyott szerver eseten eselyed sincs hogy olyan kernelt rakj ra ami fel ev alatt nem lyukasodik ki.

Az egyetlen eselyed ha nyomsz ra grsec-et + nagyon szigoru vagy egyeb helyeken. pl. no local user, minnel kevesebb szolgaltatas, pl. ssh is csak meghatarozott ip-krol, stb., stb. szoval hardening

Es remenykedsz... Egy magara hagyott szerver nem eletbiztositas...

Bar egy jol beallitott grsec ACL-es rendszer sok mindent kibirhat...

[quote:a9e127fa85="crypton"]Használj valamilyen *BSD-t. s
Svsz. megbízhatóbbak a különböző linux-oknál, amennyiben nem akarsz sokáig hozzányúlni. Telepíteni és konfigoni sem nehezebb, könnyen megtanulható, jó a hw támogaottság (újabb release-ek).
cryp.

Ne kezdjünk distwar-ba megint. A kérdés a kernel szériára vonatkozott nem pedig a rendszerre...

2.2.x-es ha a támogatottság meg van mindenhez, de 2.4.x is szóba jöhet.

[quote:16984bdd5e="_Polesz_"]Ne kezdjünk distwar-ba megint.

Ezt én is akartam javasolni... mert ugye a BSD -seknek mindenhova bele kell ugatni... de ez már OFF...

[quote:fac93ee1d5="nevergone"]
Szerintem a 2.2.x -es kernelsorozat a legbiztonságosabb a felsorolt három közül. Egyrészt az kisebb, egyszerübb, kevesebb hibalehetőséget rejt. Másrészt pedig már nagyon régóta "'nyúzzák", tehát ami hiba lehet benne, az már szerintem régen kiderült... :)

Mert a koveto szeriakba szerinted direkt bennehagytak a 2.2 hibakat... ;)
Ugyanolyan forditott kernel eseten szvsz. kevesse valoszinu, hogy biztonsagi elony lenne a 2.2 javara.
Egyaltalan foltozzak meg a 2.2-t?

[quote:a864f6ee7f="Toma_"]Egyaltalan foltozzak meg a 2.2-t?

Mert a koveto szeriakba szerinted direkt bennehagytak a 2.2 hibakat...

Karbantartják, szóval miért ne...? :)
Amúgy pedig szerintem a 2.2 -es széria "már futott annyit", illetve lett tesztelve olyan széleskörűen, hogy nagyon foltozni sem kell.

És a mostanság előkerülő hibák többsége szerintem nem létezett még a 2.2 -ben, lévén eléggé másféle felépítés és tulajdonság jellemzi a 2.2.x -es sorozatot, mondjuk egy 2.6.x -hez viszonyítva.

A mai tamadasok nem igazan Linux-specifikusak, imho ilyen korulmenyek kozott messze biztonsagosabb egy M$-nel barmelyiket is tekintjuk.

Amugy, ha tenyleg az elsodleges szempont egy "magarahagyott" bombabiztos rendszer akkor en a 2.2 fele igyekeznek. :) Persze ha a feature-k az igenyeket kielegitik. Ha megse, es programozas nem all tavol ill. nagyon eletbevago a dolog, akar lehet gyartani meg sajat patch-et az unsupported feature-hoz. Ezert opensource :)

[quote:e62f4ea1a3="nevergone"][quote:e62f4ea1a3="Toma_"]Egyaltalan foltozzak meg a 2.2-t?

Mert a koveto szeriakba szerinted direkt bennehagytak a 2.2 hibakat...

Karbantartják, szóval miért ne...? :)
Amúgy pedig szerintem a 2.2 -es széria "már futott annyit", illetve lett tesztelve olyan széleskörűen, hogy nagyon foltozni sem kell.

És a mostanság előkerülő hibák többsége szerintem nem létezett még a 2.2 -ben, lévén eléggé másféle felépítés és tulajdonság jellemzi a 2.2.x -es sorozatot, mondjuk egy 2.6.x -hez viszonyítva.

csak egy pelda: Linux Kernel Multiple Local MOXA Serial Driver Buffer Overflow Vulnerabilities (http://www.securityfocus.com/bid/12195)
Linux kernels from 2.2, through 2.4, and 2.6 are all reportedly susceptible to these vulnerabilities - es ez csak egy a sok kozul. (az, hogy "ja, de ez csak local", nem valasz)
egyebkent csavarozzad nyugodtan a userspace-t, megfelelo kernelpatchek nelkul ongyilkossag linuxot elesbe kirakni. 2.2-hez pedig lehet oscon mintajara hakkolni, csak nincs ertelme (viszont legalabb leegetheted magad grsec devel listan). en regen ra voltam kenyszeritve 2.2-re egy gepen sokaig, openwall+hap+pax+fp kombot hekkeltem kezzel, baszottul vicces volt uj kernelt rakni (paxbol jott a pagenoexec, openwallbol egyeb cuccok). amit a 2.6-al mostanaban muvelnek, az mar nem is nevetseges, hanem szanalmas, remelhetoleg eszbe kapnak, es nem csinaljak ezt tovabb. imho mission critical helyekre toljal 2.4.x-et grsecurityvel + iptables patch-o-matic-el + normalisan belott acl-ekkel, esetleg meg pie/ssp (bar ehhez ujra kell forgatnod sok mindent) - mondom ezt annak ellenere, hogy tobb eles helyen futtatok 2.6.x-et, gond nelkul. ezek utan johet a tisztessges tuzfal ruleset es a megfeleloen szejjelturt alkalmazasok.

Egyebkent nem kristalytiszta szamomra, hogyan lehet egy web/ftp szerver annyira magarahagyott.. ;)
Brutal passwordos ssh?

[quote:dfafe9d351="Toma_"]Brutal passwordos ssh?

Kulcsauthentikált és ip-korlátozott ssh.

[quote:7c567881a2="Toma_"]Mert a koveto szeriakba szerinted direkt bennehagytak a 2.2 hibakat...

Az azóta belepatkolt dolgok (2.2-ben még nem volt, 2.6-ban már igen), esetleg az azóta újrareszelt részek bugjai?
De szép lenne a világ, ha csak 'bennehagyott' bugok léteznének :) !

[quote:286fcb3024="rigidus"]A mai tamadasok nem igazan Linux-specifikusak, imho ilyen korulmenyek kozott messze biztonsagosabb egy M$-nel barmelyiket is tekintjuk.

te mirol beszelsz?

[quote:9de74d7bc5="gsimon"][quote:9de74d7bc5="Toma_"]Mert a koveto szeriakba szerinted direkt bennehagytak a 2.2 hibakat...

Az azóta belepatkolt dolgok (2.2-ben még nem volt, 2.6-ban már igen), esetleg az azóta újrareszelt részek bugjai?
De szép lenne a világ, ha csak 'bennehagyott' bugok léteznének :) !

Ugyanolyan forditott kernel eseten szvsz. kevesse valoszinu

Probaltam en erre utalni.. ;)

Szerintem még a 2.0.x -es sorozat is elég brutál lehet, és emlékezetem nem csal, még azt is karbantartják... van itt választék, kérem szépen... :)