wp-config.php hacka...

[TorsteinO]

Ok, dette er problemstillingen:
Jeg hjalp en kompis med å sette opp en WP-blogg som portfolio for en måneds tid siden, og for et par dager siden hadde den blitt hacka. Etter litt grubling fant jeg ut at det var wp-config.php som hadde blitt forandra, så heldigvis var det så enkelt som å legge den inn på nytt.

Litt kjapp google-fu har også gitt meg noen forskjellige løsninger for å hindre at det skjer igjen, men siden jeg ikke akkurat er noen PHP-guru, så jeg ikke helt sikker på hvor bankers disse faktisk er? Er det noen som vet om en god/anbefalt permanent løsning på problemet?

Syns også det virker helt rart at det skal være en så usafe løsning i et så mye og godt ansett script som wordpress?!

Jeg syns også jeg husker at det var noen her som hadde opplevd problemer med at det dukket opp "usynlige" linker de ikke helt skjønte hvor kom fra, dette her kan jo se ut til å være forklaringen.

 

[picxx]

Hoster han på servage.net
I såfall er den eneste løsningen å bytte host.

Jeg har hatt en mengde filer (både core og templates) hacket som er hostet hos servage.
Det er den eneste hosten det har skjedd hos, og jeg har overhodet ikke peiling på hvordan jeg skal få fikset det. (Har prøvd det som er å prøve + skrevet til servage, som selvsagt ikke vet nooooenting).

 

[Helge]

både domeneshop og servage og mangen andre leverandører av webhotell er VELDIG enkelt å hacke. Hvertfall om du kjører kjente script som Wordpress ol.
Alt du trenger å gjøre er å få deg en konto der (eller komme deg innpå noen andres konto), så vet du jo hvordan banen til wp-config ser ut.

Se om servage har hatt noen uttalelser på wp problem tidligere, i tilfelle så har de nok skrevet ned en løsning på problemet.

Var jo ikke SÅ mangen mnd siden både WP og forskjellige dro ned et par av serverene til domeneshop.

 

[TorsteinO]

Det er hos domeneshop. Det jeg har funnet av tips hittil er her:
Protect Your WordPress WP-Config So You Don’t Get Hacked | Devlounge

 

[Tonny Kluften]

Det skjedde meg, tror det var på hostgator det skjedde. Mulig det hjelper å oppdatere WP.

 

[TorsteinO]

Åja, glemte forresten ett viktig, enkelt og sannsynligvis bra tips: chmod wp-config.php så den ikke er skrivbar. Kan ikke nok om php&sikkerhet til å vite om det vil løse alt av problemer, men det bør ihvertfall gjøre ting *litt* værre for kjeltringene

 

[tyr897]

Det store problemet er på shared hosting. For at wordpress skal kunne kjøre, må apache ha tilgang på filen. Dersom apache har tilgang på filen, har også andre brukere det, iom at deres filer også kjøres av apache-brukeren. Det er da ingenting som hindrer meg i å inkludere noen andre sin wp-config.php, koble til databasen og slå meg løs.

Det finnes måter å takle dette på, suexec, suphp, mpm-peruser etc. Men dette er opp til hosten.

Det er jo også mulig å bli hacket i form av rene sikkerhetshull i wordpress, så man må sørge for å holde seg oppdatert.

 

[Gomlers]

Det store problemet er på shared hosting. For at wordpress skal kunne kjøre, må apache ha tilgang på filen...

Men det må vel fremdeles hjelpe å sette chmod til 666/444?

 

[Deezire]

Feil konfigurering fra hosten deres gir alle andre tilgang til filene. Det kan ganske enkelt forhindres ved å kun gi apache lesetilgang til filene.

 

[tyr897]

Men det må vel fremdeles hjelpe å sette chmod til 666/444?

Jeg har da fortsatt lesetilgang, noe som betyr at jeg kan hente ut brukernavn og passord til databasen.

 

[Gomlers]

Jo, men det vil jo nesten alltid ligge en slik risiko tilstede, fordi de fleste script er laget med en spesiell configfil. Men med tanke på å få siden sin, eller databasen slettet, så går det jo an å kjøre krypteringer på krypteringer, og så legge det i databasen.

Jeg mener, folk vil jo uansett ha tilgang på filer, om de heter jalla.navn.på.fil.cfg eller om de heter configuration.php - om du da ikke klarer å kode det slik at config.php blir liggende over /www katalogen da

 

[tyr897]

Konfigurasjonsfilen bør ideelt sett ligge utenfor www-mappen.

Men ja, denne risikoen er ofte tilstede, dersom hosten ikke har gjort tiltak for å verne deg. Det er selvfølgelig bare andre kunder på samme host som kan skade deg, men de kan jo bli hacket og dermed dra deg med seg. Kryptering gjør det bare vanskeligere, for kodenøklene må jo ligge et sted de også

 

[Deezire]

Hvis man blir utsatt for et angrep av noen som vet hva de gjør så er det ikke noe problem å finne en fil selv om den er utenfor www/public_html-mappen. Det ligger rett og slett i strukturen til Linux. Det er vanskeligere å låse en bruker innenfor sitt hjemmeområde enn på f.eks. FreeBSD.

Men ja, det vil gjøre det mye vanskeligere å angripe deg hvis filen ligger utenfor www/public_html-mappen da man gjerne kun kan lese filene, så fremt man vet hvor de ligger.

En annen gjenganger er at folk som driver shared hosting er litt sloppy når de kjører diverse programmer som root, slik som locate, og da lager en katalog over alle filene til alle brukere, som også brukere kan aksessere. Er ikke værre enn å skrive "locate wp-config.php | grep /home/*", så har du alle banene til de som har installert og bruker wordpress, og hvor konfigurasjonsfilen ligger.

 

[vidarlo]

Hvis man blir utsatt for et angrep av noen som vet hva de gjør så er det ikke noe problem å finne en fil selv om den er utenfor www/public_html-mappen. Det ligger rett og slett i strukturen til Linux. Det er vanskeligere å låse en bruker innenfor sitt hjemmeområde enn på f.eks. FreeBSD.

Not really. Ein har ulike metoder for dette, m.a Extended ACL som er støtta i alle nye filsystem, inkludert EXT2 etter 2.4.1 eller noko. Problemet oppstår i det webserveren skal ha skrivetilgang, men ikkje brukere. For script blir ofte kjørt som webserveren... Det finst vegar rundt dette, men då forsvinn også problemet, ettersom mode 700 funker om script kjører som bruker istaden for webserver.

Beste metoden er IMHO PHP som cgi + su_exec i apache.