Kako otkriti kako je neko provalio u sajt

[ivanhoe]

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...

[cvele]

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 ... 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

[andrejpav]

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.

[bofh]

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/

[nixa]

^ a zar ne vidis da je server u njegovom vlasnistvu i to "sta-bi-bilo-trt-mrt" njemu treba i nikome drugom

[cvele]

da je u njegovom vlasnistvu ne bi imao ogranicenje zvano "neki tamo cp"
bar meni tako deluje

[Aleksandar.Ilic]

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.

[LiquidBrain]

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...

[cvele]

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

[cvele]

eve izvukoh iz naftalina nesh:

Originalno napisao bofh

Ok, this was and still is hell to setup in real circumstances.
Main goal is to restrict users to their home directory, making them as less as possible dangerous for system security.

The idea is coming from standard chroot(8) command:

/usr/sbin/chroot /d1/chroot /bin/bash

Now we have a start. However we cannot use /d1/chroot directory for all users, we want to chroot them in their own directory. So we need to substitute /d1/chroot with user's home dir, for example if we want to chroot user "mohican" we're getting to this:

/usr/sbin/chroot /home/users/mohican /bin/bash

Ok, this is for only one user. To automaticaly chroot user "mohican" to his own home dir we put that in a shell script to look something like this:

slash:~# cat /usr/local/bin/chrootsh
#!/bin/sh
exec usr/sbin/chroot /home/users/mohican /bin/bash

Now we can register that /usr/local/bin/chrootsh in global shells file /etc/shells.
So, mohican dude is chrooted, but hey, why not chroot and the others?