Sziasztok!
Egy másik topic bejegyzéséből (és annak egész előzményéből) kiindulva kíváncsi lennék, hogy hogyan lehetséges az, hogy:
1) Vannak olyan szolgáltatók, ahol ma is a PHP 5.2 a preferált, pedig a biztonsági támogatása már lejárt,
2) Továbbá olyan CMS is van ott (Joomla 1.5), amely ugyancsak nem támogatott már.
Mégis működik, mégsem nyomják fel.
Én a részemről kínosan figyelek a PHP változatok és CMS-ek, LMS-ek biztonsági támogatására, ami pedig lejár, az vagy frissítendő vagy kuka. Azonban a fenti példából láthatóan nem mindenki ilyen szigorú.
A kérdés: ezek vagy felelőtlenek, vagy olyat is tudnak, amit én (még) nem. A második esetben Ti hogyan védenétek lejárt PHP-n futó lejárt CMS-t a támadásokkal szemben?
Kíváncsian várom a tippeket!
Köszi mindenkinek!
:-)
Hozzászólások
Ez a téma engem is érdekel.
Betolok én is egy csendes subscribe-t. :)
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Pont aktuális nálam a téma, subs
2) Szerintem a amíg az ügyfél fizet nem fogod cseszegetni, hogy nem támogatott az oldala. Amúgy meg, ha oldalt nem supportálod akkor miért fektetnél bele felesleges energiát? Főleg, ha több mint 1000 oldalt hostolsz. És igen Ők felelőtlenek. :)
De, fogom. Mégpedig azért, mert ha megtörik mégis, találd ki, ki lesz a fekete seggű pávián. Egység sugarú ügyfélnél szép lehetsz, de okos nem.
És lehet, hogy a másik társaság felelőtlen, de ott van az elvileg törhető Joomla az elvileg törhető PHP felett, és mégsem nyomják fel.
A lehetőség minden szolgáltatónak adott, hogy javítsa a hibákat a php 5.2-ben is, tapasztaltabbak maradnak a disztribúció által adott verziónál, amibe azért szokták backportolni a sec bugok nagy részét.
A profik meg bármelyik verzióba berakják azt a 30-40 patch-et, ami azóta megjelent, hogy zárták a php 5.2-t :)
"És lehet, hogy a másik társaság felelőtlen, de ott van az elvileg törhető Joomla az elvileg törhető PHP felett, és mégsem nyomják fel."
A legfrissebb verziókat csak egy kicsit nehezebb törni, de közel sem lehetetlen. Nem attól függ, hogy törik-e, hogy milyen alaposan frissítik, hanem hogy a hackerek robotja belefutnak-e a site-ba vagy sem.
Nem nem törik fel, csak nem veszik észre. :)
Na de komolyabbra fordítva:
Ha nem rakod agyon, mindenféle külső modullal a joomlat, akkor a régi verziókból az utolsó kiadás viszonylag nehezebben törhető meg. (Tapasztalatom szerint nem az alap cms miatt lesz áldozat az oldal, hanem valami külső galéria, fórum, akármi más rátelepített modul miatt, mert ugye a joomlat legjobb esetben frissíti az user, de a rátelepített modulokat már nem...)
Másrészt jól be kell korlátozni a php-s funkciókat, hogy semmiféle külső kódot ne lehessen lefuttatni, feltölteni stb.
Persze így is van, hogy feltörik, de legalább a scriptkiddiek ellen véd :)
Az osztott hosting mindig is erről szólt, évi pár ezer forintért, senki nem fogja összetörni magát, hogy ezeket állandóan figyelemmel kísérje.
Jobb helyeken legalább szólnak az ügyfélnek, hogy gáz van(ha gáz van), az értelmesebbje pedig ki is javítja, javíttatja, legalábbis mifelénk.
Akinek fontos a weboldala, és oda is figyel rá, annak még mindig a nagyobb gondot okoz talán , ha szerveren belül más oldalak megtörését is el lehet érni, amikor pl 1 régi joomlán keresztül elérnek más oldalt is.
A jelszavakkal sem lehet mit kezdeni, általános, hogy gyenge jelszót adnak meg wp-hez, csak a múlt hónap elején 1000-es nagyságrendben nyomtak meg magyar oldalakat.
Minden nap bot-ok százai keresik, és próbálják a jelszavakat, előbb-utóbb betalál 1-1.
1 kis stat az elmúlt 3-4 hónapok feltört oldalaiből, ezek fele szerintem szolgáltatói hiba, a szerver config-ban
F5 Big ip 1 db
Freebsd 46 db
Windows 2008 52 db
Win 2003 28 db
Win 2000 1 db
Unknown 19 db
Linux 1054 db
És elég sok szolgáltatót érint, valamikor 1 hónapja kérdezte ismerős tőlem melyik szolgáltatóhoz rakjanak oldalt, csak azért összesítettem, hogy lássák melyiknél mennyire lehet gáz.
Ezek mellé még ki kellene tenni, hogy hány darab ilyen szerver van, ui. nagyon nem mindegy, hogy 46 freebsd-s szerverből törték a 46-ot, vagy pedig 46 ezerből :)
Szerintem a PHP 5.2 azert maradt sok helyen fenn, mert az 5.2 es az 5.3 nem kompatibilis egymassal, van egy csomo valtozas, ami miatt az userek eszreveszik a frissitest, mert eltornek az oldalaik. Gondold el, van mondjuk csak 2-300 oldal (egy jol meno szolgaltatonal egy nagysagrenddel tobb), ott nem trivialis frissiteni. Foleg, hogy ekkora oldalszamnal mar nem csak a nyiltforrasu CMS-ek jatszanak a partiban, hanem az userek altal oda
hanytrakott sajat kod is.Persze, meg lehet csinalni egy upgradet, kikuldesz egy levelet, hogy most akkor mindenkinek van ket/harom/negy hete felkesziteni az oldalat, aztan gyalu, de ez alapvetoen nem a legszerencsesebb felallashoz vezet. Itthon ugyanis rendszeresen elofordulo problema az, hogy a cegek a weboldalukert meg csak-csak fizetnek, viszont karbantartast nem vesznek hozza, rosszabb esetben valami PHP Istvan vagy PHP Jozsef jonevu webdizajner rakja ossze az oldalt, aki leadas utan felszivodik mint eso utani napsutesben a tocsa. Es kesz, ismeretlen kodra nagyon nehez es/vagy draga dolog karbantartot talalni, aki lekoveti egyreszt az eredeti fejleszto hulyesegeit, masresz a PHP idiotizmusait.
--
+1
Oké, igazad van, de a kérdés ugyanaz: hogyan véded a vacak kódokkal összerakott oldalt, hogy azért valamennyire működőképes is maradjon a tiltó policyk tengerén keresztül? :-)
Shared hosting esetén is külön user minden website-ra, így egymáshoz nem tudnak átmászkálni. Ha valamelyik siteot megtörik, az az ő gondja lesz nem a tied.
Amúgy meg PHP frissítést úgy lehet a legszebben megcsinálni, hogy kedves ügyfél választhatja ki melyik verzióval legyen kiszolgálva az oldala. Így lehetősége van biztonságban futtatni a sitot, ha van rá igénye, és bele is sz@rhat az egészbe, ha nincs kedve foglalkozni vele.
Igen, csak a sok cpanel, plesk, meg egyeb tipusu cp-ken eleg nyugos ezt megoldani, mindenkepp kell hozza infra, a legjobb, ha mar kezdetektol fel van erre keszitve a rendszer. Eleg sok melo.
--
Melyik részére gondolsz, hogy nyűgös?
Per-site PHP verzio. Sem a CPanel se a Plesk, se egyik altalam ismert panel nem tudja ezt alapbol, mindenkepp fejleszteni kell hozza, meghozza eleg sokat.
A masik lehetoseg, hogy felepitesz egy N nodos hosting infrat, ahol az N a tamogatni kivant PHP verziok szama, es a regisztracios panelen az egyes PHP verziok kivalasztasa valojaban szervernevet jelent. Ez akar meg jo is lehet, de N gep, amit felugyelni kell, N darab panel licenc kell, stb., a koltsegvonzat egy pottyet nyugos. Ha 1-1 node egy chroot, az is jo otlet, de a chroot rendszereket is karban kell tartani.
A legegyszerubb, ha minden telepitett PHP verziot felpatcheled FPM patchel, es ugy uzemelteted, de mint mondtam, ehhez nem nagyon van panel, ami tamogatna ilyen felallast.
--
pleskbe bele lehet hackelni relative egyszerűen, ha nagyon kell.
Nem ügyfél állíthatja, hanem root, eseti alapon, de lehetőség van több verziójú php használatára.
lásd:
http://kb.parallels.com/114753
Hahh, mikre kepes mar a technika :-). Koszonom, errol nem volt tudomasom.
--
nem tudom, hogy működik -e.
A parallels fórumon olvastam először róla nem túl régen, egy user csinálta meg, és később beemelték a "hivatalos" dokumentációk közé.
A fastcgi/fcgid esetén viszonylag könnyen megoldható, hogy az exec után egy másik php verzióra mutató link legyen.
Kézzel kell hozzá birizgáló cuccot fejleszteni, de utána elég jól megy.
http://www.cloudlinux.com/blog/clnews/it-is-now-easy-for-customers-to-c…
Ez sajnos nálunk is probléma. Van 5.2-es PHP-val futó szerverünk mert az ügyfeleink nagy részének az oldala nem alkalmas 5.3-as kód futtatására. Ilyenkor persze próbáljuk őket tolni megfelelő irányba, de nem mindenki fizeti ki azt hogy most módosítani kell az oldalának a kódját, amiből valójában ő semmit sem érzékel. Sajnos ilyenek az ügyfelek, sőt, van aki azt mondja, hogy oldjuk meg mi a dolgot, ő kifizette az oldalát valakinek, tőlünk hostingot vásárol eddig is működött az oldala. Ilyenkor jön az hogy szinte mindig függvényt tiltasz amit lehet, tiltasz minden portot amit lehet nála, modsec megy fel maximális tiltásokkal.
A CMS frissítés a másik nehéz eset. Sok ügyfélnek el lehet adni olyan szolgáltatást, hogy mi mint hosting cég vállaljuk a Joomla/Wordpress/Drupal motorjainak a frissítését. Persze minimális összegért, mert sokan még erre sem hajlandóak.
A tény az hogy kétféle ügyfél létezik(persze nem ilyen egyszerű):
1. Akinek fontos szerepet tölt be a honlapja az üzleti életében és tudja hogy ezeket meg kell lépni és ugyan kikér minden információt de hajlandó segíteni és együttműködni a hosting céggel.
2. Aki ha megszakadsz akkor sem fog semmit tenni azon kívül hogy kifizeti az éves díjat.
Az ügyfelek fentebb leírt hozzáállást nagyon jól leírtad. És pontosan ez a baj. Mert én nem csak az ő, de a többiek érdekében is szeretném, ha nem lenne törhető alkatrészekből (CMS core, modulok, PHP változatok) összerakva az oldala, mivel lehet, hogy csak az ő tárhelyét nyomják tele vacak kódokkal, de az ezután elinduló spam áradat és egyéb huncutságok a normális ügyfelek oldala alól is elviszi a CPU-t, merevlemezt, RAM-ot és sávszélességet. Ha meg lezárod a weboldalát (pl. kimenő levelek), gyakorlatilag nem fog működni és akkor meg az lesz a baja. És mivel máshol nem ilyen szigorúak, még Te leszel a balfék meg béna, hogy amit más tud (védeni a sz.rt), Te miért nem.
Szóval a kérdés változatlan: hogyan lehet elfogadható szinten hostolni a gány PHP kódokat, de meg is védeni a támadásoktól?
Pl. a PHP 5.2 "köré" Ti mit húztatok fel?
"nyomják tele vacak kódokkal, de az ezután elinduló spam áradat és egyéb huncutságok a normális ügyfelek oldala alól is elviszi a CPU-t, merevlemezt, RAM-ot és sávszélességet."
Erre a cloud linux elvileg alkalmas. Oldalanként dedikált erőforrásokat osztasz ki.
Spam áradatra egyéni megoldásom: http://hup.hu/node/122043#comment-1570653
Elvileg? Oké, megnézem, de azért jó lenne, ha valaki kipróbált tapasztalatokat tudna mondani erről. Az oldalankénti erőforrás elosztás jól hangzik, de az hogy van, hogy például egyik MySQL user se vigye el a teljes CPU-t a többiek elől?
A Cloud Linux kb raepul az open source komponensekre. Ha sajat magad akarod betekerni, itt a howto.
Azért ennél egybegyúrtad a termék, meg nem ráépül, hanem saját megoldásuk van erre az egész dologra. Kernel modultól az apacs modulokon át, a mysql modulig, plusz a panelekbe beépülő felület.
aztan linuxfoldebol atmegy a konkurenciahoz, ahol kulon bsd jail-ekben kulon php verziok futnak az egyes siteokhoz, tokeletesen biztonsagosan
mulatsagos ez a topic, kerlek folytassatok!
És ez ugyanannyiba kerül, mint a hostolás linuxfolden?
:-)
Kb :)
Egyebkent linuxfolden is meg lehet ezt normalisan csinalni.
Hint: grsecurity + rbac, fcgi, kulon userek, stb...
úgy gondolod ez meg véd attól ha valahol sec bugos a joomla, vagy wp ? :)
de akár kérdezhettem volna a freebsd jailt is :)
az okozott kárt, és a töréssel okozható problémákat csökkentheti, abban egyetértünk
bár ez is attól függ kinek a szempontját nézzük.
Amíg csak modphp-ztek, ha jól be volt állítva a jogosultság, akkor csak az upload,cache könyvtárakat b*sztatták, ma már mivel elterjettebbek az fcgi-s, suphp-s megoldások, már nyitó oldalt megnyomják, mivel arra is lett írásjoga, legalábbis jellemzően van írásjoga. lásd: http://cvdatabas*.hu/
És amíg az ügyfél lesz*ja, hogy feltöltöttek 1 levél küldő php-t upload-ba, amikor a nyitó oldal-t megnyomják rögötn szól ha észreveszi? mondjuk így legalább a szolgáltató értesül róla( :) ), nem úgy mint a fenti esetben ami már 10 napja így van.
- Vannak eljárások a webtartalmak scannelésére, hogy tartalmaznak -e rosszindulató kódot.
- Vannak eljárások a levélforgalom elemzésére, hogy spammel -e valamilyen php kód (sőt, adott esetben alapből lehet tiltani a levélküldést php-ból, és ha szüksége van rá a usernek, akkor egy "figyelő listára" kerül. Egyébként nem feltétlen kell feltölteni php kódot, hogy a egy site-on keresztül spammeljenek. Egy elbaszott hírlevél feliratkozó modulra ha rászáll pár száz kínai bot, akkor tisztességes mennyiségű spamet tudnak kilőni vele majdnem bármilyen címre.
>> A kérdés: ezek vagy felelőtlenek, vagy olyat is tudnak, amit én (még) nem
Itt vajon a szolgáltatókra gondol?
Ez egyébként engem is érdekelne :), vajon melyik szolgáltatóra gondol, ahol nem törik meg a joomlákat, stb.?
Szvsz. egy bugos Joomlát, wordpresst vagy bármi más szar user kódot bárhol megtörnek.
A cms rendszerek hátránya, hogy mivel a felhasználó nagyon sok mindent tud kattintgatva módosítani, ezért sok írási jogosultság is kellhet neki.
Ezt a kockázatot lehet csökkenteni az írási jogok megszüntetésével. Sok site esetén ez meg is oldható, egyszer megcsinálják az oldalt, és utána már nem akarnak modulokat telepíteni, fájlokat feltöltögetni.
Ami szerintem inkább a szolgáltató felelőssége, hogy a törés lehetőleg:
1. ne veszélyeztesse a többi oldalt, vagyis azon keresztül ne lehessen módosítani más oldalakat.
2. minnél hamarabb detektálva legyen, ne tudjon malware-t spamet terjeszteni.
A szolgáltatókra gondolok, egy kedves ügyfél pedig a mediacenter.hu szolgáltatóról beszélt, mondván, neki van ott 1.5-ös Joomla és köszöni, de jól érzi magát.
idő kérdése és megtalálják.
Alapból botok scannelik a domain neveket. Kis forgalmú site-okat, jelentéktelen domain neveket kisebb valószínűséggel találják meg a scanner botok.
Évek óta látok nagyon régi verziójú joomla site-okat gond nélkül futni.
Ezek közül havonta 1-2 darab áldozatul esik valami törésnek. Van olyan amire évek óta nem került sor, mert kb 4-5 látogatója van naponta. Egyszer kell csak, hogy rátaláljon egy bot, és szevasz...
LOL :)
hány megnyomott mediacenteres oldalt postoljak most ide, amin mai napig kint van a hack.
btw, a már említett fentebbi xls-ben szerintem mcenteres a legtöbb, gondolom azért meg nagyobbacska szolgáltató, ezt nem tudom, nem ismerem őket, de mivel a szerverek szerint csoportosítva s1-től s50-ig vannak benne gondolom nagyobbnak számítanak.
Szerintem ezt csak az nem tori fol aki nem akarja.
Mediacenter admin felületén ki tudom választani magamnak:
PHP beállítások
PHP verziószáma:
4.4.4
5.2.17
5.3.21
5.4.11
Meg ez se feltetlen kell, a php-fpm kepes chrootban is futni, raadasul nagyon minimalis chroot kell neki, mert betolti magat, mielott chrootol, csak a extensionok altal hasznalt libeket (peldaul a gd, mysql, stb cuccait) kell berakni a chrootba, maganak a php-nak a fuggeseit nem.
--
ez mukodik, a linuxos nyomiskodas meg nem.
penzrol felesleges beszelni.
Ez így gazdaságos? Mert ugye nem minden hosting cég One-Man-Show.
Jailben a php interpreter van vagy az adott (alacsonyabb verzió számú php-t igénylő) oldal is?
linuxfolden is meg lehet csinálni minden major php verzióhoz külön vps-el.
Sőt, egy oprendszeren belül is meg lehet oldani külön php verziók használatát, és még jail-el sem kell szarakodni.
A probléma nem a php verziókkal van, hanem a sechole-okkal teli user kódokkal.
Ha meg minden ügyfélnek külön jailt akarsz csinálni, hát have fun....
linux vs bsd rejszolásnak nincs értelme.
Ha valaki ért hozzájuk bármelyikkel megoldható a feladat.
Ha nem ért hozzá, akkor meg valószínűleg linuxozni fog, így alapot teremt a bsd arcok nagyképűségére... :)
> Ha meg minden ügyfélnek külön jailt akarsz csinálni, hát have fun....
aki ert hozza, annak ez semmi, fel perces ujjgyakorlat. aki nem, az meg ugyis csak referenciaerteknek (nullpont) jo ezen a teruleten.
kulon zfs-ekben lehet tarolni az alaprendszer(ek)et, az egyes jail-ek pedig zfs clone-ok. ezzel a helyfoglalas is le van tudva. upgradelni eleg csak a base rendszert, a tobbit pedig ujraklonozni. a nagyon bugware php-k folyamatos felnyomasa akar cron-bol is automatikusan visszaallithato, mivel az egyes jail-ek kulon-kulon is snapshotolva vannak.
a linuxos apacsis modulos meg egyeb hulyeskedesek - amiket felhoztok - meg arra valok csak hogy az ember kirohogje oket.
de mint megtudtam, ez valojaban nem is mukodik, illuzio amit csinalok evek ota :(
> Ha meg minden ügyfélnek külön jailt akarsz csinálni, hát have fun....
aki ert hozza, annak ez semmi, fel perces ujjgyakorlat. aki nem, az meg ugyis csak referenciaerteknek (nullpont) jo ezen a teruleten.
a linuxos apacsis modulos meg egyeb hulyeskedesek - amiket felhoztok - meg arra valok csak hogy az ember kirohogje oket.
de mint megtudtam, ez valojaban nem is mukodik, illuzio amit csinalok evek ota :(
"aki ert hozza, annak ez semmi, fel perces ujjgyakorlat"
már százas nagyságrendben is gáz. Ezresben főleg
"illuzio amit csinalok evek ota "
hány ezer jail-el?
De ha esetleg van egy automata megoldásod rá, amivel két kattintás egy új user beálllítása jail-el, meg minden egyéb sallanggal mert akkor nem szóltam.
termeszetesen van
egyebkent a titok nyitja egyszeru: azokat a dolgokat kell hasznalni amiket tery meg a tobbi hupu ismeretlenul is lenez a faszba testuletileg
Akkor hajrá.
Mindenki csinálja a dolgokat a maga perverziója szerint.
A titok nyitja inkább az, hogy azt kell használni amihez értünk, vagy érteni akarunk. Hogy ki mit néz le, számomra baromira nem mérvadó.
> A titok nyitja inkább az, hogy azt kell használni amihez értünk, vagy érteni akarunk. Hogy ki mit néz le, számomra baromira nem mérvadó.
minel tobben valljak ezt az keleti bolcsesseget, annal tobb penzem lesz, ugyhogy pluszegy!!
Ez hogy is véd a lejárt CMS/PHP törése ellen?
hagyjad, már válaszolt rá
>>de mint megtudtam, ez valojaban nem is mukodik, illuzio amit csinalok evek ota :(
ugye ilyenkor jon a kepbe az, hogy akar csak egy picit is erteni kene hozza, es akkor tudnad, hogy "az ellen nem ved" ... viszont az ellen igen, hogy utana ne a hupun nyisd a "Feltortek, de hogyan??!!" topicokat, hanem asitasz, kiadsz 1 command-ot es visszaall az egesz az eredeti allapotra.
Igen, bár én ásítás helyett teát főztem, de ugyanezt csináltam 'linuxfolden' is, hihi.
Csupán azért bátorkodtam ilyen hozzánemértő kérdést feltenni, mert ugye a kérdés erről szólt, nem arról, hogy jó-e a BSD jail.
És ha belegondolok épp ekkor kell nyitni azokat a bizonyos topikokat, mert valahogy ki kellene kalapálni/kerülni azt a nyomorult bugot, vagy crontabból kell visszaállítani a jailt vagy bármit.
Özvegy Halpakker Dodóné 1983-ban vásárolt egy témát az 1.0 joomlájához. A pénzért vásárolt téma nem működik az újabb joomlával és a táma készítője már kertészként praktizál 1984 óta. Sakk-matt.
--
maszili
Látom itt sírnak hogy 5.2 vs 5.3 php, ugyanmár, nálunk még 4.3.x is van, és alig lehet megértetni az ügyféllel, hogy ez miért gáz. Persze érthető a z Ő részük is. Egyszer valaki megcsinálta kifizette működik. Ennyi. Többet nem akar áldozni rá. Majd mikor széthekkelik akkor mondjuk, hogy ennyi volt ideje lépni, és akkor nagy nehezet rávehetők, de a többség inkább csak a backupokat akarja visszaállítatni, meg lecserélik a jelszavakat, hogy jó lesz az még :/
Fedora 17, Thinkpad x61s
Valahol érthető. Nehezen egyeztethető össze azzal a megszokással, hogy megvette anno egy EVRIKA fél-automata mosógépet és 20 évig ment :)
Itt igazabol csak az a kerdes, hogy mennyi szivast okoz. Ha neki virusos a siteja, lelke rajta. Ha meg rendszeresen tulterheli a rendszert, akkor fel kell bontani a szerzodest.
a hosting cégnek sem érdeke, hogy vírusos legyen.
Annál inkább mert a trójaik mellett levél küldő kódot is előszeretettel raknak fel, arra meg tényleg a hoster is ráfarag.
Vannak erre megoldasok, lasd lejjebb.
Na igen, engem is meglepett, hogy az 5.2-ért már ekkora a nyafi, legutóbb, mikor valami hostolt szemetet meg kellett néznem, úgy indult, hogy .php3 és utoljára talán PHP4.0-hoz - de max 4.1-hez - lett hozzáigazítva a kód. Persze, ott már arra nem futotta, hogy azokat a függvényeket, amelyeket időközben belelapátoltak a PHP4-be, azoknak az "újraimplementált" változatát kipucolják...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
amúgy van amikor az ilyenről nem is az ügyfél tehet, mert egyszerűen a fejlesztő volt olyan amilyen, és nem veszi a fáradtságot, hogy elmagyarázza a vevőjének, hogy "öcsém ezt bizony x havonta karban kell tartani, ezért és azért..." Neki is jobb lenne, hiszen havidíjat is szedhetne a folyamatos frissítésért, de valószínűbb hogy inkább amolyan építőipar-jelleggel dolgozik a "fejlesztő". Miután eltűnt, mint szükre szamár a ködbe, már nem tud a vevő másra mutogatni, mint a hostingra...
(Persze itt is az ügyfél döntött rosszul, mert "olcsón - űrrepülőt" akart, aztán aki elvállalta, hogy lefejleszti annyiért, az olyan is lett.)
Nem akart olcsón űrrepülőt, csak ezer éves projekt volt, amely nem termel annyi hasznot, hogy megérje befektetni még.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Van egy külön szerver a régi vackok életben tartására.
A másik probléma a különféle cms-ekkel, hogy php verziótól függően időnként sechole-ok bukkannak fel, és napok kérdése csak, hogy trójaikkal legyen tele a Joomla vagy wordpress site.
Ugye ilyenkor is frissíteni kéne, amit a szolgáltató szintén nem csinál meg ingyé....
Álltalában a document-rootra és teljes tartalmára megy a read-only , ha ismert sechole van, és nem hajlandók frissíteni.
Ezek után nem nagyon szokott sikeres lenni a köv. exploit kísérlet.
Sajnos deface elég kevés van, mert az álltalában azonnal meggyőzi az ügyfelet a frissítésről.
+1 régi vackok külön gépre, szekurizálva. :)
Így pedig elhangzott a topiknyitó kérdésre az ultimate válasz: Document root -> Read only (+SQL)
+: reklamáció esetén egyedi folder szintű engedély, plusz munkadíjért.
Ebben az a jó, hogy nincs vele sok munka, mert ember nem fog ott hostoltatni :D
Nincs az az übersec hosting környezet, ahol egy elcseszett joomlában nem tudnak custom php kódot beinjektálni.
Az eljárás ilyenkor a következő:
1. kód megtisztít, vagy korábbi jó mentés visszatölt.
2. teljes docroot read-only
3. ügyfél értesít
4. read-only mód lekerül a megbeszélt időben hogy ügyfél frissíteni tudjon.
5. ha ügyfél nem akar frissíteni, marad a read-only mód.
6. ha a read-only mód probléma, akkor ügyfél menjen ahova akar.
szerintem ez egy elég korrekt hozzáállás, ami mindkét fél érdekét messzemenően figyelembe veszi.
A szar kóddal az is baj, hogy ha a törés nem is jut ki, előbb utóbb mindenféle feketelistán lesz a szerver IP címe, mert trójait hostol.
A szerver IP cime eleg ritkan kerul feketelistara, tobbnyire domaineket szoktak listazni. A baj akkor van, ha van egy csillagos aldomained es az alatt hostolsz mindenfele szart, mert akkor azt ugyanis egy domainnek veszik sok esetben.
Ha kinyomnak pár tízezer spamet rajta keresztül, akkor előfordul, hogy kapsz egy levelet, hogy a teljes tartományod spam listára kerül, ha nem csinálsz valamit....
Anno mi azt csinaltuk, hogy egy bizonyos level mennyiseg folott (talan 30 db / 1 perc, 200 db / 10 perc, 1000 db / nap) a leveleket visszatartotta a rendszer. Ezt ket Exim instance-al kenyelmesen meg lehet csinalni, addig ott figyel a queueban. Ezen felul lehet hasznalni bayes-szurot (pl. spamassassin) es lehet ugyfelenkent adatbazisban szamolgatni, mennyi a spam. Opcionalisan le is lehet tiltani az ugyfelet automatikusan adminisztratori revizioig.
Ez nem csak azert jo, mert nem fogjak szetspamelni a vilagot, hanem mert a szarul megirt, rosszul felkonfiguralt, galambfos hirlevelszoftverek nem zuzzak szet a gepet.
A spamelesre egy pillanatra visszaterve, a 3 csapas megoldas nagyon jol mukodik. Ha eloszor spamel az accountja, letiltodik es felhivodik az ugyfel. Ha megoldja a problemat, lekerul a tiltas. Masodikra egy hetet pihen minimum, harmadikra pedig szerzodes felbont. Lattam olyan ugyfelet, aki bekozolte, hogy ja neki ugyse kell a levelezes.
okés, ez mind teljesen jogos, és egyértelmű, viszont konkrétan nem egyszer fordult már elő a praxisomban , hogy spam-trapra küldött a php kód levelet, igy igaz, hogy csak pár 100 spam ment ki, viszont már jött is a hőbörgés a spam-trapot üzemeltetőtöl.
Mindegy, nem kötözködni akarok, mert teljesen igazad van a fentebb leírt eljárásokkal kapcsolatban, csak azt az állításod próbálom cáfolni, hogy egy rosszindulatú php kódtól még nem kerülsz feketelistára. :)
Szerintem (hangsulyozottan) a problema kezelheto anelkul, hogy az ugyfelet tulzottan buntetni kellene. Nyilvan lesz 1-2 ugyfel, akit ki kell rakni, de a tobbseg hajnaldo lesz egyuttmukodni vagy a korlatozasban, vagy a javitasban.
ez így van.
A docroot-readonly sajnos sokszor nem járható út mert akkor egyáltalán nem működik az oldal. Pl. a smarty folyamatosan hoz létre php fájlokat a működése során.
--
maszili
Az a lényeg, hogy ahol kell, legyen karbantartva a kód.
Hiába izolálod a rendszer többi részétől, magát az oldalt szét fogják cseszni.
Ha az ügyfél ennyire nem képes ezt megérteni, akkor okozzon máshol gondot.
A smarty önmagában egy hatalmas tévedés.
No rainbow, no sugar
azt ugye vágod, hogy itt most nem a konkrét termékekről szól a topic, hanem inkább elvekről.
Az teljesen lényegtelen, hogy a Joomla/Wordpres/Smarty/ACMEcms jó -e vagy sem.
Anno kellett ilyenekkel foglalkoznom:
Muszaki modszerek:
Policy-modszerek:
Az olyan modszerek, hogy PHP-bol fuggvenyeket letiltogatni, open_basedirt allitani csak hackelesek, rendszer-szinten kell megvedened a gepedet. Az ellen amugy sem tudsz tenni, ha a user sajat maga keszit vulnos scripteket vagy ne adj Isten o probalkozik felnyomni a gepet.
Érdekes, melyik szolgáltató?
Semelyik, ez a tapasztalatom alapjan a kovetendo eljaras. Egyebkent dolgoztam szolgaltatonal, ha picit utanaasol, meg is talalod (ez nem a reklam helye), de persze nem pont ez a technologia van ott.
Egyebkent szivesen fejlesztenek hosting technologiat vagy valami telepitheto panelt, de sajnos a kornyezetemben nem akar senki ilyen munkat ajanlani. :) Ahogy igy elnezem a hosting szolgaltatokat es a piacon kaphato *panel szoftvereket, nem igazan latok olyat amelyik tisztessegesen meg lenne csinalva. Aki egyszer fektetett is bele energiat, utana nem maradt rajta a teman, hanem azzal a technologiaval akar uzemeltetni a kovetkezo 10 evben.
Es pl. muszaki resze volt a kenyelmes de zuros/bugos dolgok (ftp (mentett jelszo..), chmod buveszkedesek (777), tavoli eroforrasok (url, image, banner stb.)) tiltasa, alternativa/doksi biztositasa? Mert ezek hianyan sokszor programozok is fennakadnak, nemhogy enduserek :(
A listad es az elv amugy teljesen jo, ajanlhato masoknak is :)
Az FTP-rol mar megirtam a velemenyem. Meglepoen sok ugyfel raveheto a WinSCP hasznalatara es a szerver oldalon meg hasznalhato a ProFTPd + mod_sftp. Szerencsere a virosok meg nem ismerik a WinSCP-t, plusz lehet kulcsos autentikaciot hasznalni (akar ugy, hogy egy webes feluleten generalunk az ugyfelnek kulcsot), amit egy picit nehezebb ellopni.
A chmod buveszkedesekre baromi jo a chroot, igy mindenki azt teker maganak amit akar, mas ugyse lat bele.
Szerintem egy jo doksival es szakkepzett supporttal nagyon sok problema egesz konnyen orvosolhato. A legtobb ugyfel nem ordogtol valo, gonosz vagy eppen nemtorodom, csak nem ert hozza. Igy hat olyan alternativat kell neki ajanlani, amit megert.
Pl. meg a megboldogult extra.hu idejeben meguntuk, hogy allandoan jott valaki hogy kellene biztonsagi mentes, igy hat tartottunk egy "hot copyt" az egyik backup storageon, amire be tudott a sajat FTP jelszavaval lepni. Lass csodat, par heten belul elterjedt a neten, hogy ilyen van es megszuntek a requestek.
"Minden PHP site fusson sajat rendszerfelhasznalo alatt, lehetoseg szerint sajat chrootban vagy akar LXC containerben."
Arra milyen megoldást tudsz hogy minden PHP site fusson saját LXC containerben?
Hirtelen a hasamra csapva elinditasz egyetlen FPM poolt az LXC containerben, a webszerver pedig TCP-n csatlakozik ra.
BTW FYI, http://buhera.blog.hu/2013/05/29/drupal_org_breach_rails_botnet
Sziasztok,
pont emiatt szivok en is egy szerverrel, mert a ceg tulaja nagyon nehezen all at regi joomlakrol az ujra, emiatt php-t sem lehet frissiteni. Persze, megertem, csak azzal en sem, o sincs elorebb. (Biztonsagban)
A legtobbnel a tiny_mc szerkeszton keresztul kuldheto ki email, mindenfele auth nelkul, illetve fileokat toltenek fel.
Ilyenkor igen, ro mod, rosszabb esetben karban tartas kiirasa es/vagy honlap atiranyitasa.
1-2 eve megy ez a dolog, annyit tudtam csak tenni az ugy erdekeben,hogy php security patch ( http://code.google.com/p/php52-backports/ ), suhosin, mod_sec es file feltolteskor viruskereses.
Ezutan mosom kezeimet, en jeleztem, az egyeb rendszergazdai teendoket ellatom.
Hatha masoknak is segit a dolog.
A Joomla 1.5.15-től PHP 5.3 barát, tehát az 1.5 maradhat, ha megkapja az update-et.
Persze, hogy barat, csak eppen regebbiek a joomlak es sok van beloluk :)
Éppen most írom bele az új ÁSZF-ünkbe, hogy az ilyenek figyelmeztetés után kihajítódnak.
--
Gábriel Ákos
http://i-logic.hu
"Mégis működik, mégsem nyomják fel." szerintem felnyomják időről időre. A joomlát tuti. Jó esetben annyira korlátozott a tárhely, hogy más oldalra nem hat ki, emailt küldeni nem tud, azt kész.
subscribe. jo topic.
--
http://www.micros~1