Názory k článku
Oddělte od sebe uživatele serveru Apache a PHP

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.

To musite vzdy pred napisanim clanku urobit sutaz o najlepsieho v danej oblasti a v pripade ze nevyhrate nemate narok? A co v pripade ze ten kto vyhra nechce pisat? Ma to svoje uskalia. Zostanme pri tom ze kazdy moze pisat co chce pokial neuraza ineho.

Nemusi byt nejlepsi, staci kdyz neni spatny. Tady autor trochu informaci o suexec _opet_ podaval s omackou hloupych a nesmyslnych vet, okorenou spatnym vyjadrovanim, neschopnosti hlaskovat a rozhozenym formatovanim. To po case omrzi.

vim, ze je to 2 roky pryc, ale priste si takovy clanek piste sam, rad si poctu Vy "chytraku".

Misto konstruktivni kritiky pouze rejpate a sam jste nic nedokazal. Takovahle premoudrela stvoreni primo miluji :/

No, zrovna tentokrat vedle neni. Na funkcni open_basedir vsichni PHPckari cekali jako prase na drbani. Na levnych hostinzich je totiz dostatecny a potom staci jen mit na souborech gid apache, g+ws a je to „skoro“ bezpecne. Alespon tolik jako nenavideny safe_mode.

buď konkrétní, nebo zticha

Suoshin? To bude docela honka psat o necem takovem clanek a vy jste zrejme linej pouzit Google.

Když tak už Suhosin, suoshin neznám.

; 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.securi­ty
;

;open_basedir =

Dotaz – kdyz uz se rozhodnu pro fcgi, proc Apache a ne neco rychlejsiho?

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.

A co teda misto Apache? lighttpd? nginx?

Lighttpd nebo Cherokee.

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ě.

Hmm, taky mam pocit, ze od urciteho poctu pozadavku a jader v systemu by vykon apache mel byt vyssi, nez napriklad u lighttpd, kteryzto je jednovlaknovy…

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.

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

Protože v případě (relativně) pomalého interpretru PHP je rychlost webserveru zanedbatelná.

A co oblibeny .htaccess v adresari, nekteri uzivatele bez nej neumeji zit, rewrite taky, ale ten myslim funguje

lighttpd ma hodne plus. Problem je zmineny .htaccess v jednotlivych adresarich. Pro velke hostingy hodne tezko resitelne …

17th March, 2009: Suoshin PHP Log Parsing

Tenable's Research group recently added support for logs generated by PHP servers modified to make use of the Suoshin security enhancements. Suoshin blocks many SQL injection and other web application attacks.

treba suphp, mpm-itk

mpm-itk pouzivam a zatim spokojenost – sice o neco pomalejsi, ale kdyz nekdo nepotrebuje 100% vykon, tak to staci

Na menší instalace je určitě mpm-itk výrazně jednodušší ke konfiguraci.

Taky pouzivam mpm-itk a zatim jsem spokojeny. Akorat mi stve, ze vytvoreny soubor apachem nededi nastavena rozsirena souborova posix ACL. Nemate s tim nekdo zkusenosti ? Nicim jinym v tom adresari nejsem schopen vytvorit soubor, aby ty acl nemel nastaveny.

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.

suphp je zoufale nevýkonné…

Volili jsme nedávno a podle všeho fcgid+suexec jsou prostĕ nejrychlejší

> $ sudo sudo chmod 750 /home/webuser

jedno sudo přebývá

> <Directory /home/florball/www>

nemělo by tam být místo „florball“ raději „webuser“?

Raději ano, opravil jsem, děkuji za upozornění.

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.

a co suexec modul do apachu?
(neberme do uvahy ze utocnik moze exploitnut http proces a setuid-nut sa na root-a)

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ív­nejš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á.

Myslím, že jediné řešení tohoto problému je vlastní server

Neda

Ale dá…

Zajímavé…nicméně představit si to nedokážu. Můžete to rozvést?

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.

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í.

K čemu nějaké disassemblování BLEKu?

Buď ten server budeme používat jako skladiště dat a e2e šifrování se děje mimo (jsou nahraní), anebo jsme neználci a oni nás dostanou tím, že si tam pustí třeba tcpdump a vědí, co teče k nám i od nás…

No, tu databázi v prvé řadě potřebuješ chránit před uživateli z internetu. Čili koncové šifrování/deši­frová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).

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.

Vypadá to, že vám redakční systém nesežral podtržítka, a interpretoval je jako označení zvýrazněného textu. Prosím, opravte.

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é.

Zajímalo by mě, zda-li je článek originál? Jeví se mi to jako docela nepovedený překlad.

Potíž v suPHP je to, že je neuvěřitelně pomalé…dokonce 10–50× pomalejší než klasické PHP, FastCGI se ke klasickému mod_php celkem blíží… Je to tak měsíc, co jsem to benchmarkoval, protože jsme řešili, co nasadit… mpm-itk z toho taky nevyšlo nějak dobře…

Koukam, ze to formatovani a preklepy porad nikoho netankuji…

Kdyby jen preklepy. Napriklad radku:

$ sudo cd …

povazuju za vrchol optimismu.

podarilo se nekomu zprovoznit FastCGI + mod_deflate (gzip)? Narazil jsem, ze to spolu udajne moc dobre nechodi a me se nepodarilo vubec funkcnosti docilit gzipu pres FastCGI (vsude nastaveny, ale pres mod_fastcgi to neposila v gzipu).