Názory k článku Čistění napadeného WordPressu: jak jsem hledal a vyhodil útočníka z webu

Napínavé čtení. V databázi WP je spousta míst, kam se dá ledacos schovat. Obnova stavu před napadením ze zálohy by byla jistější. Kontrolovali jste alespoň články zda tam není nějaká škodná? A jak to dopadlo s tím adminem, který zanedbal aktualizace? Byl propuštěn pro hrubé porušení povinnosti, nebo přišel o prémie? Nebo, jak to tak u státních zaměstnanců bývá, žádné důsledky vyvozeny nebyly?

> Obnova stavu před napadením ze zálohy by byla jistější.
Urcite jistejsi, a mozna i rychlejsi ;-)

Souhlas. A pokud by někdo mermomoci chtěl čistit, tak to chtělo mít něco, co umí detekovat změněné souvory, třeba wazuh - https://wazuh.com/blog/how-to-perform-wordpress-security-assessment-with-wazuh/

Články kontrolovali, bylo to v pořádku. Napadení bylo hodně staré takže čisté zálohy byly už přepsané.

Kdyby měl být vyhozen každý kdo zanedbává aktualizace tak by v žádné firmě/organizaci nikdo nezbyl. Soukromé firmy, jako dodavatelé, jsou na aktualizace ještě horší.

Nejtěžší pro mě bylo neaktualizovování aplikací akceptovat jako fakt se kterým se nedá nic dělat. Podobně jako dodržování dopravních předpisů.

Jako společnost jsme se stali závislími na internetu, ale neumíme ho bezpečně provozovat.

16. 1. 2024, 07:30 editováno autorem komentáře

Se soukromou firmou jako dodavatelem ma mit odberatel smlouvu ve ktere je definovana odpovednost. Neaktualizujes a napadnou nas? Neses naklady. Ze na to spousta firem a instituci prdi je bezne.

Smlouvu píše většinou dodavatel a rozhodně tam nedá nic co by ho položilo.

Tohle je hezká akademická teorie.
V praxi to dopadne tak, že dodavatel prohlásí, že supportuje tuhle verzi, a pokud zákazník trvá na časté aktualizaci, tak tady je nacenění, náš zákazník náš pán.
Načež milý kravaťák si uvědomí, že za tu cenu těžko budou prémie za znížení OPEXu, a tak podepíše bez aktualizací. Bohužel.

Pak je dobre dat do smlouvy upozorneni a vzdani se zodpovednosti.

Nedelal bych si iluze. Pokud to byl web nejake vyzkumne skupiny nebo predmetu, tak tak na 90% nic jako admin webu neexistuje a ten wp spis instaloval clovek, pro ktereho je to tak na hrane jeho schopnosti a je rad, ze to vubec rozjel. Chtel byste snad vyhodit vyzkumnika nebo ucitele za to, ze neumi spravovat wp?

Ano, pro takove pripady by bylo lepsi mit centralni instalaci wp, za kterou uz by skolni ajtak zodpovidal. Ale vime, jak je to s penezi na skolach. Ne, ze by nebyly, ale malokdy maji spravne barvicky, aby se daly pouzit prave na to, co je zrovna potreba.

Jsem celkem zvedavy, jaky dopad v tomhle smeru bude mit na skoly nis2. Ale treba u nas na CVUT jsme ani na nis2 cekat nemuseli, stacil jisty podzimni incident a najednou se zakazuje ssh pristup ze sveta a dalsi podobne lahudky, ktere sice lidem usnadnovaly zivot, ale dlouho jsem si rikal, jak je to bezpecnostne udrzitelne...

Když to neumí, tak ať outsourcuje. SaaS WP na custom doméně stoji 85Kč na měsíc.

Presne. Ale kde tech 85 Kc vzit, kdyz z grantu vam je casto nikdo na tohle neda a z penez na skolni pomucky se to taky zaplatit neda?

Ale jinak uznavam, ze spravne pojata skolni sit by spis mela nabidnout tu centralni spravu wp. Na katederni/fakultni urovni uz by se z toho stal normalni naklad na IT. Ale na urovni jednotlivcu/skupin se to resi blbe.

Jednotlivci by nemeli mit wordpress web kdyz to neumi, pak se muzeme bavit o zneuziti univerzitnich prostredku k ucelum ktere nejsou v grantu. Pokud jsou v grantu tak se ty penize v grantu na to najdou.

A tam se to nemusi aktualizovat? Kdyz pominu ze WP je jak reseto derave setrvale, tak aktualizace cehokoli typicky vzdy neco rozbije. V pripade WP je to pak spis pravidlo. Pak se neni cemu divit, ze spousta tech, kteri by to potencielne udrzovat mohli, od toho da s radosti ruce pryc, protoze to vedi.

zjavne netusite o com hovorite.

Ono je to jednoduche:
- ak chcete zosobnovat nedostatky zamestnanca, tak jednoducho musite platit viac zakladnu mzdu
- a sucasne zavediete brutalnu byrokraciu

Nikto sudny uvedene dve veci nechce, takze pokial mozno sa take nekona.

Prosim ukazte mi univerzitu kde plati zamestnancum v IT zakladni mzdu. Ze nekdo jde do univerzitniho prostredi delat za min penez muze byt kvuli absenci stresu, pracovni dobe, dostupnosti, atd.

Správce toho webu pravděpodobně nebyl IT pracovník. IT pracovník jen řešil důsledek - to napadení.

Tahle snaha se hnedka povozit po adminoj je hrozně úsměvná a nechápu, jak může nasbírat tolik palců. Pominuli, že šlo o nějaký side web pro jeden z mnoha projektů, které na té univerzitě běží, tak bych tě chtěl vidět třeba v nějaké firmě, kde ti napadnou web a ty se rozhodneš vyvodit důsledky na člověku co to instaloval.

Ten totiž obratem přestane řešit tebe a začne si hledat novou práci. Ty se ze dne na den ocitneš bez admina a protože ses zachoval jak si se zachoval, tak s ním ztratíš i část informací jak o tomhle systému tak o dalších, na které někdy sáhl. Přitom celou dobu je problém v tom, že si špatně definoval co vlastně chceš a nenastavil kontrolní procesy, které by tomu zabránily. Tohle je přesně ten důvod, proč se práce v malé firmě může stát peklem. Ve vedení se tam překrývají role, ideálně všechno řídí majitel a některé oblasti jsou pak prostě pokryté bez zkušeností a bez naděje to změnit.

Jenze ono neni treba nic pomijet ...

Vykopnuty za to nema byt admin, ale ten kdo za to odpovida = dekan/rektor.

A terpve kdyz od nadevsi pochybniost prokaze, ze delegoval nejen povinosti ale predevsim pravomoc a adekvatni finance, muze se z toho vyvleci.

Vyhodit děkana za to, že nejel nějakej bezvýznamenej web někde na serveru pod stolem v kabinetu? Když jsem byl na univerzitě, shodou okolností na té z článku, tak tam úplně běžně nejel systém na sestavování rozvrhu. Nikdo za to neletěl a to je prioritně o vesmír úplně jinde než projekt z článku.

Ten bezvyznamenj server je jak tu Xkrat zaznelo dira do cele site. A ani autor toho clanku vlasne nevi, protoze na to neprisel, jestli hacker pokracoval nekam dal do dalsich systemu.

Kdyz sem chodil na FEL tak si studenti bezne mohli sami editovat znamky ze zkousek ... a taky za to nikoho nevykopli. A to je presne to, co je spatne. A presne proto se to bude opakovat.

Doporučuji pozornosti https://blog.wpsec.com/backdooring-wordpress-with-phpsploit/

Velmi výkonný hack - prohledejte soubory na výskyt řetězce @eval($_SERVER[ a mrkněte na systémové crony

No ono je dobré mrknout i na pluginy, dost často se využívají na backdoory... Ideálně přeinstalovat znovu jako originál.

Byl propuštěn pro hrubé porušení povinnosti, nebo přišel o prémie?

Fascinuje mne tahle potřeba hledání a trestání viníků, přesně dle hesla: po bitvě je každá generálem!
V tomto případě zcela zřejmě udělal admin chybu (pravděpodobně zapomněl zapnout automatické aktualizace...), ale na problém přišel - podle údajů v článku zřejmě dost brzy, protože ty soubory se opravdu množí jako králíci a tady jich bylo celkem málo.
Takže vážení externí personalisté: nezapomínejte na pravidlo, že chybama se admin učí a važte si těch, kteří se ze svých chyb poučili. Pokud nevznikla velká škoda, tak jste jim právě zaplatili cenný praktický kurs bezpečnosti v IT - a je hloupost je hned po proškolení vyhazovat.

Protože když nikdo za nic nemůže, tak se svět stává lepším a lepším?

Nikoliv.
Tady je zřejmé, že (kdo) za to může: v první řadě darebák hacker, pak ten admin. Ale pokud vznikla jen minimální škoda a náprava byla rychlá (což zřejmě pro tento případ platí), je mnohem výhodnější to brát jako dobrou lekci.
Obrazně řečeno: svět bude lepší, když necháte lidi dělat chyba a učit se z nich, než když je pokaždé vyhodíte a nahradíte někým jiným, novým - který zřejmě udělá stejnou chybu.
S dodatkem, že pokud hledáte někoho, kdo žádnou chybu neudělal, nesmíte zapomínat na pravidlo, že kdo nic nedělá, nic nezkazí.

No dobře, pokud jsou tedy teď preferovanou metodou získávání zkušenosti držkopády, tak prosím. Proti nové době je zbytečné bojovat.

Asi to i mnohé vysvětluje. Třeba proč se před 50 léty přistávalo na Měsíci a teď to pořád failuje ;-)

Trošku to zveličujete či překrucujete, ale budiž...
Když se přistávalo na Měsíci, tak těch chyb nadělali všichni - včetně astronautů - hromady. Dokonce se s tím i počítalo a systémy byly navržené tak, aby se z chyb zotavily.
Ostatně, kolikrát se podařilo v kosmickém výzkumu zaměnit jednotky (metry vs. stopy), to snad ani nikdo nespočítá...

16. 1. 2024, 09:47 editováno autorem komentáře

No stím by se dalo souhlasit jen na pul.

1) ano chybama se clovek uci
2) za chybu nutne musi prijit trest, protoze, kazde jednani ma sve dusleky...

Nutne to nemusi byt vyhazov/premie atp. Mne kdyz se tenkrat povedla schodit produkce, tak trest v teamu byl takovy ze jsem pul roku delal updaty sam :D ( za a to nikdo nechce delat za b to delaly vzdy nej juniornejsi kolegove) Kcemu je to "pouceni" bez trestu jak dlouho si to clovek bude pomotovat? Ten "trest " tomu zveda uroven zaryti do pameti....

Od te doby uz si sakra davam pozor abych to nezopakoval, ci neudelal jinou...

Tahle ta doba kdy nidko za nic nemuze a za chyby se chvali, protoze cyhbovat je normalni, je minimalne smutna. Zachvily prijde doktro a rekne pardon nejak jsme udelal chybu, ale k slepaku jsem vam sebral i ledvinu. Holt chybama se clovek uci....

No a proc te vlastne nevyhodili?

2) za chybu nutne musi prijit trest, protoze, kazde jednani ma sve dusleky...
Proboha, proč nutně? Pracovat v prostředí, kde člověka za každou, sebemenší chybu někdo potrestá, by byla opravdu jedna velká radost. A to nemluvím o dopadech na kvalitu práce, pracovní morálku apod.

No, hlavním viníkem bych viděl hlavně přebujelou administrativu, která vyžaduje, aby na všechno byla kolonka / šuplíček a dvacet schválení, takže když je potřeba WordPress web pro něco, tak jediná šance je udělat si to nějak samo domo, protože oficiální formálně správná cesta je reálně neprůchodná. Ten člověk se pravděpodobně jen snažil pomáhat, ačkoli k tomu neměl znalosti a zkušenosti. A "přebujelou administrativu" potrestáte těžko.

za a to nikdo nechce delat za b to delaly vzdy nej juniornejsi kolegove

Vybudovat si takové prostředí kde: updaty jsou problém a nikdo je nechce dělat; za trest se dávají nováčkům, kteří nemají zkušenosti. A potom jmenovitě hledat viníka. Gratuluju. Tohle je sovětské vedení: vždy je potřeba přísně potrestat někoho, kdo u toho zrovna stál a tím je to vyřešené.

Tohle je asi ten nejhorší způsob řešení problémů. A tyto a podobné věty jsou jasným signálem toho, že je něco systémově špatně.

V IT je vždy považoval za obrovskou výhodu to, že si můžeme ukázat na jednotlivé komponenty (ať již sw nebo hw) a přesně identifikovat, co se stane, když selžou. A následně s tím buď jenom počítat a připravit si plán na to, až tohle selže, nebo je nějakým způsobem eliminovat (typicky raid, více zdrojů, ups). A vždy mě štve, že se to jednak nedělá, ale hůře, v situaci, kdy něco (zcela očekávaného) selže, tak se dle sovětského vzoru vždy hledá jméno a tím se "vyřeší". V IT jsme (teda alespoň já) od toho, abychom to dokázali identifikovat a navrhnout řešení.

A OK, pokud teda chce někdo hledat jména a myslí si, že se to tím vyřeší, tak OK, ať teda zcela jasně a dopředu napíše, kdo za co má být odpovědný, současně s tím mu k tomu dá potřebné prostředky, školení, vzdělání a nechá jej to dělat. I tohle by ve skutečnosti vedlo ke zlepšení. Jenže ani tohle není vidět.

Náprava byla rychlá? Výše autor píše "Napadení bylo hodně staré takže čisté zálohy byly už přepsané."

Takže web státní instituce směřoval "hodně dlouho" na phishing, ale škoda byla malá. To je fakt super :-) Švejk v žádné jiné zemi vzniknout nemohl ;-)

To píše ve vlákně nahoře, které jsem před odpovědí nestačil přečíst. Nicméně podle počtu napadených souborů a mé zkušenosti s podobným neřádem jsem odhadoval, že k ní došlo relativně brzy - jinak by ten web byl promořený až hrůza. (Tohle je schopné vygenerovat dvojnásobný počet souborů, než kolik jich ten systém má.)
Nicméně jsem myslel brzy po zjištění - a vzhledem k tomu, že byl čas na výzkum typu kus vyčistím a podívám se, co tam druhý den vyrostlo, nepředpokládám, že šlo o kdovíjak kritický web.
Navíc zcela zřejmě provozovaný/spra­vovaný laikem, který si s opravou sám neporadil - takže nepředpokládám, že měl v popisu práce pravidelný bezpečnostní audit, záplatování a okopávání nějaké webové prezentace. Mnohem spíš to bylo nutné zlo v rámci jeho odborné činnosti.

Lidi, vysoké školy a IT jsou v tomto ohledu velmi specifické prostředí. Kdysi jsem dělal a studoval na veliké univerzitě, která má i velmi známou fakultu informatiky.

Celá univerzita byla prolezlá miniaturními (co do významu) servery, které obsluhovaly jednoduché weby...

A třeba na té fakultě informatiky mělo mnoho učitelů takový servřík často v kabinetě pod stolem. Univerzita měla tehdy na každé zásuvce veřejnou IP, tak to fakt nebyl problém. Paradox byl, když jeden učitel měl serverovnu kousek od kabinetu a neustále řešil, že mu někdo ten server v kanceláři vypíná a odpojuje od sítě - občas mu někdo vytrhnul kabel ze síťovky. Do serverovny ho dát nechtěl. Byla to výhoda pro studenty, kteří získávali body v jeho předmětech za opravy toho serveru.

No a na druhém konci budovy sídlil celouniverzitní IT tým, který poskytoval věci jako server jako službu nebo webhosting... Pro potřeby univerzity to bylo bezplatné a údržba byla v ceně.

Po skončení na univerzitě jako student jsem v tomto týmu více než 10 let pracoval a některé tyto služby pro univerzitu jsem měl ve správě - přenos serveru z kabinetu do serverovny jsem nabízel mnohokrát a stejně častokrát jsem byl odmítnut. Do prvního bezpečnostního incidentu. My jsme nabízeli aktualizace, zálohování, garantovali jsme dostupnost... To v těch kabinetech neměli. Hlavně si mysleli, že to přeci zvládnou a nic to není...

Proč bys měl trestat učitele za nebezpečný web? To bys rovnou měl trestat za zavirovaný počítač. To byly horší problémy, které skončily až zavedením centrální správy a odebráním lokálního admina většině uživatelů (jo, to bylo napřed křiku).

V době, kdy jsem na univerzitě končil, tak jsme měli denně cca 15000 unikátních uživatelských zařízení - desktopy v kancelářích, notebooky a mobily/tablety studentů i učitelů. Serverů dle unikátní IP byly tisíce. Zajisti v tomto prostředí bezpečnost a trestej za každý (bezvýznamný) bezpečnostní incident...

Skola ma nejake vedeni, to jsou presne ti, kteri maji byt trestani. A to proto aby nasledne pozadovali po svych podrizenych prislusne zajisteni at uz bezpecnostni nebo provozu.

Takovy servrik nekde v kumbale by proste technicky nemelo byt vubec mozne zprovoznit.

Jak vypada realita samozrejme vim velmi dobre, takovych desitky let nikym neudrzovanych stroju tam pomezi tisice. WP je jen takova tresinka stejne jako to, ze si vubec nekdo vsiml ze to je hackle.

No... i u nas v korporatu mame servriky po kanclech/labech. Ale samozrejme nejsou vystrcene ven a jen vybrana individua muzou pres vpn do jejich vlanu. Obcas je nutne doplnit nejakou adhoc komunikaci do jinych siti. Existuji pripady kdy si domu desku fakt nemuzete odnest a ani do lokalni serverovny to nevrazite ... no nekdy to nesmite odnest. Takze ty veci se ladi tak ze je na stole rozlezla deska s hromadou konektoru na spinaci zasuvce a servrik resi jtagy, swd,uarty, back to back ethernet, povely nejake jine krabici a jine digifundace co embedaci chteji.
PLCcko uz jsem tez videl nakonektorovane na miniservriku i s kamerkou. QA tym dovede byt kreativnejsi nez zhuleny student s krabici lega.

Jsou to obcas aplikace zavisle na tom aby to bezelo nekde na lokalnim zeleze a mohl s tim nekdo verglovat. Coz je idealni pro home opice.
No a pak jsou tu servriky ktere treba jsou zavisle na near realtime odezvach nejakeho srotu co v nich bude potom sumet. To taky ze zacatku do DC clovek neda.

17. 1. 2024, 15:07 editováno autorem komentáře

Jo a pak to vypada jako RSD. Taky nikdo za nic nemuze, jen ja to mam platit ...

Osobni zodpovednost manazeru chybi i v nekterych korporatech. Mohl bych vypravet o nemeckem prumyslovem megacorpu kde to je fakt velky problem. Na tohle jednou dojedou.

To naprosto nepochybne, ale tam to plati akcionari.

Akcionarem statu sem ja.

Preco maju subory wordpresu nastavene prava na to aby sa dali modifikovat?

Protoze updaty a cache.

Asi som uz stary, ale updaty by sa mali robit pod inym pouzivatelom, co na to ma prava a cache by mala byt len v nejakom konkretnom foldri a sucasne by v cache nemal byt ziaden vykonatelny kod.

Teda, ak to chce byt co i len trochu bezpecne.

A jak resit updaty pod jinym uzivatelem, kdyz je ma byt prihlaseny uzivatel schopny provest z weboveho GUI? A jak vubec ziskat jineho uzivatele? Podivejte se na vetsinu hostingu, ty vam daji jedineho uzivatele a nazdar. Tahle strategie muze fungovat u centralne spravovaneho wp.

Napriklad externou aplikaciou, co bezi pod inym pouzivatelom.

nejhorší na tom WP je, že nejen, že potřebuje sám sebe přepisovat, on ani jednoduše nedovoluje to dělat jinak a znamená dost práce ho zkrotit a provozovat v read-only režimu, jak se běžně aplikace provozují.

Za mě logicky nelze mít nikdy bezpečnou aplikaci, když sama aplikace se může přepisovat na pozadí z internetu. Všechny ty hostované řešení to nepoužívají, ale open source WP je na tom založený.

Házet to na vypnuté aktualizace je alibismus, viděl jsem celou řadu napadených plně aktualizovaných instancí (zrovna přes svátky běžela velká infiltrační kampaň). To by fungovalo jen tehdy, kdyby všechny zranitelnosti byly nalezeny dříve než se začnou zneužívat, tomu tak ale logicky není, plně aktualizovaný systém je dobrý, ale problém špatného návrhu neřeší.

"A jak resit updaty pod jinym uzivatelem"

Tohle myslis jako vazne? Kdyz nic jinyho, i maly dite napadne ... dam do ty databaze pod uzivatelem A neco na tema "update na verzi X+1 schvalen" ... a nasledne se tam treba cronem podivam a pod uzivatelem B tu aktualizaci spustim.

To ale nemuzes pouzivat WP ... ten je deravej od prirozeni ..

Ja jsem vycistil WP pomoci gitu, ale vyzaduje to, abyste si predem udelali git init, dobre nastavili .gitignore a udelali commit (neni potreba to nikam pushovat). Potom stacilo zobrazit git status a git diff a bud delat git checkout jeden po druhym nebo rucni mazani vlozeneho kodu. Nekdy by slo asi pouzit i git reset --hard a git clean -df ale obaval jsem se, abych nesmazal neco, co bych nechtel.

16. 1. 2024, 10:26 editováno autorem komentáře

Článek sice hezkej, ale útočník mohl napáchat mnohonásobě víc a schovat se mnohem níž. Pokud jsou tohle skutečně jediné kroky, tak si určitě nemůžete být jistí, že problém je vyřešenej.

Za mě jediné sprvné řešení je přeinstalovat komplet celý systém a doufat, že se nestalo i něco ajko LogoFAIL firmware útok. Plus minimálně zkontrolovat všechno ostatní na lokální síti.

Je to ale čistě můj názor a rád se nechám přesvědčit o opaku

Zcela s vámi souhlasím, mohl toho napáchat víc. A pokud bych chtěl mít uplně klidné spaní, reinstaloval bych celou mašinu a web je nechal udělat znovu. Jenže to je nereálné udělat takže tohle beru jako akceptovatelné riziko (přestože se mi to nelíbí). Ale od té doby co jsem se smířil s nutností takového přístupu, alespoň lépe spím. Jenže ono to není až tak strašné, protože co komerční firmy nebo finanční instituce jsou schopné brát jako akceptovatelné riziko je až děsivé.

Předpokládám že poté nastala fáze č 2, Proč našim partnerům stále hlásí korporátní firewall, že náš web je nebezpečný, proč naše maily nikam nedojdou, a jak se unsubscribnout z bambilionu blacklistů, které to způsobují.

V PHP aplikacích se přetlačují dva způsoby přístupu. Jeden peferují laici a začátečníci - instalace přes webové rozhraní na jedno kliknutí. Druhý pochopitelně lidi, co chtějí aplikaci mít bezpečnou - příkazová řádka, GIT, composer, striktně omezená práva zápisu.

Bohužel rozhoduje cena. Hosting se nebude obtěžovat příkazovou řádkou, GITem, composerem za 50Kč/měsíc. Prakticky vzato to je umožněno až na úrovni VPS, což je o řád jinde...

ale i na běžném hostingu lze dělat bezpečné aplikace a používat WP, jen je k tomu potřeba třetí strana, která ten průvodce spustí, ať už aplikace na stanici, z které to instaluji nebo u nějaké třetí strany, ta se připojit na ftp (bohužel pořád frčí) a WP tam nahraje, stejně tak by probíhala i aktualizace.

Chápu, služba/aplikace navíc a stejně tak starosti navíc, ale pak mi nevadí hosting za 50 kč.

Tady si člověk moc nevybere - možnost vykonávat systémové příkazy uživatele se může dost vymstit. WordPress instalátor aktuálně také představuje pomerně značné riziko: https://smitka.me/2022/07/01/wordpress-installer-attack-race/

Pro uživatele je dnes nejlepší one click instalace od hostingu, ale musí být dobře udělaná. Potkal jsem se už několikrát s tím, že rovnou zanesla do WP další bezpečnostní problémy... Pro administrátora je naopak nejlepší používat WP-CLI.

A což se na nějaký WordPress vykašlat a používat něco jednoduššího, třeba Bludit: https://stani.1blog.cz/bludit-flat-file-cms/

To není zrovna výstava bezpečnosti: https://www.cvedetails.com/vulnerability-list/vendor_id-17229/product_id-41420/Bludit-Bludit.html

No tak, toto obecně platí pro všechny weby... Pokud dám někomu údaje k FTP nebo na web zaregistruji nějakého dezoláta, pak samozřejmě dojde k problémům.
Sám od sebe se nikdo do Bludit zaregistrovat nemůže a také nikdo nemůže sám od sebe nahrávat soubory.
Používám léta verzi 3.13.1 na několika webech a žádný problém. Předtím s Wordpress pořád něco.

19. 1. 2024, 13:28 editováno autorem komentáře

Mozno by stalo za zmienku porozmyslat o externom WAF, alebo geretku ;)

A k tomu naklady na tym ktery do toho vrta v pripade WPcka treba kazdy den kdyz se to sejde. Takze to vlastne neni tak levne a jednoduche.
Potiz je v tom ze pro mne WAF neni ikonka vysmateho architekta ve visual studiu, ale predstavuji si pod tim realnou praci kterou za tim nekdo musi pravidelne delat a byt za ni placen.

To je hodně vtipný....opravdu mě baví, jak tady ty elitní ajťáci co jsou zvyklý na HA a nástroje za miliony řeší web, na který leze 10 uživatelů měsíčně a aplikují na to svá SLA a podobné metriky... LOL na vás hoši.....někteří lidé jsou hůře placení a i ta technika většinou stojí za starou bačkoru. Nebo si třeba představte, že to někdo dělá i zdarma a pak mu vemte odměny a pořádně ho vykrákejte za ušiska... ;-D

Když vám přes ten nezabezpečený web někdo pronikne do interní sítě a následně vám zašifruje data včetně záloh, je jedno, jestli měl 10 nebo 10 tisíc uživatelů měsíčně a kolik peněz za to admin bral.

(Naštěstí se to tady nestalo, nicméně nevíme, jestli jen štěstím, že o to útočník neměl zájem, nebo proto, že zafungovala nějaká další bezpečnostní architektura.)

To je hodně ze světa snů. Nevíme jak byly zálohy udělány, takže jejich zašifrování nemuselo být vůbec reálné. Proniknutí do interní sítě neznamená, že má útočník najednou přístup všude.

A proč se tedy tak moc řeší firewally / VPN, když proniknutí do vnitřní sitě zas tak moc neznamená?

Jak jsem psal už ve svém předchozím příspěvku, tady z toho větší průšvih naštěstí nebyl. Proč, to se můžeme jen dohadovat. Ale v takovém ŘSD to byl dost zlý sen.

Nicméně pointa mého příspěvku byla jinde.

16. 1. 2024, 15:05 editováno autorem komentáře

A proč se tedy tak moc řeší firewally / VPN, když proniknutí do vnitřní sitě zas tak moc neznamená?

Jenže tohle nemá být na bedrech jednotlivých adminů Wordpressů. Pokud je přístup do vnitřní sítě takový průser (proč?), tak ta síť má být postavena tak, aby se tam nedostal ani ten server pro ten WP.

Ale v takovém ŘSD to byl dost zlý sen.

A jsou k tomu někde nějaké podrobnosti? Jestli jde zničit nebo zašifrovat zálohy, které mají být z principy věci offline, přístupem z venku, tak je v té organizaci špatně o hodně víc, než jen nějaký potenciální rizikový web. Nehledě na to, že mají povinnost mít také archiv v papírové podobě apod.

To ze je nekdo hure placeny neni akceptovatelny argument. Neni to muj problem. Je to jen a ciste problem toho technika. A treba i muj pokud jsem tim technikem. Technik na sebe vzal odpovednost. Ma vedet co odpovednost za system xy obnasi a nalezite se ocenit.

Kdyz vas nejaky doktor nenavratne poskodi taky tahle vymluva neobstoji. Pokud technik nebo doktor mysli ze jeho prace vyzaduje vzhledem k odpovednosti vyssi oceneni tak ma si resit zvednuti platu, pravni osetreni/omezeni odpovednosti, pojisteni, subdodavku sluzeb z IT security aj.

Poučení pro příště by bylo asi zavedení centrální správa takovýchto webů napříč univerzitou.
Chápu je to složité, ale pokud bude centrální správa, tak aktualizace, zálohování/ob­novení, schvalování (zakazování nebezpečných) pluginů atd. by byla jednodušší a celková bezpečnost by se jednoznačně zvýšila.

„Opruz“ by to bylo naopak pro uživatele (akademiky), kteří by museli žádat o web pro svůj projekt.
Admin takového Wordpress clusteru by pak musel dělat i support pro akademiky, když jim ve Wordpressu něco nepůjde.

Ale pozor pro ty uživatele to musí být co nejmenší „opruz“, jinak budou pirátsky instalovat cokoliv kamkoliv a bezpečnost se nezvýší.

<it>Poučení pro příště by bylo asi zavedení centrální správa takovýchto webů napříč univerzitou.</it>

Jo. Pak narazíš na realitu. Převedení těchto webů pod centrální správu jsem řešil. Byl to běh na mnoho let a spoustu přesvědčovaní.

A není to jen o tom vzít nějaké stránky a hodit je někam jako virtualhost. Tím jen přeneseš problém o dům dál. Pokud chceš skutečně těžit z centrální správy, tak potřebuješ sjednotit použité technologie a nástroje pro tyto weby. A zde opět narazíš - různé verze WP, různé verze PHP, různé verze různých WIKI, diskuzních fór... Potom design stránek a další a další problémy jako databázový backend (Postgres, MySQL/MariaDB...) Takže skončíš tím, že zvirtualizuješ ten server, co leží někde pod stolem a hodíš na oblíbený hypervizor, přidáš centrální zálohy a možná nějaké kontrolní mechanismy aktualizací. V lepším případě provozuješ třeba kompatibilní databázový server, tak použiješ svoji centrální databázi a tu dedikovanou zrušíš. Toto je realita. A celé to můžeš zrealizovat, jen když vlastník toho webu AKTIVNĚ spolupracuje.

Jo, jenze aby tahle realita nebyla realitou, je treba naprosto nekompromisne a tvrde jit po tech, kteri za ten stav muzou. A to nejsou ti, kteri si ten stv nekde provozujou, a nejsou to ani ITci. Je to vzdy a pouze vedeni. A je jedno jestli skoly nebo firmy.

Na tech skolach jde viceme o prd, maximalne si nejaky studentik zapise znamku ze zkousky ... (kdo nevidel Valecne hry?). Ale ze nebyl vykopnut na minutu sef RSD, to je nehoraznost.

Kdyby po me, jakozto adminovi, chtel nekdo abych za takovou sit odpovidal, tak se vsad, ze tam uz zitra zadny takovy srv nebude, a namitky bych dotcenym doporucil vytisknout na papir aby si snimi mohli vytrit. Jenze tu odpovednost po tech aminech nikdo nechce, protoze to by jim take musel dat prostredky na jeji realizaci.

Netyka se to ani zdaleka jen skol.

V tomhle konkretnim pripade, by mne zajimalo, kolik clovekohodin se propalilo na tom "cisteni" a kolik mam tedy pozadovat povedeni skoly aby pekne ze sveho (+100% samozrejme, aby si to pamatovali) zacalovali mam pozadovat. Kdyz strelim ze 100, tak to mame nejakych rekeme 500kKc.

Nekompromisně... tvrdě... Hezká řeč... Ale příliš to dramatizuješ! Dělal jsi na nějaké veliké vysoké škole? Víš, jak je organizovaná síť na takové škole? Víš jak je organizovaná správa sítě? Víš kolik unikátních počítačů denně komunikuje v takové síti?

Třeba taková MUNI má síť svojí velikostí odpovídající většímu ISP, rozprostřenou na území téměř celého Brna, v desítkách budov, fakult, ústavů a kateder. K tomu historicky připojuje spoustu dalších organizací, protože to tehdy nikdo jiný neuměl.

Tato síť vznikala v době, kdy NEBYLY žádná doporučení jak strukturovat a organizovat. Tato doporučení vznikala často právě na půdách vysokých skol, jako jejich zkušenosti. A máš-li někde natažený kabel, tak prostě není jednoduché ten kabel vzít a natáhnout znovu a lépe. Znamená to často rozkopat spoustu ulic... Tak ten kabel musí sloužit třeba těch 20 let, než se najde příležitost... A vyhodil bys toho, kdo to blbě naprojektoval? Nemůžeš! On přece dělal tak, jak to uměl nejlépe! Je to akademické prostředí, holt výzkum se dělá/dělal i v těchto věcech... Ty sítě často stojí na základech původních, EXPERIMENTÁLNÍCH sítí a jejich existence je důsledek skutečného VÝZKUMU.

Pak jsou tu ty roztroušené weby... Jejich správci byli často postaveni do situace rychle potřebujeme web, včera bylo pozdě, ty se v tom přece vyznáš (rovná se: dělá doubleclick rychleji než já, nebo včera použil slovo „linux“). Jsou to lidé, kteří IT na univerzitě řešili jen na úrovni „umřel mi pracovní desktop, chci si koupit toto“. Tak postaví řešení pod stolem, protože se to tak doposud dělalo... Protože prostě ty noty jak to udělat lépe a systematicky prostě nebyly nebo je během těch pěti minut vyhrazených na hledání prostě nenašli.

Ze začátku to byla dost náročná práce systematizovat používání IT na univerzitě. Bylo to o vytváření konceptů jak na to, bylo to i o čekání na životní cyklus výpočetní techniky - a to máš najednou pět let. Co všechno to obnášelo už jsem tu psal...

Takže to, že teď říkáš ty věci jako „nekompromisně“, „tvrdě“ „potrestat“ a „vyházet“, je jen proto, že tu bitvu za Tebe vybojovali právě na těch univerzitách a proklestili Tobě cestu. A Ty jsi jak ten generál po bitvě. Jsi v tomto zcela mimo mísu, nevíš o čem mluvíš.

Koncepty, systematizovani, ... lul ... ten zdaleka nejvetsi bragl na tech skolnich sitich vyrabej ti, kteri maj studenty ucit, jak to ma vypadat. A je to tak predevsim proto, ze vzivote nikde nic nedelali a tudiz ani za nic neodpovidali.

To jak ma vypadat sit se vi nejmin 30let, takze vykladej jak je treba vyjasnovat koncepty a systematizovat praci ...

S temi doporucenimi na pudach skol mate pravdu jen na pul. Puvodni doporuceni o strukturovani velkych siti vychazela ze zkusenosti klasickych telefonnich siti na bazi prepinani okruhu. A ty tu jsou uz zatracene dlouho. Doporuceni byla od stavby,pres kabelaz po nastaveni a software. Dodnes z toho tezime.

To ze se to do 3 generace tehdy zaostale analogove telefonni site v CR nedostalo je vec jina. V zahranici se clovek mohu leccemu naucit uz pred revoluci.

Nechci být zlý k autorům Wordpressu, ale myslím, že je to software z kategorie BaaC (Bug as a Concept) :-). Neznám žádnou jinou webovou aplikaci, která by nabízela tak časté reporty bezpečnostních incidentů. Asi je to způsobeno velkou mírou amatérismu a diletantismu mezi jeho uživateli a velkým množstvím nasazených instancí, ale stále třeba ve srovnání s incidenty třeba u PhpMyAdmina, který je taky nasazovaný často, mi to přijde hodně.

Za mě je Wordpress z bezpečnostních důvodů zcela neakceptovatelný.

Mám pár WP webů a ani jeden nebyl napaden a to tam není nic extra. WP jako takovej je vcelku v pohodě. Problém jsou spíš pluginy. Který projekt podobného ražení je pro tebe akceptovatelný? WP je zrovna jeden z těch lepších co se týče protestovanosti, bezpečnosti a aktualizací.

a jak poznáš, že byl web napaden? Mám zkušenosti, že web měsíce (ale i roky) po napadení se chová naprosto normálně a čeká, skenery (např. owasp) takové napadení nemusí odhalit.

Stejně tak mám pár instancí s různými sestaveními a prostě čekám, kdy tam dojde k nějaké změně, kterou sleduji. To používáme jako sondy, aby se vědělo, jak vlastně takové napadení detekovat a co se děje. Ty způsoby průniku jsou opravdu k nerozeznání od běžné změny v šabloně, tohle lze těžko detekovat nějak externě bez kontroly integrity a změn v db.

A tak kontrolovat integritu v tom smyslu, ze zkontroluji co tam ve skutecnosti je a co tam ma byt mozne je. Samozrejme je to prace navic a nikdo to nedela, ze? :-)

Jak bys to chtel kontrolovat, kdyz k tomu ma pristup treba 10+ subjektu (i ruzni externi dodavatele) a ruzne zmeny delaji na denni bazi. Musel bys leda pekne osobne kazdou jednu zmenu analyzovat,a zjistovat, co vlastne dela. A to uz mas lepsi si to delat sam ze?

Ja mam na wp jednu takovou mucholapku, a je opravdu zabavne to sledovat. Je az k neuvereni, kolik ruznych zpusobu jak to naborit existuje.

no přesně, kontrolovat to ve WP v provozu je dost těžké. V praxi pak to končí na řešeních, kdy backend se používá jen jako backend, z něho se exportuje výstup a až ten se prezentuje na frontendu. Nenašel jsem způsob jak jinak WP provozovat bezpečně aniž by to stálo spousty času za provozu.

Možná je to kvůli tomu: According to data from W3Techs, WordPress was used by 45.8% of all websites on the internet in 2023. This is an increase from 43.2% in 2022. That means that more than two out of every five websites use WordPress. WordPress powers 36.28% of the top 1 million websites.

Phpmyadmin také nemá 60 tisíc pluginů jen v oficiální databázi https://wordpress.org/plugins/ a další tolik skinů.

Zde bych úplně nesouhlasil. Když se podíváme na bezpečnostní problémy přímo v jádru WP, tak jich bylo vloni 13 (max CVSS 6.5) a většina zneužitelná jen autentifikovaným uživatelem. Když se podíváme na jiné projekty, tak to nejsou nijak hrozná čísla, například (počítáno od oka z CVE):
- Concrete CMS - také v PHP, ale modernější - 20 zranitelností (max CVSS 9.8)
- PrestaShop - 15 zranitelností (max CVSS 9.9)
- MediaWiki - 15 zranitelností (max CVSS 9.8)
- XWiki (Java) - 100+ zranitelností (max CVSS 10)
- Umbarco CMS (.NET) - 8 zranitelností (max CVSS 9.8)
- Django - 7 zranitelností (max CVSS 9.8)
- GitLab - 100+ zranitelností (max CVSS 10)

Z čísel lze vyvodit především to, že je komplexní software, který používá mnoho lidí je prostě složité psát :-)

Už ani nemusím chodit do knihovny půjčovat si detektivky. Stačí zajít občas počíst si na root cz.

Ps:. Chtěl jsem poslat jednorázový dukát za dobré počtení ale máte zde možnost jen pravidelně placeného členství. Tak třeba jindy :-)

Klasika. "Došlo k selhání zásuvného modulu."
Ne, vážně. Nechápu proč normální lidi používají WP s pluginy, když zjevně není pro normálního smrtelníka lehké to udržovat v rozumně bezpečném stavu.

Čím víc pluginů, tím víc Adidas. naštěstí časem některé z nich vyhodí už kvůli tomu, jak je ten web pak pomalý.

Dobrý článek z praxe. Je dobré zdůrazňovat, že ne vždy jde všechno podle příruček, Best practises, ne všude mají WAF a RBAC, oddělené účty jako v pentagonu nebo IT oddělení núkibu.

ne všechno je dokonalé, i i tady , způsob vyřešení asi nebyl dokonalý, ale stylem když to vypadá,nerozbitě, asi už je to vyléčený, což u samomodifikujícího a eval-based-cms je nešťastný přístup

Možná by se hodilo na závěr nebo na další článek vydat, co jaké kroky nebo jaký checklist hlídat, když se takový incident stane- detekce- konzervace, prevence šíření, zjištění škod, návrat, hlídání zda hotfix funguje a monitoring dalších pokusů a další.

Taky je vidět, že historie se opakuje, tohle je problém i minulých redakčních systémů i "slovutného wordpressu" (tzn redakčního systému číslo jedna, ale mezi modrými přezdívaný nejděravšjím bydesign)

17. 1. 2024, 19:03 editováno autorem komentáře

Dle názvu souborů jsem měl naprosto totožný útok. Bohužel jsem se o něm dozvěděl až pozdě, dle data soubory byly měněny před více jak rokem a nikdo si toho nevšiml. Dlouze jsem s tím bojoval stejným způsobem jako autor. Nakonec se nasadil Wordfence a říkal jsem si, že je klid. (cca září minulého roku)
Letos v lednu byl web napadený znovu.

Co tím chci říci ? Že někdy se k řešení problému dostanete tak pozdě, že zálohy zkrátka nemáte. A I když si myslíte, že jste vyhráli, je to jen chiméra a stačí jeden jediný backdoor, který neobjevíte a máte to tam zpět. Jak z toho ven ?

1. čistá instalace v posledních verzích a znovu obnovit data webu (ne vždy je ze strany zákazníka vůle)
2. zamknout web do read only režimu a WP tak zakonzervovat (ne vždy to jde)
3. říct zákazníkovi goodbye a problémového webu se zbavit.

Zde musím zareagovat jako člověk, který opečovává českou WordPress komunitu, a zároveň odvirování WP webů patří k jeho profesi.

Postup v článku nepovažuji za příliš dobrý… Rozhodně chybí forenzní část tohoto úkolu - je velmi důležité zjistit jak se nákaza na web dostala - zranitelností, cracknutím hesla, z prostředí, přes ftp atd. Ať už z logů, nebo analýzou používaných pluginů a šablon a jejich známých zranitelností. První, co je potřeba udělat je web odstřihnout od internetu, jinak může dále působit škody, infikovat návštěvníky, ničit reputaci ip adres, vytahovat informace z vnitřní sítě, další úniky dat. Není dobré něco zkusit odstranit a čekat, co se bude dít. Na změny souborů existuje vedlejší projekt WP CLI, který umí verifikovat checksumy a nepatřičné soubory ve WP jádru, pluginech a šablonách. Tento check lze provádět jednoduše automatizovaně.

Další důležitou součástí řešení incidentu je audit a reakce na uniklé údaje - útočník může mít hesla k účtům a databázi, různé api klíče, hesla k smtp, osobní údaje a podobně…

A pak samozřejmě návrh opatření pro minimalizaci opakování problémů.

Obecně je problém, že se o takové weby a jejich prostředí často stará někdo, kdo problematice příliš nerozumí a nechce se vzdělávat… Je sada vcelku jednoduchých postupů, které bezpečnost poměrně dost zvýší.

Protože se snažím šířit osvětu už velmi dlouho, tak bych doporučil své přednášky https://youtube.com/playlist?list=PLQ4qTpEj65qSCF2mqG9-ylZNvtz_tNEw_&si=PZ7WucZqF7z3jg_u

17. 1. 2024, 21:14 editováno autorem komentáře

Pry "utocnik". To urcite. Stopy ziveho utocnika ve Wordpressu dost tezko, to je vsechno automatizovane. A jinak staci nasadit na webu Wordpress, zapnout nejaka sledovatka, a hned od zacatku uvidite, ze se na vas utoci.

Na to neni vubec treba wp. Staci uplne prazdny weberver.

Už to tu někdo psal, že je bezpečnostní průser, když web může sám sebe modifikovat.

Bohužel časy kdy se weby spravovaly a aktualizovaly výhradně přes FTP jsou dávno pryč. Tehdy šlo dát každému webu 2 usery, jeden pro ftp (čtení i zápis) a jeden pro webserver (pouze čtení). Ale jak na to jít dnes, když se všecho dělá přes web? Aktualizace obsahu, aktualizace frameworku, změny nastavení, instalace pluginů, všechno. To není jen WordPress. Stejně to má i třeba nextcloud. A určitě mnoho dalších. A těch návodů které obsahují "chmod -R 777" a "chown -R www-data" je mnoho.

Některé frameworky aspoň řeknou kam ten zápis potřebují, ale je to dostačující? Jak zabránit aby to co se tam nahraje nešlo spustit? Stačí noexec na /var/www a .htaccess (deny all) na složkách kam je zápis? PHP includu to nezabrání, a v závislosti na frameworku asi půjde nějak načíst i soubor uložený v tmp nebo tak něčem.

Nějaké tipy, jak udělat CMS v tomto ohledu bezpečnější?

Tak my třeba máme WordPress z velké části symlinkované z centrálního repozitáře - samotný běžící web tak pak nemůže modifikovat soubory WP jádra a běžných pluginů (jiný vlastník). Lze pak nastavit DISALLOW_FILE_MODS a WP jádro pak zablokuje modifikace souborů přes jeho API. Dále k tomu zakazujeme přímý přístup k PHP souborům v uživatelském prostoru. Aktualizace lze pak stále jednoduše řešit přes WP CLI. Pořád samozřejmě zbývá několik vektorů, ale velkou část možných problémů toto pořeší.

Nevím, nakolik to je standard nebo vhodné, ale já mám web na partition přimapované v Read-Only režimu.
Ale, přiznávám, že mne k tomu nevedlo nějaké bezpečnostní nastavení, ale prostě jsem to zadával do fstab, říkal jsem si: Potřebuje to zapisovat? Nepotřebuje...

A to mate na te read-only partisne wordpress? Pokud ano, tak na ten web nedavate zadne novinky? Tak nejak mi nesedi kombinace read-only webu a CMS ?

Prepnuti do read-only beru jako spis tu posledni moznost, kdy hostuju evidentne deravy web a aktualizace ho rozbijou. Pochopitelne jako docasne reseni, nez si majitel ten web prepise do neceho spravovatelneho, ale jak vime jednotkou docasnosti je 1 furt. (cca 22 let)

Novinky nebo jakékoli jiné články by přece v případě WordPressu byly v databázi, ne v souborech na disku. Z hlediska obsahu webu by read-only oddíl s webem bránil jen nahrávání médií (např. obrázků). (Případně nějaké pluginy by se také mohly snažit něco nahrávat na disk, ale to nemá smysl řešit – pluginy mohou zkoušet dělat cokoli.)

Proc by proboha web mel cokoli zapisovat na disk? Data patri do databaze. A ta muze byt klidne i na uplne jinem stroji. RO je naopak, pokud tomu nic nebrani, dobry napad.

1. web nebude moci modifikovat sám sebe, ale nikdy se nebude aktualizovat
2. web může aktualizovat sám sebe a automatické aktualizace ho snad udržují aktuální

Druhá varianta je menší zlo. Navíc když web může modifikovat sám sebe, je možné tam přímo z administrace webu instalovat zásuvné moduly – což je další důležitá funkce WordPressu.

Holt když potřebné funkce neposkytuje operační systém (konkrétně balíčkovací systém), tak si to vývojáři WordPressu vyřešili po svém…

Nebo mít jiného uživatele, který to přes WP-CLI aktualisuje...

Ne, to v takových případech není volba, protože se tam nedostanete do shellu, ani tam není nikdo, kdo by něco takového spustil.

Pokud se o ten WordPress stará někdo, kdo má přístup i do operačního systému, je těch možností spousta, obvykle včetně kontejnerových technologií. Tady se ale bavíme o situaci, kdy někdo nakliká instalaci WordPressu na nějakém sdíleném webhostingu.

Dneska se napíše pipeline, která udělá Docker image, ten se spustí s právy, se kterými proces aplikace nemůže vůbec zapisovat a úložiště, ze kterého zase nejde spouštět kód, se drží bokem. Takhle jde hostovat i WordPress. Kdyby mi někdo řekl, že chce nasazovat kód přes FTP, tak mu řeknu, že volali z roku 1998 a shánějí někoho do týmu.

To je asi nejlepší možnost, ale v praxi to dost dře, protože je potřeba dost aktivně řešit patch management a tedy pořád buildit nové kontejnery... Mnohokrát jsem se setkal s tím, že někdo udělal kontejner a ten pak nechal hnít... Jde udělat i hybridní režim, kdy se patche aplikují přímo v kontejneru (což jde zase proti filozofii tohoto řešení) a image aktuální stav dohání.

Viděl jsem jen málo deploymentů, kde je to zvládnuté dobře... WP je opravdu dost živé prostředí...

"je potřeba dost aktivně řešit patch management a tedy pořád buildit nové kontejnery"

Od toho máme CI/CD ne?

No jo, ale zkuste si to takhle nasadit na nějaký PHPčkový webhosting za dvacet korun měsíčně…

Na to je hlavní recept “střídmost”+ ideálně systém pro hromadnou správu (ManageWp, MainWp, …) + pohlídání si základů třeba s pomocí bezpečnostního pluginu (jde to i bez něj, ale asi ne u hostingu za 20).

Hosting za 20 a bezpečnost? Na něco takového bohatě stačí ty automatické aktualizace.

Nojo, ale ty by default fungují, jen když je na webu návštěvnost, aby spustila virtuální cron, takže tam může být docela velké zeroday okno... Je také dost možností, jak je špatná konfigurace serveru rozbije. A pak je také potřeba automatické aktualizace pluginů individuálně zapnout, což skoro nikdo nedělá a nejrůznější "prémiové" pluginy takový autoupdate ani neumí...

"Dneska se napíše pipeline"

Ehm lul ... 99% webhosteru nic jineho nez ftp nenabizi,a neumi ho ani v sifrovane variante. Maximalne umi omezit pristup z konkretnich IP.

Jednoduchý způsob, jak se z toho průseru dostat:
1. vydumpovat databázi, zkonvertovat články do mardownu a zpět do HTML, 2. stáhnout čistý WP nahrát do něj strukturu kategorií a vyčištěné texty;
3. uložit do gitu a nebo si prostě udělat lokálí zálohu.
4. provozovat web readonly a updatovat z gitu.

Problém WP a dalších user friendly webových frameworků je v tom, že kvůli pohodlí administrátorů umožňuje spouštět libovolný kód, který mu podstrčíme tak, aby vypadal jako plugin. Hm, ten problém mám i ve své secure osCommerci, jdu ten autoloader hned smazat a nahradit explicitním konfiguračním klíčem :D

Problém typické instalace WP je zase v tom, že neodděluje databázového uživatele pro běh frontendu a administrace a už vůbec neřeší, že frontend uživatel nepotřebuje do většiny tabulek práva pro zápis a už vůbec ne GRANT OPTIONS.

Tady by asi bylo fér poznamenat, že neoddělování databázových uživatelů není problém WP světa, ale chová se tak naprostá většina monolitických aplikací - nezávisle na frameworku či jazyku. Velká část hostingů ani neumožňuje si vyrábět další databázové uživatele s různými právy.

Jinak postup s konverzí do markdownu není u aktuálních WP moc dobré řešení, protože ve zdrojových datech se nachází dost komentářových anotací, které ovlivňují práci s blokovým editorem a tento postup je odstraní. Zároveň jsou články často propojeny s dalšími meta informacemi a taxonomiemi a zachovat tyto vazby při takové konverzi není jednoduché.

S tím autoloadem to také není zase tak jednoduché - plugin musí uživatel aktivovat. Ano, existuje několik jasně daných souborů (drop-inů), které se WP snaží načíst. Existují speciální MU-pluginy, které je ale zase vcelku jednoduché pohlídat. A oblíbený trik je override WP template hierarchy, kdy útočník skryje kód třeba do šablony pro chybu 4O4 a tím odloží jeho spuštění. Nicméně, pokud už útočník dokáže podstrčit na server nějaký kód, tak je problém jinde, než v autoloadu.

Ad. GRANT: Stačí nám obvykle dvojí komfigirace, pro usery GRANT SELECT a pro adminy GRANT SELECT, UPDATE, DELETE a pro sebe na jednu za měsíc updatování GRANT ALL ... WITH GRANT OPTIONS.

Já jsem si upravil osCommerci tak, že generuju pro každého klienta extra db uživatele, který vidí a updatuje jenom svoje vlastní řádky protože je to pohled vázaý na username (alias Row Level Scurity).

AD Markdown: Hm, neznám WP. Tohle já bych použil když přijde zákazník, že má nějaký WP web, který mu přestal fungovat. Ale reálně za mnou přišel jen jeden člověk, kterému admin toh WP webu zmizel, tak jsem ho doloval z archive.org.

Autoloader je zlo :D

Vetsina patlalu, bez ohledu na velikost, netusi ze databaze ma nejake uzivatele, na ktera lze pridelovat nejaka opravneni. Takze typicka(zdaleka ne jen webova) aplikace pristupuje do DB pod jedinym userem a muze vse. Pak uz staci jen injektnout nejaky ten kousek SQLka.

StaticGenerator­WP... nevím jak se ten plugin jmenuje: vgeneruje z admina nehackovatelný statický web. Málokdo z akademiků potřebuje dynamickou funkcionalitu ale publikovat texty. Proč pak řešit updaty wp častěj než s verzí PHPka?

Disclaimer: Dělám eshopy v osCommerci a WP sleduju jen zdálky a v podobě pluginu wooCommerce jako kulhavou konkurenci (výkon, security, tristně nespolehivý košík v JS) a jako konkurenci naopak nebezpečnou množsvím pluginů a silou ekosystému wp.

Nejčastěji používám https://wp2static.com/, bohužel byl nedávno koupený komerční službou, která řeší statické web, takže myslím, že pomalu umře… Používali jsme ho třeba na koronavirus.mzcr.cz viz https://naswp.cz/pr-krizova-microsite-v-cloudu-za-par-hodin/. Fun fact je, že těch pluginů je více a většinu udržoval právě autor wp2static Leon Stafford a komunita kolem toho byla na https://staticword.press/.

Nově u pár projektů používám obyčejný wget mirroring doplněný o specifické věci daného webu a posíláním dynamických věcí přes rest api na origin server.

Woo se snažím držet co nejdále od sebe

Aha, super, zdá se že uvažujeme podobně :D