Synology-Forum.nl
Tweaks / Addons A.K.A. The Underground => 3rd party apps integratie in DSM => Topic gestart door: wizjos op 23 oktober 2008, 11:32:29
-
Hoi,
Op het duitse forum kwam ik deze oplossing tegen om middels Ajax en een cgi script php pagina's zodanig te beveiligen dat je ingelogd moet zijn in de DSM om de pagina op te kunnen roepen:
Werkwijze:
Maak een bestand auth.cgi aan in /usr/syno/synoman/phpsrc/systeminfo. Als deze dir niet bestaat aanmaken, of in een andere dir onder /usr/syno/synoman/phpsrc aanmaken.
(in het laatste geval dien je het pad in de aanroep naar dit script vanuit php (zie verderop) aan te passen) :mrgreen:
auth.cgi
#!/bin/ash
USR=$(/usr/syno/synoman/webman/modules/authenticate.cgi)
#[ "$USR" != "admin" ] && exit 1
echo "Content-type: text/html"
echo ""
echo $USR
Let er op dat de regeleindes geen ^M bevatten (als je dit script in Windows maakt)!
Vervolgens verander je je phpcode die je wilt beveiligen zo:
test_auth.php
<script>
var myXMLHTTPRequest = (window.XMLHttpRequest)?
new XMLHttpRequest():
new ActiveXObject("Microsoft.XMLHTTP");
function LoadHTML(htmlfile){
myXMLHTTPRequest.open("GET", htmlfile, false); myXMLHTTPRequest.send(null);
return myXMLHTTPRequest.responseText;
}
ret=LoadHTML('https://jouwsynoip:5001/phpsrc/systeminfo/auth.cgi');
var ret = ret.replace(new RegExp( "n", "g" ), "" );
if (ret != 'admin') {
alert("You are not authorised!");
window.parent.location="https://jouwsynoip:5001"
}
</script>
<?php
echo "U bent binnen.... phpcode kan nu volgen";
?>
Wat doet deze code? Middels Ajax-technologie wordt het bestand auth.cgi aangeroepen en de daaruit komende output wordt in de variabele 'ret' geplaatst.
Vervolgens (en hier wijkt mijn code af van de duitse) wordt het einde-regelteken achter de output middels een replace actie verwijderd en wordt gekeken of de output uit auth.cgi 'admin' is... Indien ja, dan wordt de php code uitgevoerd; indien niet, dan wordt er een alert gegeven en wordt de pagina herleid naar het algemene DSM inlogscherm.
De reden van de verandering is dat de output van auth.cgi bij mij admin+<enter> teruggeeft en als ik dat laat vergelijken met 'admin' is dat natuurlijk nooit hetzelfde....
Ik heb de herleiding naar het inlogscherm met een window.parent.location gedaan omdat als je enkel window.location zou opgeven je het inlogscherm van de DSM in het 3rd party apps venster krijgt en dat gaat zo op dat aloude Droste effect lijken.... :mrgreen:
Opmerking: Deze oplossing (en de oplossing die Synology zelf biedt, maar niet correct werkt) baseren zich er op dat de Sessie-Cookie nog niet vervallen is. Nadeel is dus dat je je opnieuw moet aanmelden als je te lang niets hebt gedaan :mrgreen:
Succes!
Wizjos
-
Ok, met het gevaar een zeurpiet te zijn, maar toch wat opmerkingen...
Algemeen: deze oplossing zorgt voor een stukje javascript aan de client-side (browser) die de controle uitvoerd. Iedereen die de pagina aanpast (dankzij plug-ins, gesavede/aangepaste files, speciale proxies) of die gewoon javascript uitzetten, kan deze beveiliging omzeilen...weet wat je ermee doet ! Het is gezonder als je dat aan server-side kan doen, dus bijvoorbeel php laten connecten voor de check.
Verder kleine opmerkingen:
* deze oplossing werkt alleen met IE (activeX object..), alhoewel het niet moeilijk is dit uit te breiden naar andere browsers
* jouw voorbeeld gebruikt https en poort 5001, niet standaard, voor de minder oplettende kijkers: eigen waardens invullen ;)
Groeten,
Remco
-
Merty,
Als je jezelf een zeurpiet vindt kan ik daar niets aan doen :mrgreen: Zinnige aanvullingen zijn altijd welkom! Dus nee, zeurpiet is niet van toepassing :D
Wat wél leuk zou zijn is een nadere uitwerking van je idee om php te laten connecten. Ik denk dat ik wel een idee hebt van wat je bedoelt, maar een voorbeeld zou welkom zijn. :P
Ten aanzien van je 'kleine' opmerkingen: Inderdaad, ik maak enkel gebruik van IE (of beter, Avant Browser). Een en ander is inderdaad redelijk simpel uit te breiden naar andere browsers; daarover is ook voldoende in het 'wild' te vinden.
En mijn voorbeeld gebruikt inderdaad https en poort 5001. Wat is daar niet standaard aan? Alles wat je via de DSM van buitenaf wilt laten functioneren dient minstens via HTTPS te gaan; ik moet er niet aan denken dat dat via http zou lopen! ... en poort 5001 is nou eenmaal de standaard https poort van de Syno, tóch?
Groet,
Wizjos
-
Oh, 5001 is port als https aan staat ? hmm..grappig, dan ben ik een minder oplettende kijker ;) gebruik mijn nas alleen thuis, en remote via ssh tunnel via linux server, dus heb zelf geen https aanstaan.
Anyway, je hebt gelijk, niet alleen zeuren maar betere oplossing aandragen is handiger :)
Ik heb zelf niet php draaien op de system webserver, dus heb ik eerst maar php aangezet in de system server : (AddType application/x-httpd-php .php en LoadModule php5_module /lib/libphp5.so regels toegevoegd aan /usr/syno/apache/conf/httpd.conf-sys) en herstarten, verder alles standaard gelaten in de php.ini file.
En toen heb ik wat zitten spelen met authenticate.cgi. Uiteindelijke lukte het me om ' gewoon' te checken of er ingelogd is of niet door:
* Script authenticate.cgi te kopieren van /usr/syno/synoman/webman/modules/ naar /usr/syno/bin (safe_mode_exec_dir aangegeven in php.ini, vreemd genoeg is deze nog steeds beperkend, ook al is safe_mode off ...)
* environment server variables "REMOTE_ADDR" en "HTTP_COOKIE" extra setten in environment variables voordat exec gedaan wordt...en voila, dan werkt alles weer...
Voorbeeld:
<html>
<head>
<title>PHP Test</title>
</head>
<body>
<?php
putenv('HTTP_COOKIE=' .$_SERVER['HTTP_COOKIE']);
putenv('REMOTE_ADDR=' .$_SERVER['REMOTE_ADDR']);
$user=exec('/usr/syno/bin/authenticate.cgi');
if ($user=="admin") {
echo "gefeliciteerd!";
} else {
echo "nope!";
}
?>
</body>
</html>
Probeer maar uit door deze als php file ergens bereikbaar te zetten voor system webserver en uit te voeren. Log uit in de admin page, en je zult zien dat het van 'gefeliciteerd' naar 'nope' gaat. Ik denk dat dit toch makkelijker & veiliger is...
Ik vermoed dat tijdens het uitgeven van cookies in eigen database remote addres, cookie waarde 'id' en username bewaard. authenticate.cgi gaat deze waarden ophalen en vergelijken met de server variabelen die hij meekrijgt in de environment en retourneerd de username als hij deze kan vinden in de database. Simpel, maar doeltreffend. Was leuk geweest als dat ook in de 3rd party app document had gestaan.....
Groeten,
Remco
-
Hee Remco,
Dank voor je snelle reactie... Maar 't is al wat laat voor vandaag, dus wat je allemaal schreef ga ik morgen of van 't weekend eens uitgebreid doornemen!
Je hebt gelijk als je zegt dat de documentatie van Synology op dit punt 'naatje' is :roll: Wat ik persoonlijk ook een gemis vind (ik heb althans nog niet uitgevonden wat je er aan zou kunnen doen), is dat 3rd party apps volgens mij niet de timeout van de login beïnvloeden (dus dat de sessie niet verloopt terwijl je alleen maar gebruik maakt van 3rd party spul; nu doet 'ie dat wel volgens mij) en dat je de timeout op de een of andere manier instelbaar kunt maken... Wie dat weet uit te vogelen.... :mrgreen:
Dank en groet,
Wizjos
-
Remco
Briljant gevonden! Heb e.e.a. getest en 't loopt als een zonnetje! Wat ik me alleen nog afvraag (want ik heb natuurlijk ook eens gekeken wat er gebeurt als ik de beide putenv's er uit weglaat), is waar je dat zo snel vandaan hebt gehaald :roll:
Zonder doet 'ie het niet en met wél...
Als je me daar nog een uitlegje over wilt geven ben ik je helemaal dank verschuldigd :D
Ik ga in ieder geval mijn code aanpasen.... :mrgreen: Wellicht dat men in de rest van de wereld hier ook nog wat aan heeft...
Groet,
Wizjos
-
Anyway, je hebt gelijk, niet alleen zeuren maar betere oplossing aandragen is handiger :)
Ik heb zelf niet php draaien op de system webserver, dus heb ik eerst maar php aangezet in de system server : (AddType application/x-httpd-php .php en LoadModule php5_module /lib/libphp5.so regels toegevoegd aan /usr/syno/apache/conf/httpd.conf-sys) en herstarten, verder alles standaard gelaten in de php.ini file.
En toen heb ik wat zitten spelen met authenticate.cgi. Uiteindelijke lukte het me om ' gewoon' te checken of er ingelogd is of niet door:
* Script authenticate.cgi te kopieren van /usr/syno/synoman/webman/modules/ naar /usr/syno/bin (safe_mode_exec_dir aangegeven in php.ini, vreemd genoeg is deze nog steeds beperkend, ook al is safe_mode off ...)
* environment server variables "REMOTE_ADDR" en "HTTP_COOKIE" extra setten in environment variables voordat exec gedaan wordt...en voila, dan werkt alles weer...
Groeten,
Remco
Hoi Remco,
Heb jij alleen deze 2 regels aan de httpd.conf-sys toegevoegd?
AddType application/x-httpd-php .php en LoadModule php5_module /lib/libphp5.so regels toegevoegd aan /usr/syno/apache/conf/httpd.conf-sys
Of heb je alles veranderd zoals hieronder:
<Directory />
Options ExecCGI FollowSymLinks MultiViews Indexes
AllowOverride All
</Directory>
<Directory "/usr/syno/synoman">
Options ExecCGI FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>
<IfModule dir_module>
DirectoryIndex index.html index.htm index.cgi index.php
</IfModule>
<IfModule mime_module>
...
AddHandler cgi-script .cgi
...
</IfModule>
En ik begrijp dat je in de php.ini niets hebt veranderd.
Dus
safe_mode = Off
safe_mode_exec_dir =
open_basedir =
doc_root =
allow_url_fopen = On
register_globals = On
dit heb je niet uitgevoerd?
Wat heb je ingevuld bij safe_mode_exec_dir =?
Het je daar alleen /usr/syno/bin toegevoegd?
Zo dat zijn weer een hoop vragen van een linux leek :mrgreen: :mrgreen: :mrgreen:
Groetjes m@rco
-
dank u, wat een vragen :)
Wizjos:
Ik wist dat authenticate.cgi werkte met Perl en shell scripts, maar merkte dat het vanuit php niets deed. (ook niet als ik het programma in een dir gooide die wel genoemd werd in safe_mode_exec_dir ). Dus dan moest het zijn omdat bepaalde environment variabelen niet meegegeven werden. Het leek me logisch dat HTTP_COOKIE gebruikt werd, dus was het zoeken & uitproberen welke van de andere environment variabelen er miste. Eerst alles erin en een voor een eruit halen tot het niet meer werkt..;)
Anyway, inmiddels heb ik nog verder zitten te snuffelen en de ' database' die ik vermoedde is niets anders dan een simpele file in de /tmp/ dir : 'current.connections', althans bij mij (firmware 7.22) . Nu kan het *nog* simpeler:
$file="/tmp/current.users";
if (file_exists($file)&&filesize($file)) {
$fh=fopen($file,'r');
$line=fread($fh,filesize($file));
list ($addr,$user,$begin,$last,$service) = split(":",$line);
}
if ($user=="admin") {
echo "gefeliciteerd!";
} else {
echo "nope!";
}
Dit werkt zonder aanpassing waar dan ook en ook via 'user' webserver. Simpel & eenvoudig, alleen, kans is groot dat het natuurlijk aangepast is in een nieuwere firmware (*kuch* security *kuch*). Ik denk aanroepen van 'authenticate' wat toekomst vaster is, daar dat zo'n beetje het *enige* is wat ze gedocumenteerd hebben voor 3rd party apps.
Marco:
Klopt, alleen 2 regels toegevoegd om php werkbaar te krijgen op 'system' webserver, omdat voorbeeld van Wizjos ook de 'system' webserver gebruikte, dus hij moest php hebben ge-enabled. Alle configuratiefiles zijn/waren verder default. Dus safe_mode_exec_dir stond nog op '/usr/syno/bin', daar ben ik verder vanaf gebleven. In principe hoef je niet meer te veranderen, maar mocht je willen weten wat wat is met de opties de je aangaf:
* CGI opties/docroot zijn hetzelfde
* IfModule heeft toevoeging tov. default om index.php automatisch te kiezen bij urls die geen filenaam opgeven
* safe_mode was al uit
* safe_mode_exec_dir stond dus op /usr/syno/bin/. Blijkbaar is het effectief zolang hier nog een directory staat. Vreemd, want eigenlijk moet het niet werken omdat safe_mode al uit staat...
* open_basedir stond default op al een lading directories (inclusief /tmp/ wel zo handig voor voorbeeld hierboven). Deze leeglaten vind ik geen goed idee qua security, zie andere posting. Zet er anders je shares in die php scripts moeten kunnen bereiken, of gebruik mijn 'WebShare Enable' package om dit wat makkelijker te doen.
* register_globals : als er programma's zijn die deze perse op 'on' moeten hebben staan, zijn we wel erg beroerd geschreven. Security risk (opnieuw) om open te zetten
* allow_url_fopen : default. Niet zo spannende optie.
Groeten,
Remco
-
Remco
Briljant gevonden! Heb e.e.a. getest en 't loopt als een zonnetje! Wat ik me alleen nog afvraag (want ik heb natuurlijk ook eens gekeken wat er gebeurt als ik de beide putenv's er uit weglaat), is waar je dat zo snel vandaan hebt gehaald :roll:
Zonder doet 'ie het niet en met wél...
Als je me daar nog een uitlegje over wilt geven ben ik je helemaal dank verschuldigd :D
Ik ga in ieder geval mijn code aanpasen.... :mrgreen: Wellicht dat men in de rest van de wereld hier ook nog wat aan heeft...
Groet,
Wizjos
Hoi Wizjos,
Zou jij de door jouw geposte codes hierop het forum ook aan kunnen passen met de oplossing van Merty :?:
Dus eXplorer, Simpel Shell, enz.
Een heleboel mensen (waaronder ik zelf :mrgreen: ) weten niet waar ze het moeten aanpassen.
Ik wil graag Explorer er op zetten maar dan wel dat hij niet rechtstreeks benaderbaar is.
En dus kijkt of iemand is ingelogt
Ik heb de oplossing van Merty gelezen en het eerste gedeelte kan ik nog volgen.
Maar ik zou niet weten waar het 2 de gedeelte ingevoegd moet worden :?: :?:
Ik wil je ook niet met extra werk opzadelen :mrgreen:
Maar het lijkt me beter dat we hier op het forum de meeste veilige manier hier weergeven.
Het is een idee. Ik verplicht je tot niks. Je zou mij er erg blij mee maken en ik denk meerdere mensen.
Groetjes m@rco
Ps ik ben jaloers op jullie kennis. :wink:
-
Maar het lijkt me beter dat we hier op het forum de meeste veilige manier hier weergeven.
Het is een idee. Ik verplicht je tot niks. Je zou mij er erg blij mee maken en ik denk meerdere mensen.
Groetjes m@rco
Ps ik ben jaloers op jullie kennis. :wink:
Hier sluit ik mij 100% bij aan.
Luit
-
Hoi Remco,
Ik ben wat aan het stoeien geweest met:
<?php
putenv('HTTP_COOKIE=' .$_SERVER['HTTP_COOKIE']);
putenv('REMOTE_ADDR=' .$_SERVER['REMOTE_ADDR']);
$user=exec('/usr/syno/bin/authenticate.cgi');
if ($user=="admin") {
echo "gefeliciteerd!";
} else {
echo "nope!";
}
?>
En het werkt alleen krijg ik wat foutmeldingen in bijvoorbeeld phpmyadmin
nope!
Warning: Cannot modify header information - headers already sent by (output started at /usr/syno/synoman/phpsrc/phpMyAdmin/index.php:8) in /usr/syno/synoman/phpsrc/phpMyAdmin/libraries/core.lib.php on line 558
Warning: Cannot modify header information - headers already sent by (output started at /usr/syno/synoman/phpsrc/phpMyAdmin/index.php:8) in /usr/syno/synoman/phpsrc/phpMyAdmin/index.php on line 107
Nu wil ik als je niet ingelogt bent je door wordt verwezen naar de standaard 404 pagina van Synology en als je wel bent ingelogd hij verder gaat met het de rest van de php file.
In mijn voorbeeld van PhpMyAdmin heb ik jou code toegevoegd in de index.php
Kun jij uitleggen hoe ik dat moet doen?
Alvast bedankt
Groetjes m@rco
-
Marco,
Tja, de warning krijg je omdat php denkt dat de twee putenvs bedoeld zijn om de http header die terugstuurd met de HTML code aan te passen, maar dat heeft niet veel nut want zodra deze worden uitgevoerd, zijn de headers al verstuurd. Het kan ook geen kwaad, want dat was de bedoeling niet van de putenv's , alleen maar om in environment variables te zetten voor de exec erna. Als je het echt vervelend vind zijn er wel tussen oplossingen, bijvoorbeeld een script wat als argumenten cookie en remote address meekrijgen in de URL, en dan deze eruit haalt, environment variabelen ermee zet en authenticate.cgi aanroept. Is alleen wat omslachtiger.
Overigens, ik zie nog "nope!" in de foutmelding staan... de 'gefeliciteerd' en 'nope' zijn voorbeelden...op die regels moeten de "alleen-na-login" of "afgekeurde" code komen...
Groeten,
Remco
-
Luit, M@rco,
Het bericht van mij dat ik net aan jullie schreef zie ik ineens niet meer terug... :( Op het gevaar af dat ik hier dubbel post, nog maar eens het zelfde dan als daarnet:
Jullie zijn mij voor; ik was het eigenlijk al van plan, maar ja, tijd en zo hè :mrgreen:
Ik zal mijn geplaatste codes aanpassen met de beveiliging van Merty, ik zal dan de code bijwerken en niet opnieuw posten.... Ik hou jullie op de hoogte....
Overigens is Extplorer van zichzelf al voorzien van beveiliging met inlognaam en wachtwoord... Als jullie willen, kan ik denk ik dit ook wel aanpassen. 't zal alleen wat meer vogelen zijn denk ik :mrgreen:
...en dat geeft me ook nog even de kans om te reageren op je post van zojuist M@rco... (maar wellicht maai ik Merty nu het gras voor de voeten weg :mrgreen:
De warnings die je krijgt komen doordat je al output naar het scherm stuurt (bv. die 'echo') en dat daarna in de code nog een header opdracht komt.... Oplossing is relatief eenvoudig, denk ik, als je zorgt dat je geen echo's geeft maar gewoon een redirect naar een pagina o.i.d., dan zou het moeten werken... Iets als:
putenv('HTTP_COOKIE='.$_SERVER['HTTP_COOKIE']);
putenv('REMOTE_ADDR='.$_SERVER['REMOTE_ADDR']);
$user=exec('/usr/syno/synoman/webman/modules/authenticate.cgi');
if($user != 'admin'){
header("HTTP/1.0 403 Forbidden");
exit;
}
Even van de duitse site geplukt :mrgreen:
Als dit niet wil, kun je dan je index.php eens posten?
Groet,
Wizjos
-
M@rco,
Wat bij mij in ieder geval werkt is deze oplossing voor phpMyAdmin:
Belangrijk:
phpMyAdmin staat bij mij geïnstalleerd in /volume1/adminweb/phpmyadmin
Dan wordt: application.cfg:
text = phpmyadmin
description = phpmyadmin
type = embedded
path = /phpsrc/phpmyadmin/toegang.php
En dan wordt: /usr/syno/synoman/phpsrc/phpmyadmin/toegang.php
<?php
putenv('HTTP_COOKIE='.$_SERVER['HTTP_COOKIE']);
putenv('REMOTE_ADDR='.$_SERVER['REMOTE_ADDR']);
$user=exec('/usr/syno/synoman/webman/modules/authenticate.cgi');
if($user != 'admin'){
header("HTTP/1.0 403 Forbidden");
exit;
} else {
include("/volume1/adminweb/phpmyadmin/index.php");
}
?>
In config.inc.php had ik $cfg[PmaAbsoluteUri] aan staan... Deze heb ik uit gezet.
Probeer maar eens...
Volgens mij moet hetzelfde ook toepasbaar zijn op extPlorer :mrgreen:
Groet,
Wizjos
-
Hoi Wizjos,
Het is nu 23:00 dus ik ga er morgen ochtend naar kijken.
Ik zit alleen net te bedenken dat als je het rechstreeks de index.php aanroept je het als nog omzeilt.
Moet je de index.php niet hernoemen naar index2.php en dan toegang.php hernoemen naar index.php.
En dan in index2.php een verwijzing dat hij eerst index.php moet laden om verder te kunnen.
Is maar een gedachte spinsel. Ik ben maar een leek met Linux :mrgreen: :mrgreen: :mrgreen:
Groetjes m@rco
-
M@rco,
Daar heb je helemaal gelijk in! Alleen, ik heb, zoals ik al schreef, het hele boeltje in /volume1/adminweb staan en dat is een directory die hoe dan ook niet bereikbaar is op een directe manier :mrgreen:
Reden hiervoor is dat ik op deze manier een afgescheiden deel van m'n volume1 in kan richten voor 'gevoelige' zaken die ik niet in de normale webomgeving wil hebben.
Waarom dan niet direct onder phpsrc? Omdat daar de ruimte redelijk beperkt is; Synology is er nooit van uit gegaan dat eindgebruikers hier ook nog wel eens wat willen plaatsen en hebben maar een relatief klein systeem gedeelte ingericht, dus je loopt kans dat als je al te grote pakketten in bv. phpsrc gaat zetten je bij een update de melding krijgt dat de ruimet ontoereikend is.... :(
Daarnaast geldt ook nog dat ik op meedere fora heb gelezen dat de 3rd party omgeving bij een systeemupdate om zeep geholpen kan worden (vandaar ook de eerder geposte Manager met backup mogelijkheid) :mrgreen:
Kortom, heel wat overwegingen... Maar wat jij schrijft is natuurlijk ook heel goed mogelijk... Maak alleen niet de fout om phpMyAdmin te installeren in de normale web-omgeving; deze met allerlei beveiligings-toeters-en-bellen vanuit de https omgeving benaderbaar te maken en vervolgens te vergeten dat 'ie via de achterdeur (de normale webomgeving dus) nog steeds benaderbaar is :mrgreen:
Knutsel ze! Het is er vandaag tenslotte weer voor :(
Groet,
Wizjos
-
M@rco,
Daar heb je helemaal gelijk in! Alleen, ik heb, zoals ik al schreef, het hele boeltje in /volume1/adminweb staan en dat is een directory die hoe dan ook niet bereikbaar is op een directe manier :mrgreen:
Reden hiervoor is dat ik op deze manier een afgescheiden deel van m'n volume1 in kan richten voor 'gevoelige' zaken die ik niet in de normale webomgeving wil hebben.
Waarom dan niet direct onder phpsrc? Omdat daar de ruimte redelijk beperkt is; Synology is er nooit van uit gegaan dat eindgebruikers hier ook nog wel eens wat willen plaatsen en hebben maar een relatief klein systeem gedeelte ingericht, dus je loopt kans dat als je al te grote pakketten in bv. phpsrc gaat zetten je bij een update de melding krijgt dat de ruimet ontoereikend is.... :(
Daarnaast geldt ook nog dat ik op meedere fora heb gelezen dat de 3rd party omgeving bij een systeemupdate om zeep geholpen kan worden (vandaar ook de eerder geposte Manager met backup mogelijkheid) :mrgreen:
Kortom, heel wat overwegingen... Maar wat jij schrijft is natuurlijk ook heel goed mogelijk... Maak alleen niet de fout om phpMyAdmin te installeren in de normale web-omgeving; deze met allerlei beveiligings-toeters-en-bellen vanuit de https omgeving benaderbaar te maken en vervolgens te vergeten dat 'ie via de achterdeur (de normale webomgeving dus) nog steeds benaderbaar is :mrgreen:
Knutsel ze! Het is er vandaag tenslotte weer voor :(
Groet,
Wizjos
Hoi Wizjos,
Bedankt voor je duidelijke antwoord.
Dan ga ik de boel maar verplaatsen :wink:
Daar kan ik dus ook eXtplorer naar verplaatsen :?:
En kun je daar dan alle 3rd party items die werken met php daar naar toe verplaatsen :?:
Groetjes m@rco
-
Dan ga ik de boel maar verplaatsen :wink:
Daar kan ik dus ook eXtplorer naar verplaatsen :?:
En kun je daar dan alle 3rd party items die werken met php daar naar toe verplaatsen :?:
M@rco,
Inderdaad, extplorer zou je daar ook moeten kunnen plaatsen en inderdaad, eigenlijk alle 3rd party wel denk ik... 't is tenslotte altijd de moeite waard het te proberen :wink:
Groet,
Wizjos
-
Ik krijg toch weer een error.
Warning: require_once(./libraries/common.inc.php) [function.require-once]: failed to open stream: No such file or directory in /volume1/adminweb/phpmyadmin/index.php on line 34
Fatal error: require_once() [function.require]: Failed opening required './libraries/common.inc.php' (include_path='.:/usr/syno/php/lib/php') in /volume1/adminweb/phpmyadmin/index.php on line 34
Waarschijnlijk doordat ik niet alles in /usr/syno/apache/conf/httpd.conf-sys heb uitgevoerd.
Omdat ik niet wil dat alles wagenwijd openstaat.
Ik geeft het voor vandaag weer op.
Ik heb er geen kracht meer voor :mrgreen: :mrgreen: :mrgreen:
Groetjes m@rco
-
* open_basedir stond default op al een lading directories (inclusief /tmp/ wel zo handig voor voorbeeld hierboven). Deze leeglaten vind ik geen goed idee qua security, zie andere posting. Zet er anders je shares in die php scripts moeten kunnen bereiken, of gebruik mijn 'WebShare Enable' package om dit wat makkelijker te doen.
Remco
Hoi Remco,
Ik heb nog een vraag betreffende het gebruik van Webshare Enable.
Als ik daar nu in kijk dan zijn alleen de mappen /photo en /web enabled.
Als ik dat doe met bijvoorbeeld phpmyadmin of extplorer zijn deze dan van buitenaf bereikbaar?
Of is Webshare enable alleen bedoeld om er voor te zorgen dat er in die map php code uitgevoerd kan worden?
Dus als ik die enable dan hoef ik niet bang te zijn dat deze rechstreeks benaderbaar zijn?
Groetjes m@rco
-
M@rco,
Nee het is eigenlijk andersom. Standaard configuratie is dat alle files die de webserver kan bereiken, PHP files kunnen zijn (en dus uitgevoerd worden). Maar, je wilt liever niet dat PHP scripts *alle* bestanden (ook buiten de webserver) bereikbaar zijn door (buggy-) php scripts (vandaar de open_basedir settings in PHP). Stel je voor dat een verkeerd geprogrammeerde php script plotseling je configuratiebestanden laat zien inclusief passwords, of je prive map met documentatie aan de hele wereld beschikbaar maakt... Maar ik kan me voorstellen dat je vanuit je PHP script wel bij bijvoorbeeld de share directories wilt komen, bijvoorbeeld voor upload/download/search achtige php scripts. Hiervoor zou je je PHP.ini moeten aanpassen om deze directories handmatig erbij zetten, en daarna webserver restarten, maar je kan ook mijn programma'tje gebruiken door simpelweg de share aan te vinken die toegangkelijk moet zijn voor PHP.
Overigens, default staat de share 'web' al aan (dat is voor de webserver; PHP scripts moeten wel bij hun eigen files kunnen ;) ), 'music' voor audiostation en 'photo' voor photostation. Dat zou ik ook zo laten :)
Kortom, het gaat erover waar php scripts bij mogen komen of niet, niet of php scripts gedraait mogen worden of niet. In dat laatste geval zou ik (ook) kijken naar gebruik van .htaccess files waar je dit soort regels kan instellen.....
Groeten,
Remco
-
Remco,
betekent dit ook dat als ik met eXTplorer overal aan wil kunnen komen, de open_basedir dus leeg moet zijn?
Of is er een manier om met eXtplorer wel overal aan te kunnen komen maar andere PHP scripts geen toegang te geven.
Luit
-
M@rco,
Nee het is eigenlijk andersom. Standaard configuratie is dat alle files die de webserver kan bereiken, PHP files kunnen zijn (en dus uitgevoerd worden). Maar, je wilt liever niet dat PHP scripts *alle* bestanden (ook buiten de webserver) bereikbaar zijn door (buggy-) php scripts (vandaar de open_basedir settings in PHP). Stel je voor dat een verkeerd geprogrammeerde php script plotseling je configuratiebestanden laat zien inclusief passwords, of je prive map met documentatie aan de hele wereld beschikbaar maakt... Maar ik kan me voorstellen dat je vanuit je PHP script wel bij bijvoorbeeld de share directories wilt komen, bijvoorbeeld voor upload/download/search achtige php scripts. Hiervoor zou je je PHP.ini moeten aanpassen om deze directories handmatig erbij zetten, en daarna webserver restarten, maar je kan ook mijn programma'tje gebruiken door simpelweg de share aan te vinken die toegangkelijk moet zijn voor PHP.
Overigens, default staat de share 'web' al aan (dat is voor de webserver; PHP scripts moeten wel bij hun eigen files kunnen ;) ), 'music' voor audiostation en 'photo' voor photostation. Dat zou ik ook zo laten :)
Kortom, het gaat erover waar php scripts bij mogen komen of niet, niet of php scripts gedraait mogen worden of niet. In dat laatste geval zou ik (ook) kijken naar gebruik van .htaccess files waar je dit soort regels kan instellen.....
Groeten,
Remco
Hoi Remco,
Ik snap het nog steeds niet. Ligt niet aan jou maar aan mij :mrgreen:
Wat ik heb gedaan is het volgende:
Map aangemaakt op /volume1/webmanage
Hierin staan 2 mappen: phpMyAdmin en AjaXplorer.
In /usr/syno/synoman/webman/3rdparty/ heb ik /phpMyAdmin + /AjaXplorer aangemaakt
Heb ik bij allebei de application.cfg aangemaakt en deze verwijzen naar:
/usr/syno/synoman/phpsrc/AjaXplorer en /usr/syno/synoman/phpsrc/phpMyAdmin
BIj allebei heb ik een toegang .php aangemaakt met de code van jou / Wizjos.
In /usr/syno/apache/conf/httpd.conf-sys heb ik de 2 regels toegevoegd en opnieuw gestart.
Eerst wou het de php file downloaden maar naar de herstart laat hij wel het scherm van de 3d party zien maar hij laad niets
Als ik dan bij eigeschappen ga kijken (rechter muisknop windows) dan geeft hij toegang.php aan.
Ben ik nog iets vergeten?
Groetjes m@rco
-
betekent dit ook dat als ik met eXTplorer overal aan wil kunnen komen, de open_basedir dus leeg moet zijn?
Of is er een manier om met eXtplorer wel overal aan te kunnen komen maar andere PHP scripts geen toegang te geven.
Helaas, de open_basedir config optie is inderdaad van toepassing op *alle* php scripts die draaien op die webserver. Helaas is PHP6 niet geinstalleerd, daar had het wel gekund om in .htaccess files deze waarde te overrulen.
Dus inderdaad, wil je dat eXTplorer overal (dus ook /bin/ /etc en alle andere enge directories) bij kan komen, dan zul je 'm leeg moeten houden..
Groeten,
Remco
-
Wat ik heb gedaan is het volgende:
Map aangemaakt op /volume1/webmanage
Hierin staan 2 mappen: phpMyAdmin en AjaXplorer.
In /usr/syno/synoman/webman/3rdparty/ heb ik /phpMyAdmin + /AjaXplorer aangemaakt
Heb ik bij allebei de application.cfg aangemaakt en deze verwijzen naar:
/usr/syno/synoman/phpsrc/AjaXplorer en /usr/syno/synoman/phpsrc/phpMyAdmin
BIj allebei heb ik een toegang .php aangemaakt met de code van jou / Wizjos.
In /usr/syno/apache/conf/httpd.conf-sys heb ik de 2 regels toegevoegd en opnieuw gestart.
Eerst wou het de php file downloaden maar naar de herstart laat hij wel het scherm van de 3d party zien maar hij laad niets
Als ik dan bij eigeschappen ga kijken (rechter muisknop windows) dan geeft hij toegang.php aan.
Ben ik nog iets vergeten?
Hmmm...dat truukje met includen is leuk, maar denk niet dat het altijd werkt omdat sommige php scripts rechtstreeks z'n 'helper' php scripts wilt aanroepen, wat dus niet lukt. Wellicht dat het voor phpMyadmin wel werkt, omdat dat een en dezelfde php pagina is, maar ajaXplorer wordt dat wat ingewikkelder...
Anyway, met "laad niets" bedoel je waarschijnlijk dat je een lege pagina krijgt ? wellicht dat de include directory/naam niet goed staat in het 'toegang.php' script, probeer anders een een echo "TESTJE"; voor die include regel te zetten. Kijk of na het aanroepen wel 'TESTJE' ziet, dan weet je dat er iets mis is met het includen.
Daarnaast is het nog steeds nodig om '/volume1/webmanage' bij de directories in open_basedir conf te zetten, (of dus open_basedir leeg te houden)
Toch moet er een makkerlijker manier zijn om te beveiligen...moet er nog even over nadenken ;)
PS. In eerdere voorbeelden werd '/volume1/adminweb' gebruikt ipv. '/volume1/webmanage' ...is dit wellicht verkeerd ?
Groeten,
Remco
-
Remco,
Even ter verduidelijking: dat 'adminweb' is een geheel door mijzelf uitgevonden en aangemaakte directory onder volume1. Het was wat mij betreft ook enkel maar een voorbeeld om aan te geven dat een gedeelte van je web-omgeving dat je op een veilige plek wilt bewaren/managen niet in de dir /volume1/web of de https-specifieke omgeving (phpsrc) hoeft te staan om te werken... :mrgreen:
Overigens, webmanage ken ik weer niet (tenzij je /volume1/web ermee bedoelt) :D
Groet,
Wizjos
-
Wizjos,
Ja dat snapte ik wel..:)
Overigens, webmanage ken ik weer niet
Ik zei dat omdat in uitleg van marco werd genoemd
Map aangemaakt op /volume1/webmanage
Hierin staan 2 mappen: phpMyAdmin en AjaXplorer.
en
BIj allebei heb ik een toegang .php aangemaakt met de code van jou / Wizjos.
Als hij dat letterlijk heeft gedaan, verwijst toegang.php dus niet naar webmanage...
Overigens, kwam erachter dat de include truuk helaas ook niet altijd werkt omdat je dan een hoop gezeur krijgt over cookies en headers met scripts die dat perse willen zetten..
Groeten,
Remco
-
Wizjos,
Ja dat snapte ik wel..:)
Overigens, webmanage ken ik weer niet
Ik zei dat omdat in uitleg van marco werd genoemd
Map aangemaakt op /volume1/webmanage
Hierin staan 2 mappen: phpMyAdmin en AjaXplorer.
en
BIj allebei heb ik een toegang .php aangemaakt met de code van jou / Wizjos.
Als hij dat letterlijk heeft gedaan, verwijst toegang.php dus niet naar webmanage...
Overigens, kwam erachter dat de include truuk helaas ook niet altijd werkt omdat je dan een hoop gezeur krijgt over cookies en headers met scripts die dat perse willen zetten..
Groeten,
Remco
Goedemorgen heren,
Ik heb de toegang.php niet letterlijk genomen. :mrgreen:
Ik ben wel een leek :D maar ik was gisteren nog wel wakker :D
Ik heb in de toegang.php netjes de verwijzing aangepast naar /volume1/webmanage/
Ik vond webmanage lekkerder klinken als adminweb. Smaken verschillen :wink:
Ik heb inmiddels voor de 3x alles opnieuw geinstalleerd (ik had de bootstrap van nslu geprobeerd maar dat gaf meer problemen).
En ik zit er teveel mee te rotzooien. LOL. Anders leer je het nooit. Hahahah
Wat ik graag wil weten is wat moet ik nu open zetten om phpMyAdmin en AjaXplorer te laten werken zonder dat het van buitenaf bereikbaar is.
Dus de 2 regels toevoegen in /usr/syno/apache/conf/httpd.conf-sys.
De regel /volume1/webmanage toevoegen aan open_basedir (eventueel met Webshare Enable van Remco)
En moet ik dan nog iets doen?
Moet ik ook nog in /usr/syno/apache/conf/httpd.conf-sys de index.php toevoegen?
En als ik het goed begrepen heb en wil ik met AjaXplorer de hele synology bereiken dan moet ik open_basedir helemaal leeg laten.
Geeft dat een extra risico van buitenaf.?
Groetjes m@rco
-
Nou het heeft even geduurd maar het werkt :mrgreen:
Ik heb niet de optie van Wizjos gebruikt. Dus /volume1/admin (of webmanage).
Want dat kreeg ik niet werkend.
Extplore gaf wel een scherm maar ging niet door.
phpMyAdmin gaf een error dat ./libraries niet kon vinden (dit is een submap van phpmyadmin)
Toen toch alles in phpsrc gekopiert.
Volgens deze handleiding http://www.synology.nl/forum/viewtopic.php?f=83&t=2182 alles opengezet.
Wel een backup gemaakt van orginele php.in en http.conf-sys. Deze gekopiert naar /volume1
Voor phpmyadmin en extplorer heb ik de volgende code toegevoegd in de index.php.
Helemaal boven aan.
<?php
putenv('HTTP_COOKIE='.$_SERVER['HTTP_COOKIE']);
putenv('REMOTE_ADDR='.$_SERVER['REMOTE_ADDR']);
$user=exec('/usr/syno/synoman/webman/modules/authenticate.cgi');
if($user != 'admin'){
header("HTTP/1.0 403 Forbidden");
exit;
}
Let op!! Er staat al een <?php bovenaan in de index.php van phpmyadmin en extplorer.
Haal deze eerst weg voordat je de tekst er in plakt.
Als ik nu niet ingelogt ben en ik gaan naar bijvoorbeeld https://jouwip:5001/phpsrc/applicatie/a%20...%20ienaam.php
Dan krijg ik gewoon een wit scherm. Als ik ingelogt ben dan is bovenstaande url wel bereikbaar.
En het werkt :mrgreen:
Voor de rest heb ik de uitleg voor het toevoegen van 3rdparty apps gebruikt.
Dus aanmaken van de apllication.cfg
Groetjes m@rco