B2B online marketing blog

b2b online marketing - azaz online marketing üzleti oldala.

Cseh BalázsBalee
digitális divízióvezető
CompLex Kiadó, Wolters Kluwer


adwords_certified_partner_web_HU.gif

Aztmondják...

Jogszabály v. cégkereső:

CompLex

Jogszabályt Céget

Ezeket olvasgatom

Licenc

Creative Commons Licenc

Palesztin hackertámadás - avagy legyen vészforgatókönyv

2011.01.23. 11:07 Cseh Balázs - Balee

Örülünk, ha kész a honlap, örülünk, ha keresőbarát, örülünk, ha fut rá PPC kampány, örülünk, ha van adatbázisunk és kiküldünk eDM-eket, hírleveleket. Nade... mi történik, ha egyik reggel egy oltári nagy "Free Palestina" pompázik az oldalunk helyén? Nem örülünk :(

  1. Mi történt? Mit csináljak? Kit hívjak? (kétségbeesés)
  2. Miért velem? Mi közöm nekem Palesztinához? Miért az én honlapom? Miért nem mennek el a ... (harag)
  3. Miért nem veszi fel az a kocsog rendszergazda szombaton reggel 7-kor? Miért nincsen ügyelet a szolgáltatónál (harag2)
  4. <eltelt 2 óra> Miért van még kint a felirat? Miért nem csinál senki semmit? (harag3)
  5. <újabb 2 óra eltelik> Basszus, fut Adwords kilóra, csak épp az oldalon marhaság van kint, miért nem állítottam már le? Miért nem írtam össze előre, hogy ilyenkor mit kéne csinálni (önmarcangolás)

Mindezt megelőzendő összeszedtem egy check-listet, hogy ha esetleg bármi probléma történik az oldallal, akkor legyen egy vészforgatókönyv, to-do-list ilyen esetekre.

De először is egy-két probléma, ami előfordulhat, hogy mindenki felismerje, igenis szükség van vészforgatókönyvre:

  • a szolgáltatónál áramkimaradás van, emiatt nem elérhető a honlapunk
  • a szolgáltatónál minden rendben, a szerver ment tönkre a honlap alatt (akár saját, akár szolgáltató adja, ez is megeshet)
  • feltörték a szolgáltató szerverét / saját szerverünket és felülírják a honlapot (ld. a hackertámadásos biznic a címben)
  • túlterhelt az oldalunk (online marketingesnek jó pont, ha kampány miatt, programozónak rossz pont, mert elvileg bírnia kéne a terhelést az oldalnak :)), emiatt nem elérhető
  • rendszergazda/programozó frissített valamit a kódban v. esetleg ha ingyenes CMS-t használunk, azt frissítette valaki, csak épp rosszul -> nem elérhető az oldal
  • programozás során rejtett hiba keletkezett, és egy meghatározott user tevékenységre szállt el az oldal (php, adatbázis, stb. bármivel megeshet) -> saját fejlesztésű oldal esetén van rá esély, de láttam már ingyenes CMS-t is letérdelni
  • és bármi ami csak megeshet a meteorrajtól a részeg buszsofőr hajt bele a szolgáltató épületébe, egészen az elromlott router-switch párosig, a lehaló winchesterekig, stb.stb.

Hogy készüljünk fel?

  • biztonsági mentés! - legyünk tisztában azzal, hogy ki-mikor-hol-milyen módon készít biztonsági mentést. Általában minden tárhelyszolgáltató ezt már alapból biztosítja, és megfelelő időközönként készít mentést. DE jó tudni, hogy a mentésből visszaállítás általában nincsen ingyen. Nem csinálja meg ingyen a szolgáltató sem, a programozó/rendszergazda sem.
    Én annak a híve vagyok, hogy min. hetente mentsük le mi is a biztonsági mentést egy őrzött helyre, de legalábbis pontosan tudnunk kell a fenti kérdésre választ. Ha baj van, akkor ugyanis az utolsó mentsvárunk ez lesz, ha a hiba/probléma nem javítható, akkor a végső megoldás visszaállni egy korábbi, mentett állapotra.
  • elérhetőségek - mindig legyen kéznél a rendszergazda, a programozó és a szolgáltató elérhetősége, és jó ha tudjuk azt is, hogy ők hogy dolgoznak időben. Pl. elérhetőek-e munkaidőn kívül? Elérhetőek-e hétvégén/ünnepnap? Mennyire lelkiismeretesek? Felveszik-e a telefont ilyenkor, vagy pénteken délután 5-kor kiesik a kezükből a mobil és az egér?
    Mit vállal a szolgáltató? Van-e ügyelet sürgős esetre? Ezek mind kulcs információk, szükségünk lesz rá a check-list során!
    Széljegyzet: egyáltalán egy helyen hosztoljuk-e minden oldalunkat? Ha nem, akkor pontosan kell tudnunk, hogy melyik oldal melyik szolgáltatónál van, és ott kit-mikor érhetünk el!
  • hozzáférések - bár elvileg elég ha a rendszergazda/programozó van tisztában a hozzáférésekkel, mégis azt mondom, hogy igenis tudnunk kell nekünk is a hozzáférést a tárhelyekhez, az adatbázishoz, a honlap adminisztrációs rendszeréhez, Adwords, Etarget, Facebook hirdetési fiókunkhoz (főleg, ha ügynökség csinálja a kampányt!), a statisztikákhoz, Webmaster Tools-hoz, mindenhez! Vészhelyzetben lehet, hogy egy-egy ilyen háttérinformáció fog életet menteni!

Check-list, amikor reggel Palesztin jókívánság vagy üres oldal fogad

  • más is ezt látja? - Hackertámadás esetén szinte 100%, hogy mindenkinél a "jókívánság" látszódik, de pl. ha az oldalunk helyén üres oldal van, akkor feltétlen ellenőriztessük valakivel, aki épp online az IM listánkon (IM = instant messaging, pl. MSN, Facebook, GTalk, Skype, stb.). Szinte bármilyen probléma esetén elsőre célszerű segítséget kérni az online felhasználóktól: "te, nálad is ez jön be"?
    Még egy ötlet: www.anonymouse.org egy olyan szolgáltatás, ami elrejti az IP címet, és lehetővé teszi azt, hogy kívülről, más országból nézzük meg az oldalunkat, azaz hogy látszódik pl. Amerikából. Ha senki nincsen online, ez is megoldás.
    Gondoljuk tehát végig azt, hogy ki az, aki általában online van, elérhető, és van olyan jó ismerős, hogy ilyen esetben zaklatható. Továbbá ne feledjük, mi is segítsünk a másiknak, ha ő van hasonló cipőben :)
  • ha beigazolódott a gyanú, hogy más is ugyanazt látja és az oldalunk eltűnt, akkor (bár ezt a legnehezebb betartani), várjunk kb. 5 percet, mielőtt beindul a folyamat. Megeshet ugyanis az, hogy a szolgáltatónál történt átmeneti hiba, pl. szerver újraindítás van, és lehet, hogy 5 perc múlva már vígan fut az oldalunk. Ha így lenne, akkor is érdemes felvenni a kapcsolatot a szolgáltatóval és az informatikusokkal, hogy tudjuk mi történt és mennyi ideig tartott.
    Hackertámadás esetén NEM kell várni :) Ott nem fog csoda történni 5 perc múlva sem :)
  • informatikus/programozó zaklatása + PPC kampányok off - kezdjünk el utánamenni a problémának és minimalizálni a károkat. Mivel beigazolódott, hogy a honlappal gond van, jó eséllyel mostantól minden reklámmegjelenés kidobott pénz, amit az oldalra irányítunk a hiba elhárításáig. Mivel lekapcsolni egy PPC kampányt pont egy kattintás, akár mi kezeljük az Adwords/Etarget/Facebook fiókot, akár ügynökség, mi jogunk és felelősségünk (és lehetőségünk) lekapcsolni a hirdetést. Elvégre a mi pénzüket költjük épp feleslegesen, majd ha már a vészhelyzet elmúlt, akkor emailezgetünk az ügynökséggel, hogy mi történt.
    Ezzel párhuzamosan kezdjük el vadászni telefonon az oldalt fejlesztő céget v. programozót, ehhez kell az, hogy a szükséges telefonszámok kéznél legyenek! Ők ugyanis jó eséllyel rögtön hozzáférnek a szerverhez és látják/láthatják, hogy mi a hiba oka.
    Sőt, megkockáztatom, hogy innentől az ő felelősségük a helyreállítást továbbvinni, egyeztetni a szolgáltatóval, stb., de ez persze megállapodás és hozzáállás függvénye. Kis szerencsével innentől mind a hibajavítás, mind az esetlegesen szükséges backup visszaállítás már nélkülünk zajlik, de az ördög nem alszik...
    Lehet, hogy a következő pont is a miénk lesz:
  • a szolgáltató zaklatása - ha az informatikus felteszi a kezét, hogy ő nem tudja, és nem is intézi tovább, akkor amellett, hogy a vészhelyzet elhárultát követően érdemes átgondolni a további közös munkát, hívjuk a szolgáltatót, megint csak ehhez kell az, hogy tudjuk mikor-kit és milyen számon lehet keresni. Mivel egy-egy tárhelyet kiszolgáló szerveren több honlap is helyet kap, jó eséllyel már értesültek a hibáról mástól, de ha nem, akkor főleg jó, ha telefonálunk. A szolgáltatónak viszont NEM kötelessége bármit is tenni, ha magával a honlappal van gond, pl. feltörték hackerek. Ő segíteni fog abban, hogy kiderüljön, mikor törték fel, és esetleg abban is, hogy mi volt a biztonsági rés/hiba az oldalon, feltéve, ha mindezt látja az ún. log fájlokban (ezek rögzítik a weboldalon történő eseményeket), de az oldalba még egyszer: NEM fog belenyúlni.
    Ő két dolgot tehet:
    - ha szolgáltatói hiba, akkor megpróbálják elhárítani amilyen gyorsan csak lehet
    - ha honlappal kapcsolatos hiba, akkor vissza tud állítani korábbi mentést, biztonsági mentést, pénzért. De ez sem garantálja azt, hogy a hiba v. esetleg a hacker támadás ne forduljon elő. A biztonsági rést ugyanis nem foltozza be.
  • többi kampány off - ha ezen a ponton úgy tűnik nagyobb a hiba, mint azt szeretnénk (értsd: akár fél-1 napig is elhúzódik a javítás), akkor kezdjük el leállítani a többi fizetett kampányt is (pl. banner megjelenések, betervezett eDM, stb.). A médiafelületeknek sem érdeke olyan oldalra vinni látogatót, ami oltári nagy hibaüzenetet ír ki, vagy csak simán nem elérhető.
    Ehhez kell az ügynökség, direkt vásárlás esetén pedig a médiafelületnél a kontaktunk elérhetősége.
  • biztonsági mentés - eljutottunk a lényegi részhez, amiért a bejegyzés született. A szolgáltatónál nagyon jó eséllyel lesz biztonsági mentés, de az informatikusnál/programozónál már nem biztos. Megeshet, hogy a hibajavítás már nem lehetséges vagy túl nagy erőfeszítéssel járhat, és célszerűbb visszaállni egy korábbi állapotra, és ott javítani a hibát, mert pl. a hacker túl sok mindent átírt, túl sok mindenbe belenyúlt már.
    Ekkor jó, ha nálunk is van biztonsági mentés, és nem kell ezt kérni, kérvényezni a szolgáltatótól, vagy azt keresgetni, hogy na vajon kinél állhat ez rendelkezésre.
  • final check - ha a hiba javításra került, akkor jön a teszt, az ellenőrzés. Akár javítás történt, akár rendszerhiba volt és minden megy a régiben, teszteljük az oldalt. Regisztráljunk, rendeljünk, fórumozzunk, teszteljük az admint, töltsünk fel hírt/cikket/terméket/szöveget bármit, hogy lássuk, minden funkció működik-e megfelelően.
  • restart és külső check - ezt követően indítsuk csak újra a kampányokat, tehát csak akkor, ha minden működik megfelelően és a konverziós folyamat (rendelés, regisztráció, stb.) tökéletesen működik ismét és a "még online lévő" ismerőseink is ugyanúgy tökéletes működésében látják az oldalt.
  • utógondozás - mindig menjünk utána a hibának és próbáljuk kideríteni a felelősségeket. Én annak a híve vagyok, hogy derüljön ki az, hogy ki a felelős, de NEM azért, hogy felnégyelve felhúzzuk a várfokra, hanem azért, hogy a következő hasonló esetben könnyebb legyen eljutni ahhoz, aki a megoldást nyújtja majd nekünk. Derítsük ki, hogy mi volt pl. a biztonsági rés és teszteljük le magunk, kérjünk meg mást, hogy tesztelje le, és próbáljunk hasonló hibalehetőségeket találni, hogy legközelebb ne erre ébredjünk :)
  • + természetesen legyen kéznél a check list mindig ;)

Szólj hozzá!

Címkék: backup informatika honlap site hacker támadás rendszergazda programozó informatikus back up

A bejegyzés trackback címe:

https://b2bonline.blog.hu/api/trackback/id/tr222606699

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.