Root átnevezése, toor, securelevels, chflags, stb.

Kérdés

Egy thread-et olvasva jutott eszembe néhány dolog...

Egyes Windows rendszergazdák esküsznek arra, hogy milyen jó dolog az ``administrator'' account-ot átnevezni valami másra (több helyen is láttam, hogy ez bevált gyakorlat), mert az milyen biztonságos.

A freebsd-security listán merült fel szintén a kérdés, hogy van-e értelme annak, ha valaki átnevezi a root felhasználót. A kérdező arra szeretett volna választ kapni, hogy az uid 0 és a root név milyen kapcsolatban vannak egymással. Az elképzelése az, hogy a kívülről támadóknak sokkal nehezebb a dolguk, ha nem ismerik a rendszer belső felépítését. Szerinte, ha nem létezik a root felhasználó, akkor nem tudják kívülről azt támadni.Egyesek szerint nem jó ötlet átnevezni a root felhasználót, mert az ``security through obscurity'', azaz titkolózáson alapuló biztonság, ami egyes elméletek szerint nem kifizetődő. Ezen kívül előfordulhat, hogy a root felhasználó átnevezése a rendszer hibás működéséhez vezethet. Az egyik válaszoló szerint a legtöbb bináris az uid 0-át ellenőrzi, így az, hogy amellett milyen név áll lényegtelen. Emellett a távoli támadások nagy részének nem kell tudnia a 0-ás uid-dal rendelkező felhasználó nevét, hiszen elegendő csak a nevében futó alkalmazást támadni. A brute force típusú támadások kivédéséhez pedig egyszerűen le kell tiltani a root felhasználóval történő távoli elérés lehetőségét (pl. ssh), vagy felhasználónév/jelszó páros helyett valamilyen más, biztonságosabb megoldást kell alkalmazni (kulccsal, kulccsal+jelszóval történő authentikáció) így az ilyen típusú támadások elkerülhetők.

Vannak olyanok, akik szerint a rendszert legjobb védeni még a root felhasználótól is. Ők a securelevels-re és a chflags-re esküsznek. Az elméletük az, hogy ha a root felhasználó account-ját megtörik, akkor sem tudnak fontos fileokat módosítani a rendszeren a betörők, mert a securelevel és a fileokon állított flag-ek ezt megakadályozzák. Persze erről is megoszlanak a vélemények. Éppen a minap csöppentem bele két HUP olvasó vitatkozásába az IRC-n arról, hogy van-e értelme a securelevels-nek, ha a támadó képes a kernel memóriát közvetlenül manipulálni.

Egy másik listatag szerint a root felhasználó megváltoztatása rossz, ellenben a toor felhasználónak shell-t adni (magyarul engedélyezni) és egyben a root-nak /sbin/nologin
shell-t adni annyira nem elvetélt ötlet. Valaki azt tudakolta, hogy a toor felhasználónak van-e valami létjogosultsága egyáltalán. Valaki szerint nincs.

A thread itt.

A kérdés: neked mi a kedvenc biztonsági intézkedésed?

( mpathy | 2005. 03. 24., cs – 13:19 )

"titkolózáson alapuló biztonság, ami egyes elméletek szerint nem kifizetődő"

Lehet, hogy nem kifizetődő, de az tuti, hogy a mai napig a leghatékonyabb módszer. A legnagyarcúbb krekker, autótolvaj, széffeltörő sem tud mit kezdeni egy számára teljesen ismeretlen 'fekete dobozzal'.

> A legnagyarcúbb krekker, autótolvaj, széffeltörő sem tud mit kezdeni egy számára teljesen ismeretlen 'fekete dobozzal'.

ja, mint a viccben:

mit csinál egy üres szobában 2 db 10 kilós vasgolyóval egy szőke nő?

Az egyiket elveszti, a másikat tönkre teszi!

szóval a "fekete doboz" sincs akkor biztonságban :-D

> Lehet, hogy nem kifizetődő, de az tuti, hogy a mai napig a leghatékonyabb
> módszer. A legnagyarcúbb krekker, autótolvaj, széffeltörő sem tud mit
> kezdeni egy számára teljesen ismeretlen 'fekete dobozzal'.
>
szerintem is. Semmi baj nincs a "security through obscurity"
alkalmazásában, ha nem kizárólag erre épül a biztonság, azaz emellett
rendesen karban is van tartva a renszer

Erro"l jut eszembe az a sztori, amit egyik kolegam mese'lt, hogy vmi. uj kocsi autotolvaj elleni vedelmet akartak tesztelni.

Odahivtak par uberszakit, zsarukat, meg mindent, hogy felvagjon az autogyar vele, milyen frankot alkotott.

Az egyik zsaru, meg ideiglenesen kihozott magaval a sittrol egy, automibilizer foglalkozasban tevekenykedo embert...

Mondta az ipse, hogy az utobbi 1-2 evben nem tudta kovetni a technika haladasat (elvegre a huvosrol jott), de nagyjabol ismeri a gyar gondolkodasat, vedelmi mechanizmusait, stb...

Odament a kocsihoz, es belerugott egyet a lokharitoba szembol...

Kis, apro horpadas, egyebek, meg a lufik felfuvodtak, zar (failsafe modszer miatt) kinyilt...

Beult a kocsiba, kivette a megfelelo biztositekokat, hogy a lufikat visszapakolja, stb. es elhajtott...

Na ennyit a security through obscurity-rol...

MGy wrote:
> Azért én megvizsgálnám a lábát annak az embernek, aki akkorát tud rugni egy
> legalább egy tonnás autóba, hogy elegendőt gyorsuljon, a légzsák
> kinyílásához.
>
> Szóval szerintem urban legend.

Szerintem hiheto a dolog... Talalkoztam mar olyannal, hogy tul paranoiasra volt
allitva a legzsak erzekeloje :))

De szerintem ez jelen esetben offtopic...


IroNiQ
--
Member of Frugalware Developer Team
Web: http://www.ironiq.hu
LinuxCounter: #331532

Krisztian VASAS wrote:
> Szerintem hiheto a dolog... Talalkoztam mar olyannal, hogy tul paranoiasra
> volt
> allitva a legzsak erzekeloje :))
Itt szerintem arról van szó, hogy a légzsákok kinyílását nem mechanikai
behatásra (ütközésre), hanem egy adott mértékű sebességváltozás
túllépése indítja be.

Ezt pedig igen nehezen lehet "triggerelni" lábbal.

Ezt a sztorit en mas kiadasban hallottam: A kerdeses gyar a Mercedes volt, az ajtok tuz eseten nyiltak, es a hoerzekelohoz eleg volt ongyujtoval melegiteni a megfelelo pontot. Es termeszetesen nem tudott vele elhajtani a manusz, "csak" kinyitni.

Aztan lehet, hogy ez is UL

Ez egyszeri alkalom, vagy többszöri?

Ha többszöri, akkor milyen gyakori?

Ha nagyon gyakori, akkor honnan tudja, hogy melyik az utolsó olyan szalagos mentés amely még nem tartalmaz módosított adatokat a bekövetkezett kompromitáció óta?

Miből következteti ki a kompromitáció időpontját?

...

;-)

Az IRC-n arról volt szó, hogy egy kihasználható kernel bugnál legtöbbször nincs értelme securelevelnek és hasonlóknak... A kernel bug a mai napig a Jolly Joker. Monolitikus kerneleknél a legtöbb esetben garantált ring0, ahol aztán mindegy, hogy hogyan védekezel, mert ilyen privilégiummal bármit lehet írni/olvasni.

minden portot megnyitom az ssh -t atrakom egy random portra az osszes nem szolgáltatást nyújtó port ssh nak valja magát de csak 1 az igaz

Jézusom! Ezt ugye a kardhal vagy valami hasonló hacker filmből vetted?

és mivel egy vers pár sorra a jelszavam (nem mindig ugyanaz a vers) ezért a brut force eseélyét csekélynek tartom....

Komoly hacker ritkán használ brute force-t, jelszó feltörésre pedig gyakorlatilag sosem.

mindent chroot ba futatok ...

húha!

egy külön head shell be futatom a web servert ... ami direkt kamuzik a hackernek... pl az apache az thttpd a linux az openbsd stb...

Na ez az igazi "Security Through Obscurity"... Nem mondom, egy Script Kiddiet lehet, hogy megtévesztesz vele, de ugye, nem azoktól tartasz?

És nálam se a root usere kell su zni :P van root user is de annak nem 0 az uid je ...

Nehéz lehet az /etc/passwd-ből kideríteni, hogy melyik usernek van 0 uidje... ;-P

ja és csak 1 bizonyos ipről lehett bekerülni...

és azaz 1 bizonyos ip-n lévő gép mennyire biztonságos? ;)

hunger wrote:
> Az IRC-n arról volt szó, hogy egy kihasználható kernel bugnál legtöbbször
> nincs értelme securelevelnek és hasonlóknak... A kernel bug a mai napig a
> Jolly Joker. Monolitikus kerneleknél a legtöbb esetben garantált ring0,
> ahol aztán mindegy, hogy hogyan védekezel, mert ilyen privilégiummal bármit
> lehet írni/olvasni.
Egyetértek. De nem is írtam mást :)

_Jol_ mukodo szalagos mentest latott mar valaki? A problemak amikkel talakozni szoktam mint kulsos:

- mentenek a szalagra, de mikor vissza kellene allitani altalaban: hibas a szalag, a backup visszaallitas leall ismeretlen hibaval

- a mentoszoftverek nagy reszenek _jo_ beallitasa tobb napos munka (a patchre telepits patchet, a service pack-re hotfix-et), ha egyszer beall akkor altalaban mukodik, de van amikor tobb vele a baj, mint ami a haszna

- a kereskedelmi mentoszoftverek es a jo szalagos eszkozok kib. dragak, de cserebe legalabb jo bugosak (probalt mar valaki A**se*ve-vel Exchange-et bricklevel szinten lementeni? a lementes meg tobbnyire megy, na de a visszaallitas?), nem ritka. hogy a backup fennakad, es csak nagy buveszkedesek aran lehet leloni (van, hogy csak a reboot segit)

- lattam mar sok-sok millio forintos tape library-t is szarul mukodni

Szoval nekem nem jok a tapasztalataim a szalagos mentessel. Itt most nem a ``csinalok egy tar.gz-t, aztan kitolom az /dev/st0-ra''-rol beszelek, hanem az advanced mentesrol inkabb.

Szerintem lehet, hogy arban es teljeseitmenyben is jobbat lehet kihozni egy SATA tombbol.

Kinek mi a velemenye?

Akkor elkapnak, elvisznek, es radkotnek egy hazugsagvizsgalo gepet es kerdeznek: a jelszoban van nagy betu? van a jelszoban szam? es igy tovabb :-) Vagy addig utnek, mig el nem arulod. Ne gondold, hogy a geped biztonsagban van csak azert, mert esetleg jol beconfigoltad - irl is fel kell tudni mutatni valamit :-))))))

Tape sux sajnos, az arcserve kifejezetten foobar, anno nem is volt 2000 kompatibilis, es azt mondta, hogy license expired. Annyit meg hozzatennek, hogy az exchange helyreallitas amugy is remenytelen, akarmivel is szandekozol visszaallitani :-) Sok hely kell hozza, de nekem eddig bevalt, hogy tar.gz -> /dev/st0, visszatolt, es ellenorzes.

Én láttam _elég_ jól működőt többet is.

Alapfeltétel, hogy az elején nagyon gondold át, és jól méretezz.

Ezt sokszor eltolják.

Az általad elmített hibákat mind láttam már...

De nem lehet mit tenni. Le kell menteni kb 2tb adatot, és archiválni is kell. Mi más van?

SATA tömb nem jó. Nagyon macerás az archiválás.

Meg kell a mentési hardverre support szerződés. Mert meg fog halni 2 perccel a garancia lejárata után.

Ez egyszeri alkalom, vagy többszöri?

Ha többszöri, akkor milyen gyakori?

olyan rendszereken ami adatot nem tárol heti.

Ha nagyon gyakori, akkor honnan tudja, hogy melyik az utolsó olyan szalagos mentés amely még nem tartalmaz módosított adatokat a bekövetkezett kompromitáció óta?

Miből következteti ki a kompromitáció időpontját?

...

Ez nem a mentési rendszer dolga. Erre ott vannak a tripwire jellegű cuccok, meg a debsums.

De ha nagyon vérzik az agyam, akkor visszaállítok 4 verziót aztán elkezdek checksumolni :)

> Jut eszembe, Arcserve-ből még nem láttam normálisan működőt.

Akkor mar ketten vagyunk. Bar ismerek olyan embert, aki szerint egyszer sikerult neki es team-jenek hosszu hetek munkajaval egy _jol_ mukodo Arc-ot Netware ala osszeallitani, ami sokaig mukodott. Persze a makja az volt, hogy sose kellett hozzanyulnia a backup szalagokhoz. A szalagos backuppal az a bej, hogy ritkan szoktak ellenorizni, es tuti mindig olyankor szarik be, amikor baj van.

> HP Openview Data Protectorból

Lattam (inkabb hallottam) en mar ilyet is nem _jol_ mukodni nem is olyan reg. HP EVA-t kellene menteni vele, a szoftver hozza sok misi nagysagrend, es nem is biztos, hogy bugmentes. Van hozza szupport, de kerdem en, tudod milyen supportok vannak itthon? 90% rotfl, persze tisztelet a kivetelnek. A napokban kellemensen csalodtam egy supportban :-)

> Szerintem egy raid tömb winyói gyakrabban mennek egyszerre tönkre, mint hogy külön külön.

Ha ez igy lenne, akkor ember nem epitene RAID tombot. Ertelmetlen lenne. Ki venne RAID-et, ha tudna, hogy nagy esellyel egyszerre mennek tonkre benne a lemezek? A RAID lenyege, hogy valoszinuleg NEM egyszerre mennek tonkre benne a lemezek...

Altalaban ezek kulon gepek, masik epuletben, gigabit halozaton osszekotve.

Tonkremegy a diszk. Lattal mar olyat, hogy online spare? Tudod mire valo? Beszarik a lemez, es a spare-ek mar ugranak is be helyettuk. Automatikusan rebiuild-el. Az ilyen gepekben a kontrollerek redundanssa tehetok, tehat ha az egyik elhal a masik mar veszi is at a szerepet.

A cucc levelet kuld, masnak reggel csereled a kiesett lemezt, a betett diszk ujra online spare. Mivel a SATA olcso, veszek egy szekerderek diszket, aztan cserelgetem ha kell. Nem olcso ***** softraid-rol beszeltem, hanem spec. berendezesekrol (storage).

Amit írtál, azzal megyőztél, de ha egy épület leég, akkor az összes gép leég a gigabites hálóval együtt.

Az offsite-t épületen kívüliként értettem, mint ahogy az eredeti hozzászólásban is szerepelt.

Írom mindezt azért, mert meglehetősen ritka, hogy egy intézménynek (rendszernek) több épülete legyen. :-)

Persze ha az általad vázolt rendszert két különböző épület között feszítjük ki gigabites hálóra (pl. egyetemváros kül. épületei),

akkor már tényleg feleslegessé válhat a backup, de ez az esetek nagyon elenyésző százaléka.

Az egyszerre tönkremenést, 2 winyós RAID1 -re értettem. Ez pedig a RAID egyik legelterjedtebb alkalmazása, szerintem.

Amivel szembesültem is 1x. Akkor egy offsite backup mentette meg. Igaz ünnepek miatt 2 hetes volt, de volt.

A tapasztalat: a backup szalagok altalaban a szerverszobaban, a szerver tetejen helyezkednek el. 100 esetbol 96-ban. En meg nem tapasztaltam (ettol meg lehet) olyat, hogy a rendszergazda azt mondja, ``mingya' jovok, mert a pancelbol hozom a szalagokat.

A tape library ha leeg akkor mit csinalsz? Abbol nem szokas kikapkodni a szalagokat. Kb. annyi az eselye mint annak, hogy a storage leeg. A szalagos egyseggel szemben viszont kisebb az eselye annak, hogy merevlemezrol nem tudsz adatot visszaallitani, mert a celluloid szalagrol lepergett a vasoxid (lol). Komoly storage-ot akar km-ekre is teheted a szervertol. Mi van ha gazrobbanas van? Vagy atomtamadas. Robbansz a szalaggal. Akkor mar interkontinentalis clustert kell epiteni :-D lehet ezt fokozni.

> mert meglehetősen ritka, hogy egy intézménynek (rendszernek) több épülete legyen. :-)

Igen? En nagyon sokkal talakozok... Korhazak, iskolak, stb.

> Ez pedig a RAID egyik legelterjedtebb alkalmazása, szerintem.

Tevedsz. Legalabbis nagyvallalati kornyezetben biztosan nem.

"Jézusom! Ezt ugye a kardhal vagy valami hasonló hacker filmből vetted?"

Nem kerem. Ez teny Kevin Mitnick el folytatott levelezes eredmenye ... Ha nem tudod mit lattsz nem lattsz semmit...

"Komoly hacker ritkán használ brute force-t, jelszó feltörésre pedig gyakorlatilag sosem."

Ez igaz ;) de ne kell brute force egy sniffeleshez ...

"Na ez az igazi "Security Through Obscurity"... Nem mondom, egy Script Kiddiet lehet, hogy megtévesztesz vele, de ugye, nem azoktól tartasz?"

Oke adok 1 ip t es lehett probalkozni ...

Ha barmire jutsz lada sor repul... Egyebkent ez eleg regota kint van a weboldalamon is ...

"Nehéz lehet az /etc/passwd-ből kideríteni, hogy melyik usernek van 0 uidje... ;-P"

Es ugyan melyik chroot ot szeded vissza ?:) mert mindegyik be van passwd csak masik :D

"és azaz 1 bizonyos ip-n lévő gép mennyire biztonságos? ;)"

Haat mivel az ipjet se arulom el ezert elegge :D Egyebkent kiegeszitettem a rendszert sms t kell kuldeni hogy melyik porton legyen nem kamu ssh... Mas reszrol draga hunger eddigi tapasztalatom az hogy te valami ms berenc lehettsz

nos igen ha nekem ajanlja fel valaki azt a penzt akkor szabad :P de a particiok termeszetesen titkositottak ... Igy adott kulcs nelkul meg se fel se kepes bootolni a rendszer ... Na ez nem paranolya csak ovatossag ha remenyeim szerint ujra rendorok szeretnenek rola olvasni..

( BaliHB | 2005. 03. 27., v – 22:05 )

Ahogy azt kevin bácsitól is tudhassuk a rendszernek a legritkább esetben sem a rendszer maga a gyenge pontja, hanem az ember. A hülye titkárnő, aki kiadja telefonon a jelszót és stb. Szóval alap védelemm és hozzáértő felhasználók és egy nagyobb rendszer is különösebb nehézségek nélkül védhető, anélkül, hogy folyamatosan belebotlanánk a magunk állította gátakba.

Szal szerintem ennyi. És akkor nem kell azzal vacakolni, hogy elfelejtetted a root nevét...

Amit a szallagokról írsz, teljesen igazad van.

Én a szerver háta mögötti ócska faszekrényben, műanyag tokban láttam Solaris backup-szallagokat heverni :-)

Ha nincs több millioja a cégnek egy altad írt storage-re, akkor a visszaellenőrzött és titkosított DVD lemezek magunkal cipelése is elegendő lehet szerintem. Most már csupán 13eFt-ért. Visszafelé is lehet fokozni a történetet :-)

> Igen? En nagyon sokkal talakozok... Korhazak, iskolak, stb.

> Tevedsz. Legalabbis nagyvallalati kornyezetben biztosan nem.

Egészségügy, oktatás?

Most pont nem sztájkolnak, de valószínűleg ők azok a MÁVon kívül, akik legjobban panaszkodnak a pénzhiányra.

Pesze ettől még igazad van, mert láttam én is egészségügyi centrumokban, egyetemeken miliárdos költségvetési hiány mellett milliós beruházásokat, de továbbra is fenntartom, hogy bár a legprofibb megoldást javaslod, de ez csupán az esetek elenyésző százaléka.

Még azt is meg merem kockáztatni, hogy a magyarországi nagyválalatok / intézmények túlnyomó többségének informatikai rendszere mindössze egyetlen épületre korlátozódik. A kis és középválalkozások pedig jóval nagyobb piac.

SZVSZ aki tudja csinálja, de az esetek tulnyomó többségében ez nem megoldás!

( crown v | 2005. 03. 24., cs – 12:01 )

Ha a rendszer stabilitasat nem fenyegeti, egy kis plusz biztonsag sosem arthat.

( bra | 2005. 03. 24., cs – 12:19 )

Micskó Gábor wrote:
> erről is megoszlanak a vélemények. Éppen a minap csöppentem bele két HUP
> olvasó vitatkozásába az IRC-n arról, hogy van-e értelme a securelevelsnek,
> ha a támadó képes a kernel memóriát közvetlenül manipulálni.
A securelevel emelése többek között erre is hivatott védelmet nyújtani.
Persze ha nem nyújt, akkor minek, de ahhoz már hiba kell, tehát ez
mindenképpen egy plusz szint.

( uid_1062 | 2005. 03. 24., cs – 12:24 )

Kedvenc biztonsági intézkedésem... Hmm. Lássuk:

Kiveszem a szalagot a meghajtóból és átviszem a másik épületben lévő tűzálló szekrénybe.

( Névtelen (nem ellenőrzött) | 2005. 03. 24., cs – 12:46 )

minden portot megnyitom az ssh -t atrakom egy random portra az osszes nem szolgáltatást nyújtó port ssh nak valja magát de csak 1 az igaz... és mivel egy vers pár sorra a jelszavam (nem mindig ugyanaz a vers) ezért a brut force eseélyét csekélynek tartom.... mindent chroot ba futatok ... egy külön head shell be futatom a web servert ... ami direkt kamuzik a hackernek... pl az apache az thttpd a linux az openbsd stb... Ezen felul hamisitom a tcp fejlécet ... van még pár apróság pl sms küldés mikor valaki loginol vagy ha a cron előre nem várt processt látt futtni ... ennél többet én em tehetek.... És nálam se a root usere kell su zni :P van root user is de annak nem 0 az uid je ... ja és csak 1 bizonyos ipről lehett bekerülni... és eloőtte sms t kell küldeni a gépnek egy adott telefonszámról egy dátum koddal ha másik gépről akarok belépni...

nagyjából ennyi ...