[php/batch] backup-script veilig uitvoeren

Pagina: 1
Acties:
  • 164 views sinds 30-01-2008
  • Reageer

  • js303
  • Registratie: April 2003
  • Laatst online: 25-01 14:14
hoi,

- ik heb een linux scriptje gemaakt op onze remote webserver dat een mysql-dump maakt van een database en deze vervolgens - tezamen met een map met allemaal jpg/gif/png images - zipt.

- ik roep dit linux-scriptje (backup.sh) aan vanuit php, als volgt (snippet):
code:
1
2
3
4
5
6
7
$filename   = "europe_" . date("Ymd", time());
$output     = `bash /backup.sh $filename`;

header  ("Content-type: application/force-download");
header  ("Content-Disposition: attachment; filename=$filename.zip");
readfile("../backups/$filename.zip");
exit    ();


- het php-script zelf kan alleen uitgevoerd worden als je bent ingelogd (dus mbv sessie).

- de php-sessie loopt over http, dus niet https, waardoor mogelijk 'afgeluisterd' kan worden met welke gegevens iemand inlogt.

- het linux-scriptje (backup.sh) zelf - waarin het mysqldump commando wordt gebruikt - bevat login-gegevens van de database (om de dump te mogen maken).

vragen: behalve dat de "http-login" en de "download-zip-bestand" zwakke plekken zijn, waar moet ik nog meer op letten mbt security? het script backup.sh staat in de hoofdmap van de user root. ik heb eens gelezen dat het onverstandig om als root acties uit te voeren. maar hoe zit dat dan met php: als welke user benadert php de webserver?

ik moet erbij zeggen dat ik weinig van linux weet maar graag wil leren. maar zie door de bomen het bos niet echt.

update: zou het een stuk veiliger worden als ik in php check vanaf welk ip het php-script wordt uitgevoerd en vervolgens al dan niet het linux-script uitvoerd? of kunnen slimme mensen ook dit weer omzeilen?

[ Voor 15% gewijzigd door js303 op 11-10-2004 11:33 ]


  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 20:49

gorgi_19

Kruimeltjes zijn weer op :9

* gorgi_19 ziet hier meer een rechtenkwestie in, welke minder met PHP an sich te maken heeft.
Even kijken of ze hier in Non-Windows Operating Systems meer raad mee weten :)

* gorgi_19 slaat het topic naar Non-Windows Operating Systems

Digitaal onderwijsmateriaal, leermateriaal voor hbo


  • Spider.007
  • Registratie: December 2000
  • Niet online

Spider.007

* Tetragrammaton

Alles valt uiteraard te omzeilen; je moet het veiligheidsniveau kiezen dat past bij je belangrijkheid van de gegevens. Heb je bijvoorbeeld root-rechten nodig om de database te kunnen dumpen? Kun je daar niet beter in mysql een gebruiker voor aanmaken met alleen leesrechten? :) Dan kan de 'apache' user dit gewoon uitvoeren. Als je HTTPS gebruikt, en je wachtwoord is minimaal 10 random characters dan zit het denk ik wel goed :)

---
Prozium - The great nepenthe. Opiate of our masses. Glue of our great society. Salve and salvation, it has delivered us from pathos, from sorrow, the deepest chasms of melancholy and hate


Verwijderd

Waarom gebruik je niet gewoon ssh, dan heb je 'out-of-the-box' authenticatie en encryptie.

zoiets als
code:
1
ssh user@remotehost mysqldump mijndb > ./localfile.sqldump

en voor de plaatjes en andere bestanden rsync?

Door een public/private sleutelpaar te maken, kun je wachtwoordloos inloggen op remotehost.

Ik denk dat er genoeg tutorials op internet te vinden zijn om je op weg te helpen.

Verder: als je geen gekke dingen met suExec hebt gedaan, draaien je php scripts onder dezelfde user als apache. Onder debian is dit standaard www-data. Je kunt dit uitzoeken met
code:
1
ps axu | grep apache

Je ziet dat 1 entry van je grep, 1 entry van het apache-hoofdproces dat als root draait en een x aantal apache 'slaves' die jouw php scripts draaien. De user voor die laatste processen is dus ook de user waaronder je phpscripts draaien. Het is absoluut geen goed idee om apache als root te draaien (behalve het hoofdproces dan).

/backup.sh wordt uitgevoerd door php en zal dus onder dezelfde user als php draaien.

Verder zou ik mezelf er van verzekeren dat $filename alleen a-z,0-9 bevat, anders kunnen er nasty dingen gebeuren! (b.v. $filename='; rm -rf /var/www' en weg is je website).

Tenslotte, je kunt die ip-check (en misschien ook de wachtwoord check als het toch een statisch wachtwoord is) beter door apache laten doen. Lees meer op http://httpd.apache.org/docs/howto/auth.html

  • arikkert
  • Registratie: Juli 2002
  • Laatst online: 13-02 10:18
js303 schreef op 11 oktober 2004 @ 11:26:
hoi,

- ik heb een linux scriptje gemaakt op onze remote webserver dat een mysql-dump maakt van een database en deze vervolgens - tezamen met een map met allemaal jpg/gif/png images - zipt.

- ik roep dit linux-scriptje (backup.sh) aan vanuit php
tis unix conventie om shell scripts in een bin dir te zz. system scripts in sbin en local scripts zoals je backup in /usr/local/(s)bin
- het php-script zelf kan alleen uitgevoerd worden als je bent ingelogd (dus mbv sessie).

- de php-sessie loopt over http, dus niet https, waardoor mogelijk 'afgeluisterd' kan worden met welke gegevens iemand inlogt.

- het linux-scriptje (backup.sh) zelf - waarin het mysqldump commando wordt gebruikt - bevat login-gegevens van de database (om de dump te mogen maken).
maak dan alleen readable (en executable) voor de user die het uitvoert
vragen: behalve dat de "http-login" en de "download-zip-bestand" zwakke plekken zijn, waar moet ik nog meer op letten mbt security? het script backup.sh staat in de hoofdmap van de user root. ik heb eens gelezen dat het onverstandig om als root acties uit te voeren. maar hoe zit dat dan met php: als welke user benadert php de webserver?
je hebt drie userid die belangrijk wat betreft rechten.
- userid van het executable scriptje
- userid van de user die het uitvoert
- effective userid
waar het scriptje staat heeft geen invloed.
moet je maar googlen op suid of sudo om meer over basic unix rechten te weten te komen.
wat je kunt doen is bijv : het backup scriptje als owner dezelfde maken als die van mysql zelf, dus usercode waarschijlijk mysql. Permissies 700 zodat alleen mysql er alles mee kan en world niets. daarna backup_wrapper.sh script maken (met owner dezelfde als die die php uitvoert en permissions 700) dat alleen de echte backup.sh aanroept. Dat wrapper script maak je dan suid mysql (permissions 4700)of je regelt dat met sudo (bijv sommige linux distros mogen alleen binaries suid zijn, en niet scripts). Dan zijn de mysql passwords in backup.sh op disk niet meer zichtbaar voor world.
je kunt ook proberen te voorkomen dat met ps ax of ps -ef de wachtwoorden worden gezien als het script met wachtwoorden als parameters worden uitgevoerd.
ik moet erbij zeggen dat ik weinig van linux weet maar graag wil leren. maar zie door de bomen het bos niet echt.
na 10 jaar unix leer je nog steeds bij.
update: zou het een stuk veiliger worden als ik in php check vanaf welk ip het php-script wordt uitgevoerd en vervolgens al dan niet het linux-script uitvoerd? of kunnen slimme mensen ook dit weer omzeilen?
vast wel maar dat moet je aan slimme mensen vragen :)

[ Voor 17% gewijzigd door arikkert op 12-10-2004 11:50 . Reden: altijd ff zoeken hoetzat met suid ]


  • js303
  • Registratie: April 2003
  • Laatst online: 25-01 14:14
wow veel tips. ik ga er even op studeren.

Verwijderd

Beveiligen van (het uitvoeren van) php scripts op ip-adres is heel makkelijk.
In een php script kan je heel makkelijk zien vanaf welk ip adres het aangeroepen wordt, dat is 1 variabele uit je http post vars.

Daarmee kun je dan weer heel makkelijk bepalen of je een script wel of niet uitvoert op grond van een (lijst met) ip adres(sen)

check wel even of je een vast ip hebt; met adsl is dat vrijwel altijd, maar als je inbelt of ik geloof ook sommige kabel providers, kun je soms een dhcp lease hebben en kun je dus ineens je script niet meer uitvoeren als je lease vervalt :)
Pagina: 1