|
Wordpress: kako da izbegnem chmod 777 za upload folder
Pozdrav,
vise puta sam haknut preko foldera koji su bili u 777 rezimu. Kako to da izbegnem za Wordpress? Hvala |
recimo mod_fcgid koji omogućava da se svaki sajt vrti pod userom koji je vlasnik fajlova.
Tako možeš na sve fajlove koji sadrže passworde staviti chmod 600 i koji su čitljivi samo tvom useru. Takođe dir koji je tebi writable, može ostati zabranjen za sve druge. I nikada nećeš imati problem sa permisijama. |
777 je ludost. Promeni vlasnika direktorijuma.
Takodje, dodaj .htaccess i zabrani da moze da "izadje" bilo sta sto je recimo .php, .sh... Ako recimo imas samo slike, dozvoli da moze samo .png, .jpg, .gif i relativno si miran. I ako si haknut, reinstaliraj server i dobro proveri fajlove koje postavljas. Moguce je da su "hakeri" ostavili neki backdoor. |
Moze li neko objasnjenje kako se to dogodilo? Osim upload foldera (i eventualno cache foldera, mozda je upravo ovde problem u kesiranju) nijedan folder nebi trebalo da ima write permission, osim ako neces autoupdate i online edit fajlova i ostalog, mada i tu postoji opcija sa FTP-om.
|
1) Upload folderu ne moras da dajes 777, vec samo apache treba da ima pristup njemu, a obicno je na hostingu apache dodat u grupu usera, pa ce i 770 resiti problem.
2) Treba uvek dodati u .htaccess: Kôd:
RewriteCond %{REQUEST_FILENAME} !\.[jpg|jpeg|gif|png]$ |
Koliko saveta, a nista skoor ne razumem... :)
Dakle imam uploads folder kojem po pravilima WP treba da dam 777, a to ne zelim, vec 755 Ovo sto je ivanhoe napisao mi je najlogicnije, samo pitanjce... koja je putanja? Ako je .htaccess u tom folderu, sta onda treba da pise? hvala |
Stavio sam ovo u htaccess
<Files ^(*.jpeg|*.jpg|*.png|*.gif)> order deny,allow deny from all </Files> i ostavio za sada 777... |
Folder mora da ima dozvolu za pisanje za apache usera, a nikako da bude 777.
Znaci, treba apache (ili kako god da se zove) da bude vlasnik direktorijuma i da ima 700 ili eventualno 770 (recimo ako radis rsync na neki server pa jos neko treba da pristupa fajlovima ili bilo koji slicni scenario). Svi fajlovi u tom direktorijumu treba da budu 600 (ili opet eventualno 660). Uz to i ovaj .htaccess koji si dodao, relativno si siguran (bar po tom pitanju). |
pitao sam provajdera, kaze sve moze, ali najbolji je suPHP
sta god to znacilo :) |
suPHP menja UID procesa koji izvršava skripu tako da se skripte izvršavaju pod onim korisnikom koji je njihov vlasnik, tako da skripta može i da piše u fajlove koji imaju chmod 644 i foldere koji imaju 755 npr (ako je owner isti kao owner skripte). Ja ga koristim na serveru i super vrši posao, a pritom i sprečava malware da pređe sa nekog sajta na tom serveru na drugi sajt na istom serveru
|
Najveci problem su ti html editori i ekipa koji rade upload fajlova. Pa ti onda haker lepo spakuje test.php.gif koji ima header GIF fajla (pa getimageinfo() vraca sve ok), a iza njega PHP kod...
E sad, najveci crnjak (koji nikako ne mogu da shvatim) je da default config PHPa/Apacha parsira PHPove koji imaju ".php" u imenu, a NE koji se zavrsavaju na .php. Lako je proveriti ovo, a jos lakse ispraviti... Treba dodati jos nesto u htaccess pored odbijanja pristupa, jer ova vasa resenja (@ljtruba, @ivanhoe) ne hvataju ovo o cemu pisem. Info @ http://shishworks.blogspot.com/2010/...load-file.html |
Ako se server izvršava pod apache userom a radi se o sherovanom hostingu onda imaš problem kakvu god permisiju staviš jer ako dodijeliš write pravo na neki dir za apache usera onda neka maliciozna skirpta koja se izvrši u tom diru može da piše po svim drugim dirovima koji imaju write prava za apache usera bez obzira što se radi o sasvim desetim sajtovima koji su na istom serveru...
|
@srdjevic: ne znam za taj napad, probao sam sad na dva servera i ni na jednom ne radi sa fajl.php.gif, server ga posalje kao image/gif
Onaj vektor napada za koji sam cuo je da uploadujes skript.gif, sto je u stvari php skript i da onda iskoristis neku rupu u sajtu da ga nateras da uradi include tog koda... to je vrlo opasna stvar, ali tu nikakve permisije ne pomazu |
Citat:
Da, posalje on fajl kao image/gif nazad, to nije problem, ali ako fajl ima u sebi PHP kod, on se izvrsi isto... Recimo <?php phpinfo(); ?> ce verovatno postaviti taj header jer je .gif, ali ce ludi Apache izvrsiti PHP kod; mozda nece dati nista u browseru / za download, ali kad pogledas source, vidis output phpinfo()a... Tako je bar bilo na skoro svim serverima koje sam proverio. |
@sredjevic
Sa standardnim podesavanjem apache/php (probao na ubuntu i centos) izvrsavaju se samo fajlovi koji se zavrsavaju sa .php. Fajl tipa nesto.php.gif se naravno ne izvrsava. To svakako nije standardno podesavanje apacha-a. I ovo sa .htaccess je poslednja linija odbrane. Treba spreciti upload fajla. Dodatno, moze se staviti u .htaccess da se u tom direktorijumu ne izvrsava php, ali smatram da je to u ovom slucaju nepotrebno. |
Evo sad sam procitao opet ceo clanak, i link koji ga je podstako (http://artur.ejsmont.org/blog/conten...-security-risk)... Verovatno sam ga ja proveravao samo na Debianima, ili na serverima koji koriste AddHandler a new AddType... A mozda su i ispravili to u medj'vremenu, ko ce ga znati... ovaj info je ~godinu dana star ipak, pa se ne secam vise detalja, davno sam izucavao ovo... :)
|
Mislim da je ovo default, $ označava kraj stringa...
PHP kôd:
|
Fora sa nastavkom .gif je sigurnosni propust primjećen još davno u nginx web serveru gdje nije dobro kontrolisana ekstenzija nego sve što dobije proslijedi na "žvakanje" i tako .gif postane remote shell
Štivo za čitanje 1 https://nealpoole.com/blog/2011/04/s...configuration/ Štivo za čitanje 2 http://forum.nginx.org/read.php?2,88845,88996 |
Citat:
|
Iskreno, ja koristim managed vps tako da je tehnička podrška instalirala i podesila suPHP za mene, ali ne bi trebalo da bude preterano komplikovano. Ima i dokumentacija na www.suphp.org gde je opisano kako se instalira i podešava.
Što se WP-a tiče, nema šta da se primenjuje na njega jer je suPHP dodatak za Apache i kada se jednom podesi (dobro napisane) skripte ne bi trebalo da primete da se bilo šta promenilo u serverskom okruženju, odnosno sve bi trebalo da radi out-of-the-box... |
Ja sam na VPS, tamo kazu da to radi... samo ja ne znam sta treba da uradim da bi proradilo :)
|
Pa ako je aktiviran onda radi :) bar bi trebalo. Vidi da li taj folder za upload i index.php fajl wp-a (a i ostali fajlovi) imaju istog ownera... namam pojma, ajde napravi fajl nesto.php i u njega ubaci ovo:
PHP kôd:
|
jos jednostavnije stavi na fajlu da samo ti imas pristup (600) pa vidi jel mozes da ga otvoris preko apache-a
|
Citat:
|
^ izvrsava se kao apache (tj. user nobody)
|
Onda očigledno ne radi, a zašto - nemam pojma, ali tehnička podrška bi trebalo da zna odgovor na to pitanje. Možda nije restartovan Apache :)
|
Danas sam imao pravi Twilight zone...
Otisao u WHM >> Service Configuration >> Configure PHP and SuExec i nasao ovakav setting Option Configured Value Default PHP Version (.php files) 5 PHP 5 Handler dso PHP 4 Handler cgi Apache suEXEC on promenio PHP 5 u suphp i sve se lepo resetovalo i proradilo dobio sam ovo Array ( [name] => hifiles [passwd] => x [uid] => 32012 [gid] => 32014 [gecos] => [dir] => /home/hifiles [shell] => /bin/bash ) nakon toga je WP lepo radio na 755, ali... Tek veceras primetim preko mobilnog da mi se forum raspao... kao da nije ucitao CSS. Na kompu sve lepo radi, kolegi lepo radi, kad krenuli korisnici da se zale da se i njima raspao forum I sve lepo vratim na staro... zna li neko u cemu je fora? Hvala |
Moras prvo dokuciti zasto se CSS nije ucitao (ako je to u pitanju) ili proveri server logove.
|
Hosting provajder mi je podesio sve kako treba... pokrenuli su neku skriptu i koliko vidim svi folderi su 755 a fajlovi 644
Default PHP Version (.php files) 5 PHP 5 Handler suphp PHP 4 Handler suphp Apache suEXEC on Hvala svima |
| Vreme je GMT +2. Trenutno vreme je 03:30. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.