Kontrola integrity súborov na hostingu

Aktualizoval som jednu svoju webovú aplikáciu. Je to nástroj, do ktorého nepotrebujem po inštalácii ďalej rýpať. Meniť čokoľvek v jednotlivých súboroch. Ani len zásahy do šablón pre vzhľad netreba. Dokonca ani sa, ako je rok dlhý, nemusím do adresárov pozrieť. Aplikácia funguje, zbiera a ukladá dáta do databázy a zobrazuje ich cez nejaké rozhranie na webe len mne.

A potreboval by som mať istotu, že ako je rok dlhý sa s tými php súbormi na hostingu nič neudialo. Že sa mi tam niekto nenabúral a nedoplnil nejakú parazitnú funkciu. Tak mi napadlo, že keby boli všetky súbory podpísané, stačilo by aby nejaký skener skontroloval tieto podpisy a zahlásil, že podpisy sedia. Spustiť automaticky raz týždenne a mám spokojný spánok. Pre istotu.

Už niekoľko zimných (takto v lete) večerov uvažujem nad nejakým šikovným antivirom pre prevádzkovateľov webových aplikácii. Toto by mohla byť jedna zo šikovných vlastností. Kontrola integrity súborov na hostingu.

Hneď sa vynára niekoľko potrebných nastavení, napríklad adresár pre cache, kontrola chmodu a podobne. Veď oni chlapci programátorský by isto vedeli čo a ako.

Akokoľvek, nepoznáte nejaké podobné riešenie?

11 komentárov pri “Kontrola integrity súborov na hostingu

  1. najistejsie a najjednoduchsie je, ak prava na zapis ma iba root 🙂 nemusis nic podpisovat a mozes v principe iba dufat, ze nikto neziska prava roota 🙂

    a ak chces kontrolovat zmeny v dvoch verziach fajlu, napr. fc (dostupne vo windows) – prislusny skript co obehne vsetky fajly si spravis razdva 🙂

  2. Ved taky skript mas za pol hodku, rekurzivne prejdes adresare, vypocitas hash z kazdeho suboru a vhodne ulozis (napriklad do DB alebo ku kazdemu suboru zvlast „nazov_suboru.hsh“). Nastavis CRON a spokojne spis 🙂

  3. Bystro ma už principiálne predbehol, ale napadla mi ešte možnosť zapisovať si dátumy poslednej zmeny v súbore. To by bolo buď niekde mimo, offline, v tabuľke, alebo vo viacerých kópiach, aby to útočník nemohol podvrhnúť a to stačí raz za čas skontrolovať. Možno trochu drevočubačské, ale jednoduché (ak je rekurzívne hashovanie kvanta súborov akokoľvek nevhodné). No neskúšal som, pros/cons? 🙂

  4. periodicky, inkrementalny backup.Ak sa na servery objavi nejaka zmena v zdrojakoch, skript ti vygeneruje novy rar(zip,etc) subor. relativne jednoducho naprogramovatelne (cez ftp stiahnes, potom archivujes) + mas postarane aj o zalohy 🙂

    vid napr. http://latrine.dgx.cz/jak-na-zalohovani

  5. Inak myslim, ze Piki to myslel inac… Chce si taku sluzbu kupit uz hotovu od nejakeho webhostingu, ze jo? 🙂 A my mu tu piseme skoro zdrojaky ako na to…
    Neviem ale ci takuto marginalnost nejaky webhosting bude niekedy ponukat, pretoze kazdy programator (cielova skupina webhostinov) si taky CRON naprogramuje sam behom pol hodky podla svojich zelani. Pre neprogramatora je lepsie pouzivat ine sluzby, ale ved Piki vie…

  6. Zhodnotím to tu trochu:

    Rony presne pomenoval ad jedna problém rootu (a prečo považujem za vhodnejšie si skontrolovať či sa niečo nestalo, ako sa spoliehať na silu bezpečnostných opatrení) a druhak možnosti riešenia za súčastného stavu.

    Bystro presne popísal, ako by som si to predstavoval a práve s tým doplnkom, že kontrolný súbor (súbor s kontrolnými súčtami) je oddelený, teda je napr lokálne.

    A k tomu „skrypt za pár skenúnd“. Nuž, webové aplikácie si na svoj hosting inštalujú práve ľudia, ktorým už riešenia typu biznisweb nevyhovujú (alebo ešte nepotrebujú profi servis, ale to je na inú diskusiu), ale ešte nepotrebujú zamestnávať bandu programátorov na objavovanie kolesa (ktorý by sa o takéto bezpečnostné fičúrinky postarali). Stačí nejaký chlapík občas, ktorý im doprogramuje nejakú čiastkovú funkcionalitu. A toto parciálne zamestnávanie oveľa radšej nahrádzajú vyhľadaním vhodného pluginu (preto mám rád wordpress a tisíce pre mňa pracujúcich programátorov).

    A o to ide, získať popisované riešenie (komentár 2+3) univerzálnejšie v podobe peknej klikacej onlajnovej aplikácie, ktorá by sa postarala aj o kontrolu obsahu databázy na injekcie a iné parenterálne podania, kontrolu verejnej časti webu na rôzne samootváracie okná (stane sa, že čo vo FF nevidno, IE ukáže v brutálnej nahote), vylistovanie adresárovej štruktúry a ďalšia a ďalšie bezpečnostné vecičky.

  7. Tiež som mal problém s kompromitáciou jedného webu, do všetkých indexov sa vložil nejaký Javascript, a nevedel som odkiaľ. Aby sa to neopakovalo nastavil som práva súborov na 444 a zmenil heslo na FTP. Pomohlo to, testovací index sa už nemenil. Ale chcelo by to sofistikovanejšie riešenie. Máš presnejšie požiadavky? Kontaktuj ma, niečo vyrobím.

    Ešte doplním, že treba sledovať i nastavenia servera (phpinfo(), …), zmenou nastavení môže prestať aplikácia fungovať.

Komentáre sú uzavreté.