phpsecinfo: ha biztonságosabb php.ini-t szeretnél...

Internet: PHP, CGI, stb.

Sziasztok!

Véletlenül botlottam bele ebbe: http://phpsecinfo.com/
Kipróbáltam, és elsőre elég borzalmas képet festett a házi webszerverem :-)
Végül sikerült "1 sárgára" kihoznom a dolgot, de azt is csak azért, mert az általa javasolt 8MB RAM-mal nem ment a drupalom...

Szerintetek mennyire érdemes komolyan venni a javaslatait, hiszen egy 2007-es cuccról van szó?

Ja ha valaki elsőre nem értené miről beszélek, ez egy php.ini csekkoló "weblap", ami sárga, zöld és piros színekkel jelzi a 16 teszt eredményeit, és ad javaslatokat a javításra. Ha jól vettem ki a honlap szavait, akkor a php biztonságossá tételéhez ad segítséget.

Direkt link a teszt szoftverhez: http://phpsec.org/projects/phpsecinfo/phpsecinfo.zip

Nektek mi a véleményetek róla?

  • 3556 megtekintés

( plastik | 2009. 10. 15., cs – 18:16 )

meg nem probaltam, de feluletes (15 masodperc) nezelodes utan ami latszik, hogy az altalanosan ismert hibaforrasokra vilagit ra, a jozan paraszti logikat alapul veve. termeszetesen gyakori eset, hogy a biztonsag oltaran kell aldoznunk egy-egy kenyelmi funkcioert. ilyen modon tenyleg csak egy iranyadas -- alapesetekre.
sokszor nem tehetsz semmit, ha csunyan pirosba lendul a mutato, az csak arra figyelmeztet, hogy a beepitett vedelmi funkciokat nem hasznalod ki. termeszetesen ez nem a rendszer tokeletlenseget jelenti -- ha nem felejtettel el a kikapcsolt vedelmi funkciok helyett sajat ellenorzesrol gondoskodni!:)

( kiuka | 2009. 10. 15., cs – 18:36 )

talan mert az otthoni webszervereken eleg ritkan szoktak korlatozni ha csak sajat hasznalatra van? olyan helyen probald ki ami valami hosting pl es random emberek futtathatnak php-t

( janoszen v | 2009. 10. 15., cs – 20:28 )

Na, akkor tételesen mondom a véleményemet:

  • CGI force_redirect: ha CGI, akkor legyen bekapcsolva.
  • allow_url_fopen: valóban ki kellene kapcsolni, de mivel rengeteg szoftver használja és a curl pedig beteg jószág, ezért félig igen, félig nem.
  • allow_url_include: Ez ha be van kapcsolva, akkor ássa el magát a rendszergazda.
  • display_errors: legyen kikapcsolva, erről nincs mit mondani.
  • expose_php: Legyen kikapcsolva.
  • file_uploads: Nagy többségben szükség van rá.
  • group_id: Ez 0-t ad vissza, ha nincs rendelkezésre álló tesztelő függvény, ami önmagában elég gáz. Egyébként oda kell figyelni és kész.
  • magic_quotes_gpc: Jó volna kikapcsolni, ha a sok fostos szoftvernek nem kellene.
  • memory_limit: Szép-szép a 8 mega, de én azt gondolom, hogy 64-et nyugodtan oda lehet adni, főleg hogy manapság már a normális szerverekben akár 16+ GB is van.
  • open_basedir: Kisegítő megoldás, önmagában nem elég, de legyen bekapcsolva.
  • post_max_size: DOS támadások ellen disk quotát.
  • register_globals: legyen kikapcsolva. Pont.
  • upload_max_filesize: A userek akarnak nagy fájlokat feltölteni. Ezek már csak ilyenek.
  • upload_tmp_dir: Ne tudja bárki elolvasni. Más kérdés, hogy Unix-jogosultságok szintjén mennyire van szétválasztva a gépen a PHP. Detection algoritmus szar, FastCGIvel nem jót ad vissza.
  • user_id: Ld group_id.
  • Curl: legyen ződ.
  • save_path: Detection algoritmus szar, FastCGIn nem jót ad vissza. Egyébként igaza van.
  • use_trans_sid: Kapcsojja ki.

elhiszem, hogy erősen ajánlott a "sok zöldre" törekedni, de akkor ezt miért nem a php.ini-be állítják be a disztribútorok, vagy a php készítői?

én default, gyári (debian) beállításokkal használtam eddig a phpmat, és elég siralmas volt, 2 zöld, 2 piros, többi sárga lett, most figyelembe véve az ajánlásait, 2 sárga 14 zöldbe egyeztem ki magammal :-)

--
by Mikul@s

Én azt gondolom - mint ahogy a Debianosok is - hogy a PHP security szempontból egy rémálom (bele is van írva 1-1 security beállításhoz, hogy jó-jó, de ha ezért feltörnek, Te vagy a hibás). Ha nem egy projektet akarsz vele elhajtani, hanem valami osztott hostot, akkor vagy MPM-ITK, vagy FastCGI a megoldás. Mivel a FastCGI a stabilabb megoldás, ezért azt választottam nagyon sok helyen, de még így is kellett patchelni az apacsot néhány helyen.

Ez most miert is magyarazza azt, hogy miert nem adnak biztonsagosabb defaultokat a disztributciok? Mert ha mar ugyis egy tragyadomb, akkor mar annyira mindegy? Torjek fel csak az oldalat annak a marhanak, aki a defaultokat hasznalja mert nem ert hozza? Mert a defaultok nem shared hostingra is eleg pocsekak.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Hál' Istennek a Linux nem a kézenfogós oprendszer. Az nem volna jó taktika, ha safe by default érzés meglenne, mert akkor még a nagykorú Tákoló István is kikiáltaná magát Linux rendszergazdának (mint a Windowsnál) oszt a végén úgyis feltörnék a gépét. A Linuxhoz érteni kell és kész.

nem szoktam ilyet mondani, de ez marhasag.

marpedig legyen alapbol biztonsagos. es nem aztalal tanulja meg az ember a dolgokat, hogy biztonsagosabba teszi, hanem IGENYEI SZERINT alakitja.

a windows-zal szemben ne az legyen az egyetlen erv, hogy ha ertesz hozza, barmit meg lehet vele csinalni. ha nem ertesz hozza _annyira_, akkor se jarj porul!

A gyakorlat azt mutatja, hogy mégis pórul járnak a Windows szerver üzemeltetéssel kísérletező tanulatlan népek. Az alapból biztonságos az lenne, ha nem lenne hajlandó elindulni default configgal a PHP, hanem - mint néhány szoftvernél - kiírná, hogy confolj be, mielőtt hajlandó vagyok beindulni. A biztonság ugyanis relatív, mert ha pl PHPból engedélyezve van pl az fsockopen, az lehet biztonsági rés is és feature is. Most akkor mi legyen a default? Hogy minden elérést tiltunk? Akkor használhatatlanságig butulna a PHP és akkor meg azért menne a sírás.

Vajon, amit a phpsecinfo ajanl biztonsagi dolgok, mennyire uberalles vedelmek? Szerintem, meg ha minden zold, akkor is van egy csomo egyeb dolog, amiken keresztul meg lehet nyomni egy szervert, ha az ember nagyon akarja. Viszont ezek olyan alap vedelmek, hogy legalabb _valamennyire_ vedett legyen.

Nem szabad vegletekben gondolkodni. Persze, nyilvan nem lehet mindent uber vedettre megcsinalni alapertelmezetten, mert az mar a hasznalhatosag rovasara menne. Ugyanakkor, vajon ugy adjuk el a hazat, hogy ajto-ablak tarva-nyitva, mert a kedves vevo majd becsukja maganak, ha ugy akarja? Vagy legalabb ezeket csukjuk be, mert ez valahogy... jobban kinezove teszi a hazat? Persze, ettol meg az ablak uvegje betorheto, az ajto berughato - de megis, legalabb a madarak nem tudnak berepulni, meg a budosborzok bemaszni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

a nagykorú Tákoló István is kikiáltaná magát Linux rendszergazdának (mint a Windowsnál) oszt a végén úgyis feltörnék a gépét. A Linuxhoz érteni kell és kész

Jesszum Pepi!

Ez a szöveg a szintén címlapon lévő, Linux-security kategóriában lévő "megtörtek" fórumbejegyzéssel együtt különösen pikáns... Hiába no, Tákoló Istvánok csak Windowsos területen vannak, a Linux rendszergazdák pedig egytől-egyig hihetetlen nagy security expertek.

fopen: nem ertettem soha a hisztit korulotte: ha vigyazunk, mit nyitunk meg, hasznalhatjuk. Ha meg nem vigyazunk, curl-lel is elcseszhetjuk az eletunket. En pl. nem szeretek socketeket nyitogatni feleslegesen, es igen, kenyelmes megoldasnak tartom a $obj=json_decode(file_get_contents($simplewebserviceurl)) -t, meg a $feed = simplexml_load($feedurl) -t :)

Teny, elotte ellenorizzuk le, mit kapunk, pl. csak ugy nem csatlakozgatunk mindenfele webservice-okhoz, annak biza konstansbol kell jonnie, a feedek az mar rizikosabb, mondjuk az en appjaim mindig egy adott szolgaltatas feedjeit hasznaljak, igy az is konstans.

group_id: Ez 0-t ad vissza, ha nincs rendelkezésre álló tesztelő függvény, ami önmagában elég gáz. Egyébként oda kell figyelni és kész

ezt nem értem, pl debiannál 33-as ID-ja van, az ajánlása szerint pedig 100 feletti kell legyen, nem mindegy neki, hogy 33, vagy 100, ha csak ezért van fenntartva ez a UID/GID?

--
by Mikul@s

( hrgy84 | 2009. 10. 15., cs – 21:57 )

Megnezegettem, amit irt. Az open_basedir-t nem merem bekapcsolni globalisan, viszont ezek alapjan megprobalok kiotolni valamit (per-vhost szintu beallitas johet csak szoba persze). Igazabol sok bajt nem okozhat, mert MPM_ITK-t hasznalok, ami bizonyos szintig szeparal. A tobbit atnezegettem, a memory limit az nalunk per-vhost beallitas, az upload_tmp_dir -rel az ITK miatt sokat nem tudok kezdeni (az other-nek levettem a jogit), a group_id megint egy erdekes, nem tervezem novelni, de nincs extra privilegiuma (nem 0). A tobbihez nincs mit hozzatenni.

Nekem mellesleg a curl semmilyen nem volt. Kivancsisagbol feldobtam, zold.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Hat.. megy. Eleve nem tul latogatott oldalakrol beszelunk, a 10-es MaxClientsPerVhost default mindegyiknel, es eddig 1 felhasznalonal kellett boviteni. Giga ram, giga swap, es kb 60-70 oldal megy vele. Ez a MaxClientsPerVhost az egyetlen, amire oda kell figyelni, ha tul alacsony, akkor nagyon eldobalos tud lenni. De az elso ket nap utan ki szokott bukni, ha alacsony. Egyebkent a PHP-t kell inkabb jol beallitani, agyonlimitalni. Nalunk foleg memory limit meg Suhosin korlatok vannak.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( janoszen v | 2009. 10. 18., v – 13:54 )

Apropó, ha már biztonság: mindenki gyorsan nézzen bele a PHP configjába, hogy ez a függvény működik-e. Ezt rendszeresen beleforgatják mindenféle disztribúciók a PHP-kba, csak tudnám, minek. Sechole mint az állat. (Nekem is AX hívta föl a figyelmem rá, hogy Debianban benne van.)

( Vendor v | 2009. 10. 18., v – 15:37 )

En tobbnyire kezdesnek ezekel a beallitasokkal indulok. Aztan jonnek a finomitasok, melyek itt fontebb is lettek irva.

disable_functions = system, kill, virtual, chmod, ftp_connect, connect, popen, sleep, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix_getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, openlog, shm_attach, sem_get, msg_get_queue, proc_open, proc_terminate

expose_php = Off
display_errors = Off
allow_url_fopen = Off

A sleep() -et miért? chmod érdekes tiltási szempontból megintcsak, vagy mindent db -ben tarolsz le?
Az ftp_connect szintén szükséges lehet, vagy "curlozgasson" a delikvens helyette? Az mennyivel 'securebb'?

"-Pedig vegetariánus vagyok; csak növényevő állatokat fogyasztok!"
azenoldalamponthu

A sleep() -re +1, illetve e helyt erdeklodnem meg az openlog() sebezheto pontjait. Tudtommal az syslog interface. Es ha mar, akkor a syslog() miert nem? A posix_times() kulon izgalmas erdekesseg - miert?
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.