LAMP++

Amit egy Linuxos webszerverből (ésszerű határok közt) ki lehet hozni az itt megtalálható.

Kapcsolódó oldalak

Címkék

apache (8) backup (1) blog (1) cache (1) chroot (4) cms (1) daemontools (2) ddos (1) djb (1) dns (2) dos (1) email (1) geoip (1) google (2) ip (1) kvm (1) lamp (1) linux (1) mail (1) mysql (4) nginx (3) pdumpfs (1) php (8) pound (1) proxy (2) regcheck (1) seo (2) shell (1) shorewall (1) snapshot (1) spl (1) ssl (1) statisztika (1) szerver (1) thttpd (1) tinydns (1) tűzfal (1) ubuntu (1) virtualizáció (1) wordpress (2) Címkefelhő

Utolsó kommentek

  • aFoP: Írtam bash szkriptet ami a fent letölthető hu.csv-ből legenerálja az összes hálózat-címet, így már... (2014.04.26. 10:51) Magyar IP tartományok
  • Oszi: A JPEG support -hoz nem árt még ez is: --with-jpeg-dir=/usr/include (2009.06.08. 10:52) PHP fordítás
  • Oszi: @bagoj ur: OK, össze szedem magam és blogba vésem amit tudok. Hamarosan... (2009.03.05. 20:18) Virtualizáció KVM -el
  • Utolsó 20

Feedek

Chroot - bevezetés

2008.08.27. 15:36 Oszi

Mi is az a chroot és mire jó?

Alapesetben egy alkalmazás mindenhez hozzáfér, amihez az őt futtató user hozzáférhet. Ezt lehet leszűkíteni chroot alkalmazásával.
Linuxokon ez nem túl bonyolult dolog, vagy magának az alkalmazásnak van ilyen beépített lehetősége, vagy pedig a chroot parancsal lehet megoldani (ez mindig működik).

A jó chroot csak azt a minimumot tartalmazza, ami kell az adott alkalmazás futtatásához. Általában ez okozza a problémát is vele, nem mindig egyszerű összeszedni, hogy mi is az a minimum...

Mit érdemes chroot -ba rakni és mit nem?

  • Webes alkalmazás-szerver: mindenképp. Tulajdonképpen ez a lényeg, itt esik be a legtöbb kérés és mivel mindenhonnan elérhetőnek kell lennie nemnagyon lehet másképp védeni.
  • Web proxy: nem árt. Picit kapcsolódik az elöbbihez és elég könnyű megvalósítani.
  • Adatbázis-szerver: általában nem kell. Ha az adatbázis-szerver nem érhető el kívülről akkor szerintem nem szükséges chroot -olni.
  • Távoli elérés, SSH, FTP: user szintű chroot szükséges. Ezeknél magát az alkalmazást nem, viszont a belépett felhasználót mindenképp egy adott (user függő) helyre célszerű zárni. Mivel ezeknek a szolgáltatásoknak általában nem kell, hogy mindenhonnna elérhetőek legyenek, ezért tűzfallal is elég jól lehet őket védeni.
  • Levelezés: lehet. Általában minden webszervernek kell tudni levelet küldeni és fogadni, úgyhogy nem árt ide is némi + védelem.

Chroot -hoz először is kell egy könyvtár, az új gyökér helye. Ezen belül kell létrehozni azt a minimális könyvtárstruktúrát ami az alkalmazásoknak kell. Az alkalmazás-szerver (Apache) és a proxy szerver (nginx) ugyan abba a könyvtárba (/var/www) lesz chroot -olva, de természetessen különböző user nevében futnak.
Mivel a /var olyan opciokkal van felmountolva, hogy nem engedi meg fájlok futtatását ezért közvetlenül nem lehet a chroot alá bemásolni a futtatandó fájlokat. A legegyszerűbb megoldás RAM diszkek alkalmazása erre a célra. (Ha valaki sajnálja a memóriát akkor másik partícióról néhány könyvtár be bind mount -olása is megoldás.) Természetessen a RAM diszkek tartalmát célszerű valahol a hdd -n is megőrizni és boot után a helyére másolni. Ilyen feladatokra jó az /etc/rc.local script (ez alapbol üres és tetszőlegessen bővíthető).

Részletes leírás a chroot létrehozásához a wikiben található.

A következő részekben először az nginx, majd pedig az apache chroot -jának részleteiről lesz szó.

Szólj hozzá!

Címkék: chroot

A bejegyzés trackback címe:

https://lamp.blog.hu/api/trackback/id/tr38636203

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása