Kvalitní e-mailing již od 0,01 Kč | Vyzkoušejte náš cool e-mailing | coolemailing.cz
Zobrazují se odpovědi 1 až 9 z 9

FTP checker - projekt

  1. Ahojte,
    v praci aj osobne mam ja aj kolegovia weby ktore sa nijako neudrziavaju(klienti to nikdy neriesia a pre osobne veci nie je moc casu/zaujem to riesit), ci uz Drupal alebo Wordpress a sem-tam sa stane ze ich hacknu a potom treba riesit obnovu zo zalohy a manualne aktualizovat a modlit sa ze niekde v nejakom subore neostal nejaky skodlivy kod(alebo v najhorisom aj v db).

    Kvoli tomuto som sa rozhodol ze si napisem ftp checker ktory sa bude v pravidlenych intervaloch pripajat na ftp a kontrolovat subory. A tak ma napadlo ze z toho rovno spravim platenu sluzbu.

    Principialne ide o to ze sa bude overovat zoznam vsetkych suborov na ftp(nove/chybajuce), ich atributy a pripadne aj hash. V pripade ze sa najde nieco podozrive tak sa odoslu notifikacie.

    Moja predstava je ze zdarma by bolo mozne pridat jednu stranku a ta by sa kontrolovala raz denne a robila by sa iba jednoducha kontrola metadat(velkost, datum zmeny, opravnenia...).

    Platene veci by boli napriklad viacero stranok pod jednym uctom, kratsi interval kontroly(napr raz za hodinu), moznost kontrolovat hash, sms notifikacie, historia kontrol a tak dalej.

    Prakticky to nie je nic pre profikov s vlastnym hostingom, ale 99% webov bezi na verejnych webhostingoch a 99% z nich sa stale spravuje cez s/ftp takze trh tu je.

    Co sa bezpecnosti tyka, dospel som k takemu rieseniu ze pristupove udaje budu v db zasifrovane aesom a pri spusteni serveru sa zada heslo ktore bude v pameti pocas doby kedy bezi server a udaje sa budu odheslovavat "on-the-fly" tesne pred spustenim kontroly, takze aj keby bol server hacknuty, utocnik by sa musel dostat ku pameti a vediet z nej vydolovat to heslo. Myslim ze je to asi najbezpecnejsi sposob ktorym sa to da riesit. Nejake externe sluzby ako hashicorp vault a podobne mi pridu prekomplikovane moc.

    Co si o tom myslite, mali by ste o nieco take zaujem?

  2. Co se právě děje na Webtrhu?
    Doda.design poptává: HTML koder - ASAP
    Adam Gajdečka poptává: Nastavení Linux serveru
    Abushasek poptává: Mobilní aplikace - iPhone - příkaz k jízdě
  3. Nemyslím si, že by to mělo šanci na úspěch... Koncový zákazník musí vědět, že něco takového chce. A když už to ví, tak je pro něj nejlepší použít již existující a často doporučované nástroje (bavím se teď především o WP) - plugin od Sucuri nebo Wordfence.

    Moc se mi nelíbí dávat FTP přístup nějaké další službě, která pak v bude v případě FTP má data nezabezpečeně přenášet buhví kudy.

    Aby to mělo smysl, tak je potřeba počítat ten hash a to většina FTP serverů sama od sebe neumí, takže by bylo potřeba soubory stahovat k sobě a počítat. Zrovna teď řeším jeden web, který má cca 70GB, to by se mi nechtělo každý den stahovat a kontrolovat.

    Když už, tak bych to řešil jako doplněk do vybraných CMS.

  4. a) este mi vysvetli ako ti tie pluginy pomozu ked budes mat hacknuty web?
    b) tak ftp je ftp, ked nepouzijes sftp tak budu data na sieti nechranene, len zas neviem ktora vlada po tebe ide :)
    c) s tou velkostou to budem riesit tak ze sa budu hashovat iba "textove" subory(php, css, js, twig, go, cpp ...) a nie binarne a aj to do max velkosti(asi max 1mb). Primarne ide o detekciu hackutia webstranky upravou php suboru a naslednu detekciu tejto zmeny. Ak ti niekto nahra na web obrazok, to je mi fakt jedno - akurat sa dozvies ze pribudol novy subor.

    "Když už, tak bych to řešil jako doplněk do vybraných CMS." - mam pocit ze ti naprosto unikla podstata tohto projektu a ako spominane pluginy realne funguju, ale aj tak diky za postrehy.

  5. nektere hostingy toto delaji sami

  6. a) je třeba vzít v potaz typy útoků v dané cílové skupině. Nejčastěji se bude jednat o zneužití nějaké zero day zranitelnosti, zero day v dané cílové skupině bohužel může trvat i několik měsíců. Tyto zranitelnosti jsou v naprosté většině zneužívány jednoduchými boty a ty neřeší testy, zda je na webu bezpečnostní plugin, aby ho vypnuly. Pak je web samozřejmě často hacknut protože nejsou použita silná hesla. Opravdu cílené útoky živým zkušeným útočníkem, který jde po konkrétním webu, jsou v této cílové skupině spíš vyjímečné.

    Dále je potřeba rozebrat, co je vlastně cílem dané nákazy:
    - modifikovat web: přidat vlastní reklamu, těžící js, spamové odkazy, nebo nějakou infekci pro návštěvníky - to lze zvládnout všechno přes databázi bez modifikace souborů
    - získat uživatelské účty - zase to lze bez modifikace souborů
    - implantovat backdoor - to je místo pro tvůj projekt, nicméně budeš řešit spoustu problémů:
    -- updaty
    -- instalace nových pluginů/šablon
    -- soubory cache (tyto 3 věci budou způsobovat spousty false positive a cílová skupina tomu nebude rozumět)
    -- adresáře mimo web hlavní web - mnoho hostingů umožňuje vyrábět prostor pro subdomény (nebo i celé domény) jen vytvořením nové složky, tam se klidně může backdoor pěkně schovat a provádět crossinfekci mezi weby. Dále lze občas využít třeba rozdílné nakládání se symlinky mezi FTP a HTTP serverem a na to je také třeba myslet.

    Jak jsem psal výše, tak útoky neřeší vypnutí bezpečnostního pluginu a tak jejich kontrola integrity funguje dobře. Navíc hledají v souborech infekci pomocí signatur, takže mohou najít i problémy, které si uživatel zavlekl polovědomě, nebo tam už backdoor byl když si začal s testováním.

    b) cílová skupina bohužel často o sftp moc neví, takže ti tam stejně budou nastavovat to nejjednodušší = FTP. Každý článek v řetězci může být zdrojem problémů. Sám předpokládáš, že ti tvůj systém někdo může hacknout a proto řešíš šifrování AESem. Což když už se tak stane, tak na výstupu tvého serveru pojedou nešifrované informace k FTP. A nemusí to být tvůj server, může to být server/router tvého poskytovatele, nebo cokoliv dalšího po cestě. Když přidám více článků, kudy periodicky putují nešifrovaná data, tak tím zvyšuji pravděpodobnost, že někde uniknou.

    Samozřejmě se do toho pustit můžeš, ale myslím si, že to bude strašně moc nevděčné práce, aby to fungovalo dobře. Hlavní problém ale vidím v tom, že daná cílová skupina netuší, že by něco podobného měla řešit. A když už to řešit bude, tak věřím, že raději sáhne po dostupném řešení, které nic nestojí a částečně řeší i prevenci.

  7. také v tom nevidím žádný užitek. Pokud tam má statický web, stačí nastavit vše na read only a je v podstatě vyřešené, pokud tam má CMS, je lepší použít nástroje/template pro dané CMS, jak píše smitka, je obrovský problém se vyhnout false positive a správně detekovat změny z administrace CMS a změny mimo administraci CMS (aktualizace, instalace pluginů atd.).

    Kdysi dávno jsem měl podobný nápad, implementace nebyl vůbec snadná a ve výsledku by se nezaplatila, bylo levnější to přepsat nebo změnit hosting...

  8. Dobrý leda pro lidi,kteří nemají git. Kdo má git, ten by za to neplatil. Není důvod.

  9. Taktéž v tom nevidím užitek. Nemohu mluvit za Drupal ten neznám, ale na WP existuje X nástrojů které ti mohou monitorovat změny v souborech a jsou zdarma.

  10. Na podobnem projektu pracuji, konkretne https://www.webalert.cz
    Zatim se spise jedna o "proof of concept" v testovaci fazi, je s tim hromada prace a nejspis to na sebe nevydela. Hlavnim bodem je prave ta osveta uzivatelu, protoze vetsina lidi na bezpecnost kasle. Pokud by jsi mel nejake zajimave napady, muzeme se domluvit na nejake spolupraci.

Hostujeme u Server powered by TELE3