<trojanski || kropf> ej, greš dans na en vodka pong? ker če se ga ne morem prej konkretno vlit, sploh ne vidim pointa v tem, da grem ...
<trojanski || kropf> =/
<trojanski || kropf> also: tt novi MSN je res kurac

n00b samo zmaje z glavo... Jst sem z emesene / amsn kombinacijo že lep čas srečen.

Ne zastopim, zakaj windowsašom nikoli nič ne paše in imajo konstantno neke probleme? Jaz sem si moj ubuntu resda rihtal lep čas, preden je bil tak kot hočem da je, ampak zdaj teče kot urca...

Ne vem kdaj sem se nazadnje kot root prijavil samo zato da bi nekaj spremenil, kar mi ne paše...

WebSec - Del I - Konfiguracija strežnika.

Ogromno, ogromno vdorov ali ranljivosti v kodi se da preprečit že z pravilno konfiguracijo PHP in strežnika kot takega. Vendar je to nekaj na kar večina sistemcev pozablja (ja, s tem mislim tudi vas hosting providerje! Vaš security je ponekod za zjokat!). Seveda, saj so PHP aplikacije že same po sebi dovolj varne, ane? Pa 12 letni koderji, tudi zelo dobro vedo, kako pisat varno kodo? Seveda, of course... Tukaj bom samo naštel par smernic kako primerno konfigurirat, točna konfiguracija bo prišla kasneje, ali pa jo bom prepustil vašim googlarskim™ sposobnostim.

fopen("/etc/passwd", "r")

Mišljenje, ki sem ga zapazil na marsikaterem strežniku (ne toliko na shared hosting, dedicated je bolj problem) je to da je PHP kodi dovoljeno brkljat po dobesedno vsakem fileju ali direktoriju. Pametno, vsekakor... A res? Verjetno je res pametno, da ko pride do vdora, da lahko napadalec kar preko PHP kode zbriše vse access loge. Čeprav je bil čez ta varnostni feature prelitega že mnogo črnila o njegovi resnični varnosti, je vseeno boljše kot nič. Nastavitev v php.ini se imenuje open_basedir. Na kratko povedno, ta feature onemogoča PHPju dostop (via fopen(), file_get_contents() ipd funkcijami) do katerekoli datoteke izven poti nastavljenimi v tistem filetu. Ja, to velja tudi za kakšne symlinke (simbolične linke). Omejite PHP na samo in samo tisti direktorij kjer ima datoteke potrebne za delovanje (običajno www dir, /srv/www/, /var/www/, odvisno). Ne, access logi tudi ne pridejo v upšotev (vbistvu je pametno, da se da apacheju samo write dostop do log datotek, tudi ni pametno da je lastnik le-teh). Tudi /tmp/ se nujno ne potrebuje. Kot bom pokazal na primeru LFI (local file inclusion), je to dober prostor kamor lahko napadalec spravi svojo kodo, ki se ob primernih pogojih (in tudi zelo pogostih, da smo na jasnem) lahko izvede na strežniku.

Can I has bash, gcc and vmsplice?

Ok, recimo, da smo PHP omejili na njegov domači direktorij. Smo varni? E, ne. Spet vzemimo teoretični primer da je napadalec spravil svoj PHP shell na škatlo, in bi resnično, resnično rad dostopal do nekih datotek. Preko PHP-ja ne sme. Ima pa še drugo opcijo. Kodoa zanjo se nahaja v mojem repozitorju. Tako je, lahko kratko malo požene pravi shell. Recimo /bin/bash ? Bash nekak ne pozna open_basedir restrikcije, kajne?

[n00b@lamebox :: ~]> nc -lvvp 1337
listening on [any] 1337 ...
connect to [192.168.2.100] from nekastran.com [0.0.0.0] 53398
rShell v1.0 - Ready
Linux nekastran.com 2.6.18-53.1.4.el5 #1 SMP Fri Nov 30 00:45:55 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
uid=99(nobody) gid=99(nobody) groups=99(nobody)
sh: no job control in this shell
sh-3.2$ PS1="\w:> "     
/home/example/public_html:> cd ../..
/home/:> ls -l
total 1458
[ odrezano ]

You guessed it, kljub open_basedir restrikciji, lahko browsam po drugih uporabnikih istega strežnika. Ups, a sem ti dumpnu bazo? Res, res, nisem mislil. Kaj naredit da se zaščitimo?

Kot prvo, php ima zelo zanesljiv feature, ki se imenuje disabled_functions. Ta direktiva nosi seznam funkcij, ki so PHP kodi onesposobljena za klicanje. Kakšen fsockopen(), exec(), proc_open() se res ne rabi. Med drugim, tukaj tudi vskočijo filesystem dovoljenja. Med drugim je priporočljivo da datoteke do katerih dostopa http server niso pod istim lastnikom kot je http server.

Kako preprečit da bi uporabnik vseeno izvajal kake programe? Chmodajte pomembne binarije (bash, gcc, tudi ostale), tako da so izvedljive samo omejeni skupini uporabnikov. Še boljša rešitev je da chrootamo celoten server, vendar o tem kdaj drugič.

magic_quotes :: ' => \' && 0x00 => \0x00.

Kaj so to magic_quotes? PHP-jev feature, ki koderjem povzroča obilico preglavic, ampak zato ščiti marsikateri app pred ranljivosti (predvsem SQL injection in LFI). Predvsem se gre za to da pošlje nekaj podabnega kot addslashes() skoz ves input ($_GET, $_POST, mislim da tudi $_SERVER, samo me ne držat za besedo). Probati se zanest na ta feature si zasluže svinec v glavo, saj bo kmalu odstranjena (PHP6), kaže pa tudi na zanesljivost koderja. Da se preprosto preverit z get_magic_quotes_gpc() in na podlagi tega preverjat ali je potrebno input inflitrirati ali nam ga je PHP že sam (2 liniji kode, ne jokat). Kasneje bom pokazal da se da pri LFI odstranit končnico preko NULL bajta (0x00), kar seveda ni mogoče dokler je magic_quotes na on. Karkoli, zanašanje na to si zasluži kroglo v glavo.

safe_mode ali safe_mode_gid?

Osebno imam raje safe_mode_gid. Da prej obrazložim, kaj oboje pomeni. safe_mode v osnovi pomeni, da PHP se ne bo tiknu nobene datoteke, katere lastnik ni isti uporabnik pod katerim php laufa. Safe_mode_gid pa pomeni da se bo PHP tikal datotek, ki so od iste skupine, kot je apache, kar je imo rahlo primerneje (če pride do vdora lahko napadalec spreminja datoteke, ki so v lasti apacheja - safe_mode - kar mu odpre pot do podtikanja backdoora - isto ne more velja za safe_mode_gid). Tudi zanašanje na to pri pisanju kode, si zasluži postavitev pred zid.

register_globals = off, kapishi?

Register globals je funkcija (zastarela, večinoma na off, ampak OK) ki bo vsaki variabli ob zagonu PHP skripte dodala ime in vsebino iz $_GET, $_POST, $_COOKIE in podobnih variabel. To omogoča napadalcu prepis nekaterih variabel, ki niso pravilno incializirane (dober je primer je bil velik cirkus glede parih phpBB ekstenzij, ki niso pravilno inicializirale svojih variabel in s tem omogočale RFI). Kakrkoli, kljub temu da je to po defaultu že na off, je pametno preverit, ziher je ziher. Koda se pa tak ne piše več s tem v mislih.

Ostale omejitve

Dobro je tudi PHP omejiti okoli ostalih, stvari, predvsem uporabe spomina, najdlje časa, kar se lahko izvaja ipd. Nastavitve, so očitne, tweakajte jih na podlagi tega kaj laufate gor (vendar pozor, ecommerce npr požre ogromno spomina).

; Koliko časa lahko PHP skripta laufa (sec)
max_execution_time = 30

; Koliko časa lahko PHP zapravi za parsanje inputa
max_input_time = 60     

; Koliko memorije lahko PHP skripta zapravi
memory_limit = 16M       

; Največja velikost uploada datoteke
upload_max_filesize = 2M 

; Največja velikost POST zahtevka (Pozor: Če je tole manjše od upload_max_filesize bo se upload_max_size avtomatsko prilagodil!)
post_max_size = 8M   

; Ne, errorjev ne bomo prikazoval (Uporabi samo na serverju, doma obvezno na on)   
display_errors = Off 
 
; Shrani erroje v fajl (seveda  )
log_errors = On     
 
; Ne, php ne bo niti murksu da obstaja
expose_php = Off 

Pametno je tudi da apacheju preprečimo dostop do kakih .inc ali .sql fajlov od zunaj. Za to se uporablja majhen trik v .htaccess fajlu (ali pa kar v konfigu).

<FilesMatch "\.(inc|.*sql|.*~)$">
  Order allow,deny
  Deny from all
</FilesMatch>

Bottom line

Tukaj sem predstavu par stvari, ki jih je treba upoštevati ob postavitvi serverja. Mogoče bom nekega dne povedal še kaj v malce več podrobnosti, odvisno od časa & moje volje.

Naslednjič bom povedal nekaj malega o RFI/LFI (Remote/Local File Inclusion).

Vse kritike (predvsem kritike) so zelo zaželjene.

Torej ... Če bi hotel z besedami opisat kak je blo... Ne morem, je ni. Najbljižji približek je faking fenomenalno absolutno nepozabno.

Glede nove gripe se ni za bat, ker sem sproti vse razkuževal z žganjem

Smo doli odkrili nov koktelj: džezla. Tak da smo vso žganje kar smo ga meli (od vodke, jegra, šnopsa, likerje in pir za okus) zlili v 16 literski emper - žal se noben več ne spomni v kakem razmerju.

Bojde dobimo tisto kar se ne spomnimo plačano nazaj (zajebancija, ampak ok). Zahtevam polovico stroškov povrnjenih!

Grem spat, potem pa obdelam slike, naredim cenzuro...

"Ker je reku čjesen?" :: Naš moto.

... in zasejem, dobro voljo med grki...

Ja, v grčijo grem spet. Podrobneje: Atene¹ in Zakintos! Maturanc, pač... Ju3 ob desetih ...

Pričakujte malo zatišja, po vrnitvi bo trajal še kak teden rehabilitacije

1: Mater, spet bom lazu ko majmun do akropole, samo zato da bom videl lep 2000 let star kup kamenja...