Názory k článku Nebezpečné webhostingy II

U prvního dílu jsem se ještě držel, čekal jsem totiž, že se tím druhým autor rehabilituje a vše zlé bude zapomenuto. Nestalo se tak a na zázrak v podobě třetího dílu čekat nehodlám. Autor, nebo někdo z Lupy, by se zde měl rozepsat o cílové skupině seriálu, protože z obsahu článků to není patrné a s případnou kritikou to úzce souvisí. Měl-li být určený laikům, jak tvrdí autor v komentářích pod prvním dílem, pak mám několik výhrad:

1) Termíny, obraty a slovní spojení

"konfigurace (…) ovlivňuje integritu sdílených dat"
S pojmem "integrita sdílených dat" se zde setkáme hned dvakrát, aniž by bylo vysvětleno co přesně tím autor myslí. Například pro mě jsou sdílenými daty soubory v adresářích icons nebo error, tedy soubory, které správce systému určil jako sdílené. Jaká data má na mysli autor? Všechna, která jsou přístupná s právy uživatele, pod kterým běží Apache? Dále tu máme to slovo integrita, tedy česky celistvost. Pokud útočník kompletně smaže celý obsah adresáře s mou webovou prezentací, integritu dat nijak nenarušil. Nejde o slovíčkaření, ale o poukázání na vágnost pojmů používaných autorem.

"mass virtual hosting"
S tímto pojmem jsem se setkal poprvé, co teprve chudák laik. Nicméně podle Google se takto označují hostingy, kde se jednotlivé virtuální servery zakládají bez nutnosti ručního zásahu do konfiguračních souborů webserveru. Podle článků i diskusí je seriál zaměřen právě na tento typ hostingu. Takže se nezbytně musím zeptat, proč tomu tak je, co si pod tímto pojmem představuje autor a zda je to důležité ve vztahu k informacím obsaženým v článcích. Na svém serveru používám modul mod_vhost_alias, ale příslušné adresáře pro prezentace zakládám ručně - jedná se nebo nejedná o mass virtual hosting? Které další techniky spadají do autorovi představy o "mass"? Ale především: jsou ohroženy všechny virtuální hostingy, nebo jen ty "mass"? Pojem virtuální hosting je sice široký, ale zato jasný. "Mass virtual hosting" nutně musí být jeho podskupinou. Má toto rozlišení význam z pohledu autorem popisovaných bezpečnostních rizik?

"… neboť PHP, tedy dynamický skriptovací jazyk, jimž je …"
Skutečně je nutné informovat čtenáře, že PHP je "dynamický skriptovací jazyk"? A mohl byste jen na okraj a pro zajímavost uvést jediný dynamický jazyk, který by zároveň nebyl skriptovací?

"lokální exploit"
Nejdřív máte potřebu vysvětlovat co jste myslel slovy "root" a "shell", ale slovo exploit necháte bez vysvětlení. Navíc jste si neodpustil "lokální", ačkoliv je to z předchozího textu více než zřejmé. Pokud někdo ví, co je to exploit, ví také, že jste měl na mysli lokální. Pokud to ale neví, přidání slova lokální mu vůbec nijak nepomůže. Zase jsme u té cílové skupiny. Pro účely takového článku by použité slovo "snadno" stačilo, ale "pomocí volně dostupného lokálního exploitu", zní určitě více dramaticky.

Jistě se shodneme na tom, že jsou tyto mé výtky přísné a nepodstatné, ale mám neodbytný pocit, že právě těmito obraty, jakoby si chtěl autor pomoci k vytvoření dojmu odbornosti textu. Ale jako základ pro knihu "Jak blufovat o bezpečnosti" to na druhou stranu není zlé.

2) Nepřesné a zavádějící informace

"… aplikace lze instalovat buď přímo ze zdrojových kódů, nebo pomocí binárních balíčků, v lepším případě pak jsou standardní součástí používané distribuce."
Tady trochu mícháte jablka s hruškami: je-li program kompilován a následně instalován, nebo je rovnou instalován z připravených binárek je jedna věc a jestli je nebo není standardní součástí distribuce, je zase věc druhá. A to v "lepším případě" si příště laskavě nechte od cesty. Akorát nám matete veřejnost, pane inženýre. :-))

"Instaloval-li správce systému PHP ze zdrojových kódů, můžeme v řádku s názvem Configure Command vidět konfigurační direktivy, se kterými byla aplikace zkompilována."
Zda funkce phpinfo() vrací nebo nevrací informaci o konfiguračním skriptu a jeho parametrech nijak nesouvisí se způsobem, jakým bylo PHP nainstalováno. Navíc mi termín "konfigurační direktiva" pro označení parametru skriptu přijde trošku nešťastný a hlavně matoucí, vzhledem k tomu, že to samé označení dále používáte pro skutečné PHP direktivy jako např. "safe_mode".

Asi nejhorší je předposlední odstavec, ve kterém nejdřív vyjmenujete direktivy, které by měly pomoci zabezpečit PHP bežící jako modul Apache a pak napíšete toto:

"Zdaleka ne všechny se hodí k nasazení na mass virtual hosting a jsou určeny pro PHP v podobě modulu Apache, jsou zde uvedeny pouze pro názornost a lepší pochopení toho, k čemu tato rozšíření slouží."
To opravdu nemůžete myslet vážně. A pak to dorazíte větou:

"Běží-li tedy PHP jako modul, alespoň jedno z výše uvedených rozšíření byste měli v přehledu funkce phpinfo() nalézt."
Jak mi mod_cgi pomůže k vyšší bezpečnosti skriptů běžících pod mod_php5? To bude asi jeden z těch modulů jen pro názornost a lepší pochopení… A to už se nezmiňuji o tom, že obecně samotné zavedení modulu do Apache ještě mnoho neznamená, ve výsledku záleží hlavně na dalších souvisejících nastaveních v jeho konfiguračních souborech.

3) Tlachání kolem

Zábavné jsou povídačky o tom, jak je funkce phpinfo() nenápadná (2x), jak se nemáme nechat mýlit a jak její výstup vzbuzuje obdiv. Další perly jen telegraficky:

• "Jak známo, z chyb se člověk učí"
• "Vyznáte-li se alespoň trochu v Linuxu, pak zajisté víte, že…"

Závěr

Já nezpochybňuji vaše odborné znalosti, jen schopnost se o ně podělit se čtenáři Lupy.

Tento clanek je naprosty BRAK, stejne jako prechozi dil.

1. dil -> pan megasuperborec a master hacker Klubal "hackl" nejake webhostingy, ou !

2. dil -> nektere webhostingy jsou "potencionalne" nebezpecne. Co nazvy celosvetove nejznamejsich bezpecnostnich modulu na tom zmeni?

3. dil -> laicky popis 3 konfiguracnich direktiv (open_basedir, safe_mode, allow_url_fopen) - jako by k tomu cele ty roky neexistovala dokumentace a nebylo v kvalitnejsich operacnich systemech jako napr. FreeBSD zmineno, ze safe_mode nic neresi a ze na open_basedir se nelze spolehat.

--------------------------------------------------------
Toto neni serial, nybrz odflaknuty a laidacky clanek pro
nactilete deti ze soom.cz, ktery se autor rozhodl rosekat
umele na 2 casti, pripsat pred to nic nerikajici uvod a prodat to na Lupu jako "3 dilny serial o bezpecnosti shared webhostingu".

Kolik jste testoval počítačů? Kolika firem? Kolik tyto firmy mají strojů? Jaké firmy to byly (nemusíte uvádět, které prošly a které ne, ať zůstane přijatelná úroveň utajení)?

Nabyl jsem dojmu, že prezentujete pouze svůj názor a k žádnému testování ani nemuselo dojít. To je trochu málo na Lupu.

Navíc jste jako autor nový, skoro anonymní, informace o vás žádné nejsou. O co chcete své názory opřít?

Můžete prosím udělat aspoň stručnou statistiku? Je zjevné, že někteří diskutující mají bohaté zkušenosti (není důvod jim nevěřit) a mají zcela odlišný názor na stav českých webhostingů. Já sám jsem si tyto direktivy na svém webhostingu ověřil. Kromě direktivy POSIX (která podle diskuze není tak důležitá jak uvádíte) je vše v pořádku. Znamená to, že je můj hosting bezpečný nebo to neznamená nic. Je takový webhosting v bezpečí alespoň před vámi (z článku jsem to nepochopil a diskuze mluví jasně proti vám).

Bez čísel, jmen a konkrétních příkladů je váš článek zajímavý, ale bohužel TOTÁLNĚ BEZCENNÝ. Můžete mu tedy nějakou váhu dát doplněním chybějících informací? Jsme přece na lupě, to není čtení jen tak pro nějaké uživatele co si zakládají blog. Lupu čtou spíš webdesigneři, kteří pak vybírají hosting pro klienty. Nemyslíte? To co tu napíšete by mělo být jednoznačné, doložitelné čísly... opřené o statistiku. Kde jsou ta čísla?

S takovymi klienty kteri tomu nerozumi komunikuji dnes a denne a verte mi tem vas clanek urcite nepomuze, spis v nich vyvolate jen paniku.

Jenže Ti kterým jak tvrdíš, že je článek určen se z něho dozvědí ledatak kulový...... možná jednu desetinu toho co by potřebovali vědět, k tomu aby byli schopni alespoň rámcově posoudit kvalitu zabezpečení hostingu......takže Tvůj článek je na hovno jak obyčejným uživatelům tak dejme tomu středně poučeným odborníkům....no a Ti co tomu rozumnějí :):):):):):):):):):):):)

Pokud něco najdu, tak se zeptám a oni mi buď vysvětlí, že je to v pořádku nebo se na to sami podívají. Když nic nenajdu, budu dál spokojený, že jsem zvolil kvalitní hosting.

Myslim, ze to je presne neco proc tak jako jeden ze ctenaru vyse povazuji tyto clanky za nebezpecne - cekam, ze par ctenaru ted obepise sve hostery a zacne resit jak nebezpecne konfigurace provozuji, prip. se spokoji s tim ze podle schemat ktera pouziva autor neni jejich hosting "nebezpecny" a ziskaji falesny pocit bezpeci.

Ne kazdy je nadan aby publikoval clanky, proto je taky spousta lidi nepise. Ale ocividne se tu pomerne dost lidi zabyva administraci, proto je cela rada kritizujicich komentaru relevantni a naopak reakce typu "tak napiste neco lepsiho" zcela irelevantni. Jednak je pomerne dost pravdepodobne, ze za clanky dostal autor zaplaceno, takze bych take predpokladal kvalitni praci, a jednak nepovazuji jakykoliv stek napsany od kdejakeho patlala bez poradne praxe za kvalitni jen protoze "si dal tu praci ze to napsal", to je prece naprosto nesmyslna argumentace. Pro Lupu ma tato "serie" clanku ale super vyhodu - protoze jsou to tak otresne blaboly, prilaka to celou radu lidi, kteri budou sledovat diskusi a prectou si to.

> Toto neni serial, nybrz odflaknuty a laidacky clanek pro...

NAPROSTÝ SOUHLAS !!!!

Autor je proste 21 lety kluk, ktery si mysli, ze skrz putty a svuj nove nainstallovany KUbuntu server (asi se pozvracim - pardon - neni mi od vcera dobre, jelikoz jsem zkonzumoval mnoho piva) cR4X0rN3 vsecicky serfery na interfernetu.

Pro pana kolegu autora:

Mam pro Vas navrh - udelam Vam ucet na mem serveru, sice to neni klasicky webhosting a pouzivam ho pouze pro nase klienty, ale zato mi muzete otestovat vsechny sluzby, ktere jen najdete. Takovy ten Vas tuzkovy test - nebo je to perovy test?

Jinak strucne - mam tam:

open_basedir = $home_of_web
allow_url_fopen = Off
a taky dalsi tyto nesmysly
mod_security21
mod_doseavasive
/etc/passwd 640 root wheel
weby maji 701 kvuli tomu ze ve FreeBSD nejde apache pridavat do skupin do nekonecna
apache ma zmeneny header
mam tam rkhuntera a dalsi nesmysly
zkousel jsem i portsentry, ale z toho se mi chce taky zvracet
samozrejme ze tam mam suexec a zakazane funkce exec a spol v php
Mam X desitek skriptu, ktere simuluji shell v php a perlu a ktere se mi tam turci snazi dostat - uz se tomu smeju.

Jesli pan autor bude schopen mi ten server sundat jinak nez DDoSem tak ma u me basu piv!

Hele ja te nechci trapit draku, staci proste jenom priznat, ze je okurkovka a ze kdybys prelozil nejaky jiny clanek o zabezpeceni webhostingu z anglictiny, tak jsi udelal pro komunitu mnohem vice. Je videt, ze lidi si tu proste mysli, ze tomu nerozumis. Jak rikam - udelam ti ucet u me na serveru ktery se mimochodem jmenuje boxtokill - coz jiste pochopis proc - a muzes se ukazat. Neni problem. Muzes sem pak vpastit vsechno co najdes a treba mi to nekdo sunda jeste lepsim zpusobem nez ty ;o))) Pohoda - my tu jen tak blabolime - chapeme, ze se snazis.

Hele pane mistr a umite psat aspon vsema deseti? Pri rychlosti jedne myslenky za minutu a 300 znacich by vam to trvalo cca 660 vterin to tak krasne ztvarnit. Coz je presne 11 minut. To je parada - dostavate za to honorare ?

Jako vazne to neni nic proti Vasemu skillu. Ja uz jsem si taky parkrat nabehl s dobrou myslenkou a nepochopenim.

Jen jestli se muzu zeptat - vopravdu mate wydle na desktopu? Proc do haje nikdo nepouziva FreeBSD na desktopu ? A pritom je to tak krasne jednoduche - rozjet 2 monitory mi trvalo cca jen 2 hodiny ;o))))

kolega nademnou ma pravdu. Proc se nevykaslete na to rypani, kdyz to bylo receno asi 100x ze clanek neni dobry a proste se nekdo z Vas nepochlapi a neudela tady list tech na ktere si dat bacha a proc?
Diky.

Treba protoze mi tu praci nikdo nezaplati (a ani o ni nemam zajem abych pravdu rek), kdezto autor si vybral tema clanku a jeste za to dostal nejspis zaplaceno... Obhajoba clanku je na autorovi, ktery dal svym clankem podnet k reakcim, ne naopak.

"jak a kde kdo blbe nastavil nejakej bezpecnostni bit..." SUID neni bezpecnostni bit.

Pokud server nebezi na nejakem doma na kolene spravovanem systemu a pouziva distribucni jadro (pokud mluvime o linuxu), tak je tato oprava (mimo jine) samozrejme backportovana i do starsi verze.

Obvykle tudiz do 2.6.18 pokud se bavime o aktualnim RHELu. V Debianu byvala stable udrzovana na 2.6.18 taky, akorat si pravda nevzpominam jestli v etch nebo sarge.

Ja si proste musim rypnout ;) Ale jinak celkem souhlasim

> A mohl byste jen na okraj a pro zajímavost uvést jediný
> dynamický jazyk, který by zároveň nebyl skriptovací?

Smalltalk

Dík, právě jsem si na Wikipedii přečetl o Just-in-time kompilaci a pár příbuzných hesel a zase jsem se dozvěděl něco nového. Naštěstí se nemusím živit programováním programovacích jazyků, to už je pro mě trochu vyšší dívčí. :-)

Katalog všech firem nabízejících webhosting a také články na toto téma najdete také na http://web-hostingy.com/

/etc/passwd 640 root wheel

Zastrelit a pro vystrahu dvakrat. /etc/passwd je volne citelny z dobrych duvodu (napriklad preklad jmen na uid a zpet nebo umisteni domovskeho adresare treba pro ucely MDA) a stejne v nem nejsou hesla. Skryvani seznamu uzivatelu je security-through-obscurity a to nikdy nefungovalo. Zvlast kdyz si seznam UID vylistuju bez problemu z filesystemu a nic vic nepotrebuju, protoze stejne poznam komu co patri.

Krom toho tam kolikrat nejsou ani ucty, ktere by mely povolene prihlaseni (krome roota a o tom stejne kazdy vi), protoze se pomoci NSS nebo PAM tahaji z nejake uplne jine databaze prave pomoci getent, getpwnam a podobnych funkci.

Porad ale plati to, ze si seznam UID sezenu z filesystemu, takze skryvat jmena je uplne zbytecne a nikoho to nezastavi.

Souhlasim, ze autor je nevyspele tele, ale to on se rozhodl sem psat a musel pocitat s kritikou, i takto drsnou.

Nebo naopak zacit.

Ten clanek je priblizne na te urovni, jako kdybych se ja rozhodl napsat do casopisu o autech o tom, jak opravovat karoserie, ac by to bylo jiste naprosto tragicke, a nekteri ze ctenaru stale nechapali, ze to, ze clanek vysel v casopise o autech, jeste neznamena, ze je kvalitni a spravny, a v horsim pripade se ridili heslem "lepsi neco nez nic".

Po bitvě každý generálem.

Bylo by zajímavé jaký článek by napsal zde kritizující a pro jaký okruh uživatelů by byl napsán.
- zda by byl vhodný pro root.cz nebo pro lupu.cz

ps: pro daný okruh čtenářů není snadné psát tak, aby rozuměli obsáhlému tématu jako je bezpečnost serveru.

Neco podobneho jsem take ochoten nabidnout tomuto "borcovi", akorat s tim rozdilem, ze bych si vyhradil pravo sledovat co dela a uverejnit zde stopy po jeho pokusech vcetne detajlu.

Asi nema smysl to tu komentovat nejak vic, ten druhy dil je jeste vetsi (s prominutim) sracka plna nesmyslnych zvastu a demagogie nez prvni a autor je vysoce odolny vuci jakymkoliv negativnim komentarum. Radeji si pockam jeste na treti dil, jestli alespon ten bude za neco stat, a az se autor nebude moct odvolavat na "dalsi dil". Jsem zvedav, jake argumenty bude pouzivat pak, az se na nej ctenari, kteri narozdil od nej vi, o cem mluvi, prip. maji rozumnou produkcni zkusenost, sesypou.

Ale tomu, co tu zatim prevedl, by dokazala oponovat i technicka podpora kdejakeho vetsiho webhostingu. A musim se priznat, ze jsem od nej ocekaval rozumnejsi vyplod, a to i pres prvni dil. Tento clanek totiz snad ani nelze kritizovat po castech, to je tak "vzit a vyhodit", proste odpad ... Naprosto nemam slov.

"která je sice pomalejší a už ze své podstaty nemůže standardně disponovat některými funkcemi (konfiguračními soubory .htaccess, HTTP autentifikací atd.)"

Co to je za blabol ?

Ja tam mam demony a taky mod_fastcgi, suexec, a konfiguruje mi to pan guru nastroj, ale o tom, ze by mi tam nefungoval .htaccess nevim. Protoze ho pouzivam na vsech virtualhostech.
Hele, bud neco bere, nebo je to Wydlak!

Tak doufam, ze soucasti posledniho dilu bude prehledna tabulka vetsiny hostingu s oznamkovanim bezpecnosti.

To by bylo pěkný, nechce se mi utrácet za to že se pro zajímavost kouknu jak to vypadá...

Jsem možná v podobné situaci jako ty (až na to že nečtu soom).

I pro mě je toto téma velmi zajímavé a informace vítám a na svém hostingu si je ověřím.

Ale narozdíl od tebe jsem rozumnější a čtu i diskuze pod článkem, koukám na problém s nadhledem a nestraně. Když v diskuzi najdu příspěvky mnoha (řekněme samozvaných) odborníků, kteří mají na informace v článku negativní názor (ve smyslu informace nejsou přesné, jsou neaktuální, chybí mnohem důležitější informace) co si mám myslet? Mám si jako ty myslet, že můj hosting je allright, když těchto pár asi triviálních věci dodrží? Čím mě má (řekněme samozvaný) autor přesvědčit, že je pravda na jeho straně, když odmítá uvést fakta? Nikdo neví co zkoušel... u kterých hostingů... s jakou úspěšností...

Vím jen, že: autor je 21 let starý (asi kluk), půjde do druhého (možná třetího) ročníku VŠE, pracuje pro někoho (???) na něčem (???) na dohodu (to je smlouva na 150 hodin ročně = praxe jako bejk (vím, že ty hodiny nikdo nehlídá, ale i tak)) a podstatná data si nechává pro sebe (to není problém morálky, ale spíš nepřítomnosti jakýchkoli dat - čísla jdou prezentovat i bez poškození testovaných firem).

Takže mi nezbývá než souhlasit, že jediná informace v článku je, že některé webhostingy jsou nebezpečné. Pro mnohé určitě novinka.

Hele ale vono to neni tak spatne - ja je beru a takovy blekot bych taky vyplodil. Az bych se teda vyblil.

Jinak by autor mohl zkusit http://ego.easy.cz - tam je jenom kostra, ale treba by o tom mohl napsat 20 clanku ;o)))

K tomu jsem chtel jen dodat, ze Lupa za chvili bude server pro 15-20ti lete h4X0rZ, kteri budou P4Wn0W4T swet - nebo jak se to v tech letech pise - to bude zabava. Aspon prijde cas na neco lepsiho - treb woot.cz ;o))) nebo jak se to pise ;o)

Já tedy nevím, proč se do něj tak pouštíte. Já jsem laik, který má pár webů a informace, že "Hostingy mohou být nebezpečné" je pro mě zajímavá. Ne že bych to nevěděl, ale když mi to tak pěkně připoměl, tak se mohu podívat, jestli náhodou nemají některý parametr, který autor považuje za nebezpečný. Pokud něco najdu, tak se zeptám a oni mi buď vysvětlí, že je to v pořádku nebo se na to sami podívají. Když nic nenajdu, budu dál spokojený, že jsem zvolil kvalitní hosting.
Pokud umíte napsat lepší článek, tak sem s ním. Myslím, že redakce Lupy uvítá jakékoli zajímavé informace a já koneckonců taky.

Souhlas. Mnohem lip nez osobnim urazenim byste se pochlapili, kdybyste napsali neco sami.

OK, tak to bylo nekompletni (souhlasim), povrchni (souhlasim), byly tam chyby. Stacilo to napsat, ostatni uz by se podle toho zorientovali. Ale tahle smrst? Autor jeste nedospel natolik, aby vam na ty urazky dokazal odpovidat asertivne. No a co? Taky jste byli mladi, ne?

Tak ho kurna prestante stresovat a bezte si detaily, ktere vam tu chybi, najit treba na root :)

Jinak mne jako laikovi tenhle clanek taky pomohl. Minimalne mi pripomnel, ze tenhle problem existuje, a ze kdyz budu chtit, tak si muzu nekde vygooglit detaily. Toz tak.

PHP skripty nemusí běžet pod uživatelem serveru. Stačí použít jiný worker než ten implicitní prefork worker. Např. itk worker umí měnit vlastníky procesů v rámci VirtualHost. Člověk co tohle psal nainstaloval apache a nasal 10 řádek PHP skriptu, protože by jinak takovou blbost neplácl.

Hele ty draku a kolik z tech mastru of dizastru si precte tenhle clanek na sofistikovane Lupe ? (co jsem to placl?)

Ja vim, ze jsi mlady a nezkuseny clovek - cili si predstav situaci:

Kdo to bude delat - kdo si bude zkouset zabezpeceni webhostingu? Ty? Nebo nejaka starsi manazerka ve firme s pralinkama nebo trampolinama nebo necim takovym?

Tento clanek je OKURKA

Pane Klubal.

Mám podobný názor na diskutující, na druhou stranu si myslím, a slušně vám sděluji, že byste se měl asi chytit za nos a napsat něco konkrétního. V současném článku jsem našel jen jednu informaci a to --disable-posix, hned se podívám, zda můj hosting tohle nemá zapnuté.

Nicméně by to chtělo napsat líp, třeba, když už povídáte o tom phpinfo(), tak ho pořádně rozebrat z hlediska bezpečnosti, třeba vzít nějaký hosting a na něm to ukázat. Pokud víte o nebezpečných hostinzích, tak klidně jmenujte, vemte ho jako odstrašující případ. Pakliže by se článek zakládal na pravdě, tak se nemusíte bát, že by Vás někdo popotahoval kvůli článku po soudech.

Takto pojatý seriál je podle mne naprosto o ničem a nesmíte se divit, že lidi nadávají, když věnují několik minut svého drahoceného času k čtení něčeho, co naprosto nemá žádné myšlenky.

Doufám, že to bylo dost slušně napsané, aby vyzněl můj názor na kvalitu článku.

Děkuji. Ondřej Novák.

Ty jsi jenom "paces", znamy ze soom.cz, ktery leze Klubavoli ("emkei" ze soom.cz) hluboko do rektalniho otvoru. Mel by's prestat, je to socialni :-)))

Jenom bych rád podotkl, že Linux a MS Windows nejsou jediné operační systémy používané pro provoz webhostingu s PHP, běžně se používají i systémy jako např. FreeBSD, OpenBSD nebo Solaris.

V tomto kontextu Váš argument "Fakt, ze ... na nem bezi OS Windows neni beznou praxi" vykazuje dva nedostatky:

1) Argument předpokládá, že "PHP běžící na jiném systému než Linux" znamená "PHP běžící na Windows". Nezanedbatelné množství webhostingových služeb však využívá jiné operační systémy.

2) Argument není pravdivý. Množství webhostingových služeb nabízejících provoz PHP na platformě Windows není malé a rozhodně nelze tvrdit, že by to nebylo běžnou praxí.

Souhlasím proto, že navádět laické uživatele (kteří mají tvořit cílovou skupinu článku) ke kontrole verze jádra není dobrý nápad a může být ve svém důsledku kontraproduktivní a matoucí. Verze jádra neříká nic o aplikovaných záplatách a je irelevantní pro jiné operační systémy.

Článek by byl jistě zajímavý kdyby neskončil v polovině -alespoň takový byl můj pocit když jsem se dočetl až k podpisu.

Škoda :-(

Odborná autorita tohoto serveru (jako celku) je podle mého názoru posledních pár let zhruba na úrovni serioznosti blesku.

Jen bych rad uvedl na pravou miru tu zminku o verzi kernelu < 2.6.24. Je to ptakovina... diplomaticky: mirne zavadejici... sireni poplasne zpravy...

Napriklad debian stable (etch) ma verzi kernelu 2.6.18 a vzhledem k tomu ze je to stable, tak pochybuji ze tomu bude nekdy jinak.

Jde o to ze security patche jsou casto backporrtovany dotechto starsich jader, popripade dane problemy se ve starsich jadrech nevyskytuji, protoze v nich neni dany subsystem, vylepseni, zaplata, ... .

Priklad:
Na jednom serveru kde mam gentoo, mam verzi kernelu 2.6.23-hardened (grsec patche), takze se pouziti beznych exploitu celkem stezuje. (alespon tech co jsem videl v tech masove sirenych "privatnich" shellech).

Vase pripomonka se tyke zrejme vanilla kernelu, coz bych v clanku mozna zminil. Takhle je to dost zavadejici.

PS: budete se take zminovat o bezpecnostnich zaplatach pro lin. kernel? Myslim ze ani tato oblast by se nemela zanedbat.

ad clanek: stale jsem v nem nenasel nic zajimaveho :/