Kysymys wget -ohjelmasta liitettynä WordPressin turvallisuuteen

[Jere Sumell]

WordPress -sisällönhallintajärjestelmässä asetetaan kuuluisassa viiden minuutin asennuksessa tietokannan nimi, käyttäjänimi ja salasana "wp-config.php" -tiedostoon, jossa on "-sample" -loppu tiedostopaketin purun jälkeen, mutta se pitää poistaa.

Luin Stackoverflowsta, että jos käyttää komentoa:

Koodia: [Valitse]

wget -m http://web-site.com
Niin tuo peilaus, Mirror -kytkin kopioi rekursiivisesti myös kaikki "php" -tiedostot palvelimelta. Onko näin? Jos näin on, lopetan WordPress -alustan käytön. Sieltähän saa kuka tahansa salasanan selvitettyä ja sabotoitua kotisivun?

[jekku]

Miten mahtaa tunnistaa 'kaikki "php" -tiedostot' ?
Edit:
Kokeilin sisäverkossa, se näytti ryystävän aika outoja juttuja ??
Tosin ei saanut kuin index.html:n ja openlogo-75.png:n
Vaan eipä ole WordPressiäkään ...

[Jere Sumell]

No joo, itsekin selvitin asian ihan Empirian keinoin kohdentaen varmuuskopio-kyselyn omaan tradenomi-ammattiblogiini. (https://tradenomi.tuntikirjuri.net/Blogi) ja eihän sieltä mitään saanut irti. Tuli pelkkää herjaa, että "SSH-yhteyden muodostus epäonnistui". En sitten tiedä, onko noissa verkko-isäntien turvallisuus-conffeissa eroja, mutta ainakaan omalla verkkoisännälläni, jossa olen asiakkaana, ei toimi tuo.

Löysin blogin varmuuskopintiin liittyvän mielenkiintoisen artikkelin D'Arcy Normanin blogista melkein kahdeksan vuoden takaa, https://darcynorman.net/2011/12/24/archiving-a-wordpress-website-with-wget/ , kun tänään herätessäni aamulla havaitsin kotisivujeni heittävän 503-service unavailable -virhekoodin selaimeen, niin päädyin tutkimaan sivustolleni kohdistuneita kyselypyyntöjä joulukuun 2019 aikana, ja lisäselvitys sai minut siihen lopputulemaan, että jokin red-hat-botti on hyödyntänyt jotain backdoor-haavoittuvuutta installatron-plug-inin asennuksen aikana luomista väliaikaistiedostoista. Monet verkkoisännät ovat hankkineet Installatron -plug-in-retailer -lisenssin, jotta näiden asiakkaiden olisi helpompaa asentaa WordPress -palvelimelle, ja itsekin olin 2015 helmikuussa asentanut sen sillä. Kyseisestä haavoittuvuus-riesasta ja hackki-botti-sabotoijaa ei tarvitse enää välitttää, käsittääkseni ainakin kyseinen WordPress hacki on toimintakelvoton, jos WordPressin asentaa manuaalisesti palvelimelle. Kirjoitin aiheesta artikkelin alkuillasta myös Tietokone--blogiinikin.

[jekku]

Niinpä niin - "helppoudella" on hintansa.

[retu]

Php on ajettava tiedosto eli wget saa hyppysiinsä mitä php-tiedosto tulostaa. Tietysti tilanne on toinen jos palvelinta ei ole konfiguroitu ajamaan php tietostoja tai php ei ole asennettu. Tällöin php-lähdekoodi näkyy.

Tuo wget peilaus perustuu siihen että wget seuraa rekursiivisesti sivuilla olevia linkkejä ja lataa kaikki tiedostot joihin sivuilla viitataan. Sillä ei kuitenkaan ole mitään 6. aistia. Jos palvelimella on jokin tiedosto johon sivuilla ei ole linkkiä, wget ei löydä sitä.

Mualimalla on monenlaisia hakukoneita, joten on ihan normaalia että eri botit käyvät nuuskimassa web-sivuja.

[Jere Sumell]

Joo, botteja kehitellään koko ajan, itsekin kun seuraan verkkosivujeni liikenne-logia, niin tulee mitä oudompia botin nimiä vastaan.

Tuossa vastasinkin jo aiemmin, kun kerroin oman tarinani Installatron -plugin- kokemuksestani, ja kokeilin tosiaan tuota omaa blogia varmuuskopioida, niin ajettavan php-tiedoston lähdekoodia ei saa, jos verkkopalvelimella on php asennettu, että se ajaa tiedostot. Selaimellakaan luonnollisesti ei saa lähdekoodia selville, ja se on ihan turvallisuus-syistä.

[jekku]

Oli muuten ihan asiallinen harjoitus.

Olen jostain omaksunut tavan että nimeän includattavat tiedostot poikkeavasti, en siis .php -loppuisesti.
Ja kun kokeilin, niin apassihan tarjoaa ne ladattavaksi jos vain tietää nimen.

Joten nuo salasanoja sun muut piilottamisen arvoiset tiedostot tallentanen webrootin ulkopuolelle.
(php:n include löytää ne kyllä, ainakin kun kirjoittaa absoluuttisen polun.)

Harjoitus jatkuu ...

[Jere Sumell]

Jos joku tietää keinon, miten saa PHP-tiedostoistakin ladatuksi palvelimelta lähdekoodina tiedostot, olisin kiinnostunut lukemaan/tietämään, miten se käytännössä varmuuskopiointi tapahtuu. Luulisi, että jokin työkalu on olemassa, kun PHP on niin vanha kieli, ja verkkoteknologiaa kehitetään koko ajan eteenpäin.

[Tomin]

Jos joku tietää keinon, miten saa PHP-tiedostoistakin ladatuksi palvelimelta lähdekoodina tiedostot, olisin kiinnostunut lukemaan/tietämään, miten se käytännössä varmuuskopiointi tapahtuu. Luulisi, että jokin työkalu on olemassa, kun PHP on niin vanha kieli, ja verkkoteknologiaa kehitetään koko ajan eteenpäin.

Ainoastaan www-palvelimen ohi. FTP- tai SSH-yhteyden yli (jälkimmäisen tapauksessa siis SFTP-protokollalla yleensä). Jos www-palvelin on säädetty oikein, niin PHP-tiedostoja ei pääse koskaan sellaisenaan lukemaan.

[jekku]

Minä käytän tilanteen mukaan joko scp tai rsync tuohon varmuuskopiointiin.
Hienosti kulkee

[Jere Sumell]

Jos joku tietää keinon, miten saa PHP-tiedostoistakin ladatuksi palvelimelta lähdekoodina tiedostot, olisin kiinnostunut lukemaan/tietämään, miten se käytännössä varmuuskopiointi tapahtuu. Luulisi, että jokin työkalu on olemassa, kun PHP on niin vanha kieli, ja verkkoteknologiaa kehitetään koko ajan eteenpäin.

Ainoastaan www-palvelimen ohi. FTP- tai SSH-yhteyden yli (jälkimmäisen tapauksessa siis SFTP-protokollalla yleensä). Jos www-palvelin on säädetty oikein, niin PHP-tiedostoja ei pääse koskaan sellaisenaan lukemaan.
[/quote

Sitä vähän arvelinkin, kun tuolla Auttomatticin inc:n wordpress.com -siviullakin etusivulla on mainoslause, että noin vajaat 40% Internet-sivuista pyörii WordPressin varassa, niin jos olisi mahdollista, käyttö olisi paljon vähäisempää. Ja monen muun alustan, joka on toteutettu PHP:llä, niin käyttö olisi vähäisempää nolla-turvallisuuden takia.

[retu]

Tuo rsync varmaan kätevin, jos haluat tehdä 1:1 kopion sivustosta ja päivittää sitä ajoittain. Se kun osaa kopioida vain muuttuneet tiedostot.

Jos sivut on tehty wordpressillä tai vastaavalla, tärkeämpää on ottaa kopio tietokannasta. Koska siellähän se sivujen vasinainen sisältö on. Ne php-kilkkeethän saa ladattua/asennettua tarvittaessa uudestaan (paitsi asetustiedosto, joten se talteen). Tietokannan voi varmuuskopioida ajamalla mysqldumpin ssh-yhteydellä.

Jos koodailee sivuja itte, kannattaa käyttää erillistä kehitys/testikonetta ja siellä versiohallintaa. Näin siksi ettei julkisesta palvelmesta tulisi matolaatikkoa, jolla kasapäin jotain keskeneräisiä puolivillaisia tekeleitä.

[Jere Sumell]

Joo, mun verkkoisännälläni on automatisoitu tuo tietokannan varmuuskopiointi, ni sain sen sittenpalautetuksi. Asensin manuaalisesti WordPressin palvelimelle, niin nyt ei voi automaattibotti enää hyödyntää Installatron-pluginin asennuksen yhteydessä luotuja väliaikaistiedostoja tai pluginin haavoittuvuuksia sivujeni sabotointiin. Red-Hat-teknologia-orientoituneiden ihmisten täytyy keksiä jotain muuta, jos nyt välttämättä näkevät jotain lisäarvoa tuottavaa just mun sivujen kaatamisessa, ko ei ole sillä tavalla oikeastan vihamiehiäkään oikeassa elämässä, saati netissä ainakaan tietääkseni pitäisi olla.