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.
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.
- jakym zpusobem probihaji penetracni testy a opravdove utoky
- jake bezpecnostni vyhody maji komercni hostingy oproti free variantam
- jakym zpusobem se utocnici dostavaji k informacim
- ze je potreba vyhledavat co mozna nejaktualnejsi verze PHP
- ze verze kernelu starsi nez 2.6.24.1 jsou nebezpecna, bezny uzivatel = root
- ze je potreba zakazat sadu funkci POSIX, k cemu lze zneuzit
- jakym zpusobem muze PHP na serveru bezet a jaka rizika to s sebou prinasi
- prehled modulu pro praci s uzivatelskymi identifikatory
- ...
tech informaci je tam podle meho nazoru dost.
Co se tyce dalsiho rozboru funkce phpinfo(), pak Vas pristi dil jiste potesi. Nerad bych ale jmenoval nejaky webhosting, bylo by to vuci one spolecnosti nefer.
- jake bezpecnostni vyhody maji komercni hostingy oproti free variantam
To jsem se z clanku nedozvedel.
- jakym zpusobem se utocnici dostavaji k informacim
K naprosto nezajimavym informacim. Rozumne utoky na servery probihaji trochu jinak.
- ze je potreba vyhledavat co mozna nejaktualnejsi verze PHP
Doporucuji doplnit, ze nejen PHP, ale je potreba mit aktualni verze veskereho serveroveho SW vybaveni, a to mit spravne nakonfigurovano (on se da vest utok na server i napriklad prez chybne nastavenou SQL databazi).
- ze je potreba zakazat sadu funkci POSIX, k cemu lze zneuzit
Tak to je silne nekompletni. Mnozina funkci ktere je potreba na sdilenem webhostingu je daleko sirsi. Obecne doporucovany seznam:
popen, stream_select, socket_select, socket_create, socket_create_listen, socket_create_pair, socket_listen, socket_accept, socket_bind, socket_strerror, system, exec, shell_exec, proc_close, proc_get_status, proc_nice, passthru, escapeshellarg, escapeshellcmd, proc_open, proc_terminate, readlink, symlink, link, pfsockopen, ini_alter, dl, openlog, syslog, pcntl_exec, pcntl_fork, pcntl_signal, pcntl_waitpid, pcntl_wexitstatus,pcntl_wifexited,pcntl_wifsignaled,pcntl_wifstopped,pcntl_wstopsig,pcntl_wtermsig, set_time_limit
# ad vyhody
Prectete si ten clanek prosim jeste jednou a poradne. Napoveda: naklady, tarify.
# ad informace
Na zaklade tech, podle Vas, naprosto nezajimavych informaci, lze ziskavat a menit data cizich uzivatelu, prochazet systemove adresare a v krajnim pripade ziskat opravneni spravce systemu, ale to jsou jiste podle Vas naprosto nezajimave utoky.
# ad aktualizace
Souhlasim.
# ad POSIX
Sadu POSIX funkci je dobre zakazat rovnou pri kompilaci, proto jsem ji uvedl jiz v teto casti, jinak o direktive disabe_functions pojednava zaverecny dil.
Pravdepodobne jste se s vetsim webhosterem jeste nesetkal. Nejake cteni /etc/passwd Vam bude uplne nanic (pokud by se Vam vubec podarilo), protoze nad vice servery je stejne nutne zajistit jiny system spravy uzivatelskych uctu (LDAP, Kerberos, a dalsi). A uzivatelsky login toho nemusi mit se systemovym UID v takovemhle pripade opravdu mnoho spolecneho.
Ale pane Klubale, vždyť vy melete nebezpečné a zavádějící nesmysly.
- verze kernelu vůbec nic neříká o bezpečnostních vlastnostech, známé chyby mohou být opravené i ve starší verzi
- zakazování funkcí není řešení, nemyslíte, že tam ty POSIX funkce k něčemu jsou? Že vy nevíte, na co je použít, neznamená, že jsou k ničemu
- čtení /etc/passwd nic neříká o bezpečnosti. Dokonce ten přečtený soubor vůbec nemusí být TEN /etc/passwd!
- webhosting = PHP je stejná blbost, jako třeba počítač = windows
Vaši publikační činnost považuji přímo za nebezpečnou. Nesmysly vydáváte za globálně platná tvrzení a opíráte se o odbornou autoritu tohoto serveru. To může mít za následek, že například webhoster s řádně opatchovaným jádrem, leč "starší" verze, bude před svými zákazníky vypadat jak blbec.
Je to ale i chyba "redakce", že články bere od kohokoliv a bez řádné oponentury je rovnou publikuje. To pak otevírá prostor pro tyhle úlety, které musí v diskusi opravdoví odborníci uvádět na pravou míru.
- mohou, ale v drtive vetsine pripadu nejsou a pokud Vy mate jine zkusenosti z praxe, rad si je vyslechnu.
- z ceho jste prosim Vas vydedukoval, ze nevim, k cemu ony POSIX funkce jsou? Muzete mi jmenovat alespon jedno rozumne vyuziti zminenych funkci beznymi uzivateli, tedy krome sbirani informaci ze strany utocniku?
- nemusi, ale v 99 % je, tudiz duvod pro Vas, abyste me urazel, ze?
- kde jsem ve clanku uvedl, ze webhosting = PHP? Muzete me prosim citovat? Naopak jsem napsal, ze bezpecnost webhostingu netkvi pouze v konfiguracnich direktivach dynamickeho jazyka. Prectete si ten clanek prosim jeste jednou, nez napisete dalsi komentar.
- o odbornou autoritu tohoto serveru se neopiram, opiram se o vlastni zkusennosti podlozene praxi, ktere Vam v tomhle ohledu chybi, ale presto mate tu drzost me urazet. Pokud se na webhostingovou spolecnost obrati zakaznik s zadosti o sdeleni, zda je dane jadro opatchovane, pak nevidim duvod, proc by mu dana spolecnost nemela odpovedet a citit se jako blbec.
- neurazte se, ale Vase komentare poslednimu odstavci nenasvedcuji.
Cituji: ".. především verze jádra, ...vyšší než 2.6.24.1. Pokud tomu tak není ...pomocí ...lokálního exploitu velice snadno dosáhne eskalace práv a získá ... naprostou kontrolu..."
Teď mi ukažte, kde radíte, že se má dotyčný dotázat webhostera, zda je jádro opatchované. Kde máte informaci, že u opatchovaného jádra na verzi nezáleží. A že to PHP nemusí vůbec běžet na Linuxu. To vás ale vůbec nenapadne, vy vůbec nepřemýšlíte nad možnými odlišnostmi od vaší domácí konfigurace. Takhle se snažíte psát univerzální návod pro hlupáky?
Jak vidno, je to váš styl. Do článku napíšete nějaký nesmysl a pokud se proti tomu v diskusi někdo ohradí, tak lžete, jako když tiskne.
Za tim, co jsem napsal, si samozrejme stojim, nebot nejde o zadnou lez. Jak jste sam podotknul, snazim se psat univerzalne pro co nejsirsi okruh sdilenych serveru, se kterymi se mohou v dnesni dobe zakaznici setkat, nezminuji proto minoritni vyjimky. Fakt, ze jeden z mala serveru timto patchem disponuje, nebo na nem bezi OS Windows neni beznou praxi a s moji domaci sestavou to nesouvisi uz vubec. Postradate jakykoliv prehled o vybaveni soucasnych webhostingu, kde skutecne dominuje GNU/Linux a tento patch neni aplikovan, presto se ocividne rad poustite do kritiky neceho, cemu nerozumite.
Zato u Vas je jasne videt, ze mate prehled pouze o freehostingach nebo zkusenost s nejakym "radoby" webhosterem. Pracoval jsem totiz u jednoho z nejvetsich ceskych webhosteru a i kdyz webhostingove servery mely jadro nizzsi nez 2.6.24.1, tak byl vsude samozrejme aplikovan zminovany PATCH. Radite tedy bludy a naprosto souhlasim s panem Kucerou.
Vy mate zkusenoti s jednim jedinym webhosterem, to je urcite fajn, stejne jako aplikovani zminovane zaplaty. Ja mam zkusenosti hned s nekolika komercnimi webhostingy, kde tento patch aplikovan dodnes neni. Kdo z nas dvou ma tedy podle Vas objektivnejsi pohled na vec?
Nebojte se, nemam zkusenost pouze s jednim webhosterem. To je ted preci uplne jedno. Otazka vsak je, zda tou verzi jadra vydesite pouze majitele tech stovek webhostingu u spolecnosti, ktere jste testoval nebo spis vydesite ty desetitisice majitelu webhostingu u velkych webhostingovych spolecnosti, kteri bezpecnost svych serveru nepodcenuji, ale diky Vasim "odbornym" radam si ted kazdy BFU bude myslet, ze jsou h4ckut3ln1 ?
Z toho, co jste napsal, jsem nabyl dojmu, ze je podle Vas zminovany patch aplikovan na vetsine sdilenych serveru a pouze vyjimecne se na nej "zapomnelo". Opak je ale pravdou, a proto si za svym clankem pevne stojim. Pokud bych totiz nyni ukazal nahodne na nektery z webhostingu prstem, je mnohem vetsi pravdepodobnost, ze timto patchem disponovat nebude, nez, ze bude.
Vase sebekritika je usmevna, i kdyz doma Vas slusnemu vychovani asi neucili.
Bud se mi podari spustit aplikace na urovni prikazove radky a sam mam moznost dany exploit otestovat, nebo se v opacnem pripade jednoduse zeptam, zda byl zmineny patch aplikovan. Jake se mi ve vetsine pripadu dostava odpovedi je doufejme logicke z mych predchozich prispevku.
Vazeny anonyme,
uvedena konfigurace neni typickym prikladem webhostingu, ze kterych dnes bezni uzivatele vybiraji. Ac bych tedy test provedl, jeho vysledek by byl irelevantni v porovnani s tim, na co se snazim pomoci tohoto serialu upozornit. Tento fakt by vsak zde diskutujici "odbornici" zajiste nedokazali pochopit a byla by to jen dalsi voda na jejich mlyn.
a mate to statisticky podlozeno na relevantnim vzorku (rekneme X desitek nejvetsich webhosteru, at uz free nebo placenych, tedy firmy pokryvajici vetsinu klientely), nebo (opet) placate do vetru?
Pokud to mate statisticky podlozeno, proc to neni zverejnene? Pokud proto, ze jste natolik neobycejne cestny abyste nezverejnoval chyby u konkretnich spolecnosti, informoval jste tyto spolecnosti?
Pokud to statisticky podlozeno nemate, jak si troufate tvrdit, ze to neni typicky priklad webhostingu, kdyz sam zadnou praktickou zkusenost z provozu ani nemate?
Tak jste pravdepodobne netestoval dostatecny statisticky vzorek. Nicmene urcite je problem, pokud se Vam u jakehokoliv webhostera podari spustit jakykoliv binarni kod - pokud se nejedna o nekterou z technologii sandboxingu, ale to uz by jsme byli v trosku vyzsi cenove hladine webhosteru, nez je obvykle.
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?
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.
jsou linuxove systemy, kde naopak co nejnovejsi jadro neni zadouci, a bezpecnost se resi backportovanim
schvalne se treba podivejte jakou verzi jadra pouziva debian stable
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.