Virtuális (web)szerverek feladatai

Virtualizáció

Sziasztok!

Van egy szerverünk (24 processzor, 16GB memória, ...stb), amin szeretnénk létrehozni a webfejlesztő vállalkozásunknak virtuális gépeket. Az elmúlt években egy gép szolgált ki mindent (apach, mysql, ..stb), de most ezeket szeparálni szeretnénk.

A koncepciónk egyelőre ott tart, hogy lesz egy adatbázis szerver, egy éles "kód" szerver és egy teszt "kód" szerver. Abban viszont nem tudunk napirendre térni és nem is találunk hozzá best practice leírást, hogy a honlapokra a megrendelők és felhasználók által ftp-vel és böngészőből feltöltött fájlok (képek a galériákba és cikkekhez, letölthető dokumentumok, ..stb) egy külön virutális szerveren legyenek-e. Szerintem biztonsági szempontból fontos lenne, lévén, hogy ki tudja mit töltenek fel, no meg az ftp sem a legbiztonságosabb dolog. Ti mit tanácsoltok?

Köszi,
karpatil

  • 9926 megtekintés

( janoszen v | 2012. 10. 11., cs – 14:34 )

Ha nem akartok kulsosoket beengedni ra, nezzetek meg az LXCt. Ubuntu alatt egeszen jol mukodik, kb 3 perc munkaigenye van es elegge lighweight virtualizacio. Annyi hatulutoje van, hogy meg nem tud minden limitet megfeleloen kezelni, ergo ha szigoru hatarokat akartok szabni, akkor OpenVZ vagy valami mas.

Ami a feltoltest illeti, ha komolyan gondoljatok a webfejlesztest, akkor vezessetek be egy verziokoveto es egy deployment rendszert is, ami kezeli a valtozasokat illetve tud rollbackelni, ha szar van a palacsintaban.

Ezen felul termeszetesen biztonsagi mentesekre is szuksegetek lesz valami offsite helyre, idealisan naponta. Erre a feladatra nezzetek meg a Baculat.

Ami a webszervert illeti, a vhostokat vagy kezeljetek konfiguracio-menedzsmentbol (pl. Puppet) vagy keszitsetek egyforma templateket a vhostoknak. Ha lehet, akkor alkalmazzatok privilege separationt, tehat minden weboldal sajat user alatt fusson. Ha PHP-ban utaztok, akkor PHP-FPM lesz az idealis megoldas.

Ha teszel fel konkretabb kerdest, kapsz kevesbe generikus valaszt is. :)

Anno probaltam en is, alapvetoen szimpatikus, de egy csunya problema miatt lemondtam rola. Ha beallitottam memoria limitet a containernek es azt kitoltotte, akkor a host olyan szinten kezdett el swapelni, hogy megallt az elet. Azota boldog xen felhasznalok vagyunk. :)

_Konkretan_ _az_, hogy _minmalis_ _swap_ _hasznalatnal_ _megolt_ _mindent_. Ez nem valid mukodes. Es nem irtam swap limitet. Mielott valaszolsz olvasd el, hogy mire valaszolsz. Megneztem ugyanazt a VM-et LXC-ben, KVM-ben es XEN alatt is. Teljesitmeny es megbizhatosag alapjan XEN, KVM es LXC a csokkeno sorrend.

Megneztem. Amit te irsz, az netto hujeseg:

Egyik:
# ps ax|wc -l
749

# free
total used free shared buffers cached
Mem: 32940000 30558312 2381688 0 1805256 13072976
-/+ buffers/cache: 15680080 17259920
Swap: 4194300 685696 3508604

Aktiv swap hasznalat mellett koszoni jol van.
Zimbra, apache, tomcat instance-ok, mysql 12 db kontenerben.

Masik:

# ps ax|wc -l
1288

~# free
total used free shared buffers cached
Mem: 132033560 128585304 3448256 0 3513876 91948808
-/+ buffers/cache: 33122620 98910940
Swap: 9764860 537264 9227596

Itt meg van mellette nehany kvm gep is.
Ezen vegkepp rengeteg szi-szar, jo reszuk vmilyen java szarmazek.

Gondolkoztal azon, hogy ha nem adsz neki memoriat, akkor a swap-ot nagyon aktivan fogja hasznalni? Okos...
Igen, meglepoen lassu tud lenni a HDD.

Az LXC igazabol nem is tudja befolyasolni, hogy mit csinaljon a program, az nem tudja kinyirni a gepet, azt csinalja, amit egyebkent is.

tompos

Helló,

Köszi a tanácsokat, a legtöbb dolog, verziókezelő, backup-ok, ...stb, megvan már, mert van bennük tapasztalatunk az elmúlt sok évnek köszönhetően. Amiben viszont nincs és erre vonatkozóan próbáltam a kérdést megfogalmazni, az az, hogy ha lehetőségünk van szeparálni a szervereket, akkor azt minek mentén tegyük (adatbázis-,tesz-,éles-,upload/kép- szerver ...stb), különösen, hogy kell-e külön "upload" szerver. De már ez is kezd körvonalazódni a többi válasznak (is) hála.

Köszi,
karpatil

Ha minden projektnek kulon szervert akartok, akkor az sok melo es igazabol nem fog akkora security elonyt hozni. En inkabb arra figyelnek, hogy meglegyen a privilege separation, tehat minden lenyeges komponens kulon userkent fusson es a fileok permissionjei rendben legyenek.

Ami az FTP-t illeti, csinaljatok egy upload scriptet, ami elrakja a fileokat a megfelelo helyre.

En epp, hogy projektenkent szetszednem. Jo a biztonsagnak is es jo a rendszer karbantartasa szempontjabol is, mivel a projekteket egymastol fuggetlenul lehet kezelni (pl. a sec. modell alkalmazas szempontjabol, extensionok, jogosultsagok...stb.).

A kepfeltoltes egy huszadrangu kerdes, ha a rendszer tobbi komponense helyesen van beallitva, ill. eleve azok meghatarozhatjak.

tompos

Nekem ebbol az ellenkezoje derul ki, azaz megoldott, legalabbis egyelore "workaround" segitsegevel.

En ugy tudom egyebkent, h a checkpoint kornyeken meg tobbmindent is kell csinalni, mintha nemreg lett volna thread errol a levlistajukon. De mar talan valoban kozel jarnak hozza.

Egyebkent az konkretan ma volt a listan, hogy mar nagyon kozel jarnak ahhoz, h userkent futtathato legyen egy-egy container, ami nagy josag lenne. Azzal pl. megoldhato lenne a per container szintu max. process number szabalyozas. Bar elvileg mar vhol a mainline kernel eloszobajaban van a patch ahhoz is, h ez meglehessen cgroup szinten is.

tompos

Igen, kozel jarnak, de meg kell a munka oda. En hasznalok LXC-t eleg aktivan es en is belefutok idonkent olyan dolgokba, amik kellemetlenul erintenek. Plusz tenyleg tobb melo egy rakas kontenert karban tartani, mint egy vasat. Mar ha csak arra gondolok, hanyszor kellett valamelyik containeremet ujrainditani random security fix miatt, vagy foglalkozni vele, hogy tobb disket adjak, stb stb.

less /usr/share/doc/lxc/TODO.Debian
lxc:
* add a lxc-config script similar to git-config.
* clear tty and enable them dynamically
* enable console log by default and rotate them if necessary
* add debconf multi-select for autostarts in /etc/lxc/auto
* extend README.Debian to include all information from http://wiki.progress-linux.org/software/lxc/
* update package description
* expose lxc-setcap run with debconf
* integrate example debian packages that contain /usr/share/lxc/cache/*
* add debconf question to ask for level of mac conflict check
* support 'all' in lxc convenience wrapper
* add a lxc-reboot command
* add a timeout to lxc-halt after which the container is forcefully stopped
* since the required kernel patches will not make it to wheezy,
add a watchdog so that containers are started again after a reboot/halt
* add lxc-console script as valid shell so that that unprivleged users can
access lxc containers on the host
* add lxc 'control' user with sudo magics so that unprivileged users can
start/stop/restart/create/destroy their containers

lxc-debconf:
* if invoked as lxc-debconf, ask for mode (debian, progress, ubuntu, etc.)
* allow to have templates (that do not get modified) in /etc/lxc/debconf
* write preseed file into /etc/lxc/debconf after lxc-debconf is done
* create /etc/lxc/{debian,progress} and respect it depending on mode
* add a warning when building squeeze but no live-config 3.x in /usr/share/lxc
* allow using architecture=auto
* save last used IP, use this +1 as default for next container
* add manpage
* handle mac (arp; local; etc.)
* guess bridge device
* get rid of /bin/bash
* use same perseeds as d-i does
* check that veth-foo is not overly long
* don't embedd lxc config, use a template from etc

---------------------------------------------------------------------------------------------------------------
http://l.bitcasa.com/Bbw1wOii

( eax | 2012. 10. 11., cs – 14:44 )

"a honlapokra a megrendelők és felhasználók által ftp-vel és böngészőből feltöltött fájlok (képek a galériákba és cikkekhez, letölthető dokumentumok, ..stb) egy külön virutális szerveren legyenek-e"

Ha a szoftveretek ezt tudja kezelni, akkor biztonsagi szempontbol nem rossz otlet.

( Fisher v | 2012. 10. 11., cs – 14:48 )

Első körben a 16G memória igen kevésnek tűnik.

Második körben az ftp nem azért veszélyes, mert törölni tudnak fájlokat (bár úgy is meg lehet csinálni, hogy ezért is veszélyes legyen :)), hanem mert alapból titkosítatlan az adatátvitel (pl. az usernév-jelszó is). Lehet külön gépre tenni, és ha ragaszkodtok az ftp-hez (sajnos az ügyfelek miatt néha tényleg muszáj), akkor érdmes pl. write-only ftp beállításokat csinálni, így bármit is töltenek fel, se törölni nem tudják, se mások nem tudják ellopni. És ehhez mondjuk sql authetntikációt, olyan usernév-jelszó párossal, ami mondjuk egy nap múlva lejár, és az ügyfélnek újat kell kérnie mondjuk egy https-es felületen.

A külön szerveren tárolt statikus tartalom amúgy se balgaság, könnyebben lehet cdn-né alakítani, illetve esetleg meglévő cdn szolgáltatást eléhegeszteni.

A felötltött adatokra aztán már lehet tetszés szerinti víruskeresőt ráengedni.

És igen, menteni, menteni, menteni :)

( gabrielakos v | 2012. 10. 11., cs – 18:13 )

"ki tudja mit töltenek fel": ez milyen szinten számít? (kit érdekel?)

A válasz attól is függ hogy mit féltesz:
- a szerver többi részét
- a feltöltött adatokat

Ha a szervert félted, akkor tedd egy külön virtuális gépre, ahonnét elviszed az adatokat máshova.

Ftp-ről szerintem kb. lehetetlen a usereket leszoktatni, pedig egy scponly hozzáférés mennyivel szebb lenne.

--
Gábriel Ákos
http://i-logic.hu

a szerver többi részét és a feltöltött adatokat is féltem :)

nyilván az előbbit jobban, mert ha jól tudom van az az alapelv, hogyha megtörik a szervert akkor nem érdemes foltozgatni, hanem fel kell húzni egy teljesen újat. ha csak egy "kép szervert" törnek meg azt kisebb meló újrarakni mint egy teljeset, amin van apache, git, meg még ezer dolog.

( legyes | 2012. 10. 12., p – 09:01 )

Szerintem a "24 processzor" valójában 2 darab 12 magos (AMD?) CPU vagy talán 4 darab 6 magos, esetleg 2darab 6 magos HT-vel. Inkább az előbbi. Ha valóban 24 proci van benne, akkor legalább 160GB memóriát akartál írni :)

Ami a jogosultságokat illeti, jó ki leírások vannak arról a neten, hogyan tehetsz kicsit biztonságosabbá szervert php-fcgi finomhangolások, chroot, jail és társai. Ha egy virtuális gépet megtörnek, azon rajta lesz a hozzáférés a többi géphez is, szal' a halottnak a szenteltvíz. Ha meg Google alapú a hack (konkrét PHP tartalomkezelő verzióra jön a támadás), akkor csak egy konkrét dolgot fog hazavágni. Az ilyen hack is általában a fájlfeltöltésen (kép feltöltésen is, mert EXIF infoban is lehet PHP scriptet futtatni) alapul. Leggyakrabban a TinyMCE/(F)CKeditor-t és társait használják fel.

A konkrétan rád irányuló hackelések esetén pedig minden VM ki lesz nyírva, hisz' a webszerver fájlkiszolgálón (amin nyilván először jutnak be) ott van az elérés az adatbázisokhoz, stb-stb.

[OFF] Nem semmi webes fejlesztés lehet, ha ilyen vas kell alá, én dolgozom 10k+ napi látogatottságú oldallal, és egy ősi dual-core Xeon-on röhögve megy online képátméretezésekkel, SATA RAID-el [/OFF]

Szerkeszteni akartam a hozzászólásom, de kis pity-puty történt:

+

Szerintem a "24 processzor" valójában 2 darab 12 magos (AMD?) CPU vagy talán 4 darab 6 magos, esetleg 2darab 6 magos HT-vel. Inkább az előbbi. Ha valóban 24 proci van benne, akkor legalább 160GB memóriát akartál írni :)

Ami a jogosultságokat illeti, jó ki leírások vannak arról a neten, hogyan tehetsz kicsit biztonságosabbá szervert php-fcgi finomhangolások, chroot, jail és társai. Ha egy virtuális gépet megtörnek, azon rajta lesz a hozzáférés a többi géphez is, szal' a halottnak a szenteltvíz. Ha meg Google alapú a hack (konkrét PHP tartalomkezelő verzióra jön a támadás), akkor csak egy konkrét dolgot fog hazavágni. Az ilyen hack is általában a fájlfeltöltésen (kép feltöltésen is, mert EXIF infoban is lehet PHP scriptet futtatni) alapul. Leggyakrabban a TinyMCE/(F)CKeditor-t és társait használják fel.

A konkrétan rád irányuló hackelések esetén pedig minden VM ki lesz nyírva, hisz' a webszerver fájlkiszolgálón (amin nyilván először jutnak be) ott van az elérés az adatbázisokhoz, stb-stb.

[OFF] Nem semmi webes fejlesztés lehet, ha ilyen vas kell alá, én dolgozom 10k+ napi látogatottságú oldallal, és egy ősi dual-core Xeon-on röhögve megy online képátméretezésekkel, SATA RAID-el [/OFF]

Amin én dolgozom, ott úgy oldották meg, hogy:

1. Internet
2. Mikrotik router/tűzfal/VPN (távmanagement csakis VPN-ben, csakis bizonyos IP tartományokból)
3. web load balancer server
4. webszerverek, amik igazából csak a CPU-t adják
5. MySQL master és slave szerverek
6. NFS file storage+backup

Bizonságilag minden webes mappa tartalma egy másik Linux user tulajdona, ami fcgi-vel van megoldva. A logolás syslog szerverre, csak INSERT engedélyezett.

Remélem találsz benne valami hasznos dolgot. Sok sikert, majd érdekelne hogyan oldottad meg, én is épp most kezdek neki egy ilyen projektnek.