Vlákno názorů k článku Hostingové služby nerespektují bezpečnostní doporučení od admin na pes.cz vi - Pred deviti dny jsem zadal webhostingovou sluzbu pes.cz o...

Pred deviti dny jsem zadal webhostingovou sluzbu pes.cz
o upgrade php z 4.0.2 na aktualni verzi a to z duvodu bezpecnosti:

http://www.securityfocus.com/bid/2205

Zde je odpoved a musim napsat, ze na serveru, kde mam domenu se zatim nic nezmenilo. Pritom upgrade na novou verzi je otazka maximalne nekolika desitek minut.

Dle meho nazoru zneprsitupneni serveru je otazka nekolika sekund.


ODPOVED Z pes.cz


Vazeny pane,
o upgradu samozrejme uvazujeme, ale je to docela problematicka zalezitost.
Prinese hodne problem vsem klientum a hlavne na nejakou dobu znepristupni
cely nas server.

Problematice zabezpeceni se veneujeme prubezne.

Dekujeme za informaci a preji hezky den
Josef Grill

Jojo, PES :o))) Az vam nekdo smaze veskera data a podobne (at uz je to hacker ci admin PES :o)), nebo az vam server nepojede cca deset dnu (dungeony.cz rulez :o)), tak udelate to co vetsina provozovatelu ambiciozne rostoucich serveru, ktere by mely spise fungovat nez nefungovat (napada me treba Seznamit.cz, ktery mel nejprve reklamy na Psa snad vsude na homepage, kam se clovek podival :o)) - sbalite si svych pet svestek, databazi a ja nevim ceho vseho jeste a pujdete co nejdrive jinam :o)))

BTW: a za tenhle prispevek budu sedet, nebot mi prave volal Grill, ze jde oznamit na policii trestny cin pomluvy z me strany :o))) Aspon vidite, co se u Psa dela cely den - ctou internetove diskuse :o)))

Cituji začátek skutkové podstaty trestného činu pomluvy podle § 206 odst. 1 tr. zákona : Kdo o jiném sdělí nepravdivý údaj, který je způsobilý značnou měrou ohrozit jeho vážnost... Nevím, jestli tady někdo sdělil nějaký nepravdivý údaj, ale dost jistě vím to, že kromě čtení intertnetových diskusí, se po zbytek dne, když zbude chvíle, u PSA píše denně několik trestních oznámení. Ale jsem klidný, zatím z důvodu psích trestních oznámení nikoho nezavřeli. Bylo by zajímavé založit Sdružení těch, na které PES podal trestní oznámení, myslím, že by nás nebylo málo :-))

No já myslím, že je už dávno veřejným tajemstvím, že PES se hodí možná tak k hostování osobních stránek :)

To by pak šlo sedět více lidí. Můj známý měl u Psa "lechtivý" server a cituji: "Po týdnu neustálých výpadků a dohadování s jejich techniky jsem se sbalil a utíkal jako zdravý před morem." Takže s tou kvalitou to nebude nic moc. Já osobně jsem u Globe a nestěžuju si (konec skryté reklamy ;-)).

he he ono o jejich profesionalite hovori uz jen ten fakt ze vsechny jejich servery na TELECOMU maji kvaltni pripojeni jednim spolecnym koaxem :-), myslim ze to je revolucni technicka novinka kterou nikdo jiny nepouziva :-))))

Dobry den ve spolek. Plne souhlasim s panem Polachem. PES jsou nejvetsi amateri, jaky kdy cesky webhosting videl. Nejenze ze neumi delat svoji praci, ale ani nezvlada zakladni pravidla slusneho chovani. Radsi se k tomu nebudu vice vyjadrovat, zabralo by to min. par kB, stejne planuji sepsat a nasledne zverejnit sve pameti a zkusenosti s touto znamou "firmou". Zdravim Vas, pane Grill - dlouho jsem o Vas neslysel :)))

Až je budete sepisovat, vzpomeňte si i na mě, stanu se signatářem :)

Musim konstatovat, ze autor predchoziho prispevku si predstavuje provedeni upgradu na serveru, kde bezi mozna stovky webu jako Hurvinek valku. Co, kdyz se stane to, ze po provedeni upgradu nepobezi desitky serveru, ktere vam za provoz plati nejake penize...

Jo jo, je to tak.
Kdyz si nekdo predstavuje neco, co nemusi byt jen otazkou par sekund. Pan Grill uvazuje dle meho nazoru rozumne.

Takze podle vas se upgrade neudela dokud bude ten server fyzicky existovat, ze. A to, ze hrozi prunik do systemu a kradez dat a zdrojaku, to vam asi nevadi, ze?

Nezaznamenal jsem za ten vice nez tyden od pes.cz zadnou snahu problem resit. Jako mozne reseni vidim napriklad oznameni: "dne x.x bude proveden upgrade php4.0.2 na bezpecnejsi php4.0.4pl1. Doporucujeme provozovatelum virtualnich serveru naslednou kontrolu funkcnosti jejich skriptu".

Ale to oni ne, jen ticho po pesine.

Poznamky v nekolika komentarich a me zkusenosti s "on-line" zprovoznenim serveru a database uvazuji o odchodu jinam.

Muze nekdo doporucit levny, ale dobry webhosting?

Mohu doporučit firmu OUTLINE, u níž hostuji. Zatím žádné problémy, vstřícný přístup, levné ceny. Jsou na stránkách www.outline.cz.

Abychom se drzeli tematu:

Non-authoritative answer:
outline.cz nameserver = ns1.outline.cz
outline.cz nameserver = ns2.outline.cz

Authoritative answers can be found from:
ns1.outline.cz internet address = 194.228.3.58
ns2.outline.cz internet address = 194.228.3.59

Ze by .58 a .59 nebyli na stejne siti (ci dokonce na stejnem stroji) - to podle mne neni ani mozne..

Jinak outline neznam, jejich kvalitu hostingu nemohu posoudit..

Na jedné síti jsou sice taky, ale ne na jednom stroji. To jen pro upřesnění.

No jo, ovsem pak se nesmi divit, az mu to pres nejaky znamy bug nekdo hackne...

Ja si nemyslim, ze by problem upgradu byl tak velky.
Budu-li uvazovat server apache, upgrade znamena bud prelozit znovu s novou verzi PHP, nebo, pokud pouzivam nemodifikovany balik z distribuce(coz asi ne), update baliku. Specielne u PHP se myslim nestane, ze by prechod na novejsi verzi( nemyslim z 3.x na 4.x) znamenal nejakou nekompatibilitu s verzi predchozi, zvlaste kdyz jde v podstate o bezpecnostni patch.
Samozrejme, ze stary apache hned nesmazu. Udelam si zalohu a pokud se nedejboze neco nepodari, snadno to z te zalohy obnovim. Co je na tom tak narocneho? Co na to Hurvinek?

Jeste k debate o nameserverech. Ja osobne si myslim, ze pokud mam nameservery na ruznych IP segmentech s ruznymi cestami ven, uplne to staci. U posty problem resi vice MX serveru, jak uz tu nekdo podotkl. Pokud 'chcipne' linka, ktera me spojuje s ostatnim svetem, bud existuje jina a pak je alespon cast site dosazitelna, nebo je jedno, kde je jaky server. Pak by asi bylo vhodne mit nameserver u jineho providera. To s sebou ale prinasi problem se spravou a neco to vetsinou stoji. Proste to nepovazuji za obecne platne pravidlo(jak jsem mel pocit z clanku). Ani zminovane RFC nikde nerika, ze je nutne mit zalozni servery v sitich cizich subjeku. Nebo se mylim? Clanek mi prijde dost populisticky. Vice objektivity a precteni trochy dokumentace by autorovi jiste nzaskodilo.

Jeste jeden dodatek. Nechapu, jak v kontextu clanku souvisi umisteni nameserveru v lokalite a sitich s bezpecnosti. Autor si zjevne plete hodinky a holinky.

No, to je asi jednoduche, ne? Pokud budete mit dva nameservery v jedne cimre, byt na uplne jinych dratech do jinych siti, pri pozaru vam shori oba dva... Bezpecnejsi je, mit kazdej fyzicky nekde jinde... Takze to souvisi s bezpecnosti (stabilitou i za zhorsenych podminek castecnych vypadku) provozu jako takoveho. Ja bych se pojmu bezpecnost provozu nebranil...

Mozna. Moje reakce pramenila z toho, ze z clanku jsem mel pocit, ze vubec nejde o zadnou bezpecnost. O bezpecnosti mluvi jen tucny titulek. Takze muzeme vymyslet, spekulovat, hadat se. Ja tez nemyslel fyzickou bezpecnost masiny. Kazdy pocitac vam prece muzou ukrast. :-))

Dobry den! Dovolim si nesouhlasit s vyse uvedenym:
> Proste to nepovazuji za obecne platne pravidlo(jak jsem
> mel pocit z clanku). Ani zminovane RFC nikde nerika, ze
> je nutne mit zalozni servery v sitich cizich subjeku.

Zde je citace z RFC:
"When selecting secondary servers, attention should be given to the various likely failure modes. Servers should be placed so that it is likely that at least one server will be available to all significant parts of the Internet, for any likely failure". Zde se rika, ze by servery mely byt umisteny tak, aby byly dostupne z vetsiny internetu i v pripade vypadku. "Consequently, placing all servers at the local site, while easy to arrange, and easy to manage, is not a good policy. Should a single link fail, or there be a site, or perhaps even building, or room, power failure, such a configuration can lead to all servers being disconnected from the Internet." Tady se rika, ze neni dobre umistit oba servery na jednom miste, ci serveru.. "Secondary servers must be placed at both topologically and geographically dispersed locations on the Internet, to minimise the likelihood of a single failure disabling all of them."

Zde se rika, ze servery MUSI (zminovane RFC nikde nerika, ze ;-) byt umisteny na ruznych mistech jak topologicky (ruzne site) tak i geograficky (jine misto).

"That is, secondary servers should be at geographically distant locations, so it is unlikely that events like power loss, etc, will disrupt all of them simultaneously. They should also be connected to the net via quite diverse paths. This means that the failure of any one link, or of routing within some segment of the network (such as a service provider) will not make all of the servers unreachable." Etc...

Opet se rika, ze vyse uvedene doporuceni zajisti, aby nameserver byl dostupny i v pripade vypadku konektivity.
-----
K tomu, ze:

> Clanek mi prijde dost populisticky. Vice objektivity a
> precteni trochy dokumentace by autorovi jiste neskodilo Stouru jsem na celou situaci upozornil ja a to uz pred casem. Vedlo mne k tomu kuriozni zjisteni - ne u PES.CZ, ale u CZECHIA.COM - tam totiz ve 14. duvodech proc volit Czechii uvadeji, ze:
> 12. Autonomní doménový systém
> Czechia má autonomní doménový systém. Nově vąechny domény
> registrujeme na DNS servery ns1.czechia.cz a
> ns2.czechia.com. Jedinečnou výhodou Czechie je, ľe oba
> DNS servery jsou na různých sítích a mají různé doménové
> jméno, takľe výpadky konkrétního poskytovatele nebo DNS
> serverů registrátorů se netýkají domén na Czechii.

Kdyz jsem to nasel, tak jsem si nejdriv rekl "to je dobry napad s temi .cz a .com domenami.." a aplikoval to i u nas (DNS u ruznych poskytovatelu jsme tehdy uz samozrejme meli) - od te doby se pro registraci novych domen pro domeny.cz pouzivaji ns.servery.cz a ns.servery.com umisteny kazdy skutecne na jine siti a i v jine domene.. Pri te prilezitosti mne take napadlo si udelat traceroute na oba uvadene servery (ns1.czechia.cz a ns2.czechia.com) a dosel jsem ke kurioznimu zjisteni - oba jsou sice na jine siti (nelze takto na dalku overit, ale mozna ano), ale kupodivu k nim vede stejna cesta - na sit NEXTRA..

Stouru jsem upozornil jeste jednou - po vypadku site IOL v jedne z predchazejicich noci (kdy mimo jine i cela slavna "nepretrzita" technicka podpora IOL hlasila stale, ze vsichni operatori jsou obsazeni :-)) a kdy jsem zjistil, ze neni diky tomu dostupny ani jeden z nameserveru PES.CZ..

Diky za citace RFC. I ja jsem jej cetl. Nikde mi z nej vsak nevyplyva, ze ono topologicke oddeleni MUSI byt nutne na urovni providera. Jak jsem rikal v predchozim prispevku: Proc by nemohly byt ony servery v RUZNYCH IP SEGMENTECH? Samozrejme jsem myslel i v jinych fyzickych lokalitach.
Predpokladam, ze do siti o kterych se bavime LZE vstoupit ruznymi cestami.

Mate pravdu v tom, ze je lepsi, kdyz jsou servery rozdeleny mezi vice provideru, ale jak rikam NEMUSI TO BYT NUTNOST.

Dobry den!

Je pravda, ze ve zminovanem RFC neni rec o ruznych providerech - lze tedy samozrejme mit oba servery u stejneho providera v ruznych lokalitach nebo ruznych sitich.. Lze si ale snadno overit, ze ani Pes ani Czechia (alespon podle traceroute) nic takoveho nema..

Ano, namitku prijimam.. I kdyz mne napada - pokud se bude jednat o jednoho providera, ktery ma routing ve vlastni siti manageovany centralne a chyba v routingu, ktera zpusobi vypadek se proto promitne do cele jeho site, pak to bude problem.. Jedna se samozrejme pouze o hypotezu.. (ale chybu v routingu jako duvod nedostupnosti uvadi RFC a proto mne take tato konstrukce napadla..)

ale panove...
v puvodnim prispevku se mluvilo o upgrade PHP 4.0.2 na PHP 4.0.4pl1, tzn zadna podstatna zmena
takze upgrade znamena pouze rozbalit zdrojaky php, ./configure --s-puvodnim-nastavenim, make, make install, apachectl restart
v pripade, ze mate php zkompilovane jako dso a zalohovany konfigurak, je to vcetne downloadu prace na 10 minut.

Mate pravdu, prekompilovat apache, pripadne vymenit modul, je v idealnim pripade prace na deset minut.
Problem je ale v tom, ze pokud provozujete webhosting s radove tisici weby, z nichz zhruba desetina pouziva php, problemy s nekompatibilitou se temer urcite vyskytnou, i kdyz se jedna o upgrade minor verzi. Zkuste se podivat na opravdu velke servery, v jake bezi konfiguraci, a zjistite, ze do upgradu se adminum nijak moc nechce.
Na druhou stranu je jasne, ze pokud se jedna o bezpectnostni zaplatu, je treba provest upgrade co nejrychleji. Z meho pohledu se mi jevi schudne vystavit na strankach informaci o upgradu, duvod, pripadne mozne komplikace a take konkretni datum prechodu. Nebylo by na skodu poslat klientum webhostingu take email. Pokud by se u klientskych webu objevily potize, mela by byt moznost okamzite zajistit prechod na puvodni konfiguraci.

to snad nemyslite vazne? vezmu to selskym rozumem: dela se (mela by se) delat napriklad denni nebo tydenni zaloha. co brani dotycenmu zazalohovat, upgradovat a pripadne obnovit? ztrata dat za nekolik hodin ktere si mezitim nekdo ulozi? najit hodiny s nejmensim provozem, dat to dopredu vedet at s tim lide pocitaji pro "sichr" a hotovo.
2. varianta - nejlepsi proste cely uprade provest nejprve na zaloznim stroji (nemusi byt tak vykonny), otestovat, spustit ladit.... posleze pustit na hlavnim stroji

nebo mi snad chcete rici ze takhle to nefunguje, pripadne ze "velky" "slavny" "nejlepsi" apod. privlastky, ktery si kazdy poskytovatel dava nema treba zalozni masinu nebo nejake zalohy? v tom pripade at bezi slusne "nekam", to si to muzu provozovat na svem stroji bez zalohovani apod a budu na tom stejne....

Pan Grill mi (telefonicky) vytknul, ze jsem sve dva predchozi prispevky nepodepsal, takze timto tak cinim. Mel jsem za tom, ze me jmeno neni podstatne (viz napr. prispevek od 'm') a ze obsah je podstatnejsi. Takze svuj omyl ted napravuji.