Sziasztok,
Kellene infó, hogyan lehet biztonságossá tenni php-t olyan gépen, amire 4-5-6 cég szeretne a weblapjával ráköltözni. (A fikázást, hogy a php szar, meg ilyenek, most hagyjuk...)
Meg úgy általában érdekelne, miképpen lehet a php-t vmennyire biztonságossá tenni, mire kell figyelni ilyen esetekben, stb.
- 2671 megtekintés
Hozzászólások
A legjobb, ha a mod_security-t megfelelően beállítod, és az apache-ot nem rootként futtatod. :)
--
Coding for fun. ;)
- A hozzászóláshoz be kell jelentkezni
"hogyan lehet biztonságossá tenni php-t"
hardened-php?
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
A suhosin pofásnak tűnik, de ez amolyan "oltsuk a tüzet" megoldás, mivel ha jól láttam, a rosszul megírt cuccok tökét szorongatja. Bár kétségkívül hasznos.
Inkább az érdekelne, hogy egy sima telepített php-ben milyen trükkök vannak, amivel globálisan meg lehet húzni olyan határokat amiket aztán a júzerek nehezen lépnek át (mint pl. a saját php.ini-k készítése, stb.)
- A hozzászóláshoz be kell jelentkezni
A suhosin core része a php tökeit szorongatja, megéri feltenni.
- A hozzászóláshoz be kell jelentkezni
eloszor is az apacs konfigban virtualhostonkent kulon openbasedir, safe_mode, register_globals
php_admin_value safe_mode 1
php_admin_value register_globals 0
php_admin_value open_basedir /ott/ahol/a/website/van
masodszor
magic_quotes_gpc = On
magic_quotes_runtime = On
http://www.php.net/magic_quotes
harmadszor rakjal imutable flaget az osszes php filera ha nincsen fejlesztes
# chattr +i test_file
ezek altalaban megvedenek a tucat massdeface szintu baromsagoktol
--
"en csak hupot olvasok" al3x
http://litch.eu/blog
- A hozzászóláshoz be kell jelentkezni
thx, ez király. a magic quotes meg főleg.
vmi ilyesmikre gondoltam.
- A hozzászóláshoz be kell jelentkezni
A doksi szerint:
"It's preferred to code with magic quotes off and to instead escape the data at runtime, as needed."
"Because not all data needs escaping, it's often annoying to see escaped data where it shouldn't be. For example, emailing from a form, and seeing a bunch of \' within the email. To fix, this may require excessive use of stripslashes()."
Kivancsi vagyok, hogy pl. a feltoltott kepek rendesen felmennek-e.
De azt alairom, hogy kezdo php kodereknek ez hasznos lehet.
ASK Me No Questions, I'll Tell You No Lies
- A hozzászóláshoz be kell jelentkezni
allow_url_fopen = Off
is elengedhetetlen. Ott a curl vagy a socket kezelő api, ha mégis kellene.
- A hozzászóláshoz be kell jelentkezni
A "biztonsagossag" nagyon keplekeny dolog. Elso korben elarulhatnad milyen alapveto hasznalati mintak merulhetnek fel, illetve milyen kovetelmenyeknek kell megfelelnie ezen cegek szamara. Masodik korben egy igen alapos kockazatelemzes a minimum. Persze csak ha nem szeretned, hogy a gatyat is lepereljek majd mert valahogy az "osztott" kornyezetben bizalmas informaciok szivarogtak a konkurenciahoz...
- A hozzászóláshoz be kell jelentkezni
apache jailben, tiltsd le az osszes folosleges modult, futtasd a php-t cgi-kent (suexec vagy suphp), a sebesseg miatt hasznalhatsz fastcgi-t, a drastik altal irt beallitasokat pedig rakd minden usernek a sajat php.ini-jebe. Minden weboldalnak ertelem szerint sajat usere es csoportja legyen, akinek semmi masra nincs joga a szerveren. Ha van lehetoseged ra, akkor azt a konyvtarat ami a weboldalakat tartalmazza kulon particiora tedd, es mountold oket "noexec,nosuid,nodev"-el. Ha nem okoz gondot, akkor tedd ugyanezt a /tmp konyvtarral is, vagy megjobb, ha a user konyvtaraba teszed a sajat /tmp-jet, a docroot-on kivulre.
(php.ini-be:
open_basedir = /opt/www/ceg1
upload_tmp_dir = /opt/www/ceg1/tmp/
session.save_path = /opt/www/ceg1/sessions/
A documentroot ilyenkor peldaul az /opt/www/ceg1/www)
Ezeket is erdemes berakni a php.ini-be:
disable_functions = system, exec, passthru, proc_open, shell_exec, popen
expose_php = Off
Ha mar be van love az osszes oldal rendesen, akkor johetnek ezek:
display_errors = Off
log_errors = On
Mindent tesztelj miutan a funkciokat letiltottad, lehet, hogy valamelyik programodnak kell valamelyik funkcio, de mondjuk en akkor inkabb a programot neznem at a helyedben.
A szerveren csak olyan csomagok legyenek fent, amik tenyleg szuksegesek (gcc, make, patch sok minden mas mellett peldaul nem az, ha megis kell felteszed, hasznalod, aztan leszeded). Ezen felul a tuzfalban a kimeno kapcsolatokat csak biztonsagos szerverre engedelyezd. Megeri a faradtsagot, a scriptelo kispucak agyatlan probalkozasainak nagy reszet eleve megakadalyozza.
- A hozzászóláshoz be kell jelentkezni
Ezek is mind-mind jó ötletek, köszi!
Különsebb követelmények így előre nincsenek, inkább olyasmikre gondoltam, mint pl. a php default telepítésből származó hülyeségeinek kiszűrése, ismert php megtámadási módok kizárása, stb.
De ez a topic pont ilyesmi irányba halad. B-)
- A hozzászóláshoz be kell jelentkezni
Szia!
En ezt a cikket ajanlanam:
http://www.securityfocus.com/infocus/1786
Es amit a tobbiek ajanlottak ... a virtualhostonkenti config, immutable bit ... stb.
- A hozzászóláshoz be kell jelentkezni
Ezzel csak annyi problema van (imho), hogy az iras szerint "Only static HTML pages will be served". Elhiszem, hogy ez mar truly secure, csak manapsag eppenseggel hasznalhatatlan, mert minden web site dinamikus, adatbazis van mogotte, blog-got akar a nep, meg cms-t. Ezek pedig nem igen erik be Javascript-tel vagy Java appletekkel....
ASK Me No Questions, I'll Tell You No Lies
- A hozzászóláshoz be kell jelentkezni