Wordpress "felügyelet" - üzemeltető oldalról

Fórumok

Sziasztok,

Sajnos (?) lassan minden harmadik oldal WP alapú. Ez pedig folyamatosan generálja a problémákat.
Eljutottunk odáig hogy több 100 WP oldalt „üzemeltetünk”, úgy hogy a többségéről nem is tudunk.

Ezek közül rendszeresen vannak problémás oldalak.

Arra gondoltam hogy ezeket valahogyan keresni kellene.

Két dologra keresek megoldást:

  • adott hoston megkereseni egy scripttel a WP-s oldalakat, ez valószínűleg pár grep-el megvan.

  • A megtalált oldalakon valamilyen check-ek lefuttatni pl. wpvulndb.com alapján

  • a sérült oldalakról értesítést kapni

Ami főleg kérdés lenne, github és társai tele vannak WP scanner scriptekkel amit wpvulndb-t (is) használják, van ezekkel valakinek tapasztalata?
Megbízható, más kedvességet nem tartalmazó scriptet keresek.

Hozzászólások

Bár mi nem elsősorban hostolunk, de én meg azt mondom, hogy szerencsére, mert a joomla bugtengerhez meg az egyéb már ránézésre is hányadék motorhoz képest még mindig a legjobb.

"Sose a gép a hülye."

  • de én meg azt mondom, hogy szerencsére, mert a joomla bugtengerhez meg az egyéb már ránézésre is hányadék motorhoz képest még mindig a legjobb.

Aha. Ennyi erővel wp is egy hulladék. Joomlának sokkal jobb adatbázis struktúrája van. Persze kisebb forgalmú oldalaknál nem veszi észre az ember, de ha van egy több tízezres tételű webshopod kurvára nem mindegy, hogy wp vagy joomla megy alatta.

A joomla egyetlen baja, hogy sokan nem kellően értenek hozzá.

A WP csak azért ennyire népszerű, mert sok gyökér nem képes megtanulni a joomlát, meg valamivel nagyobb választék van az ingyenes kiegészítők között.

De én annak a híve vagyok, hogy joomlából csak fizetős kiegészítőket érdemes komolyabb célra használni, ott viszont lesöpri a wp-t.

Régen a joomla biztonsági szempontból olyan volt, mint egy lyukas sajt.

Igen ez igaz. Ezzel montad ki a tutit. Az 1.0-ás joomla kész öngyilkosság volt, amit azzal tetéztek, hogy önjelölt programozó wannabeekiddyk is tudtak rá írni modult 0,00000000000000000001%-os php tudással. Az 1.5-es is hagyott kívánni valókat, de a 2.5 óta egész normális lett. Annyiban szarabb még a joomla a vetélytársaihoz képest, hogy irgalmatlanul lassan fejlődik. Már rég ki kellett volna jönnie a 4.0nak és még az is bizonyalan, hogy idén megjelenik.

Azt azért hozzá tenném, hogy nem hozzáértő kézben az összes cms tele lehet biztonsági réssel. Elég az hozzá, ha nem frissítik.

Szia, meg szabad nézni a szolgáltatói oldalt?

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

Szerkesztve: 2020. 06. 11., cs – 19:16

Hogy a témához hozzászóljak egyébként, nem érdemes sem wordpress-re, sem semmilyen más specifikus dologra rámenni. Általánosan, szolgáltató oldalról kell a szervert biztonságossá tenni. Pl. chroot az oldalnak, természetesen külön userként futtatva a php, minden problémás php függvény tiltva, levélküldés csak auth-tal csak smtp-n, minden kimenő kapcsolat tiltása. Rengeteg problémába fogsz belefutni, jönnek majd hogy nem megy a szarjuk, szar a szervered mert máshol megy, nem fogok a sok "okos" "php-programozót" meggyőzni, hogy szar a kódjuk. Rengeteg meló van azzal, ha pl. a tűzfalat karbantartani akarod, de csak így lehet. A webhosting az egyik legutálatosabb dolog.

"Sose a gép a hülye."

A helyzet az, hogy nem a szerver konfigon keresztül jutnak át, hanem az elhanyagolt WP-n keresztül. Tehetsz oda akármilyen WAF (web app firewall-t), ha olyan bug van a WP-ben, hogy regisztrálni tudnak trükkösen vagy simán file-t feltenni. Onnantól, hogy a csúnyagonosz PHP felkerült vége és az aktuális divat, hogy a WP saját cronjába pakolják bele és már leszedi magának, hiába takarítja ki bárki a filerendszert. Ezek a fő ellentmondások, problémák szerintem:

  • legyen a PHP külön juzer, ahogy írod, de persze tudja a docroot-ot fullosan írni, praktikusan ugyanaz a juzer, hiszen ha nem így van, akkor szar a szerver... hiszen nem tudsz fél klikkel feltenni plugint vagy full WP-t frissíteni (ami pl. a lecserélt index.php-t se javítja meg)
  • hiába próbálsz mondjuk a wp-content/*.php -ra feltenni egy szabályt, hogy az direktben forbidden, tuti lesz valami elb.... plugin vagy téma, ami márpedig mindenképpen onnan kell, hogy működjön, és persze szar a szerver, ha nem
  • a pluginek külön csodálatos világát rendszeresen elfelejtik frissíteni és nem takarítják le a fölösleges, de le sem kapcsolják
  • hiába megy automatikus levél, hogy nézd régi a WP (wp-includes/version.php -ból kinyerhető) nagyon minimális a foganatja, pedig talán manapság még a WP is szól magától
  • ami működik részben, az a wp-login.php és xmlrpc.php -k referer nélküli POST-olásának tiltása, ez sok brute force-t is megfog, de a fentieken nyilván nem segít
  • az adminisztratív ellentét főleg ott van, hogy a weboldal megrendelője a "kifizettem, akkor márpedig menjen és kész" logika alapján nagyon nem szeretne folyamatos karbantartásért fizetni a webfejlesztőnek, a fejlesztői oldalról pedig jogos elvárás, hogy azért az nem megy, hogy van 150 oldal amit összerakott és utána a világ végéig már csak ezeket frissítgeti, az külön szép, amikor a sokéve nem frissített WP-s oldalnál fel sem tűnik hogy tele van spammelve, nyilván szar a szerver
  • végül ha felteszed a valamilyen WAF megoldást, akkor tuti lesz minimum egy, de inkább több, olyan juzer, akinek instant letúrja a cuccát, vagy ha új install akkor felteszi és nemmegy és szaraszerver..., hiszen a mindegyhogyan csak műküdjön semmire sincs idő logikába ez már nem fér bele, ja és "nekünk ezt nem fizetik" (valszin tényleg nem...)

Innentől kezdve senki se csodálkozzon, ha ennyi gyanús link és minden szar kering a neten.

"van 150 oldal amit összerakott és utána a világ végéig már csak ezeket frissítgeti"

Szerintem ezzel baromira nem lenne baj. Ha van 150 oldalad, aminek a frissítéséért, karbantartásáért elkérsz oldalanként havi X ezer forintot, amiből elvagy, vagy ad egy fix alapot. A probléma azzal van, hogy nemcsak a userek, hanem még a fejlesztők jó része is úgy van vele, hogy odaszarik egy oldalt, és kész, az a világ végezetéig elmegy így, semmit nem kell vele csinálni. Pedig nincs a világon semmi olyan dolog, amihez ne kéne időnként hozzányúlni, az IT-ban meg nem időnként, hanem rendszeresen.

"Sose a gép a hülye."

Elkezdtem írni egy hasonló összefoglalót, de ezt nagyon jól összefoglaltad!

 

Csak néhány példával egészíteném ki!:

  • Elkezdtünk központi eszközön szűrni xmlrpc-t, 2 nap múlva már jött a panasz hogy valami plugin nem megy. A „fejlesztőnek” fogalma nem volt hogy a plugin hova-hogyan kommunikál, a válasz a szokásos volt, az ő tárhelyén megy!

  • Másik WP „fejlesztő” által készített oldalon, 600 Mb!!! az SQL dump, ezt másolgatja a fejlesztői tárhely és éles hely között. PHPmyAdmin timeout-olt, szerintünk teljesen normálisan ~25perc után.
    A mi rendszerünk milyen xar, ez máshol megy.
    Magyarázd meg a megrendelőnek, hogy 600Mb SQL dump mozgatása PHPmyAmin-nal nem életszerű. És amúgy meg mi 600Mb egy WP dumpban?

  • Harmadik „fejlesztő”, mysql x.y verziót kérek! Mariadb van fent, kisebb volt a verziószám. Nem! Nem, ez nem kompatibilis az oldal, neki mysql x.y kell. Jah a te kedvedért a teljes cluster SQL-t szétborítjuk.

  • Önálló VM-re nagyobb WP telepítés, nginx + PHP-FPM, volt pár rewrite és hasonló probléma. Nem egy WP-t raktunk már nginx alá, soha semmi gond, ha tudod mit-mire kell átírni. Na a fejlesztő a kérdést sem értette, és jött az anyázás hogy miért nem Apache van, mert az az „ipari standard”. OMG, anyád, aztán kénytelen ment fel apache …

  • Aztán a szokásos, WP + 318 plugin, a nyitó oldalt valami 10sec alatt generálja, válasz: lassú a szerver!!! Javasoltunk redist és hasonlókat, nem-nem! Az ő gépén otthon jó, xar a szerver.

    Jah, otthon te nézed egyedül, élesben meg más is …

 

Szóval lehet ezt ragozni, WP és társai nekünk probléma forrás, de ha tudunk róla, és esetleg nagios-ban lesz rá egy warning, akkor talán jobb a reagálási idő!

Lehet semmi sem elég:) azért a felhasználóknak is vannak eszközeik

"Funkcionális" hiányosság van-e a listában?

  • tárhely szolgáltató oldalon minden ami biztonsággal kapcsolatos
  • Cloudflare tűzfala + egyéni szabályok
    • Security Level High
    • Browser Integrity Check 
    • Challenge requests matching patterns of known bots before they can access your site.
    • wp login Cloudflare Javascript Challenge 
    • wp admin Browser Integrity Check: On, Security Level: High, Cache Level: Bypass, Disable Apps, Disable Performance
    • threat_score >10 Javascript Challenge 
    • threat_score > 50 Block
    • Always Use HTTPS
    • Automatic HTTPS Rewrites 
    • HTTP Strict Transport Security + Preload
    • minimum TLS version 1.2 or 1.3
    • Child Sexual Abuse Material (CSAM) Scanning Tool 
    • email address encrypts
  • Captcha
  • Ban Hammer
  • Easy Updates Manager
  • iThemes Security
    • protect System Files Prevent public access to readme.html, readme.txt, wp-config.php, install.php, wp-includes, and .htaccess. 
    • HackRepair.com's blacklist 
    • Max Login Attempts 
    • Automatically ban "admin" user
    • Disable Directory Browsing
    • Filter Request Methods. Filter out hits with the trace or track request methods.
    • Filter Suspicious Query Strings in the URL. These are very often signs of someone trying to gain access to your site but some plugins and themes can also be blocked.
    • Filter Long URL Strings. Limits the number of characters that can be sent in the URL. Hackers often take advantage of long URLs to try to inject information into your database.
    • Disable PHP in Uploads. Disable PHP execution in the uploads directory. This blocks requests to maliciously uploaded PHP files in the uploads directory.
    • Disable PHP in Plugins. Disable PHP execution in the plugins directory. This blocks requests to PHP files inside plugin directories that can be exploited directly.
    • Disable PHP in Themes. Disable PHP execution in the themes directory. This blocks requests to PHP files inside theme directories that can be exploited directly.
    • Change WordPress Salts
    • Remove the Windows Live Writer header. This is not needed if you do not use Windows Live Writer or other blogging clients that rely on this file.
    • Remove the RSD (Really Simple Discovery) header. Removes the RSD (Really Simple Discovery) header. If you don't integrate your blog with external XML-RPC services such as Flickr then the "RSD" function is pretty much useless to you.
    • Disable File Editor. Disables the file editor for plugins and themes requiring users to have access to the file system to modify files. Once activated you will need to manually edit theme and other files using a tool other than WordPress.
    • Disable XML-RPC
    • Restrict access to most REST API data.
    • Disables a user's author page if their post count is 0.
    • Prevent attachment thumbnails from traversing to other files.
    • Change Database Table Prefix
    • Hide the login page by changing its name and preventing access to wp-login.php and wp-admin.
    • Blacklist more Countries
  • 2 Factor Authentication
  • Proxy & VPN Blocker (havi díjas)
  • Stop Web Crawlers
  • w3dev Ban Users
  • 404 detection 

Igaz nem a főoldal, de a további kattintások 0,13 - 0,30s, valószínű nem apache és nem nginx a kiszolgáló.

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

chroot helyett esetleg docker container php-fpm-mel, és úgy lényegesen jobban szeparált minden ügyfél, mint a chroot esetén, meg a konténereknél az erőforrásokat is lehet limitálni.

Láttam én is olyat, hogy ügyfél csoda php-s vackán bejött valami bot, és IRC-n várt utasításokat - 2000-res évek közepe, akkor ez volt a divat. Akkor ez nagyon jól megoldotta volna a gondomat (hogy a többi ügyfelet ne érintse, stb...)

Én wordpresst, egyéb hasonló necces dolgot csak saját felelősségre, írásosan erről tájékoztatva vállalok, ahol ha szétverik az oldalt, én annyit teszek hogy letörlöm az egész motyót (chroot), és sok sikert. :)

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Szerkesztve: 2020. 06. 15., h – 20:23

"az adminisztratív ellentét főleg ott van, hogy a weboldal megrendelője a "kifizettem, akkor márpedig menjen és kész" logika alapján nagyon nem szeretne folyamatos karbantartásért fizetni a webfejlesztőnek, a fejlesztői oldalról pedig jogos elvárás, hogy azért az nem megy, hogy van 150 oldal amit összerakott és utána a világ végéig már csak ezeket frissítgeti, az külön szép, amikor a sokéve nem frissített WP-s oldalnál fel sem tűnik hogy tele van spammelve, nyilván szar a szerver"

Engem inkább ez érint:) Ha (bizonyos okból kifolyólag) szóbeli megállapodás alapján, 1x csak nem fizet az ügyfél, akkor azért az idők végezetéig nem gondolhatja hogy karban lesz tartva a tárhelye, a 4-5 wp oldala,  a CDN és a levelezése.

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek