Vlákno názorů k článku Čistění napadeného WordPressu: jak jsem hledal a vyhodil útočníka z webu od Vladki - Už to tu někdo psal, že je bezpečnostní...

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.