Názory k článku Oddělte od sebe uživatele serveru Apache a PHP
-
caracho (neregistrovaný)
je tu s nami minimalne od verze php3, co si pamatuju, tak nevim, co autor na tom povazuje za moderniho. Spis je smutne, jestli ji driv neznal.
Taky, kdyz uz se bavi o bezpecnosti php, bylo by vhodne se zminit o projektech jako suoshin, ktere jsou dnes v nekterych distrech uz standardem.
-
Moderní ve smyslu, že safe_mode je deprecated a open_basedir ne.
Suoshin jsem neznal. Hostuju hlavně pythoní projekty a PHP jsem byl nucen nasadit kvůli některým známým a jejich WordPressům. Jeho bezpečnost jsem řešil velmi dlouho, ale řekl bych že ne moc efektivně, nakonec jsem se dostal k řešení popsané v článku.
Budu rád, když Suoshin rozvedete trochu víc, ať už v této diskusi nebo v samostatném článku, o který bychom určitě měli zájem.
-
. (neregistrovaný)
Chtěl jsem to přejít jen tak s pocitem „achjo“, ale když už jste to tady tak pěkně vypíchl… My víme, že tomu nerozumíte, vy to taky víte, ale stejně o tom musíte psát?
[Co na vedení víte tak hrozného, že vám to prochází? A co ví korektorka? A co programátoři? Všichni jste se v tomhle článku zase pěkně ukázali.]
-
Polish (neregistrovaný)
; open_basedir, if set, limits all file operations to the defined directory
; and below. This directive makes most sense if used in a per-directory
; or per-virtualhost web server configuration file. This directive is
; *NOT* affected by whether Safe Mode is turned On or Off.; NOTE: this is considered a „broken“ security measure.
; Applications relying on this feature will not recieve full
; support by the security team. For more information please
; see /usr/share/doc/php5-common/README.Debian.security
;;open_basedir =
-
Apache je moc pomalý? Já nehostuju žádný web, který by vytrhával procesory z desky, takže volím spíše pohodlnost nad efektivitou. Rozdíl mezi lighttpd (či jiným light web serverem) a apachem bude řádově v jednotkách procent a za to to fakt nestojí. Stejně většina času procesoru na jeden požadavek končí ve zpracování samotného webu.
-
Rozdíl poznáš, soukromě ti pošlu skript.
Vtip je v tom, že úzké hrdlo Apache není procesorový čas (alespoň u dobře napsané aplikace) ne, ale spotřeba paměti.
V době, když Apache posílá odpověď nějakému klientovi na pomalé lince (takže třeba několik sekund), tak jedno vlákno drží obsazenou celou paměť potřebnou k vyřízení požadavku – a že jí není málo.
Kolegovi takhle omylem vznikl docela elegantní DoS útok na web.
-
Láďa (neregistrovaný)
Nesmysl, alespoň u popsaného řešení s FastCGI. Pokud se zbavíte PHP jako modulu, tak můžete bez problému nasadit mod_worker, který paměti spotřebovává několikanásobně méně. Samozřejmě, pořád to bude víc, než například Nginx, ale jestli to bude 10 nebo 50MB je pro většinu nasazení už nepodstatně.
-
Palo (neregistrovaný)
HAHAHA to je vazne jednothreadovy? Tak to vam rovno poviem ze tam kde bude vo vykone vyhravat lighthttp nema zmysel lebo rovnako dobre to poriesi aj apache a zacne prudko stracat pri zatazi na ukor klientov nie stroja. Pocitace su od toho aby pocitali. Co ked je proc v zatazi 80% – no problem na to tam je. A ten lighthttp efektivnejsi nebude.
-
Michal Vyskočil (neregistrovaný)
Není lepší si o lighttpd něco přečíst aspoň na wikipedii, než potom plácat takové komentáře? On thready umí, jenom prostě nespouští thread pro každý request.
Jeho chování odpovídají první dvě IO strategie popsané v http://www.kegel.com/c10k.html
-
ondrej (neregistrovaný)
Taky pouzivam mod-itk. Je to mnohem lepsi protoze se to neresi jen na urovni PHP, ale taky apache. Treba s CGI je problem ze dany VHost bezi pod jednim uzivatelem a php pod druhym. Takze treba kdyz pod PHP vytvorite soubor, tak neni na 100% jiste ze k nemu bude mit pristup apache.
-
tatra (neregistrovaný)
Diky autorovi za clanek, mel bych vsak jednu celkem vyznamnou poznamku k modulu mod_fcgid. Module se vyborne konfiguruje, ale ma zasadni nevyhodu. Pokud puzijete nejaky opcode cache pro php (napr APC), ktery vyuziva sdilenou pamet pro ulozeni zkopimlovaneho kodu, mod_fcgid pri startovani vice angel php procesu zpusobi, ze kazdy takovy angel proces bude mit vlastni sdilenou pamet ⇒ mrhani prostredky, snizeni efektivity opcode cache. Tohle by slo obejit direktivou pro mod_fcgid MaxProcessCount 1, ovsem tady narazime na drasticke snizeni vykonu, jelikoz mod pak neni schopen paralelne obsluhovat vice pozadavku (staci provest zakladni test pomoci http_load). Resenim je uplne se vyhnout mod_fcgid a nasadit mod_fastcgi, ktery je slozitejsi na konfiguraci, ale umoznuje beh statickych (lokalni/externi), dynamickych aplikaci. Pro max stabilitu s APC doporucuji staticke aplikace. Tohle reseni je spise vhodne pro projekty, kde bezi maly pocet narocnych aplikaci co do poctu pozadavku za jednotku casu. U statickych aplikaci se nastartuje konstatni pocet angel php procesu, ktery je v case nemeny.
-
open_basedir na systémoch ako FreeBSD, Windows, … pri PHP 5.2 > spôsobuje dosť dramatické zníženie rýchlosti. Na túto tému som našiel dosť threadov na nete a žiadne konkrétne riešenie, dokonca priamo som zachytil niekde reakciu PHP-čkarov, že PHP je primárne ladené pre linuxové systémy a ostatné ich momentálne netrápi.
Takže na FreeBSD odporúčam jednoznačne MOD_FCGID + eAccelerator.
A keď som písal o dramatickom znížení výkonu pri open_basedir PHP5, tak samozrejme najviac sa strácalo pri Includovaní a prístup k súborom. Dovtedy plne funkčné aplikácie (e-shop, …) dosahovali v PHP5 (FreeBSD) 5–8× dlhšie časy ako v PHP4.
-
echo zulu (neregistrovaný)
Podľa mňa je článok dostatočne zaujímavý. Ak aj nepopisuje všetko do detailu, ani to od takéhoto článku nečakám. Úplne mi stačí, keď sa niečo nové dozviem a potom si to už do detailu dohľadám. No a samozrejme diskusie, tie sú asi na tomto všetkom najinšpiratívnejšie.
Riešili ste niekto opačný problém? Ako zabezpečiť vlastnú databázu na hostingu, či už zdieľanom, vyhradenom alebo virtuálnom, pred pracovníkmi samotného hostingu?
Čakal by som, že to bude pomerne bežný problém, veď predsa nikto asi nechce, aby sa mu niekto cudzí hrabal v jeho dátach, ale nejaké jednoznačné tipy nenachádzam, tak si hovorím, že či sa to vôbec dá.
-
echo zulu (neregistrovaný)
Rozviesť čo? Technické riešenie? To nepoznám a možno ani neexistuje :)
Z hľadiska potrieb je to v podstate idea postavená na paranoji, že keď niečo budujete, môže to byť zaujímavé pre niekoho iného, zvlášt pre niekoho, komu to vy osobne nechcete dať.
Príkladom môže byť nejaká nekomerčná komunita, ktorá potrebuje nejaké miesto, kde funguje. To, že je nekomerčná je rozhodnutie členov, no aj tak by sa mohla dať speňažiť a to napriek vôli členov, treťou osobou, ktorá má k údajom prístup. Napríklad osobné údaje členov, kontakty na nich, história komunikácie, atď.
Prístup k akýmkoľvek údajom majú správcovia hostingu. Nerád by som sa dostal k nejakému paušalizovaniu alebo podozrievaniu, no hovorí sa, že príležitosť robí zlodeja a ideálna preto by podľa mňa bola možnosť takúto príležitosť nedávať nejakým technickým opatrením, ak by existovalo.
No a ako prípadný prevádzkovateľ musíte riešiť, že či to teda pôjde na nejakom lacnejšom hostingu s rizikom, že sa to nedá zabezpečiť alebo či to pôjde na vlastnom serveri, ktorý si musíte dodať a niekde fyzicky umiestniť a už vás to bude stáť o niečo viac ako málo, pričom, keďže je to nekomerčné, peniaze sa nevrátia a musíte to dotovať.
Neviem ako sa to berie v tejto dobe, keď Facebook tvrdí, že súkromie nepotrebujete, ale naivne mám tendenciu myslieť si, že ľudia neradi dávajú niekomu to, čo nemusia a tak si, opäť naivne, myslím, že s podobným problémom musí bojovať veľa začínajúcich nadšencov, ktorí riešia dilemu v zmysle: buď si to poriadne zaplatím a nevráti sa mi to, alebo za to zaplatím menej, nevráti sa mi toho menej, ale do mojich dát bude mať možnosť vidieť aj ten, kto nechcem.
-
BLEK. (neregistrovaný)
100% bezpečně to neuděláš. Můžeš ta data před uložením do databáze třeba šifrovat, ale ty šifrovací klíče budeš mít na tom samém počítači, takže ti je správce stejně bude moct přečíst.
Tohle se dá řešit pouze technikou nazvanou „security through obscurity“ — čili to ukládání dat udělat tak složité, že se správci nebude chtít se s tím analyzovat a dekódovat to.
Obecná knihovna na ukládání dat způsobem „security through obscurity“ není a ani z principu existovat nemůže — kdyby někdo takovou knihovnu udělal, tak by někdo jiný napsal proti tomu protiútok, takže ty bys sice data pomocí knihovny zakódoval bez práce, ale zloděj by je stejně tak bez práce dekódoval.
Musíš prostě sám vymyslet a napsat nějakou metodu, jak ta data zakódovat, a naprogramovat ho způsobem, aby se to špatně četlo (ideální by byla binárka bez zdrojáků, kdyby se tam dala spustit), a doufat, že ta data nemají takovou cenu, aby správci hostingu stálo za to se s tím piplat. Pokud se s tím bude chtít piplat (např. tu binárku disassemblovat), stejně ti to prolomí.
-
BLEK. (neregistrovaný)
No, tu databázi v prvé řadě potřebuješ chránit před uživateli z internetu. Čili koncové šifrování/dešifrování celé databáze u uživatele v browseru nepřipadá v úvahu. Z té spousty návštěvníků tvého webu se určitě najde jeden, který se v tom bude chtít povrtat, dokázat, jak je to nebezpečné, a šifrování v browseru ti rozbije.
Když to budeš kódovaně ukládat do databáze na tom hostingu, tak musíš spoléhat na to, že k tomu má přístup omezený počet lidí, ne všichni umí assembler a ne všichni mají tendenci strávit několik dní na to, aby se v tom vrtali. Nic lepšího ti nezbývá, když si nechceš platit vlasní fyzický server.
I když použiješ vlastní server, tak ti stejně provozovatel v tvé nepřítomnosti může rozlomit skříň a do toho serveru strčit PCI kartu, která mu za běhu vyjede obsah paměti, ani to nepoznáš. Ale zase je to o dost dražší a nebezpečnější než šmírování na sdíleném serveru (navíc, kdyby se provalilo, že to nějaký provozovatel udělal, tak skončí). Můžeš předpokládat, že ti to provozovatel udělá jen tehdy, jsou-li ta data extrémně cenná nebo trpíš-li extrémní paranoiou.
-
„do toho serveru strčit PCI kartu“
Jde tohle udělat za chodu? S restartem si toho člověk samozřejmě všimne (a bez restartu asi taky, že přibylo nějaké nové zařízení).Šifrování v DB mi přijde trochu na nic, protože se ty data nedají indexovat a pořádně v nich vyhledávat. To už je zajímavější šifrování celého disku, jenže pak tam člověk musí osobně při každém (re)startu serveru (protože vzdálenou konsoli může poskytovatel odposlouchávat).
-
BLEK. (neregistrovaný)
Ta PCI karta nemusí odpovídat na konfigurační přístupy a může přesto požadovat bus-master — čili nebude vidět ve výpisu PCI zařízení, ale paměť bude schopna přečíst. Podle specifikace PCI se karta za běhu do počítače strčit nesmí, což ovšem neimplikuje, že to nemůže nikdy fungovat.
-
Jak už tu někdo psal… a co root exploity? V okamžiku, kdy dáte uživateli možnost spouštět na serveru binárky, nebo loadovat do PHP knihovny, tak dříve nebo později získá server dalšího nechtěného administrátora.
Když už tu byla zmínka o pythonu, zajímalo by mě, jak byste vytvořili bezpečný hosting například právě pro python. Tedy skriptovací jazyk, který není primárně určen pro webhostingové nasazení. Dva způsoby, které mě napadají jsou vytvoření „safe_mode“ patche na vm pythonu a zabránění tak spouštění cizího kódu, nebo co uživatel to vlastní virtuální server.
Pro PHP existuje právě safe_mode, který zakazuje veškeré nebezpečné funkce z pohledu administrátora serveru. Sice stále může dojít k nějakému tomu „přetečení zásobníku“, ale to může i u apache samotného, nebo jiné služby na serveru. Od toho je tu administrátor, aby si hlídal vydané bezpečnostní opravy a včas je aplikoval.
-
BLEK. (neregistrovaný)
Proti těm root exploitům: shodit SUID u všech programů. Zkompilovat si vlastní kernel a zakázat v něm všechno, co nepotřebuješ (nepoužívat kernely z distribucí, protože ty obsahují spoustu serepatiček, které ti na hostingu na nic nejsou, a v nichž ty exploity bývají). Pak to bude bezpečné.
-
to same resi treba i suphp (http://www.suphp.org/Home.html). Funguje jako modul web servera.
Osobne mi pride optimalnejsi pouzivat neco, co je k tomu primo napsane, jako volat sve bash skripty. I z hlediska performance je to minimalne o proces pro kazdy nacitani stranky mene.
Kazdopadne – reseni jsi popsal hezky.
