Onderwerp: Server beveiliging / hardening.

Ik denk dat ik hier nog wel wat leuks aan kan toevoegen.

Veel mensen draaien hun Apache's zoals ze worden geleverd door hun CP, dat is leuk, maar iedereen draait dan onder de zelfde gebruiker, dat is vaak "nobody", "apache" of "www-data".

Alle files die je nu aanmaakt via PHP worden dan van deze gebruiker, nu kan dus ook iedereen via PHP jouw file aanpassen.

Zoiets kan je proberen tegen te gaan met safemode of open_basedir, maar dat is echt allemaal schijnveiligheid, daarmee zit je echt niet veilig.

Een optie is te kiezen voor mod_ruid in combinatie met Apache 2.

Daarmee kan je iedere vhost onder zijn eigen gebruiker laten draaien, het voordeel hiervan is dat je elke directory op 700 kan zetten en elke file op 600. (Pas wel even de umask op je systeem aan zodat nieuwe files ook de juiste rechten krijgen).

Mocht er dan nu een deface plaats vinden via een lekke Joomla ofzo, dan is alleen die ene website getroffen, die gebruiker kan namelijk verder helemaal niets, hij kan geen enkele andere directory van een gebruiker in aangezien die allemaal op 700 staan.

Ook alle files die via PHP worden aangemaakt komen onder de eigen gebruiker.

Om nog veiliger te zitten leg je daar RSBAC nog eens overheen (www.rsbac.org), daarmee kan je vervolgens per gebruiker policy's maken, welke directory hij wel en niet in mag, elke directory hij "ls" mag doen en elke niet.

Zo kan je ook nog eens voorkomen dat die nasty bots iets doen als: find / -name 'index.php'; ze mogen namelijk helemaal niets behalve in hun eigen homedir spelen.

Zoiets opzetten (met RSBAC erbij) kost tijd, veel tijd, maar als je het eenmaal werkend hebt, dan heb je wel een superveilig systeem.

Wij draaien er nu al 2 jaar mee en hebben sindsdien nooit een deface gehad die verder kwam dan een homedir van die gebruiker. Wij gebruiken het ook op onze SSH-servers (alleen RSBAC) en daar hebben we ook nog nooit een security breach gehad.

Over RSBAC en mod_ruid is weinig te vinden, je zal dus veel zelf moeten uitzoeken. mod_ruid is niet zo moeilijk, maar RSBAC is flink doorbijten. Je kan overwegen om professional RSBAC support te nemen, kost je wat per maand, maar dan heb je je problemen wel stukken sneller opgelost.

Uiteraard kan je ook SELinux of GRSEC nemen, dat werkt het zelfde (naja, lijkt er op). Wij werken met RSBAC en dat bevalt ons prima.

Een echte howto is het niet, maar meer iets om over na te denken.

De nieuwere mac-systemen zijn toch selinux en apparmor. Met als basis LSM; zie http://www.mrleejohn.nl/LSM.htm

Oorspronkelijk geplaatst door mrleejohn

De nieuwere mac-systemen zijn toch selinux en apparmor. Met als basis LSM; zie http://www.mrleejohn.nl/LSM.htm

Tot nu toe heeft RSBAC bij mij altijd voldaan, ik zie (nog) geen reden tot overstappen.

Oorspronkelijk geplaatst door mrleejohn

De nieuwere mac-systemen zijn toch selinux en apparmor. Met als basis LSM; zie http://www.mrleejohn.nl/LSM.htm

Bij RSBAC geven ze een aantal redenen waarom ze niet gebruik maken van LSM:
http://www.rsbac.org/documentation/w...es_not_use_lsm

Oorspronkelijk geplaatst door Digiover

Coolvibe... Toch niet... ?

Ja die ja

Dit veranderen in de php.ini geef ook wat zekerheid:

allow_url_fopen = Off
register_globals = Off
enable_dl = Off
expose_php = Off
safe_mode = On

De eerste 4 inderdaad, maar safe_mode is echt pure schijnveiligheid waar je alleen jezelf maar mee hebt.

Waarom denk je dat het er anders in PHP6 uit gaat?

Rsbac, grsecurity e.d. voldoen ook nog wel. Maar ik verwacht toch dat de toekomst voor selinux en apparmor zijn. Het e.e.a. van de oude hardening-mac-instellingen zitten standaard al in de enterprise-kernels.

mod_ruid gebruik ik al jaren, maar dat is toch geen jail of chroot zoals je in een andere thread suggereerde? jailkit gebruik ik op onze ssh server. ik ben over zowel mod_ruid als jailkit tevreden.

Oorspronkelijk geplaatst door t.bloo

mod_ruid gebruik ik al jaren, maar dat is toch geen jail of chroot zoals je in een andere thread suggereerde? jailkit gebruik ik op onze ssh server. ik ben over zowel mod_ruid als jailkit tevreden.

Nee, een echte jail of chroot kan je het noemen, maar met iets als RSBAC kom je aardig in de buurt.

Elke klant in een eigen chroot draaien gaat niet zo handig, maar een combinatie van mod_ruid en een extra security layer brengt je aardig op weg.

Er is nu ook een mpm in apache 2 welke hetzelfde doet als mod_ruid, itk.

Oorspronkelijk geplaatst door X-Hosted

- disable_functions in php.ini: exec,system,pcntl_exec,parse_ini_file,show_source, curl_exe,shell_exec,passthru,escapeshellarg,escape shellcmd,proc_close,proc_get_status,proc_nice,proc _open,proc_terminate,apache_note,apache_setenv,clo selog,debugger_off,debugger_on,define_syslog_varia bles,openlog,syslog

Werken alle scripts nog wel als je dat allemaal uitschakeld?

Oorspronkelijk geplaatst door _arno_

/etc/hosts.allow checkt hij toch pas op het moment dat je inlogd, dus je username pass invult?
Want in dat geval heb je nog wel vrijheid om dingen te kunnen vervelen.

Tenminste ik heb de illusie dat dit zo is

Fout, u gaat niet door voor de koelkast

/etc/hosts.(allow|deny) zijn onderdeel van Wietse Venema's tcpwrapper / access control facility tcpd en voeren op het moment van verbinding een rule uit (deny of allow). Hier zou je overigens ook D. J. Bernstein's tcpserver (ucspi-tcp package) voor kunnen gebruiken.
De betreffende daemon moet wel tcpwrapper ondersteuning hebben.

Iets wat ik jaren geleden al eens heb geschreven (en gejat van een LPI cursus) over Linux beveiliging:
http://www.dsinet.org/hackfaq/html/l...veiliging.html

Oorspronkelijk geplaatst door guidob

Werken alle scripts nog wel als je dat allemaal uitschakeld?

Nee, niet alle scripts werken dan nog. Dat is namelijk ook de bedoeling

Goed geschreven scripts zullen blijven werken. Malafide scripts niet, maar dat is juist de bedoeling.

Oorspronkelijk geplaatst door Glenn

Nee, niet alle scripts werken dan nog. Dat is namelijk ook de bedoeling

Goed geschreven scripts zullen blijven werken. Malafide scripts niet, maar dat is juist de bedoeling.

ik moet zeggen, ik gebruik exec(), system(), parse_ini_file() best wel vaak, dus mijn script is malafide?

Daarnaast is de DL functie nog veel linker, zie: http://nl2.php.net/dl