Co takhle přidat "/bin/false" do "/etc/shells"? Nebo vzít nějaký jiný (z hlediska bezpečnosti) "false" program, přidat ho do "/etc/shells" a uživatelům jediným scriptem v "sed"u nahradit zatím invalidní shell validním?
Tedy promin, MK, ale "to communicate something" v anglictine neexistuje. Pak nevim, kde jsi vzal "komunikovat neco". To je k zbliti. Uz staci "zminit neco", "diskutovat neco" a podobne vyblitky.
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 :-))))
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 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 ;-)).
No jsou veci, ktere ma cenu komunikovat a jsou veci, ktere cenu komunikovat nema - respektive jsou dulezitejsi veci na praci :-) Ale to urcite znas taky ...
Napad dobry, je fakt, ze kdyz jsem se dozvedel o WinSCP tak jsem o tom uvazoval.. Bohuzel je problem - aby to fungovalo, musi mit uzivatel povoleny shell - pokud nema, WinSCP (a vubec scp) nefunguje... A na hostingu maji uzivatele nastaveny shell na /bin/false - tedy jako by ho nemeli.. A povolovat jim ho kvuli tomu se nam z bezpecnostnich duvodu nechce..
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..)
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. :-))
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.
Když už jsme u té bezpečnosti hostingových firem. Podívejte se schválně do jejich nabídek. Většina z nich nabízí přístup k pronajatému prostoru jen přes FTP nebo FrontPage extenze. Oba dva protokoly přenášejí jméno a heslo v otevřené podobě, takový ráj pro hackery.
Těším se na dobu, až místo FTP a FP uvidím v nabídkách jen FTPS a SCP. Jestli chcete něco udělat pro zvýšení bezpečnosti stránek zákazníků, nabídněte jim přístup přes SCP a program WinSCP (http://winscp.vse.cz), který nabízí grafické prostředí ala Norton Commander pro práci se vzdálenými soubory přes SCP.
Neda mi to nereagovat - byl bych rad, kdyby si ten nejmenovany koupeny taky uvedomil, jaky mel v cele siti b....l. Ale opravdu dalsi diskusi spis osobne...
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...
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..
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.
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....
Jeste jeden dodatek. Nechapu, jak v kontextu clanku souvisi umisteni nameserveru v lokalite a sitich s bezpecnosti. Autor si zjevne plete hodinky a holinky.
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.
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.
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.
Nikdy jsem nerekl, ze CTT je best ve vsem. To, ze PVTNet a Nextra jsou po svatbe nijak neimplikuje stav zakaznickych sluzeb obou partneru provozovanych pred svatbou. Kdyz CTT koupil komercni Cesnet, byly (a stale jsou) nektere zakaznicke sluzby provozovany prakticky beze zmeny. Je mozne, ze v pripade PVT<>Nextra to je jinak, ale dost o tom pochybuji.
Takze, proboha si uvedomte, ze po zakoupeni casti konkurence _neni_ vasi hlavni cinnosti desinfikovat nakoupene zelezo a prenaset vse na vase puvodni stroje. Vasim prvoradym zajmem bude, aby pokud mozno nikdo ze zakazniku tuto zmenu nezaznamenal. Asi nebudete, alespon hned, pregistrovavat domeny z jedne entice vasich nameserveru na jinou emtici.
Proboha a vsiml jste si uz, ze Nextra a PVTnet je uz jedna a tataz sit, jen ma do NIXu dva pristupy ? Takze kdyz PVTnet podle Vas ma nameservery na "ruznych" sitich, jakto ze Nextra nema ?
Pri tvych nepopiratelnych schopnostech by nemelo byt tezke to v ramci firmy vykomunikovat. Je podivne, ze se spokojis s nadhledem nad chybami/lenosti firem, s kterymi mas co do cineni, potazmo pro ne pracujes.
Nicmene pripadne dalsi kolo teto diskuse navhuji spis jen mezi sebou :-)))
s utopii souhlasim :-)). Ale kdyz zalozni sluzby umistim dostatecne blizko zaloznim linkam, pak vypadek hlavni casti site nema za nasledek nedostupnost zaloznich sluzeb z okolniho internetu.
Sveho casu jsem u nejmenovaneho ISP z telekomunikacniho ringu nezavazne poptaval cenu za umisteni serveru prave pro tyto ucely. Odpoved jsem nedostal. To je potom tezke.
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 :-))
"Ruzna sit je jiny ISP. Nechci se chlubit, ale zkus zkusit totez u domeny pinknet.cz :-)"
Okay, necht. V tom pripade temer zadny (=nevim o zadnem) cesky ISP tomuto predpokladu nevyhovuje. Je fajn, ze domena pinknet.cz je na tom lip (moje soukrome domeny taky). Nicmene velke organizace typy ISP to tak jednoduche nemaji. Treba ten.cz (jeden AS), ze ano :) Pravda, potize maji i ti mensi, treba pragonet (jeden segment) :)
co je to sit? Mam za sit povazovat subnet, nebo sit urcite tridy, nebo jednoho ISP? Asi o tom lze polemizovat. Na druhou stranu z ceho poznam, ze stroje s IP 192.168.0.5 a 192.168.0.35 jsou na stejnem subnetu? Teoreticky muzou lezet v ruznych mistech republiky, pokud ma provozovatel dostatecne sileny adresni plan a silne paterni routery.
Pravdou asi je, ze jeden zalozni DNS/MX server mimo prostor ISP se hodi, riziko je ale na podle mne unosnou miru snizeno pri pripojeni na ruzne upstream provideru z ruznych bodu vlastni site.
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...
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 :)))
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)))
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)))
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
Jiste, pripoustim, ze situaci u jinych provideru neznam, proto jsem pouzil informaci, kterou si muzu zjistit (a overit). Puvodni clanek me ovsem ponekud nadzvedl (slusne receno) a utvrdil me v ponekud tendencnim zamereni Lupy. Proste jsem se nechal unest. Osobne predpokladam, ze vetsina provideru narodniho vyznamu ma nameservery nejen na ruznych sitich, ale i v jinych lokacich.
Soude podle vasi (opravnene) lehce rozhorcene reakce usuzuji, ze s puvodnim clankem take "lehce" nesouhlasite.
To jsem nevěděl. Díky za informaci. Ale stejně bych to dal alespoň jako doporučení, protože v té frontě můžou maily třeba po dnu vypršet. No ale zase je fakt, že celodenní výpadek by i tak byl docela průser...
Kdyz je znamy, ale nedostupny, tak mail zustane ve fronte na odesilacim mailserveru a muze byt dorucen pozdeji. Kdyz je ovsem neznamy, tak bude mail okamzite vracen odesilateli
trochu fer pristup by mozna neuskodil, u Contactelu uvadite ruzne lokality, u jinych nic. Bud zkuste zjistit udaje u vsech, nebo o nich nepiste, vyvolavate nespravne dojmy. Prinejmensim GTS ma nameservery rovnez umistenene v ruznych lokalitach
IMHO nestačí mít odděleně umístěné nameservery, ale taky více MX záznamů, a někde mít alespoň mail-relay, ne? Je sice hezké, že se dozvíte správnou adresu mail serveru, ale když je tento také nedostupný, tak to nepomůže.
Obavam se, ze autor ponekud prestrelil. Contactel neni z nejmensich ISP, ma webhosting, serverhosting i portal a MA nameservery na ruznych sitich, dokonce v ruznych lokalitach.
Vsechny domeny v Contactelu hostovane tedy jsou podobneho problemu usetreny.
Mimochodem, nemyslim, ze umisteni nameserveru na jednu sit je _bezpecnostni_ problem. Spis je to problem navrhu site. Ten muze byt byt spatny nebo dobry, ale jestli muze byt i bezpecny, pripadne nebezpecny, to si nejsem moc jist.
Nebezpecny muze byt samotny provoz, ale tezko umisteni.
Kazdopadne, straste lidi, piste pokud mozno poplasne ladene zpravy. Zvysuje to navstevnost ;)
Pro uplnost jsem se dival na nameservery nekterych ISP:
Contactel - ruzne site, ruzne lokality
GTS - ruzne site
IOL - stejne site
Eunet/KPNQuest - ruzne site
Nextra - stejne site
PVTNet - ruzne site
InWay - ruzne site
.... takze situace neni tak zla, jak vidno. Pokud si webhostingova sluzba chce delat DNS sama a udela si DNS nejlepe na dvou IP jednoho fyzickeho stroje, nemuze s tim ISP nic udelat. Krom toho, ze nabidne vlastni, lepe postavenou sluzbu.