Bekijk Volledige Versie : Disable functions niet meer nodig in shared hosting??
Ik kwam een uitspraak tegen die mij nogal zeer verbaasde.
In disable_functions van php.ini heb ik o.a. exec, proc_open, escapeshellarg en popen staan zodat die uitgeschakeld zijn.
Nu beweerde iemand dat dit niet meer nodig zou zijn voor "beveiligingsredenen". Dus klaarblijkelijk gelooft hij daar niet in.
Voor proc_open kan dat kloppen als je met php-fpm werkt of mod_ruid2 hebt draaien.
Maar hoe zit dat voor de rest? Ik lees nog altijd overal dat dit toch tot de basis beveiliging van shared hosting hoort en dit wordt bijv. ook nog altijd standaard (samen met nog wat anderen) in de disable_functions gezet als je in Directadmin de secure_php optie aan zet.
Dat is dan toch niet voor niks lijkt me.
Of is er in de afgelopen jaren zoveel verandert dat het opeens niet meer zoveel uit maakt? Terwijl kwaadwillende nog altijd in staat zijn om via lekke scripts of thema's php bestanden naar een account te uploaden?
stefantriep
08/10/20, 15:40
Ligt er ook nog aan of je Suhosin draait volgens mij
Nee geen suhosin, ofwel mod_php met mod_ruid2 ofwel php-fpm.
Maar lijkt me wel interessant om te weten gezien toch overal nog op internet ziet dat het wel verstandig is om die beveiliging aan te zetten in een shared omgeving.
Het ligt geheel aan je omgeving. En dan gaat het verder dan mod_php met mod_ruid2 of php-fpm. Bepaalde functies blokkeren lijkt mij nog steeds te verantwoorden als onderdeel van je beveiliging. Al is het maar om het een stapje moeilijker te maken om misbruik van bepaalde zaken te maken. En het ligt mogelijk ook nog aan wat voor sites je klanten veel al hosten.
Ik weet niet precies wat je bedoeld met de omgeving, maar het gaat om servers met Directadmin voor shared hosting, echter zonder cloudlinux.
Schijnt dat exec nodig is voor XFMG en ffmpeg integratie in Xenforo.
Zelf leek het mij ook dat meer stapjes moeilijker toch wat beter was om misbruik tegen te gaan. Maar als ik straks meer klanten krijg met Xenforo die wel bijv. de Gallerie willen gebruiken, dan zou exec open gezet moeten worden voor Gallery.
Vreemd eigenlijk want als je kijkt naar bijv. IPB die ook een Gallery ingebouwd heeft.
Met custom php.ini's per gebruiker kom je er helaas ook niet, ten minste niet met mod_php (wordt specifiek benoemd op https://help.directadmin.com/item.php?id=672)
Qua security scope, zou bij toegang tot het DA account de functie exec niet meer rechten betekenen, gezien je ook via cronjobs onder de user kunt uitvoeren.
Het standpunt van het stapje moeilijker maken blijft wel staan natuurlijk, zeker bij geautomatiseerde scripts die enkel via de webserver dingen uitvoeren.
Voor shared hosting zou ik eigenlijk altijd CloudLinux aanbevelen. Wat betreft een incident waarbij een script buiten de webserver treed, maar binnen de user-scope (bijv. via cron of exec) zit, wordt het systeem zelf in veel minder gevallen getroffen.
De beperkte ervaring die ik met CloudLinux heb is heel slecht. Van willekeurige kernel panics overdag tot het niet meer kunnen updaten van de server zonder een kernel panic. Uiteindelijk zijn alleen de willekeurige kernel panics over, maar de servers die er nog zijn, gaan zo snel mogelijk gemigreerd worden naar een systeem zonder CloudLinux.
Qua security scope, zou bij toegang tot het DA account de functie exec niet meer rechten betekenen, gezien je ook via cronjobs onder de user kunt uitvoeren.
Aha, dat is dan wel interessant, dus dan maakt het feitelijk niet uit of het uit of aan staat. Custom php.ini per gebruiker is dat niet alleen in een cloud omgeving?
Cloudlinux kan leuk zijn, maar zijn we te klein voor denk ik. Sowieso is een ander de server eigenaar, ik doe alleen onderhoud en updates etc. en heb daarom overal toegang toe en mag en kan wat extra dingen.
Ben wel van plan om nu van php 7.2 met mod_ruid2 en mod_php over te stappen naar php-fpm en dan meerdere php versies, eens kijken of dat goed uit pakt. Moet vrij makkelijk om te zetten zijn
Dus exec en proc_open zijn niet zo'n probleem dan als ik het goed begrijp.
Hoe zit het dan met escapeshellarg en popen?
De beperkte ervaring die ik met CloudLinux heb is heel slecht. Van willekeurige kernel panics overdag tot het niet meer kunnen updaten van de server zonder een kernel panic. Uiteindelijk zijn alleen de willekeurige kernel panics over, maar de servers die er nog zijn, gaan zo snel mogelijk gemigreerd worden naar een systeem zonder CloudLinux.
Vind dit een vreemd verhaal, CloudLinux wordt veel ingezet, ook door grotere partijen. Zelf met een aantal servers ook deze problemen niet gehad.
Aha, dat is dan wel interessant, dus dan maakt het feitelijk niet uit of het uit of aan staat. Custom php.ini per gebruiker is dat niet alleen in een cloud omgeving?
Cloudlinux kan leuk zijn, maar zijn we te klein voor denk ik. Sowieso is een ander de server eigenaar, ik doe alleen onderhoud en updates etc. en heb daarom overal toegang toe en mag en kan wat extra dingen.
Ben wel van plan om nu van php 7.2 met mod_ruid2 en mod_php over te stappen naar php-fpm en dan meerdere php versies, eens kijken of dat goed uit pakt. Moet vrij makkelijk om te zetten zijn
Dus exec en proc_open zijn niet zo'n probleem dan als ik het goed begrijp.
Hoe zit het dan met escapeshellarg en popen?
Er blijft altijd nog wel een verschil zitten, bijv. een script via een lekke wordpress plugin zou zonder de uitgeschakelde functies eventueel makkelijker eea uit kunnen voeren onder de user.
escapeshellarg lijkt mij overigens in geen geval een probleem, het haalt potentiële gevaarlijke tekens uit een string. Wel wordt de functie in de context van exec() e.d. gebruikt, vandaar dat men deze mogelijk in de lijst toevoegt, zo van: in die hoek willen we je helemaal niet hebben.
Exec zelf of iets als popen of andere functies, ik zou eigenlijk zeggen:
- Bij geen CloudLinux: beter toch wel deze functies standaard blokkeren.
- Bij CloudLinux kun je deze makkelijker toestaan, omdat met cagefs de risico's meer beperkt blijven tot de user, en niet het systeem.
Als het gaat om een server van een klant, en diezelfde klant wil bepaalde functies gebruiken, zou ik uitleggen dat je wel iets van beveiliging inlevert, maar dat het wel een optie is. Dat moet de klant uiteindelijk zelf weten lijkt mij.
Hier nog iets meer info over de disable functions met php-fpm: https://forum.directadmin.com/threads/overwrite-disable_function-for-an-user.51415/ - daar wordt geconcludeerd dat je dan per user een disable_function zou moeten specificeren, want je kunt wel extra functies per user blokkeren, maar niet functies die in de main php.ini geblokkeerd worden, in de user.ini de-blokkeren.
Exec zelf of iets als popen of andere functies, ik zou eigenlijk zeggen:
- Bij geen CloudLinux: beter toch wel deze functies standaard blokkeren.
Ja volgens Xenforo zou dat dus geen security risk zijn omdat er methodes zouden zijn om dat te omzeilen, ze gebruiken exec dus voor XMRP en ffmepg. Maar dan laten we dat fijn geblokkeerd staan allemaal. Zolang er niemand Gallery installeert zou het geen probleem moeten zijn.
Vind dit een vreemd verhaal, CloudLinux wordt veel ingezet, ook door grotere partijen. Zelf met een aantal servers ook deze problemen niet gehad.
Het gebeurde ook niet op alle servers. Waarom, dat weet ik niet. We hebben het probleem bij CloudLinux aangekaart en kernel dumps opgestuurd. Na een aantal maanden heeft CloudLinux een kernel uitgebracht waar dit probleem in opgelost was en daarna is het niet meer voorgekomen.
Dat betekent niet dat het voor iedereen slecht is. Maar het betekent ook niet dat het voor iedereen goed is. Onze ervaringen vielen tegen, dus wij gaan het niet meer gebruiken. Prima verder als andere partijen het wel gebruiken.
systemdeveloper
07/11/20, 21:39
Het gebeurde ook niet op alle servers. Waarom, dat weet ik niet. We hebben het probleem bij CloudLinux aangekaart en kernel dumps opgestuurd. Na een aantal maanden heeft CloudLinux een kernel uitgebracht waar dit probleem in opgelost was en daarna is het niet meer voorgekomen.
Dat betekent niet dat het voor iedereen slecht is. Maar het betekent ook niet dat het voor iedereen goed is. Onze ervaringen vielen tegen, dus wij gaan het niet meer gebruiken. Prima verder als andere partijen het wel gebruiken.
Ik had een week geleden een perfect werkend CentOS 8.2 vps op XenServer. Geconverteerd naar CloudLinux OS+, direct hangen na reboot. 5 minuten later weer eraf gemikt.
Ben er wel benieuwd naar. wat gaf Cloudlinux support aan?
Wij draaien namelijk bijna alles op Cloudlinux
Ik had een week geleden een perfect werkend CentOS 8.2 vps op XenServer. Geconverteerd naar CloudLinux OS+, direct hangen na reboot. 5 minuten later weer eraf gemikt.
systemdeveloper
09/11/20, 10:41
Ben er wel benieuwd naar. wat gaf Cloudlinux support aan?
Wij draaien namelijk bijna alles op Cloudlinux
Ik heb het niet bij support neergelegd. Voorheen heb ik al CL gebruikt (ook mee gestopt uiteindelijk om ik een simpelere manier wilde die ik zelf onder controle had) en dat werkte zonder problemen. Nu was het de + versie op een ouder xenserver systeem van een klant en dat haperde met sommige kernels sowieso al.