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).