|
Kako otkriti kako je neko provalio u sajt
Pozdrav
imam jedan problem. A to je da mi neko stalno hakuje jedan SMF forum (1.1.4) na serveru. I to brise malo po malo, svaki dan, i onda mi je bekap beskoristan jer kasno otkrijemo brisanje. E sad, ovi na smf sajtu, kazu da 1.1.4 nema nijedan poznati exploit, a forum je cak hakovan 2 dana nakon sto sam instalirao 1.1.4 :( Dislocirao sam skoro sav php kod van web stabla, stavio readonly dozvole na fajlove, cak sam sifru za mysql ubacio negde bezveze u kod, i u settings.php stavio laznu sifru... menjam sifru za mysql cesto, i moderatore teram da menjaju svoje.. I apsolutno nista ne pomaze. Pretpostavljam da je neki drugi sajt provaljen. Ali imam oko 300 sajtova, svaki ima svoj apache log, jako mi je tesko da analiziram logove. Pretpostavljam da nije nista na nivou servera, da je on kompromitovan, jer cisto sumljam da ovi sada to ne bi iskoristili (ostavali su poruku da su siptari i sl) i pobrisali sve zivo na serveru ili nesto slicno :( Jel ima neko ideju sta mogu da uradim da saznam kuda provaljuje:please:. Ja cu lako da zapusim rupu, samo ne znam gde je... |
Citat:
|
ako su samo postovi u pitanju - pogledaj mySQL ili ako ga nemas ukljuci ga pa prati kad je ko obrisao, prati vrijeme pa onda idi gledaj apache logove u to vrijeme i gledaj sta se tamo desava.
|
pa ako nije uhakovana masina, onda mora da postoji u apache logu podatak o tim akcijama.. ili to ili ti hakuje bazu direktno, sto je mnogo manje verovatno (naravno, pretpostavljam da si vec promenio sve sifre na serveru?)
mozes da koristis auto-prepend u php.ini-ju da ubacis na pocetak svake skripte neko logovanje po zelji u neki svoj "tajni" log fajl, ako sumnjas da access.log ne sadrzi sve podatke... |
Citat:
|
mozda zvuci kao bezveze pitanje - ali da li ti je klijent mashina cista?
Ovo zvuci kao da te neko targetira namerno, a do sifara moze da dodje ako imas trojanca ili neki key logger na racunaru. Mislim zaista treba posvetiti vremena, imati strpljenja i biti resen da nekome brises bazu, menjas postove itd. |
pratio sam sve logove od tog domena.
Imam i mysql logove, ali on daje logove za sve baze, imam vise SMF foruma. Nemam iskustva toliko u ovome, i maltene mi je ne moguce da analiziram toliki log. Pada mi na pamet da dignem jos jedan mysq server samo za taj smf... @ivanhoe: to imam vec uradjeno za ovaj domen, mada nisam primetio nista slicno. Trenutno mi ne pada na pamet, koje podatke da logujem da navatam odakle dolazi. I imam jak utisak da hakuje direktno bazu, a i ovi sa SMF sajat, ko papagaji ponavljaju da ne znaju ni za jedan exploit za smf-1.1.4 |
Citat:
Al sada vise nije on u pitanju. Znamo... on je bio sadista, i svaki put je na druaciji nacin ulazio. I trebalo je dosta vremena se skonta, da ima gmail naloge. |
To za gmail je jednostavno, dovoljno da se koristi nesiguran bezicni, ucini ce hijack sesije tako sto uhvati cookie.
|
ne verujem da je 3-4 coveka na taj nacin navatao. A za jednog znam da ne koristi WiFI...
|
Citat:
|
Aleksandre, rekao si da nije brisao fajlove sto vrlo verovatno znaci da nema pristup file sistemu, orjentisi se na mysql bazu i to za tog usera. Ja bih pre svega, za svaki slucaj, isparsovao apache log za nekim cudnim upitima tragajuci za backdorom, kljucne reci npr: root, include, r57, c99, ...
@ivanhoe, gmail ne ide uvek preko SSL-a imas vise ovde. |
meni vala ide :)
proverio sam sad iz drugog browsera i stvarno prebacuje na http://, ali ja u firefoxu koristim https:// link i sve radi normalno, tako da eto, koristite https sta da vam kazem... |
Nema veze sto koristi ssl jer tada nece moci da se direktno uhvate podaci konekcije,
ali ako se sniff-uje saobracaj moze cookie da pokupi, i posle moze napadac da udje u gmail, hotmail, yahoo, proverio sam ih na sopstvenoj kucnoj mrezi. Pa posle sve zavisi na sta nailazi, mozda postoji neki mail registracije negde, ista sifra itd. Valja paziti :) hint: creepy |
Citat:
|
obican grep ti radi posao, samo potrazi ove keyworde sto ti je spomenuo Ivan, takodje trazi cudne url_enkodovane stringove, znaci kobasice sa puno %xxxx
U php skriptama loguj $_REQUEST varijable, pa onda taj log fajl grep-uj da vidis da li ti se negde pojavljuje neka SQL komanda ili neki sumnjivi paramtri, za slucaj da ima neki SQL injection propust.. i ako mozes, upgrejduj apache i mysql na serveru na poslednje verzije... |
naravno i dalje ne znam sta se desavalo sa ovim sajtom, ali sam u medjuvremenu otkrio druge probleme. PhpMyAdmin (ceo dir sa fajlovima) je imao za vlasnika httpd usera (tako da mi je neko tamo stavio C99 root shell ).
I iskljucio sam url_fopen. I samo cu da iskljucim jos sve system exec funkcije. Ako korisnici ne mogu da paze na svoje skripte, ja nemam izbora :( |
Nisam ga updejtovao odavno ali moze da pomogne u nekim situacijama: PHP Security Info ;)
|
Obavezno odradi i http://rootkit.nl/projects/rootkit_hunter.html
Svojevremeno sam ga cesto koristio ... evo ti moj script sa starom verzijom rkhunter-a: Kôd:
cd /usr/local/src/ |
Citat:
Koje još open source aplikacije imaš na serveru ? Starije verzije Horde Webmail imaju žešći bug. |
mogao bi za pocetak da chrootujes korisnike...
|
malo je nezgodno zbog kontrol panela koji koristim. Mada su u novoj verziji ubacili to kao opciju, al je verzija jos beta...
|
Malo je nezgodno jer svi mi ovde više manje pogađamo šta bi moglo da bude a - da se razumemo - može da bude sve i svašta.
Ja sam godinu dana bio administrator za jedan američki datacentar i na svakih 10-15 dana sam radio to što ti radiš sada. I skoro svaki put je bilo drugačije. Prvo pusti rkhunter da odradi svoje pa čitaj šta će da ti kaže. Ako je haker bio pravi i ubacio svoje fajlove, može lako da se desi da ćeš morati da uzmeš drugi server. Ja sam to imao u 10-15% slučajeva. Onda pregledaj log file-ove za sve korisnike. Ne mislim ručno, ali možeš da grepuješ sve log file-ove samo jednom komandom ... sve zavisi od putanje do korisničkih naloga. Pregledaj i sve log file-ove koje ti generiše HSphere. Traži gde se pojavljuje znak % ili tgz, pa ako imaš sreće isplivaće na videlo. Proveri sve user-e na serveru koji imaju ssh ili ftp pristup. Pogledaj .bash_history file-ove da vidiš šta je ko radio na serveru. Pogledaj ko se sve i odakle logovao. Redovno proveravaj server load, aktivne procese i konekcije na serveru. ... Narodski rečeno, ima da rodiš mečku ako ti je to prvi put da juriš hakera sa komandne linije. Moj server je isto pod HSphere kontrolnim panelom tako da znam šta pričam. Uostalom, jesi li pokušao da kontaktiraš admina u datacentru ? Ako ti je HSphere-a legalna, možeš da kontaktiraš i njih (nekad PSoft pa Comodo pa Parallel) i zatražiš pomoć. |
Citat:
Neko reko Verat i Dizajn Zona ? |
^ spank !
|
Citat:
|
mislim da cvele prica o tome da apache mora da ima pristup tim fajlovima, a to znaci da svaki korisnik moze svojim skriptama (koje izvrsava apache) da menja tudje fajlove..
|
mora da ima read pristup, ne i write...
A kod mene je najverovatnije i jeste slucaj da negde postoje write privilegije. Ja sam vec navatao jedan propust kroz logove, ali ima jos negde :( jer su mi skoro hakovali jedan SMF. Inace imam rkhunter i logwatch koji rade, mada je skoro svaki put neki drugi haker u pitanju, tako da sumljam da mi je provaljen sam OS. Niko sem root-a i jos jednog sistemskog naloga nema shell. A izgleda cu morati da pravim skriptu za parsiranje logova :( , jer su za svaki domen na razlicitim lokacijama. |
Citat:
Kôd:
/hsphere/local/home/{user}/logs/{domain}/Kôd:
grep "neki_text" /hsphere/local/home/*/logs/*/* |
Citat:
Saki korisnik je 'owner' svojih file-ove i samo ih on moze menjati. Apache ili bilo koja scripta koja radi na web serveru ne moze menjati ove file-ove jer web server radi kao user httpd. Problem nastaje sa korisnicima koji odredjenim folderima setuju permissions 777 i time dozvole upis/editovanje file-ova scriptama sa web servera. |
Ajd posto ste krenuli da mi drzite vakelu, da se "preciznijem izrazim":
Problem 1: Bilo koji web sajt koji ima cache ili menja neke fajlove (tokom instalacije, snima config fajlove, menja .htaccess), mora da da apachu +w privilegiju na tom diru/fajlu (obicno se user apache doda u user group). To automatski znaci da svaki korisnik moze da pise tamo. Ovo izmedju ostalog pogadja vecinu Wordpress konfiguracija sa default setinzima i ukljucenim cachom (sto mislim da vise nije po defaultu, ali bilo je dugo vremena).. Problem 2: U setupu koji ne ukljucuje chroot, apache mora da ima read pristup svim fajlovima koji se koriste iz php-a, sto znaci da svaki korisnik na sistemu moze da procita koj vam je sifra za DB, samo ako zna gde da pogleda Na sistemima sa vise korisnika chroot je obavezna stvar, to je bila poenta... |
posto me vecina nije razumela, vako :)
PHP se moze postaviti na dva osnovna nacina, kao modul i kao cgi (posle dolaze razne varijacije na temu...fast cgi isl). Kada je php instaliran kao modul Apache je vlasnik falova i on ih izvrsava. Kada je php instaliran kao cgi, khm sad dodje deo u kome cu morati da se potrudim da nekoga ne uvredim :D... Korisnik koji je vlasnik fajla izvrsava php skript, apache nema nista sa time (nikakav read ili write, vec samo fizicki sistemski korisnik). CGI ima jos jednu zackolicu :) a to je da php fajlovi, da bi se mogli izvrsiti, moraju imati permisije (max) 644, a folderi 755, u suprotnom dobices jedan lep http ISE 500. Sad, tvoja situacija je verovatno vaka: PHP instaliran kao modul, korisnici su vlasnici svojih fajlova ali fajlovi imaju perimisije setovane tako da svi mogu da ih citaju i izvrsavaju. Samim tim ti dozvoljavas svima da citaju tudje falove prostim include. Ako vec kazes da *nemozes* da chrootujes korisnike (sto se rucno da iz shell-a uraditi za koji min, cak je bc ostavljao neki bash skript za to na starom default sajtu), onda setuj php da radi u safe mode i lisices sebe nepotrebnih glavobolja. tol'ko |
Mozes da namestis mod_security Apache modulu, pa da pregledas te logove.
Drugo vidi u koje vreme su brisani podatci iz baze. To bi trebao da mozes da vidis u query log-u. Onda pogledaj apache access logs i vidi koji su IP-evi bili aktivni u to vreme pa mozda mozes barem te IP-eve da blokiras privremeno. Na kraju ako imas te IP-eve, mozes da pogledas na kojim su sve stranicama bili i mozda ces moci da provalis kojim putem upadnu u tvoj server. |
slepo nagađanje i bockanje šta-bi-bilo-kada-bih-mogao-trt-mrt je totalno pointless.
nazovi tehničku podršku provajdera gde hostuješ sajt i traži im da urade istragu povodom upada na isti. ne vidim zašto bi se smarao (grepovao-jebao-skenirao) kada to može da uradi neko drugi za tebe (a još je i plaćen za to) što se tiče sigurnosti php-a i ostalih sranja vezano za njegov security (server side)....... pa gospodo php je jedan od najpopularnijih i najjednostavnijih (!!!lol!) skripting jezika out there. popularnost ide sa podilaženjem korisnicima istog. a to je obrnuto proporcionalno tamo nekakvoj sigurnosti i dizajnerskom konceptu. http://www.bitstorm.org/edwin/en/php/ |
^ a zar ne vidis da je server u njegovom vlasnistvu i to "sta-bi-bilo-trt-mrt" njemu treba i nikome drugom
|
da je u njegovom vlasnistvu ne bi imao ogranicenje zvano "neki tamo cp" :)
bar meni tako deluje |
server jeste moj, ceo :). A CP mi pravi problem jer i nisam bas neki extra strucnjak za administraciju, i nisam bas rad da kastomizujem sam CP, jer je posle nezgodno kad radim update.
Javio se jedan od clanova foruma da mi licno pomogne, pa se nadam da cemo nesto navatati. Cvele, jel imas lepo uputstvo za chroot apache-a? PHP ne zelim da prebacujem u safe mod, taj server meni sluzi za moje projekte, i uzasno me nervira safe mod. |
Shto se tiche apache chroot-a ovde imash uputstvo: http://www.linux.com/feature/36331
ali to nece da pomogne u ovoj situaciji jer tebi nije sam httpd daemon kompromisovan vec neka od aplikacija... |
zasto mislis da mu je neka aplikacija kompromitovana? mozda jednostavno covek ima interes da ceprka po toj aplikaciji... a da je dosao do pristupa preko mysql lozinke... ima hiljadu scenarija.
btw chroot ce spreciti razne korisnike servera da izlaze iz svog prostora i onemoguciti ih da ceprkaju po drugim fajlovima |
eve izvukoh iz naftalina nesh:
Citat:
|
| Vreme je GMT +2. Trenutno vreme je 04:46. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.