Hlavní navigace

Vlákno názorů k článku Nebezpečné webhostingy III od anonym - Mam to chapat tak, ze pokud nekdo upozorni...

Článek je starý, nové názory již nelze přidávat.

  • 2. 9. 2008 13:27

    anonymní
    Mam to chapat tak, ze pokud nekdo upozorni na to ze autor neni odborne zpusobily na to napsat clanek, tak ma byt rovnou schopen napsat clanek nahradni?

    To logicky vede k tomu, ze podle vas mohou kritizovat jen jedinci co krom svych odbornych znalosti jsou take navic jeste literarne zdatni a maji cas psat clanky... To myslite vazne?;)
  • 2. 9. 2008 16:21

    ef (neregistrovaný)
    Ale ne, ja Vam preci nenadavam, ja pouze konstatuji svuj pohled na vec. Proste mam s lidmi ze soom.cz uz jistou zkusenost a tenhle clanek do ni zapada :-). Ale dost toho, hura do odpovedi.

    Souhlasim s Vami, pristup k cizim datum je nepripustny, at se jedna o spatnou konfiguraci PHP direktiv nebo o kernel jak cednik, to je celkem jedno. Tohle samozrejme podstatne je. Ja jen tvrdim, ze se neda pausalizovat a ze informace typu "pokud je safe_mode_gid zapnuty, tak jdete od toho" ma vahu jen za jistych podminek, ktere ovsem v clanku nezminujete. Ja treba tvrdim, ze pokud kazdy uzivatel bude mit sve vlastni UID i GID (neni tak neobvykle), tak neexistuje zpusob, jakym by safe_mode_gid mohl bezpecnost zhorsit. Naopak pomuze zbavit se nekterych negativnich dopadu, ktere safe_mode ma. Je jasne, ze pokud budou vsichni uzivatele ve stejne primarni skupine, tak je safe_mode_gid na pytel (a neverim, ze takovou konfiguraci skutecne nejaky realny komercni webhosting ma, at uz je jakkoli garazovy). Ale to je presne ten sirsi kontext, o kterem jsem mluvil. Nekde to pomaha, jinde to je nezadouci.
    Teda, vse vychazi z toho, ze jsme vubec ochotni tolerovat mod_php. Pokud jste ale chtel tremi dily serialu poukazat na to, ze mod_php je spatny (mkay), tak se to myslim dalo rict strucneji :-). Pokud bylo cilem clanku rici, ze mod_php se da nakonfigurovat lepe, tak zase chybi nejaky vetsi nahled.

    Predstavu mam docela dobrou, dokonce i realizovanou :-).
  • 2. 9. 2008 13:03

    hm (neregistrovaný)
    Lupa jistě ocení další redaktory, příp. dokonce jen jeden jednotlivej článek či seriál. Můžete se přihlásit se svojí pravdou.
  • 2. 9. 2008 23:01

    ppp (neregistrovaný)
    Neregistrovaný ef napsal:
    Bezpecnost je tak nejak nutno brat v kontextu souvislosti.

    "Věci je nutno viděti nikoli odděleně, nýbrž vcelku. Dějiny jsou dějinami třídních bojů. Já to tak vidím."
    "Ty vidíš, Jasánku, veliký hovno," odvětil kulak Vata.

    Teda tak nějak v kontextu souvislosti, to je fakt perla, to by se mělo tesat.

    A čo vy si, Kefalín, predstavujete pod takým slovom "kontext"? :-)

  • 2. 9. 2008 12:38

    eGo (neregistrovaný)
    Ten clovek je mlady a nezkuseny - chtel bych videt, kolik webhostingu kdy on spravoval. Jako uzivatel psat o bezpecnosti a nevedet co to znamena administrace je naproste plytvani casem pro vsechny - dokonce i prostorem v databazi, kde je tenhle clanek ulozeny.

    Uz jsem tomuhle klucinovi nabize, ze mu dam hosting u me na serveru, ktery je primo urceny k tomu, aby ho nekdo rozbil.

    Ale aspon jeden dalsi, ktery se treba casem neco nauci.
  • 2. 9. 2008 15:18

    Martin Klubal
    Co je na tom spatneho, ze ve svem profilu uvadim portal SOOM.cz jako homepage? Kdybych uvedl pentester.cz spousteny za 14 dni, byl byste pak spokojenejsi? Naopak byste mi ted tady nadaval, ze cely serial nebyl nic jineho, nez pouha reklama.

    Pomoci spatne konfigurace vyse uvedenych direktiv lze pristupovat k datum cizich uzivatelu, systemovym slozkam, obchazet restrikce,... a Vam to prijde nepodstatne?

    Bezpecnost je zajiste nutno brat v kontextu souvislosti, cilem tohoto serialu vsak bylo seznameni se s bezpecnosti na urovni PHP, o kterou se soucasne webhostingy silne opiraji a ctenari na to byli upozorneni, hned nekolikrat.

    ad safe_mode_gid
    Dalsi priklad lenosti spravcu serveru. Namisto komplexnejsi konfigurace radeji tuto direktivu aktivuji a maji po problemu za 5 vterin, ze? Co to udela s bezpecnosti je jiz tolik netrapi.

    ad posledni odstavec
    Vy si samozrejme muzete pouzivat cokoliv a ja budu ten posledni, kdo Vam to bude vyvracet, nebot jsem rad, ze mate predstavu o idealne zabezpecenem webhostingu. Tento serial se ale zabyva realitou (webhostingy), nikoliv predstavami (zde diskutujici ctenari).
  • 2. 9. 2008 11:22

    ef (neregistrovaný)
    Nez jsem byl upozornen, ze autor ma ve svem profilu hned dvakrat zminenou domenu soom.cz, tak jsem se docela divil. Ale tohle to vysvetluje.

    U dvou predchozich clanku jsem se hodne drzel, abych nejaky komentar nenapsal, tenhle to dovrsil. Cely tenhle serial dokazal jednu vec - lide, kteri skutecne nemaji ani poneti o bezpecnosti, si pujdou slepe overit, co ten jejich hosting vlastne ma nastaveno a bud ho hned z fleku vymeni, nebo s tim budou alespon otravovat technickou podporu, a to bez toho, ze by to bylo jakkoli opodstatneno. Bezpecnost je trochu neco jineho, nez jit slepe krok po kroku "tohle musi byt off, tohle musi byt on, tady musi 'neco' byt a nespecifikuju co, ale hlavne aby to bylo 'neco'". Proc by tam ty volby byly, kdyby bylo predem jasno, co je spravne nastaveni? Bezpecnost je tak nejak nutno brat v kontextu souvislosti.

    Kuprikladu safe_mode_gid... proc je to podle vas spatne? Vzhledem k chovani setgid bitu na adresarich muze byt obcas na sdilenem hostingu s mod_php naopak mnohem lepsi pouzivat gid nez uid. Soubory, ktere budou vytvoreny na disku, bud primo, nebo napriklad pres vami obavany copy, podedi skupinu toho, kdo vlastni adresar, a mame tak nejak po problemu. Dokonce se do toho souboru pak i z PHP se zapnutym safe_mode_gid znovu dostaneme.

    Proc nejde brat hosting nepouzivajici open_basedir za bezpecny? Pokud pouzivam mod_fcgid+suexec alternativu, pak kuprikladu nevidim duvod, proc open_basedir pouzivat, a presto i tak mam vysledny system mnohem bezpecnejsi nez cokoli, co se da vytvorit pres mod_php at kouzlite s direktivami sebevic. Izolace pomoci OS je neco trochu silnejsiho, nez izolace kterou vytvari PHP.

    Totez disable_functions, samozrejme.