Jsou to parchanti, ale útoku hrubou silou jde zabránit jednoduše. Stačí silné heslo (relativně k účelu hesla. Například PIN bankovní karty je pouze čtyřmístný, protože osmimístný PIN by způsobil větší škody na obnovování zapomenutých PINů, něž těch pár ukradených tisícovek. Krátký pin, maximálně 3 pokusy a denní limit výměru jsou dostatečné zabezpečení) a dát si pozor na recyklaci hesel (nikdy nepoužívat stejné heslo vícekrát nebo pro různé služby).
Omezení počtu pokusů je sice jednoduché, akorát to jednoduché řešení způsobí, že se v případě útoku nepřihlásí ani oprávněný uživatel. Útočník se pak ani nemusí pokoušet heslo uhodnout, může mu stačit, že zablokuje přístup.
To, že si heslo volí sám uživatel nebo že silné heslo je nepohodlné je způsobené akorát nemožnou implementací v prohlížečích. Kdyby to bylo implementováno rozumně, silné heslo vytvoří správce hesel, a uživateli by bylo úplně jedno, jak je heslo komplikované, protože by ho nikam nepsal.
V ideálním případě by prohlížeč pro vyplňování hesel poskytl nějaké API, na které by se mohl připojit libovolný správce hesel. Takže kdyby někdo chtěl používat různé programy, použil by nějaký externí správce hesel, který by na ty jednotlivé programy napojil. Pokud někdo používá jeden prohlížeč na více počítačích, stačila by mu třeba synchronizace vestavěná v prohlížeči. Synchronizaci přes centrální server není problém zabezpečit, ten server hesla vůbec nemusí vidět, může synchronizovat jen zašifrovaný soubor.
Problém je hlavně v tom, že WP si dneska instaluje na nějakého hostingu každý, kdo má do zadku díru, aniž by měl alespoň základní pojem o bezpečnosti. Není to tak dávno, kdy jedna wannabe webdesignerka a online marketérka napsala článek o tom, jak si zprovoznit hosting s WP na Wedosu. Když jsem ji upozornil, že by neměla zanedbat bezpečnost a že je potřeba se o WP a pluginy starat a aktualizovat, tak mi odepsala něco ve smyslu, že "ajťáčtině" ona a její čtenáři nerozumí. Pak se není čemu divit, že je web plný neopatchovaných wordpressů, ze kterých do světa leze ransomware.
*ironie*
updaty jsou o nicem, nepridavaji zadnou cuul ficuru, jenom zerou cas a ubiraji z pameti a zabiraji vice mista na disku. a jeste aby to cloveka sledoval, ci co ...
a pak, kolikrat je slyset, ze nejake updaty rozbili behajici system. jeste to tak.
kdyz web funguje (tak hlavne o to jde, ne?), tak nejsou treba updaty, to si jenom ajtaci honi trika a delaji se duleziti.
jak ajtaci radi rikaji: don't touch the running system
*/ironie*
Tady bych mírně oponoval. Opravdu užíváte a aktualizujete Android aplikace? Tam se totiž stalo zvykem (obdobně jako nyní win10, dříve skype, ...), že jednou za čas se udělá upgrade tvářící se jako obyčejný update. Rozkop co, layout, práva, nově nezbytně nutný runtime přístup na net (jinak funkčnost horší než dříve) a podobně.
Dříve prostě bývaly samostatné (nové) major verze, nyní major podstrčí jako obyčejný update, tvářící se jako záplata chyb. Pak se nedivím, že už pár lidí kolem mne plošně zakázalo automatický update a "opravují" pouze až když opravdu potřebují nějakou novou funkcionalitu, kterou stará verze nenabízí.
- nejakej backdoor se obcas prihodi kazdemu projektu: https://www.root.cz/clanky/utok-na-wordpress-pres-rest-api-tretina-webu-nema-posledni-zaplaty/
- jenze kdyz nemas security review na contrib, mas historickou zatez apod tak se ti stane tohle: https://www.root.cz/clanky/vice-nez-8-800-pluginu-pro-wordpress-ze-44-705-je-deravych/ , a zde je dulezity se podivat jaky typ zranitelnosti to je. nejde o nejaky mozny zneuziti opravneni "administer něco" za splneni x podminek.
- jenze kdyz mas blbe nastaveny obchodni model, nemas to cele komplet open source a as free as a beer tak se ti zacne zakonite dit tohle: https://www.root.cz/zpravicky/prodany-plugin-pro-wordpress-instaloval-backdoor/ a jeste vic "hele ta galerka stoji $10 tak si ji stahnu z torrentu"
Chapu, ze je pro WP tezke udelat to co udelal Drupal s verzi 8 a riznout do toho, prejit na Composer apod. Drupal za to zaplatil ztratou docela zajimaveho zdroje vyvojaru - hobíků, "zaplatil" za to ztratou podilu, ale prineslo to velmi zajimavy byznys. Je otazka jestli s ohledem na cílovku by tohle WP prezil. Ale koneckoncu kazde zbozi ma sveho kupce.
Promiň, neznám Drupal a nebudu hledat jeden dva články abych se mohl tvářit že tomu kdoví jak rozumím. A proto se tě chci zeptat:
Když pominu 0days, jak teda Drupal zabrání tomu, aby si někdo nestáhl plugin jenom tak odněkud "z torentu" jak píšeš, jak zabrání tomu, aby plugin někdo odfláknul, udělal chybu nebo potenciální chybu či snad dokonce tam propašoval backdoor?
Zaprve je to o obchodnim modelu. Drupal neprodava veci za $10, ale je orientovany na vyrazne vetsi projekty a proto funguje cely ekosystem na GPL. Neni zadny store, je proste jen drupal.org contrib space. Me jako vyvojarovi se vyplati davat mozne maximum verejne ven protoze je to muj zivotopis a prihrava mi to vetsi a lepsi zakazniky.
Zadruhe je to nepochybne ta vec, ze Drupal je historicky by developers for developers. Komunita byla dost puritanska ohledne kvality kodu. Diky modularite a kvalitnimu API(jakkoliv bylo do verze 7 zastarale v navrhu tak bylo citelne a robustni) neni jednoduche prasit - a kdyz uz tak nemas koule to zverejnit. WordPress asi taky bude mit ruleset pro phpcs, ale kdo z "vyvojaru" za 200,-/hod z Webtrhu ho pouziva?
Zatreti je tady Security team. Mame "Drupal Security Shield". Nerozepisuju vic, pokud mas zajem vygoogli si to.
Ano existuje i nejaky prodej themes na Code Canyon apod, co jsem mel tu moznost dvakrat videt tak jsou to pekny sračky(stejne jako platiti.cz , ktery prodava totalni hovnokod - vsechna cest jestli to za ten rok kdy jsem to koupil opravil, a jeste s pokusem o jakousi trapnou "obfuskaci" pres site URL coz je pecka kdyz mas nastavene CI procesy a per-feature dev stroj). Nastesti diky vyse zminenemu a diky vyrazne jine cilove skupine nez ma WP je to minorita nad kterou lze mavnout rukou.
Nerikam, ze Drupal je bez chyb, ale ty jsou uplne jinde nez v bezpecnosti. Zeptej se treba na beznych webhostinzich, ktery system(y) jsou deravy jak reseto a pres ktere jim servery nejsou hackovany. Jedny Panama papers s 3 roky neaktualizovanou 0-day chybou na tom nic nemeni.
(Btw symfony, nette, zend, laravel apod projekty taky nikdo nijak masivne neatakuje)
Tak podívej, můžu tě ujistit, že něco zprasit, obejít, vynechat nebo prostě nepoužít api jde vždycky ..... a věř tomu, že u zveřejnění některé lidi ani nějaké koule vůůbec nezajímají.
Ostatně byla by sranda, kdyby hypoteticky WP skončil a ta armáda matlačů a jejich zákazníků přešla k Drupalu ... To bychom se nasmáli s api, modularitou a Drupal Security Shield ...
V momentě, kdy potřebuješ dát normálním uživatelům možnost nainstalovat si vlastní plugin jeho aktualizace, případně rychlou úpravu, tak je to prostě potenciální díra do systému, i kdyby sis "Drupal rules" na pyžámko vyšít nechal. A to je ten největší problém WP. Až bude mít Drupal takový počet instancí s možností jakýchkoliv pluginů a uživatelů, tak se můžeme pobavit o tom, co jak je nejhackovanější. A všichni víme co znamená restrikce na pluginy - je jich méně a tím méně funkcionalit atd.
To je asi jako bys srovnal Android se Storem a možností nahrát si jakoukoliv appku z vlastních zdrojů s Windows Phone a vůbec se nezmínil o rozšířenosti, délce života projektu a vůbec možnosti tvořit appky ...
Jenze kdyz nekdo nahlasi zasadni bezpecnostni chybu v contrib modulu tak security team vyzve maintainera k oprave. Pokud tak neucini tak jsou dalsi procedury (nevim z hlavy, myslim, ze se projekt oznaci jako abandoned, smaze u nej DEV release apod. Nedavno se to stalo u celkem pouzivaneho modulu - proste najednou byl abandoned, oznaceny jako nepouzivat a hotovo. Patch byl komunitou pridan a mergnut behem hodiny.
Na brute force lamani Wordpressu hesla slušně zabírá analýza logu a skript ala fail2ban kterej ho přidá do firewallu. Pokud mi někdo z jedné IP 30x za minutu zavolá wp-login.php nebo xml-rpc.php není důvod ho nechat dál blbnout. Nemluvě o tom že konzumuje zbytečně výkon serveru. Používáme to už pár let a celkem to funguje. Pokud je ale děravý plugin nebo template (typicky Joomla), pak je zle. Typickej uživatel si nastaví všechny adresáře pro zápis, aby mu instalátor neřval, a je výmalováno.
Vůbec nejde o to, že by se celá vesnice někam logovala. Jde o to, že stačí, aby tam byl jediný napadený počítač, a na ten web už se nepodívá nikdo za tou IP adresou. Protože firewall nezablokuje jenom přihlašovací stránku, ale celý web. Jestli je to sdílený webhosting, tím hůře, protože by se tím zablokoval přístup i k jiným webům. Ale webhostingy snad neprovozují takoví amatéři.
Přihlašování, pokud se udělá rozumně, také nežere skoro nic. Vlastně jen vyhledáte uživatele v indexu podle jména a pak zkontrolujete shodu hesla. Při analýze logu také hledáte, zda už se daný záznam neobjevil, což je podobné hledání uživatelského jména, ale navíc ještě musíte tu prohledávanou „databázi“ záznamů aktualizovat. Takže analýza logů možná nežere skoro nic, ale nejspíš je to pořád podstatně víc, než ty neúspěšné pokusy o přihlášení. Takže není pravda, že se tím výkon serveru šetří, nejspíš je to právě naopak.
Děkuju. Rád si nechám poradit. Podle tebe je tedy správnější nechat je pár týdnů louskat hesla a pak řešit následky. Tzn . kompromitovaný CMS. Ano, pokud máš suprer výkonnný sdílený hosting který zvládne >1000 pokusů/sekundu (třeba proto, že poskytovatel neřeší FUP ) ani to tak dlohu trvat nemusí :). Ano , existují jiné možnosti jako: WAF = drahé pro běžného uživatele opensource CMS, omezení přístupu k administraci třeba GeoIP = nepraktické. Případně to mužeš řešit domluvou = volat do čínské školy, jestli tam náhodou nemají zavirovaný počítač , že namáš srdce je zablokovat. Faktem ale je že pokud je na hostingu nastaven FUP nebo jiné omezení výkonu , takový útok prezentaci zpomalí a zákazník si bude stěžovat. Co mu pak řekneš , že si má přikoupit výkon ?
Podle tebe je tedy správnější nechat je pár týdnů louskat hesla a pak řešit následky.
Podle mne to správnější je. Následky louskání silného hesla jsou přesně stejné, jako následky žádného louskání hesla – tj. útočník nemá nic.
Tzn. kompromitovaný CMS.
Ne, kompromitovaný CMS není následek louskání hesla, je to následek slabého hesla.
Ano, pokud máš suprer výkonnný sdílený hosting který zvládne >1000 pokusů/sekundu
Proč byste měl dovolit vyzkoušet 1000 hesel za sekundu pro jeden uživatelský účet? Proč byste měl vůbec dovolit tisíc pokusů o přihlášení k jednomu uživatelskému účtu?
Ano , existují jiné možnosti jako
Ano, existuje mnoho hloupých možností. A pak existuje možnost uvědomit si, že pokud oprávněný uživatel zmatkuje a nepamatuje si správné heslo, bohatě mu stačí pět nebo sedm pokusů, po kterých je jasné, že to nedá a že by se měl přihlásit jiným způsobem – nejspíš resetem hesla přes e-mail.
Naprosto souhasím tím, co píšeš. Bohužel to platí pouze za předpokladu, že to každý CMS podporuje a má to defaultně zapnuté. Navíc ti nedovolí zadat slabé heslo. Pro šechny ostatní případy (tj. většina) si musíš pomoct jak to jde (hloupě). Pokud mi tohle vyřeší 99% problémů a je to bezúdržbové, jsem spokojen. Ovšem nikomu to nenutím. Snahu edukovat uživatele nebo je dokonce do něčho nutit jsem vzdal už dávno. Běžný franta instalátor si dá heslo franta a jakýkoli požadavek na bezpečnost bere jako omezování osobní svobody. Jinak by snad ani tenhle článek nevznikl. Jestli se nepletu ,hi-hi-hi
No to musí být výborné, než abyste řešil jeden nezabezpečený web, zablokujete přístup uživatelům na další weby. Ale na vašem webhostingu musí být zábava – třeba takhle zablokovat přístup robotům vyhledávačů ke všem vámi hostovaným webům, to by někomu mohlo stát za to si u vás hosting objednat. S tou vaší první větou souhlasím – nezáleží na tom, jestli si říkáte správce nebo admin. Že takhle „spravujete“ sdílený webhosting bylo mé temné tušení. Ale jo, některé zajímá na webhostingu jen nejnižší cena, tak dostanou, co si za ty peníze zaslouží…
Děkuji za váš názor. Zatím si "žádná" nestěžovala :) . Trvám na tom, že řešení fail2ban je legitimní cesta jak chránit zdroje, pokud se rozumně nastaví. Používá se to v mnoha jiných příadech. Sony playstation network vás zabanuje po pár neúspěšných pokusech na FW. Vy trváte na tom že je to chyba. Neshodnem se. Není potřeba být osobní, nebo ano ?
Já zase trvám na tom, že fail2ban legitimní cesta není, protože to neřeší problém a postihuje to spoustu nevinných, zejména na sdíleném webhostingu. O jakémsi magickém „rozumném“ nastavení fail2banu jsem již četl mnohokrát, ale zatím nikdo nebyl schopen vysvětlit, jak zařídí, aby fail2ban nepostihoval lidi, kteří s útokem nemají vůbec nic společného. Osobní nejsem, fail2ban považuju obecně za amatérské řešení. Ještě jsem nepotkal nikoho, kdo by sám od sebe popsal důsledky toho řešení a vyjmenoval alternativy a odůvodnil, proč je nemůže použít. Zatím vždy to bylo amatérské „ostatní to taky používají“, „pokud se rozumně nastaví“, „chrání zdroje“, „několikastupňová filtrace, proti sofistikovanějším útokům mám sice sofistikovanější řešení, které by vlastně pomohlo i proti tomu, co dělá fail2ban, ale stejně si fail2ban nechám“ a „tak mají prostě smůlu, stejně je to nepravděpodobné“. U vás je to navíc vylepšené o to, že dáváte každému svému zákazníkovi do ruky nástroj, kterým na vás může spáchat DoS útok.
Jak , vy odborníku, vyřešíte útok na protokol jako IMAP,SIP? Necháte útočníka blbnout a raději 3x za týden deaktivujete účet uživateli. Chci být u toho až to budete zákazníkovi vysvětlovat. Navíc vy (ne já) tímto stvoříte dokonalý DoS vektor. Minimum zdrojů 100% funkčnost. A pokud máte vítězný pocit, že jste zachoval síťovou neutralitu, je to hořký omyl. Pouze ... následky nese oběť místo útočníka. Připomíná mi to některé zákony v této zemi. Taky je dělali odborníci.
Prosím vás, než něco napíšete, zkuste se nad tím alespoň zamyslet. Porovnáváte situace, kdy já zablokuju účet jednomu uživateli na IMAP, zatímco vy zablokujete přístup všem uživatelům a ke všem službám. Takže kdo toho asi bude muset vysvětlovat mnohem víc?
Já jsem žádný DoS vektor nevytvořil, to jste asi jen něco nepochopil. Naopak u vás může každý zákazník zablokovat všem libovolnou IP adresu, která přistupuje na jeho web – třeba roboty internetových vyhledávačů.
To, že napíšete „100% funkčnost“ svědčí akorát o tom, že si vůbec neuvědomujete důsledky toho, co děláte. Jediné pravdivé na tom je to minimum zdrojů – jak už jsem psal, když někdo hledá nejlevnější hosting, zaslouží si to. Holt kvalifikovaný admin něco stojí, takže je potřeba počítat s tím, že za minimální cenu do toho taky admin vloží minimální energii.
IP adresa není uživatel. Z dané IP adresy zablokujete přístup všem uživatelům. Že je to nějaká VM v cloudu je akorát vaše přání – kdybyste dělal skutečné zabezpečení, nemůžete počítat s nejlepším případem ale musíte se připravit na nejhorší. Mimochodem, když už jste dospěl k tomu cloudu, mohlo by vás také napadnout, co se asi stane, když ten útočník bude hesla zkoušet z mnoha různých IP adres. Jak vám v takovém případě pomůže fail2ban a jak zabráníte rozlousknutí slabého hesla?
Ne, v mém případě útočník nedokáže znepřístupnit účet žádného uživatele – to je pouze váš výmysl.
F2B je jen pojistka. Jsou projekty, kde je rozhodně levnější (efektivnější) na nějaký čas odříznout celou zavirovanou školu / vesnici za jednou IP adresou, než řešit následky. Je pak už lhostejné, jestli někdo z privilegovaných uživatelů měl slabé heslo, nebo jestli hosting nezvládá brute force.
Mimochodem, ISP, z jehož sítě odchází takový útok, ho může detekovat stejně tak. Je podle mě nevyřešitelná filozofická úvaha, jestli je matlák ten provozovatel serveru, který používá F2B, nebo jestli je matlák ISP, který svůj provoz nehlídá (neřídí).
Proti brute force útokům je účinnou ochranou dvoufaktorová autentikace.
Jak už zde bylo řečeno, tak cílová skupina WP není příliš edukovaná v IT a bezpečnosti, takže to by musel ten mechanismus nabízet WP by default. Bohužel, programátoři WP jsou jen o maličko menší matláci, než jejich "zákazníci". (Onehdá jsem na WP po delší době narazil, zjistil jsem, že v roce 2017 dosud nemají vyřešené nastavení pro SSL offloading).